[jira] [Updated] (FELIX-5351) 5.7 Coordinations
[ https://issues.apache.org/jira/browse/FELIX-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5351: Summary: 5.7 Coordinations (was: 5.7 Coordinates) > 5.7 Coordinations > - > > Key: FELIX-5351 > URL: https://issues.apache.org/jira/browse/FELIX-5351 > Project: Felix > Issue Type: Sub-task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > If configurations are created, updated or deleted and an implicit > coordination exists, Configuration Admin should > delay updating the ManagedService(Factory) until the coordination completes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5351) 5.7 Coordinates
Carsten Ziegeler created FELIX-5351: --- Summary: 5.7 Coordinates Key: FELIX-5351 URL: https://issues.apache.org/jira/browse/FELIX-5351 Project: Felix Issue Type: Sub-task Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: configadmin-1.9.0 If configurations are created, updated or deleted and an implicit coordination exists, Configuration Admin should delay updating the ManagedService(Factory) until the coordination completes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5294) Implement Configurator (RFC 218)
[ https://issues.apache.org/jira/browse/FELIX-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5294. - Resolution: Fixed Implementation moved to trunk - as well as the needed changes to configuration admin (see FELIX-5288) > Implement Configurator (RFC 218) > > > Key: FELIX-5294 > URL: https://issues.apache.org/jira/browse/FELIX-5294 > Project: Felix > Issue Type: Task > Components: Configurator >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configurator-1.0.0 > > > RFC 218 defines the Configurator service: an extender based mechanism to > provide configurations through YAML files in bundles -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5289) 5.1 PID Handling of Factory Configurations
[ https://issues.apache.org/jira/browse/FELIX-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5289. - Resolution: Fixed Moved the code to trunk > 5.1 PID Handling of Factory Configurations > -- > > Key: FELIX-5289 > URL: https://issues.apache.org/jira/browse/FELIX-5289 > Project: Felix > Issue Type: Sub-task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > There are two new methods defined in RFC 227 for getting factory > configurations (getFactoryConfiguration) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5288) Implement RFC 227 (R7 Update)
[ https://issues.apache.org/jira/browse/FELIX-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495515#comment-15495515 ] Carsten Ziegeler commented on FELIX-5288: - Moved the code to trunk > Implement RFC 227 (R7 Update) > - > > Key: FELIX-5288 > URL: https://issues.apache.org/jira/browse/FELIX-5288 > Project: Felix > Issue Type: Task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > This is a container issue for implementing the R7 updates as defined in RFC > 227. > I've created a branch at > https://svn.apache.org/repos/asf/felix/sandbox/cziegeler/configadmin-r7 to > implement the changes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5292) 5.4 Capabilities
[ https://issues.apache.org/jira/browse/FELIX-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5292. - Resolution: Fixed Moved the code to trunk > 5.4 Capabilities > > > Key: FELIX-5292 > URL: https://issues.apache.org/jira/browse/FELIX-5292 > Project: Felix > Issue Type: Sub-task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > Add osgi.implementation and osgi.service capability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5293) 5.5 Improved ConfigurationPlugin Support
[ https://issues.apache.org/jira/browse/FELIX-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5293. - Resolution: Fixed Moved the code to trunk > 5.5 Improved ConfigurationPlugin Support > > > Key: FELIX-5293 > URL: https://issues.apache.org/jira/browse/FELIX-5293 > Project: Felix > Issue Type: Sub-task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > A new method is added to the Configuration object to allow to call > configuration plugins -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5291) 5.3 Improving Configuration Updates
[ https://issues.apache.org/jira/browse/FELIX-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5291. - Resolution: Fixed Moved the code to trunk > 5.3 Improving Configuration Updates > --- > > Key: FELIX-5291 > URL: https://issues.apache.org/jira/browse/FELIX-5291 > Project: Felix > Issue Type: Sub-task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > A new method is added to the configuration object which only informs > listeners etc. if the configuration properties are different -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5290) 5.2 Locking Configuration Records
[ https://issues.apache.org/jira/browse/FELIX-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5290. - Resolution: Fixed Moved the code to trunk > 5.2 Locking Configuration Records > - > > Key: FELIX-5290 > URL: https://issues.apache.org/jira/browse/FELIX-5290 > Project: Felix > Issue Type: Sub-task > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > A new method for locking configurations is added to the Configuration object -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5328) NoClassDefFound not wrapped in the ClassScanner
[
https://issues.apache.org/jira/browse/FELIX-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5328.
-
Resolution: Fixed
Thanks for the patch, [~kwin]. I've applied a slightly modified version which
leaves the call to process() in the try/catch block. I'm not 100% but I think
to remember that a CNFE can be thrown from there as well
> NoClassDefFound not wrapped in the ClassScanner
> ---
>
> Key: FELIX-5328
> URL: https://issues.apache.org/jira/browse/FELIX-5328
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.14.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0, scr bnd plugin 1.6.0
>
>
> Unfortunately only {{ClassNotFoundException}} is wrapped in
> https://github.com/apache/felix/blob/trunk/tools/org.apache.felix.scr.generator/src/main/java/org/apache/felix/scrplugin/helper/ClassScanner.java#L148.
> Every other exception is not wrapped at all, making it very hard to figure
> out where an issue happened.
> An example stack trace of an error might look likes this
> {code}
> [ERROR] Bundle analyzing:java.lang.NoClassDefFoundError:
> javax/servlet/jsp/el/VariableResolver
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:144)
> at
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
> at
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
> at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
> at aQute.bnd.osgi.Builder.analyze(Builder.java:385)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
> at aQute.bnd.osgi.Builder.build(Builder.java:105)
> at
> org.apache.felix.bundleplugin.BundlePlugin.buildOSGiBundle(BundlePlugin.java:972)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:470)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:387)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:378)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(
[jira] [Resolved] (FELIX-5344) HTTP_WHITEBOARD_TARGET doesn't work reliably
[
https://issues.apache.org/jira/browse/FELIX-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5344.
-
Resolution: Fixed
> HTTP_WHITEBOARD_TARGET doesn't work reliably
>
>
> Key: FELIX-5344
> URL: https://issues.apache.org/jira/browse/FELIX-5344
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.12, http.jetty-3.2.4
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14
>
>
> I am trying to use HTTP_WHITEBOARD_TARGET to match a specific http instance:
> (I'm actually experimenting with multiple http instances, but the problem
> occurs with a single instance).
> @Component(service = Servlet.class,
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET +
> "=(org.osgi.service.http.port=)"
> })
> I am configuring http.jetty using config admin (via fileinstall)
> I have disabled automatic jetty startup using:
> org.apache.felix.http.enable=false
> Now I start jetty by dropping the file org.apache.felix.http.cfg into the
> fileinstall load directory:
> org.apache.felix.http.enable=true
> org.osgi.service.http.port=
> and my servlet is not always registered.
> This appears to be because WhiteboardManager.addWhiteboardService() is being
> called before the http service properties have been set.
> Here's the output of some debug I added to isMatchingService():
> XXXtarget =(org.osgi.service.http.port=) match=false
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
> It doesn't contain any endpoint properties.
> To prove this is a timing issue, I stopped and started my web bundle, which
> then registered correctly. The corresponding debug is:
> XXXtarget =(org.osgi.service.http.port=) match=true
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop org.apache.felix.http.enable=true
> XXXprop org.apache.felix.https.enable=false
> XXXprop org.osgi.service.http.port=
> XXXprop org.osgi.service.http.port.secure=8443
> XXXprop osgi.http.endpoint=[Ljava.lang.String;@1d1447fa
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-5344) HTTP_WHITEBOARD_TARGET doesn't work reliably
[
https://issues.apache.org/jira/browse/FELIX-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-5344:
---
Assignee: Carsten Ziegeler
> HTTP_WHITEBOARD_TARGET doesn't work reliably
>
>
> Key: FELIX-5344
> URL: https://issues.apache.org/jira/browse/FELIX-5344
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.12, http.jetty-3.2.4
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14
>
>
> I am trying to use HTTP_WHITEBOARD_TARGET to match a specific http instance:
> (I'm actually experimenting with multiple http instances, but the problem
> occurs with a single instance).
> @Component(service = Servlet.class,
> property = {
> HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET +
> "=(org.osgi.service.http.port=)"
> })
> I am configuring http.jetty using config admin (via fileinstall)
> I have disabled automatic jetty startup using:
> org.apache.felix.http.enable=false
> Now I start jetty by dropping the file org.apache.felix.http.cfg into the
> fileinstall load directory:
> org.apache.felix.http.enable=true
> org.osgi.service.http.port=
> and my servlet is not always registered.
> This appears to be because WhiteboardManager.addWhiteboardService() is being
> called before the http service properties have been set.
> Here's the output of some debug I added to isMatchingService():
> XXXtarget =(org.osgi.service.http.port=) match=false
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
> It doesn't contain any endpoint properties.
> To prove this is a timing issue, I stopped and started my web bundle, which
> then registered correctly. The corresponding debug is:
> XXXtarget =(org.osgi.service.http.port=) match=true
> XXXprop objectClass=[Ljava.lang.String;@292aebaf
> XXXprop org.apache.felix.http.enable=true
> XXXprop org.apache.felix.https.enable=false
> XXXprop org.osgi.service.http.port=
> XXXprop org.osgi.service.http.port.secure=8443
> XXXprop osgi.http.endpoint=[Ljava.lang.String;@1d1447fa
> XXXprop osgi.http.service.id=[60]
> XXXprop service.bundleid=22
> XXXprop service.id=61
> XXXprop service.scope=singleton
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-5350) Deprecate SCR Annotations
[ https://issues.apache.org/jira/browse/FELIX-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-5350. - Resolution: Fixed Added deprecation marker > Deprecate SCR Annotations > - > > Key: FELIX-5350 > URL: https://issues.apache.org/jira/browse/FELIX-5350 > Project: Felix > Issue Type: Task > Components: SCR Tooling >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: scr annotations 1.12.0 > > > We should deprecate the SCR annotations and make users move to the official > OSGi annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-5150) Add property to define output filename of generated component.xml
[ https://issues.apache.org/jira/browse/FELIX-5150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-5150: --- Assignee: Carsten Ziegeler > Add property to define output filename of generated component.xml > - > > Key: FELIX-5150 > URL: https://issues.apache.org/jira/browse/FELIX-5150 > Project: Felix > Issue Type: Bug > Components: SCR Tooling >Reporter: Marco Descher >Assignee: Carsten Ziegeler >Priority: Minor > > Using the maven-scr-plugin it is possible to divert the generation of > component.xml files into the OSGI-INF/ directory. It seems, however, not > possible to determine the generated filename, s.t. the full class name is > used as filename. > For readability I propose to add a property to only use the short class name > on generating the XML file, or to even be capable of providing a result > classname within the resp. Component annotation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5150) Add property to define output filename of generated component.xml
[ https://issues.apache.org/jira/browse/FELIX-5150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5150: Assignee: (was: Carsten Ziegeler) > Add property to define output filename of generated component.xml > - > > Key: FELIX-5150 > URL: https://issues.apache.org/jira/browse/FELIX-5150 > Project: Felix > Issue Type: Bug > Components: SCR Tooling >Reporter: Marco Descher >Priority: Minor > > Using the maven-scr-plugin it is possible to divert the generation of > component.xml files into the OSGI-INF/ directory. It seems, however, not > possible to determine the generated filename, s.t. the full class name is > used as filename. > For readability I propose to add a property to only use the short class name > on generating the XML file, or to even be capable of providing a result > classname within the resp. Component annotation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5350) Deprecate SCR Annotations
Carsten Ziegeler created FELIX-5350: --- Summary: Deprecate SCR Annotations Key: FELIX-5350 URL: https://issues.apache.org/jira/browse/FELIX-5350 Project: Felix Issue Type: Task Components: SCR Tooling Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: scr annotations 1.12.0 We should deprecate the SCR annotations and make users move to the official OSGi annotations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-5328) NoClassDefFound not wrapped in the ClassScanner
[
https://issues.apache.org/jira/browse/FELIX-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-5328:
---
Assignee: Carsten Ziegeler
> NoClassDefFound not wrapped in the ClassScanner
> ---
>
> Key: FELIX-5328
> URL: https://issues.apache.org/jira/browse/FELIX-5328
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.14.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0, scr bnd plugin 1.6.0
>
>
> Unfortunately only {{ClassNotFoundException}} is wrapped in
> https://github.com/apache/felix/blob/trunk/tools/org.apache.felix.scr.generator/src/main/java/org/apache/felix/scrplugin/helper/ClassScanner.java#L148.
> Every other exception is not wrapped at all, making it very hard to figure
> out where an issue happened.
> An example stack trace of an error might look likes this
> {code}
> [ERROR] Bundle analyzing:java.lang.NoClassDefFoundError:
> javax/servlet/jsp/el/VariableResolver
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:144)
> at
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
> at
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
> at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
> at aQute.bnd.osgi.Builder.analyze(Builder.java:385)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
> at aQute.bnd.osgi.Builder.build(Builder.java:105)
> at
> org.apache.felix.bundleplugin.BundlePlugin.buildOSGiBundle(BundlePlugin.java:972)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:470)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:387)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:378)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
[jira] [Updated] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5345:
Fix Version/s: scr bnd plugin 1.6.0
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0, scr bnd plugin 1.6.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5328) NoClassDefFound not wrapped in the ClassScanner
[
https://issues.apache.org/jira/browse/FELIX-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5328:
Fix Version/s: scr bnd plugin 1.6.0
> NoClassDefFound not wrapped in the ClassScanner
> ---
>
> Key: FELIX-5328
> URL: https://issues.apache.org/jira/browse/FELIX-5328
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.14.0
>Reporter: Konrad Windszus
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0, scr bnd plugin 1.6.0
>
>
> Unfortunately only {{ClassNotFoundException}} is wrapped in
> https://github.com/apache/felix/blob/trunk/tools/org.apache.felix.scr.generator/src/main/java/org/apache/felix/scrplugin/helper/ClassScanner.java#L148.
> Every other exception is not wrapped at all, making it very hard to figure
> out where an issue happened.
> An example stack trace of an error might look likes this
> {code}
> [ERROR] Bundle analyzing:java.lang.NoClassDefFoundError:
> javax/servlet/jsp/el/VariableResolver
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:144)
> at
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
> at
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
> at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
> at aQute.bnd.osgi.Builder.analyze(Builder.java:385)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
> at aQute.bnd.osgi.Builder.build(Builder.java:105)
> at
> org.apache.felix.bundleplugin.BundlePlugin.buildOSGiBundle(BundlePlugin.java:972)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:470)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:387)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:378)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassNotFo
[jira] [Updated] (FELIX-5328) NoClassDefFound not wrapped in the ClassScanner
[
https://issues.apache.org/jira/browse/FELIX-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5328:
Fix Version/s: scr generator 1.15.0
scr ant task 1.16.0
maven-scr-plugin 1.23.0
> NoClassDefFound not wrapped in the ClassScanner
> ---
>
> Key: FELIX-5328
> URL: https://issues.apache.org/jira/browse/FELIX-5328
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.14.0
>Reporter: Konrad Windszus
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0, scr bnd plugin 1.6.0
>
>
> Unfortunately only {{ClassNotFoundException}} is wrapped in
> https://github.com/apache/felix/blob/trunk/tools/org.apache.felix.scr.generator/src/main/java/org/apache/felix/scrplugin/helper/ClassScanner.java#L148.
> Every other exception is not wrapped at all, making it very hard to figure
> out where an issue happened.
> An example stack trace of an error might look likes this
> {code}
> [ERROR] Bundle analyzing:java.lang.NoClassDefFoundError:
> javax/servlet/jsp/el/VariableResolver
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:144)
> at
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
> at
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
> at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
> at aQute.bnd.osgi.Builder.analyze(Builder.java:385)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
> at aQute.bnd.osgi.Builder.build(Builder.java:105)
> at
> org.apache.felix.bundleplugin.BundlePlugin.buildOSGiBundle(BundlePlugin.java:972)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:470)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:387)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:378)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.class
[jira] [Resolved] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5345.
-
Resolution: Fixed
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495133#comment-15495133 ] Carsten Ziegeler commented on FELIX-5349: - Thanks for your patch, [~db82407] Really appreciated. If I see it correctly, you're using the same PID for the existing configuration and for the factory configurations - which means that this is fully compatible with what we have today. I'm wondering if we should enforce the name property for factory configurations and do some checking like if the same name is used twice? > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6 > > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-5349: --- Assignee: Carsten Ziegeler > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6 > > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-5349: Fix Version/s: http.jetty-3.2.6 http.base-3.0.14 > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Priority: Minor > Fix For: http.base-3.0.14, http.jetty-3.2.6 > > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-5346) Start annotation not propagated to sub classes
[
https://issues.apache.org/jira/browse/FELIX-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494761#comment-15494761
]
Pierre De Rop edited comment on FELIX-5346 at 9/15/16 10:52 PM:
Jago,
can you please give a try to this attached patch (the svn diff has been done in
the dependencymanager/ directory on
org.apache.felix.dependencymanager.annotation sub project).
Notice that it should also work with scala (the scanner stops scanning
inherited class if the class is "java.lang.object" or "scala/ScalaObject")
the remaining things to implement are:
1) possibly detect if the inherited class is outside the bundle of the
extension class. but I'm not sure it's possible. if it's possible then I think
an error should be thrown, in order to avoid potential issues (like BJ
explained in his post).
2) ignores inherited annotation in case they are overriden in child/extension
class
for example:
{code}
class Base {
@Start
void init() {}
}
class Extension extends Base {
@Start
void anotherStart() {}
}
{code}
currently, the patch uses the inherited @Start, not the one from the extension
class (will do that a bit later).
In the meantime, I would be interested to know if it works in your environment ?
thank you.
was (Author: pderop):
Jago,
can you please give a try to this attached patch (the svn diff has been done in
the dependencymanager/ directory on
org.apache.felix.dependencymanager.annotation sub project).
Notice that it should also work with scala (the scanner stops scanning
inherited class if the class is "java.lang.object" or "scala/ScalaObject")
the remaining things to implement are:
1) possibly detect if the inherited class is outside the bundle of the
extension class. but I'm not sure it's possible. if it's possible then I think
an error should be thrown, in order to avoid potential issues (like BJ
explained in his post).
2) ignores inherited annotation in case they are overriden in child/extension
class
for example:
{code}
class Base {
@Start
void init() {}
}
class Extension extends Base {
@Start
void anotherStart() {}
}
{code}
currently, the patch uses the inherited @Init, not the one from the extension
class (will do that a bit later).
In the meantime, I would be interested to know if it works in your environment ?
thank you.
> Start annotation not propagated to sub classes
> --
>
> Key: FELIX-5346
> URL: https://issues.apache.org/jira/browse/FELIX-5346
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Reporter: Jago de Vreede
>Assignee: Pierre De Rop
> Attachments: FELIX-5346.patch
>
>
> Following case in pseudocode:
> {code}Class A {
> @Start
> public void start() {
> System.out.println("start");
> }
> }
> @Component
> Class B extends A {
> }{code}
> When you run this nothing is printed but the start method in A should be
> called as B extends A.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5346) Start annotation not propagated to sub classes
[
https://issues.apache.org/jira/browse/FELIX-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5346:
-
Attachment: FELIX-5346.patch
Attached the initial patch (more work to be done).
> Start annotation not propagated to sub classes
> --
>
> Key: FELIX-5346
> URL: https://issues.apache.org/jira/browse/FELIX-5346
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Reporter: Jago de Vreede
>Assignee: Pierre De Rop
> Attachments: FELIX-5346.patch
>
>
> Following case in pseudocode:
> {code}Class A {
> @Start
> public void start() {
> System.out.println("start");
> }
> }
> @Component
> Class B extends A {
> }{code}
> When you run this nothing is printed but the start method in A should be
> called as B extends A.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5346) Start annotation not propagated to sub classes
[
https://issues.apache.org/jira/browse/FELIX-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494761#comment-15494761
]
Pierre De Rop commented on FELIX-5346:
--
Jago,
can you please give a try to this attached patch (the svn diff has been done in
the dependencymanager/ directory on
org.apache.felix.dependencymanager.annotation sub project).
Notice that it should also work with scala (the scanner stops scanning
inherited class if the class is "java.lang.object" or "scala/ScalaObject")
the remaining things to implement are:
1) possibly detect if the inherited class is outside the bundle of the
extension class. but I'm not sure it's possible. if it's possible then I think
an error should be thrown, in order to avoid potential issues (like BJ
explained in his post).
2) ignores inherited annotation in case they are overriden in child/extension
class
for example:
{code}
class Base {
@Start
void init() {}
}
class Extension extends Base {
@Start
void anotherStart() {}
}
{code}
currently, the patch uses the inherited @Init, not the one from the extension
class (will do that a bit later).
In the meantime, I would be interested to know if it works in your environment ?
thank you.
> Start annotation not propagated to sub classes
> --
>
> Key: FELIX-5346
> URL: https://issues.apache.org/jira/browse/FELIX-5346
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Reporter: Jago de Vreede
>Assignee: Pierre De Rop
>
> Following case in pseudocode:
> {code}Class A {
> @Start
> public void start() {
> System.out.println("start");
> }
> }
> @Component
> Class B extends A {
> }{code}
> When you run this nothing is printed but the start method in A should be
> called as B extends A.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5349) add ManagedServiceFactory to HTTP service
Derek Baum created FELIX-5349: - Summary: add ManagedServiceFactory to HTTP service Key: FELIX-5349 URL: https://issues.apache.org/jira/browse/FELIX-5349 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http.jetty-3.2.4, http.base-3.0.12 Reporter: Derek Baum Priority: Minor I need to run multiple HTTP services, with different configurations. I was surprised to find that felix.http.jetty does not provide a ManagedServiceFactory and so were others as indicated in this stack overflow conversation: http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports I have experimented with creating a ManagedServiceFactory for the HTTP service myself. It is difficult to do externally to the http.jetty bundle, as it requires access to internal packages. I have therefore created a small patch to revision 1760954 which adds a ManagedServiceFactory, without changing any of the existing functionality of the ManagedService. This allows multiple http.jetty instances to be configured using WebConsole, fileinstall or other config admin clients. I have also added a new configuration property: org.apache.felix.http.name, which is added as a service property to the HTTP runtime instance. This makes it easier to target a specific HTTP whiteboard service than filtering on the port: HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5349) add ManagedServiceFactory to HTTP service
[ https://issues.apache.org/jira/browse/FELIX-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum updated FELIX-5349: -- Attachment: factory.patch patch to implement FELIX-5349 > add ManagedServiceFactory to HTTP service > - > > Key: FELIX-5349 > URL: https://issues.apache.org/jira/browse/FELIX-5349 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http.base-3.0.12, http.jetty-3.2.4 >Reporter: Derek Baum >Priority: Minor > Attachments: factory.patch > > > I need to run multiple HTTP services, with different configurations. > I was surprised to find that felix.http.jetty does not provide a > ManagedServiceFactory and so were others as indicated in this stack overflow > conversation: > http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports > I have experimented with creating a ManagedServiceFactory for the HTTP > service myself. It is difficult to do externally to the http.jetty bundle, as > it requires access to internal packages. > I have therefore created a small patch to revision 1760954 which adds a > ManagedServiceFactory, without changing any of the existing functionality of > the ManagedService. This allows multiple http.jetty instances to be > configured using WebConsole, fileinstall or other config admin clients. > I have also added a new configuration property: org.apache.felix.http.name, > which is added as a service property to the HTTP runtime instance. This makes > it easier to target a specific HTTP whiteboard service than filtering on the > port: > HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)" > I would be grateful if you would consider adding this functionality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493594#comment-15493594
]
Sergey B. commented on FELIX-5345:
--
Now the problem is fixed.
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493436#comment-15493436
]
Carsten Ziegeler commented on FELIX-5345:
-
Good point, I've changed the code accordingly
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493339#comment-15493339
]
Sergey B. commented on FELIX-5345:
--
Nothing has changed. Please, note that properties file format allows only
ISO8859-1 encoding.
https://docs.oracle.com/javase/6/docs/api/java/util/Properties.html
The issue was not in that encoding is platform-dependent, but that it was other
than ISO8859-1.
If one uses method store(OutputStream), class Properties makes character
escaping. When the method store(Writer) it is the responsibility of user.
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5348) [HTTP Service] Location not URL Encoded during Redirect
Dominique Jäggi created FELIX-5348:
--
Summary: [HTTP Service] Location not URL Encoded during Redirect
Key: FELIX-5348
URL: https://issues.apache.org/jira/browse/FELIX-5348
Project: Felix
Issue Type: Bug
Components: HTTP Service
Reporter: Dominique Jäggi
With SSL forwarding enabled, a _sendRedirect_ will not properly encode the
resulting location header value:
{noformat}
> GET /?$$bla$$=test HTTP/1.1
> Host: localhost:4502
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.49.1
> Accept: */*
> X-Forwarded-SSL:on
>
< HTTP/1.1 302 Found
< Location: https://localhost/index.html?$$bla$$=test
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{noformat}
Non-SSL-forwarded requests result in properly encoded location header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-5345:
---
Assignee: Carsten Ziegeler
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15492792#comment-15492792
]
Carsten Ziegeler commented on FELIX-5345:
-
Thanks for reporting, I've committed a potential fix, could you please give
this a try?
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5345) Incorrect encoding in metatype props file
[
https://issues.apache.org/jira/browse/FELIX-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-5345:
Fix Version/s: scr generator 1.15.0
scr ant task 1.16.0
maven-scr-plugin 1.23.0
> Incorrect encoding in metatype props file
> -
>
> Key: FELIX-5345
> URL: https://issues.apache.org/jira/browse/FELIX-5345
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.8.0
>Reporter: Sergey B.
> Fix For: maven-scr-plugin 1.23.0, scr ant task 1.16.0, scr
> generator 1.15.0
>
> Attachments: MetaTypeIO.patch, pom.xml
>
>
> maven-scr-plugin generates metatype properties file in incorrect encoding.
> Steps to reproduce:
> 1. Create component with non-ascii label
> {code:java}
> import org.apache.felix.scr.annotations.Component;
> @Component(
> metatype = true,
> label = "Какие-то буквы",
> description = "Какие-то буквы")
> public class Reproduce {
> //
> }
> {code}
> 2. Make bundle using maven-scr-plugin 1.14 or higher
> 3. Deploy to Apache Felix
> 4. Go to configuration page of Felix Web Console
> Expected result
> 1. There is component with correct name
> Actual
> 1. Component name is scrumbled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5347) Fileinstall metatype information does not reflect the fact that FileInstall uses a ManagedServiceFactory
Guillaume Nodet created FELIX-5347: -- Summary: Fileinstall metatype information does not reflect the fact that FileInstall uses a ManagedServiceFactory Key: FELIX-5347 URL: https://issues.apache.org/jira/browse/FELIX-5347 Project: Felix Issue Type: Bug Components: File Install Reporter: Guillaume Nodet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
