[jira] [Created] (FELIX-3000) Move sending service registered event out of bundle lock
Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.2.2, framework-3.0.7 Reporter: Felix Meschberger We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock: 127.0.0.1 [1305717927375] GET /xxx.html HTTP/1.0 daemon prio=3 tid=0x000106203000 nid=0x2c01b in Object.wait() [0x7ffe939f7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4712) - locked 0x7ffeabca9908 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix$FelixResolver.markBundleResolved(Felix.java:4220) at org.apache.felix.framework.Felix$FelixResolver.markResolvedModules(Felix.java:4200) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:3999) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3402) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1594) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904) at org.apache.sling.commons.classloader.impl.PackageAdminClassLoader.findClass(PackageAdminClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) - locked 0x7ffecc57d040 (a org.apache.sling.commons.classloader.impl.PackageAdminClassLoader) at org.apache.sling.commons.classloader.impl.PackageAdminClassLoader.loadClass(PackageAdminClassLoader.java:174) at java.lang.ClassLoader.loadClass(ClassLoader.java:296) - locked 0x7ffecc58b260 (a org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.jsp.apps.wci.components.page.page.page_jsp._jspService(page_jsp.java:170) at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.sling.scripting.jsp.JspServletWrapperAdapter.service(JspServletWrapperAdapter.java:59) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:173) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:84) ... ObservationManager daemon prio=3 tid=0x00010232e000 nid=0x30 in Object.wait() [0x7ffef24fe000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4785) - locked 0x7ffeabca9908 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.access$400(Felix.java:80) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4043) at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412) at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734) at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:544) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:275) at org.apache.felix.framework.Felix.getServiceReferences(Felix.java:2920) at org.apache.felix.framework.Felix.getAllowedServiceReferences(Felix.java:2970) at org.apache.felix.framework.BundleContextImpl.getServiceReferences(BundleContextImpl.java:309) at org.apache.felix.eventadmin.impl.handler.BlacklistingHandlerTasks.createHandlerTasks(BlacklistingHandlerTasks.java:102) at org.apache.felix.eventadmin.impl.EventAdminImpl.postEvent(EventAdminImpl.java:92) at org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.postEvent(EventAdminSecurityDecorator.java:77) at org.apache.sling.jcr.resource.internal.JcrResourceListener.sendOsgiEvent(JcrResourceListener.java:224) at
[jira] [Created] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Derek Baum Priority: Minor java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3000: - Attachment: FELIX-3000-stacktrace.txt Stacktrace to replace the inline stacktrace from the description Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock: 127.0.0.1 [1305717927375] GET /xxx.html HTTP/1.0 daemon prio=3 tid=0x000106203000 nid=0x2c01b in Object.wait() [0x7ffe939f7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4712) - locked 0x7ffeabca9908 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix$FelixResolver.markBundleResolved(Felix.java:4220) at org.apache.felix.framework.Felix$FelixResolver.markResolvedModules(Felix.java:4200) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:3999) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3402) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1594) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904) at org.apache.sling.commons.classloader.impl.PackageAdminClassLoader.findClass(PackageAdminClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) - locked 0x7ffecc57d040 (a org.apache.sling.commons.classloader.impl.PackageAdminClassLoader) at org.apache.sling.commons.classloader.impl.PackageAdminClassLoader.loadClass(PackageAdminClassLoader.java:174) at java.lang.ClassLoader.loadClass(ClassLoader.java:296) - locked 0x7ffecc58b260 (a org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.jsp.apps.wci.components.page.page.page_jsp._jspService(page_jsp.java:170) at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.sling.scripting.jsp.JspServletWrapperAdapter.service(JspServletWrapperAdapter.java:59) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:173) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:84) ... ObservationManager daemon prio=3 tid=0x00010232e000 nid=0x30 in Object.wait() [0x7ffef24fe000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4785) - locked 0x7ffeabca9908 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.access$400(Felix.java:80) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4043) at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412) at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734) at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:544) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:275) at org.apache.felix.framework.Felix.getServiceReferences(Felix.java:2920) at org.apache.felix.framework.Felix.getAllowedServiceReferences(Felix.java:2970) at org.apache.felix.framework.BundleContextImpl.getServiceReferences(BundleContextImpl.java:309) at
[jira] [Updated] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3000: - Description: We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. was: We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock: 127.0.0.1 [1305717927375] GET /xxx.html HTTP/1.0 daemon prio=3 tid=0x000106203000 nid=0x2c01b in Object.wait() [0x7ffe939f7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4712) - locked 0x7ffeabca9908 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix$FelixResolver.markBundleResolved(Felix.java:4220) at org.apache.felix.framework.Felix$FelixResolver.markResolvedModules(Felix.java:4200) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:3999) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3402) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1594) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904) at org.apache.sling.commons.classloader.impl.PackageAdminClassLoader.findClass(PackageAdminClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) - locked 0x7ffecc57d040 (a org.apache.sling.commons.classloader.impl.PackageAdminClassLoader) at org.apache.sling.commons.classloader.impl.PackageAdminClassLoader.loadClass(PackageAdminClassLoader.java:174) at java.lang.ClassLoader.loadClass(ClassLoader.java:296) - locked 0x7ffecc58b260 (a org.apache.sling.jcr.classloader.internal.DynamicRepositoryClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.jsp.apps.wci.components.page.page.page_jsp._jspService(page_jsp.java:170) at org.apache.sling.scripting.jsp.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.sling.scripting.jsp.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.sling.scripting.jsp.JspServletWrapperAdapter.service(JspServletWrapperAdapter.java:59) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.callJsp(JspScriptEngineFactory.java:173) at org.apache.sling.scripting.jsp.JspScriptEngineFactory.access$100(JspScriptEngineFactory.java:84) ... ObservationManager daemon prio=3 tid=0x00010232e000 nid=0x30 in Object.wait() [0x7ffef24fe000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:4785) - locked 0x7ffeabca9908 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.access$400(Felix.java:80) at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4043) at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412) at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734) at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:544) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:275) at org.apache.felix.framework.Felix.getServiceReferences(Felix.java:2920) at
[jira] [Assigned] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum reassigned FELIX-3001: - Assignee: Derek Baum [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Derek Baum Assignee: Derek Baum Priority: Minor java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3001 started by Derek Baum. [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Derek Baum Assignee: Derek Baum Priority: Minor java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-3001. --- Resolution: Fixed [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Derek Baum Assignee: Derek Baum Priority: Minor java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3002) Embed the OBR specific information for the EventAdmin bundle in the manifest
Embed the OBR specific information for the EventAdmin bundle in the manifest Key: FELIX-3002 URL: https://issues.apache.org/jira/browse/FELIX-3002 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.2.12 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: eventadmin-1.2.14 So that the OBR information generated by the maven-bundle-plugin bindex goal is correct -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2919) Aggregate sources when aggregate binaries
[ https://issues.apache.org/jira/browse/FELIX-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-2919: Fix Version/s: (was: maven-bundle-plugin-2.3.6) Doing some rescheduling Aggregate sources when aggregate binaries - Key: FELIX-2919 URL: https://issues.apache.org/jira/browse/FELIX-2919 Project: Felix Issue Type: New Feature Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Stephane Chomat Original Estimate: 720h Remaining Estimate: 720h maven bundle plugin allows to aggregate binaries but it doesn't aggregate source when it's possible. Add this action on goal source:jar and a configuration to activate this feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2920) Check a list of bundles to see if all bundles can be resolved when its will deploy on osgi framework.
[ https://issues.apache.org/jira/browse/FELIX-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-2920: Fix Version/s: (was: maven-bundle-plugin-2.3.6) Doing some rescheduling Check a list of bundles to see if all bundles can be resolved when its will deploy on osgi framework. - Key: FELIX-2920 URL: https://issues.apache.org/jira/browse/FELIX-2920 Project: Felix Issue Type: New Feature Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Stephane Chomat Original Estimate: 720h Remaining Estimate: 720h It's helpfull to add another goal checkConfig to check a configurations of bundles with the bundle 0 to see if all bundles can be resovled and reports some warning or errors like a package exported by two bundles, a package exported by a bundle less version and by another with a version It's a test to see if these bundles can be started on a osgi configuration. You can use felix implemention to do it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3002) Embed the OBR specific information for the EventAdmin bundle in the manifest
[ https://issues.apache.org/jira/browse/FELIX-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-3002. Resolution: Fixed Embed the OBR specific information for the EventAdmin bundle in the manifest Key: FELIX-3002 URL: https://issues.apache.org/jira/browse/FELIX-3002 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.2.12 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: eventadmin-1.2.14 So that the OBR information generated by the maven-bundle-plugin bindex goal is correct -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2765) bundle plugin throw IllegalArgumentException while do the install
[ https://issues.apache.org/jira/browse/FELIX-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050407#comment-13050407 ] Stuart McCulloch commented on FELIX-2765: - Any chance of getting a test project that recreates the error? Or at least an idea of the project layout / bundle instructions, since I haven't managed to recreate this locally. bundle plugin throw IllegalArgumentException while do the install - Key: FELIX-2765 URL: https://issues.apache.org/jira/browse/FELIX-2765 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.0.1 Environment: maven3 on win os Reporter: Zeng.haojie Priority: Blocker [ERROR] An internal error occurred java.lang.IllegalArgumentException: Cannot write resource: res/images/wired.gif aQute.lib.osgi.PreprocessResource@106121 exception: java.io.IOException: Opening resource at aQute.lib.osgi.Jar.writeResource(Jar.java:302) at aQute.lib.osgi.Jar.write(Jar.java:211) at aQute.lib.osgi.Jar.write(Jar.java:182) at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:313) at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:238) at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:229) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050443#comment-13050443 ] Andrei Pozolotin commented on FELIX-2993: - I think I've got a better idea :-) (from the embedder point of view) I suggest: 1) break down osgi compendium into subset api bundles which address only specific part of osgi spec; for exaple: one for framework security, one for event admin, etc these api bundles will only export interfaces support classes 2) along with current monolithic bundles (which carry both api and impl) you have for framework security, for event admin, etc, start producing embedder friendly, reduced bundles, which do NOT carry osgi spec api, and instead expect to import corresponding osgi api from some other external provider (such as embedders' framwork host); 3) in this way an embedder can carry osgi api within the framework host (say, security api, events api), and export these osgi api for the reduced bundles (which might not be present); this allows an embedder to make RUN-time, NOT build-time decision whether to load or not: security or events, etc bundle, and still be able to use security and events inside the embedder host if the provider bundle is present; so this suggestion is basically a more flexible way to deal with: http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-hostserviceusage the fact that both the host application and the bundle must be using the same class definitions for the service interface classes jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050451#comment-13050451 ] Richard S. Hall commented on FELIX-2993: It just sounds like more work to maintain all of these little artifacts for little benefit. You can just use bnd or maven-bundle-plugin, as we already do, to depend on the compendium JAR and slice up and pull into your own project whichever API packages you need. Pretty much all the Felix bundles (e.g., Event Admin, etc.) do exactly that. With bnd, it is all about slicing and dicing what is on your project class path to creating a resulting JAR file. I think you need to quit thinking in terms of JAR files and just start thinking in terms of which packages do you want in your JAR file. jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050461#comment-13050461 ] Andrei Pozolotin commented on FELIX-2993: - re: think you need to quit thinking in terms of JAR files - you are right; will do! :-) except I do not see how can I resolve the following: even if my host slices/dices exports events api, current felix event admin bundle still will not see / will not use my host export? jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2873) Dependencies with 'provided' scope gets added to the 'Export-Package' directive while they shouldn't
[
https://issues.apache.org/jira/browse/FELIX-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-2873.
-
Resolution: Invalid
Assignee: Stuart McCulloch
The observed change in behaviour is due to FELIX-2817 which fixed the manifest
goal to honor the supportedProjectTypes configuration setting. This change
means that the manifest goal now does a full bnd analysis to generate the
manifest whereas originally it did a quick analysis, which skipped checking the
full project classpath.
The problem is in the example bundle instructions, it has:
{code}
Export-Package*/Export-Package
{code}
Which tells bnd to export the complete project classpath - this includes
compile, runtime, _and_ provided dependencies. Instead it should use:
{code}
_exportcontents*/_exportcontents
{code}
Which tells bnd to export whatever ends up packaged inside the bundle (ie. not
the full project classpath).
Also note that because you have a maven-jar-plugin entry which pulls the
generated META-INF/MANIFEST.MF back in before the bundleplugin runs you
should remove this file so that bnd can re-generate it from scratch (otherwise
it will pick up the existing instructions and you will likely end up with the
same results).
Dependencies with 'provided' scope gets added to the 'Export-Package'
directive while they shouldn't
Key: FELIX-2873
URL: https://issues.apache.org/jira/browse/FELIX-2873
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.3.4
Reporter: Pierre-Arnaud Marcelot
Assignee: Stuart McCulloch
Priority: Blocker
Attachments: MANIFEST.MF, pom.xml
Since version 3.2.4, the plugin adds dependencies with 'provided' scope to
the 'Export-Package' directive even when Embed-Dependency only includes
'compile' or/and 'runtime' scopes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-2873) Dependencies with 'provided' scope gets added to the 'Export-Package' directive while they shouldn't
[
https://issues.apache.org/jira/browse/FELIX-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050466#comment-13050466
]
Stuart McCulloch edited comment on FELIX-2873 at 6/16/11 2:46 PM:
--
The observed change in behaviour is due to FELIX-2817 which fixed the manifest
goal to honor the supportedProjectTypes configuration setting. This change
means that the manifest goal now does a full bnd analysis to generate the
manifest whereas originally it did a quick analysis, which skipped checking the
full project classpath.
The problem is in the example bundle instructions, it has:
Export-Package*/Export-Package
Which tells bnd to export the complete project classpath - this includes
compile, runtime, _and_ provided dependencies. Instead it should use:
_exportcontents*/_exportcontents
Which tells bnd to export whatever ends up packaged inside the bundle (ie. not
the full project classpath).
Also note that because you have a maven-jar-plugin entry which pulls the
generated META-INF/MANIFEST.MF back in before the bundleplugin runs you
should remove this file so that bnd can re-generate it from scratch (otherwise
it will pick up the existing instructions and you will likely end up with the
same results).
was (Author: mcculls):
The observed change in behaviour is due to FELIX-2817 which fixed the
manifest goal to honor the supportedProjectTypes configuration setting. This
change means that the manifest goal now does a full bnd analysis to generate
the manifest whereas originally it did a quick analysis, which skipped checking
the full project classpath.
The problem is in the example bundle instructions, it has:
{code}
Export-Package*/Export-Package
{code}
Which tells bnd to export the complete project classpath - this includes
compile, runtime, _and_ provided dependencies. Instead it should use:
{code}
_exportcontents*/_exportcontents
{code}
Which tells bnd to export whatever ends up packaged inside the bundle (ie. not
the full project classpath).
Also note that because you have a maven-jar-plugin entry which pulls the
generated META-INF/MANIFEST.MF back in before the bundleplugin runs you
should remove this file so that bnd can re-generate it from scratch (otherwise
it will pick up the existing instructions and you will likely end up with the
same results).
Dependencies with 'provided' scope gets added to the 'Export-Package'
directive while they shouldn't
Key: FELIX-2873
URL: https://issues.apache.org/jira/browse/FELIX-2873
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.3.4
Reporter: Pierre-Arnaud Marcelot
Assignee: Stuart McCulloch
Priority: Blocker
Attachments: MANIFEST.MF, pom.xml
Since version 3.2.4, the plugin adds dependencies with 'provided' scope to
the 'Export-Package' directive even when Embed-Dependency only includes
'compile' or/and 'runtime' scopes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2355) [Gogo] Closures and scopes should be handled in a fashion similar to normal commands
[ https://issues.apache.org/jira/browse/FELIX-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2355: --- Fix Version/s: (was: gogo.runtime-0.10.0) gogo.runtime-0.12.0 [Gogo] Closures and scopes should be handled in a fashion similar to normal commands Key: FELIX-2355 URL: https://issues.apache.org/jira/browse/FELIX-2355 Project: Felix Issue Type: Improvement Components: Gogo Runtime Affects Versions: gogo-0.6.0 Reporter: Richard S. Hall Fix For: gogo.runtime-0.12.0 Currently, closures are treated differently when it comes to scopes than normal commands. It would be better if they were assigned an explicit default scope if none were specified and that scope could be placed in the scope path as desired. Likewise if the scope for a closure is explicitly specified when creating the closure. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2536) Gogo Shell should export org.apache.felix.gogo.options package
[
https://issues.apache.org/jira/browse/FELIX-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-2536:
---
Fix Version/s: (was: gogo.shell-0.10.0)
gogo.shell-0.12.0
Gogo Shell should export org.apache.felix.gogo.options package
--
Key: FELIX-2536
URL: https://issues.apache.org/jira/browse/FELIX-2536
Project: Felix
Issue Type: Improvement
Components: Gogo Shell
Reporter: David Savage
Priority: Minor
Fix For: gogo.shell-0.12.0
The Gogo shell bundle includes a helpful utility class to handle Options
parsing in the gogo environment.
org.apache.felix.gogo.options.Options
final String[] usage = {
test - test Options usage,
text before Usage: is displayed when usage() is called and no
error has occurred.,
so can be used as a simple help message.,
,
Usage: testOptions [OPTION]... PATTERN [FILES]...,
Output control: arbitary non-option text can be included.,
-? --helpshow help,
-c --count=COUNT show COUNT lines,
-h --no-filename suppress the prefixing filename on
output,
-q --quiet, --silent suppress all normal output,
--binary-files=TYPE assume that binary files are TYPE,
TYPE is 'binary', 'text', or
'without-match',
-I equivalent to
--binary-files=without-match,
-d --directories=ACTION how to handle directories
(default=skip),
ACTION is 'read', 'recurse', or
'skip',
-D --devices=ACTION how to handle devices, FIFOs and
sockets,
ACTION is 'read' or 'skip',
-R, -r --recursive equivalent to --directories=recurse
};
Option opt = Options.compile(usage).parse(args);
if (opt.isSet(help)) {
opt.usage(); // includes text before Usage:
return;
}
if (opt.args().size() == 0)
throw opt.usageError(PATTERN not specified);
System.out.println(opt);
if (opt.isSet(count))
System.out.println(count = + opt.getNumber(count));
System.out.println(--directories specified: +
opt.isSet(directories));
System.out.println(directories= + opt.get(directories));
However the package containing this class is not exported from this bundle so
it cannot be used by client code
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2340) Combine type and help commands into a single help facility
[ https://issues.apache.org/jira/browse/FELIX-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2340: --- Fix Version/s: (was: gogo.shell-0.10.0) (was: gogo.command-0.10.0) gogo.command-0.12.0 gogo.shell-0.12.0 Combine type and help commands into a single help facility -- Key: FELIX-2340 URL: https://issues.apache.org/jira/browse/FELIX-2340 Project: Felix Issue Type: Improvement Components: Gogo Command, Gogo Shell Affects Versions: gogo-0.6.0 Reporter: Richard S. Hall Fix For: gogo.shell-0.12.0, gogo.command-0.12.0 Currently, we have a type command for exploring existing commands and I've implemented a help command in the felixcommands module. They serve slightly different purposes, but I think it would be fairly straightforward to combine them into a single help facility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2662) [Gogo] Consider more fully qualified configuration property names
[ https://issues.apache.org/jira/browse/FELIX-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2662: --- Fix Version/s: (was: gogo.shell-0.10.0) gogo.shell-0.12.0 [Gogo] Consider more fully qualified configuration property names - Key: FELIX-2662 URL: https://issues.apache.org/jira/browse/FELIX-2662 Project: Felix Issue Type: Task Components: Gogo Shell Affects Versions: gogo-0.6.1 Reporter: Richard S. Hall Priority: Minor Fix For: gogo.shell-0.12.0 I am not sure if this applies to the other Gogo modules, but Gogo Shell uses configuration property names like gosh.args and gosh.home, but these should likely be more fully qualified names. For the framework, we've typically used names like felix.* although one could argue for org.apache.felix.*...I think the former is sufficient. For the precise names, it is not clear if they should be felix.gosh.args or felix.gogo.shell.args...I assume if the runtime has config properties they would be felix.gogo.runtime.*... We just need to think about this and make things consistent and meaningful. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2910) Regression: maven-bundle-plugin 2.3.4 is ignoring individual entries in custom MANIFEST.MF
[ https://issues.apache.org/jira/browse/FELIX-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch resolved FELIX-2910. - Resolution: Won't Fix Assignee: Stuart McCulloch According to bnd docs, included files ending in .mf are parsed as manifests - so you should be able to _include manifests. However I cannot recreate the missing entries given your example manifest because bnd always throws an error about the Name sections: Your bnd file contains a header called 'Name'. This interferes with the manifest name section. This suggests that bnd intentionally disallows including manifest files with Name sections. However, you can workaround this by using a separate feature of the bundleplugin that merges the bnd generated manifest with a configured maven manifest. Just add the following plugin entry: plugin artifactIdmaven-jar-plugin/artifactId configuration archive manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile /archive /configuration /plugin and put your custom manifest in src/main/resources/META-INF/MANIFEST.MF. The final bundle should then contain the generated OSGi metadata along with the Name sections from your manifest. Regression: maven-bundle-plugin 2.3.4 is ignoring individual entries in custom MANIFEST.MF -- Key: FELIX-2910 URL: https://issues.apache.org/jira/browse/FELIX-2910 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Jörg Waßmer Assignee: Stuart McCulloch Priority: Critical I tell the plugin to use a custom manifest via the _include option. Version 2.2.0 of the plugin correctly copies all entries from the specified manifest to the one generated by the plugin. Version 2.3.4 is skipping all manifest entries that are related to individual packages and classes. For example: Name: foo/bar Sealed: true Name: foo/bar/Bean.class Java-Bean: true Name: foo/bar/Bean2.class Java-Bean: true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2910) Regression: maven-bundle-plugin 2.3.4 is ignoring individual entries in custom MANIFEST.MF
[ https://issues.apache.org/jira/browse/FELIX-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050493#comment-13050493 ] Stuart McCulloch commented on FELIX-2910: - Note that I get the same error about the Name sections with 2.2.0, so I can't see how this was working with 2.2.0 If you have a test project (pom+instructions) that did work with 2.2.0 please attach it to this issue, in case there is anything else we can do. But for now the easiest way to merge manifests is to take advantage of the above bundleplugin feature (where it looks at the maven-jar-plugin configuration and merges with that). Any other change would require a change to bnd, but as I mentioned above the explicit error message does suggest that bnd deliberately disallows including files with Name sections... Regression: maven-bundle-plugin 2.3.4 is ignoring individual entries in custom MANIFEST.MF -- Key: FELIX-2910 URL: https://issues.apache.org/jira/browse/FELIX-2910 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Jörg Waßmer Assignee: Stuart McCulloch Priority: Critical I tell the plugin to use a custom manifest via the _include option. Version 2.2.0 of the plugin correctly copies all entries from the specified manifest to the one generated by the plugin. Version 2.3.4 is skipping all manifest entries that are related to individual packages and classes. For example: Name: foo/bar Sealed: true Name: foo/bar/Bean.class Java-Bean: true Name: foo/bar/Bean2.class Java-Bean: true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-2937) [Gogo Command] OBR commands do not output anything when nothing is found
[ https://issues.apache.org/jira/browse/FELIX-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2937. -- Resolution: Fixed changed summary [Gogo Command] OBR commands do not output anything when nothing is found Key: FELIX-2937 URL: https://issues.apache.org/jira/browse/FELIX-2937 Project: Felix Issue Type: Bug Components: Gogo Command Affects Versions: gogo.command-0.8.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: gogo.command-0.10.0 When searching for bundles using the info command (for example), if nothing is matched then nothing is output to the user. This appears to be because the repository search routine is returning an empty array, but the command is expecting a null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2937) [Gogo Command] OBR commands do not output anything when nothing is found
[ https://issues.apache.org/jira/browse/FELIX-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2937: --- Summary: [Gogo Command] OBR commands do not output anything when nothing is found (was: [Gogo Command] Commands do not output anything when nothing is found) [Gogo Command] OBR commands do not output anything when nothing is found Key: FELIX-2937 URL: https://issues.apache.org/jira/browse/FELIX-2937 Project: Felix Issue Type: Bug Components: Gogo Command Affects Versions: gogo.command-0.8.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: gogo.command-0.10.0 When searching for bundles using the info command (for example), if nothing is matched then nothing is output to the user. This appears to be because the repository search routine is returning an empty array, but the command is expecting a null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (FELIX-2937) [Gogo Command] Commands do not output anything when nothing is found
[ https://issues.apache.org/jira/browse/FELIX-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reopened FELIX-2937: [Gogo Command] Commands do not output anything when nothing is found Key: FELIX-2937 URL: https://issues.apache.org/jira/browse/FELIX-2937 Project: Felix Issue Type: Bug Components: Gogo Command Affects Versions: gogo.command-0.8.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: gogo.command-0.10.0 When searching for bundles using the info command (for example), if nothing is matched then nothing is output to the user. This appears to be because the repository search routine is returning an empty array, but the command is expecting a null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-3001: --- Affects Version/s: gogo.command-0.8.0 Fix Version/s: gogo.command-0.10.0 [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Affects Versions: gogo.command-0.8.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo.command-0.10.0 java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050515#comment-13050515 ] Richard S. Hall commented on FELIX-2993: Well, it does export AND import those packages, so in theory it should be possible for it to use your exports as long as they meet its requirements and are resolved first, then it should work. jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-3001) [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[]
[ https://issues.apache.org/jira/browse/FELIX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-3001. -- fixed [gogo] help command throws ClassCastException if any osgi.command.function service property is not String[] --- Key: FELIX-3001 URL: https://issues.apache.org/jira/browse/FELIX-3001 Project: Felix Issue Type: Bug Components: Gogo Command Affects Versions: gogo.command-0.8.0 Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo.command-0.10.0 java.lang.ClassCastException: java.lang.String cannot be cast to [Ljava.lang.String; at org.apache.felix.gogo.command.Basic.getCommands(Basic.java:384) at org.apache.felix.gogo.command.Basic.help(Basic.java:211) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.gogo.runtime.Reflective.method(Reflective.java:136) at -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050526#comment-13050526 ] Richard S. Hall commented on FELIX-3000: I was thinking something similar, but I was thinking about eliminating the callbacks object altogether. I just need to make sure it makes sense from a design and compliance perspective. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-3000: --- Fix Version/s: framework-4.0.0 If this fix is needed before framework 4.0, then we'll need to branch from the 3.2.2 release tag. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2873) Dependencies with 'provided' scope gets added to the 'Export-Package' directive while they shouldn't
[ https://issues.apache.org/jira/browse/FELIX-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050530#comment-13050530 ] Pierre-Arnaud Marcelot commented on FELIX-2873: --- Thanks for the _exportcontents directive trick. This one seems based on the scope of the Embed-Dependency directive. Dependencies with 'provided' scope gets added to the 'Export-Package' directive while they shouldn't Key: FELIX-2873 URL: https://issues.apache.org/jira/browse/FELIX-2873 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Pierre-Arnaud Marcelot Assignee: Stuart McCulloch Priority: Blocker Attachments: MANIFEST.MF, pom.xml Since version 3.2.4, the plugin adds dependencies with 'provided' scope to the 'Export-Package' directive even when Embed-Dependency only includes 'compile' or/and 'runtime' scopes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050531#comment-13050531 ] Andrei Pozolotin commented on FELIX-2993: - I could not make it work so far; will try again. jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Gogo Runtime, Shell, Command version 0.10.0
+1 Missing DEPs files in source artifacts, but otherwise looked ok. - richard On 6/16/11 12:27, Richard S. Hall wrote: We solved these issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12316048 https://issues.apache.org/jira/browse/FELIX/fixforversion/12316049 [Note that Gogo Shell didn't have any JIRA issues, but there was a minor fix in it too, which is in it's change log.] Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-021/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 021 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050564#comment-13050564 ] Felix Meschberger commented on FELIX-3000: -- @Callbacks: Yes, I didn't go the route of removing that. If I see it correctly, this has been introduced as a bridge for the ServiceRegistry to call the framework's private fireServiceEvent method, right ? Altough it looks a bit heavy-lifting it kind of makes sense (and probably also simplifies testing ?) @framework 4.0: what would be the timeframe for this ? We currently have this change under test and expect some results towards end of June at which time we would have to have a fix. I would like to prevent branching. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050565#comment-13050565 ] Richard S. Hall commented on FELIX-3000: Regarding Callbacks, original the service registry used a full-blown listener pattern, but this seemed overkill since the framework was the only listener, thus I replaced that with a single callbacks object. What we are essentially proposing is to remove any notion of events from the service registry and handle them completely externally. I think the tricky one is unregister. Regarding 4.0, I don't think it will be done until end of July at the earliest. Branching is not a big deal, really, we just create a branch from the 3.2.2 tag, apply the fix, do a release, remove the branch. So, if we have to go that route, then no big deal. It only becomes more difficult if there are a lot of other issues to port over from trunk to the branch...but we could only include this one issue. Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3000) Move sending service registered event out of bundle lock
[ https://issues.apache.org/jira/browse/FELIX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050573#comment-13050573 ] Felix Meschberger commented on FELIX-3000: -- @Callbacks: Yes. BTW Just a nitpick, but I think the call to ((ServiceRegistrationImpl) reg).invalidate(); in the unregisterService(Bundle, ServiceReference) method needs not be in the synchronized(this) block. @4.0: Ok, thanks for the info. Lets pick this up again, when we need to ;-) Move sending service registered event out of bundle lock Key: FELIX-3000 URL: https://issues.apache.org/jira/browse/FELIX-3000 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-3.0.7, framework-3.2.2 Reporter: Felix Meschberger Fix For: framework-4.0.0 Attachments: FELIX-3000-stacktrace.txt, FELIX-3000.patch We have a strange situation on a Framework 3.0.7 based system here which is not reproducible on all platforms. We can track down a system freeze/deadlock to three threads all contending for bundle locks and the global lock. See attached FELIX-3000-stacktrace.txt for the stack trace. Looking at the Framework source, particularly acquireBundleLock and acquireGlobalLock I cannot see where this deadlock can occur. The only hint I have is a note in the Felix.registerService: // TODO: CONCURRENCY - Reconsider firing event here, outside of the // bundle lock. I wonder whether this situation can be fixed with moving the service registration event ? Looking at the code it seems to have not been changed. Thus I report this against 3.0.7 where we saw this and 3.2.2 being the latest release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2765) bundle plugin throw IllegalArgumentException while do the install
[ https://issues.apache.org/jira/browse/FELIX-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050575#comment-13050575 ] Andrei Pozolotin commented on FELIX-2765: - the issue is gone after switch to: dependency groupIdorg.apache.felix/groupId artifactIdorg.apache.felix.scr.annotations/artifactId version1.5.3-SNAPSHOT/version optionaltrue/optional /dependency plugin groupIdorg.apache.felix/groupId artifactIdmaven-scr-plugin/artifactId version1.7.1-SNAPSHOT/version /plugin plugin groupIdorg.apache.felix/groupId artifactIdmaven-bundle-plugin/artifactId version2.3.5-SNAPSHOT/version extensionstrue/extensions /plugin bundle plugin throw IllegalArgumentException while do the install - Key: FELIX-2765 URL: https://issues.apache.org/jira/browse/FELIX-2765 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.0.1 Environment: maven3 on win os Reporter: Zeng.haojie Priority: Blocker [ERROR] An internal error occurred java.lang.IllegalArgumentException: Cannot write resource: res/images/wired.gif aQute.lib.osgi.PreprocessResource@106121 exception: java.io.IOException: Opening resource at aQute.lib.osgi.Jar.writeResource(Jar.java:302) at aQute.lib.osgi.Jar.write(Jar.java:211) at aQute.lib.osgi.Jar.write(Jar.java:182) at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:313) at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:238) at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:229) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Deprecating the bundleall goal
Hi folks,
I'm planning to deprecate the bundleall goal since it has several faults,
produces low quality bundles, and was never meant to be used by everyday
projects.
Any objections? The goal will still be available in the next minor release,
but marked as deprecated with a warning - the next major release would remove
it.
--
Cheers, Stuart
Begin forwarded message:
From: mccu...@apache.org
Date: 16 June 2011 18:41:19 GMT+01:00
To: comm...@felix.apache.org
Subject: svn commit: r1136563 -
/felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
Reply-To: dev@felix.apache.org
Author: mcculls
Date: Thu Jun 16 17:41:18 2011
New Revision: 1136563
URL: http://svn.apache.org/viewvc?rev=1136563view=rev
Log:
Deprecate the bundleall goal
Modified:
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
Modified:
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
URL:
http://svn.apache.org/viewvc/felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java?rev=1136563r1=1136562r2=1136563view=diff
==
---
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
(original)
+++
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
Thu Jun 16 17:41:18 2011
@@ -64,7 +64,9 @@ import aQute.lib.osgi.Jar;
* @phase package
* @requiresDependencyResolution test
* @description build an OSGi bundle jar for all transitive dependencies
+ * @deprecated The bundleall goal is no longer supported and may be removed
in a future release
*/
+@Deprecated
public class BundleAllPlugin extends ManifestPlugin
{
private static final String LS = System.getProperty( line.separator );
@@ -174,6 +176,9 @@ public class BundleAllPlugin extends Man
*/
protected BundleInfo bundleAll( MavenProject project, int maxDepth )
throws MojoExecutionException
{
+getLog().warn(
);
+getLog().warn( ! The bundleall goal is no longer supported and may
be removed in a future release ! );
+getLog().warn(
);
if ( alreadyBundled( project.getArtifact() ) )
{
Re: Deprecating the bundleall goal
+1
Regards
JB
On 06/16/2011 07:49 PM, Stuart McCulloch wrote:
Hi folks,
I'm planning to deprecate the bundleall goal since it has several faults,
produces low quality bundles, and was never meant to be used by everyday projects.
Any objections? The goal will still be available in the next minor release,
but marked as deprecated with a warning - the next major release would remove
it.
--
Cheers, Stuart
Begin forwarded message:
From: mccu...@apache.org
Date: 16 June 2011 18:41:19 GMT+01:00
To: comm...@felix.apache.org
Subject: svn commit: r1136563 -
/felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
Reply-To: dev@felix.apache.org
Author: mcculls
Date: Thu Jun 16 17:41:18 2011
New Revision: 1136563
URL: http://svn.apache.org/viewvc?rev=1136563view=rev
Log:
Deprecate the bundleall goal
Modified:
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
Modified:
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
URL:
http://svn.apache.org/viewvc/felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java?rev=1136563r1=1136562r2=1136563view=diff
==
---
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
(original)
+++
felix/trunk/bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java
Thu Jun 16 17:41:18 2011
@@ -64,7 +64,9 @@ import aQute.lib.osgi.Jar;
* @phase package
* @requiresDependencyResolution test
* @description build an OSGi bundle jar for all transitive dependencies
+ * @deprecated The bundleall goal is no longer supported and may be removed in
a future release
*/
+@Deprecated
public class BundleAllPlugin extends ManifestPlugin
{
private static final String LS = System.getProperty( line.separator );
@@ -174,6 +176,9 @@ public class BundleAllPlugin extends Man
*/
protected BundleInfo bundleAll( MavenProject project, int maxDepth )
throws MojoExecutionException
{
+getLog().warn(
);
+getLog().warn( ! The bundleall goal is no longer supported and may be
removed in a future release ! );
+getLog().warn(
);
if ( alreadyBundled( project.getArtifact() ) )
{
maven-bundle-plugin roadmap
FYI, I'm doing a triage of maven-bundle-plugin issues this week with the aim of fixing small bugs before staging a new maintenance release. I'll also be planning what features should go into the next major release, so now's the time to vote / flag issues so they get some attention :) -- Cheers, Stuart
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050770#comment-13050770 ] Andrei Pozolotin commented on FELIX-2993: - Richard/Karl: I have a new dead end: now I am trying to run inside jnlp with full osgi permissions: config.put(org.osgi.framework.security, osgi); framework = factory.newFramework(config); framework.init(); the result is: java.lang.SecurityException: SecurityManager already installed at org.apache.felix.framework.Felix.init(Felix.java:543) ~[org.apache.felix.framework-3.2.2.jar:na] at com.barchart.platform.host.impl.HostOsgiFramework.osgiStartup(HostOsgiFramework.java:190) ~[barchart-platform-host-1.0.1-SNAPSHOT.jar:na] at com.barchart.platform.host.impl.HostServiceProvider.osgiStartup(HostServiceProvider.java:191) ~[barchart-platform-host-1.0.1-SNAPSHOT.jar:na] at com.barchart.platform.host.main.App.access$000(App.java:11) [barchart-platform-host-1.0.1-SNAPSHOT.jar:na] at com.barchart.platform.host.main.App$1.runCore(App.java:36) [barchart-platform-host-1.0.1-SNAPSHOT.jar:na] at com.barchart.platform.api.util.RunSwitch.run(RunSwitch.java:57) [barchart-platform-api-1.0.1-SNAPSHOT.jar:na] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_24] yes, because jnlp installs own SecurityManager; per framework.Felix.init() source, it is expected behavior; why? what is the work around? thanks Andrei. jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050774#comment-13050774 ] Andrei Pozolotin commented on FELIX-2993: - and another, hm, difficulty: :-) the same code which produces the exception above in jnlp mode, fails in test mode (run inside eclipse) for unrelated reason: (probably framework.security can not handle exploded jar during the signature check?) 17:26:13.819 [# OSGI START] DEBUG com.barchart.platform.host.main.App - install : reference:file:../barchart-plugin-core/target/classes 17:26:13.873 [# OSGI START] ERROR com.barchart.platform.host.main.App - org.osgi.framework.BundleException: Could not create bundle object. at org.apache.felix.framework.Felix.installBundle(Felix.java:2650) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.Felix.installBundle(Felix.java:2501) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:142) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:123) ~[org.apache.felix.framework-3.2.2.jar:na] at com.barchart.platform.host.impl.HostOsgiFramework.osgiActivate(HostOsgiFramework.java:277) ~[classes/:na] at com.barchart.platform.host.impl.HostServiceProvider.osgiActivate(HostServiceProvider.java:45) ~[classes/:na] at com.barchart.platform.host.impl.HostServiceProvider.osgiStartup(HostServiceProvider.java:193) ~[classes/:na] at com.barchart.platform.host.main.App.access$0(App.java:1) [classes/:na] at com.barchart.platform.host.main.App$1.runCore(App.java:36) [classes/:na] at com.barchart.platform.api.util.RunSwitch.run(RunSwitch.java:57) [classes/:na] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_25] Caused by: java.io.FileNotFoundException: ../barchart-plugin-core/target/classes/META-INF/maven (Is a directory) at java.io.FileInputStream.open(Native Method) ~[na:1.6.0_25] at java.io.FileInputStream.init(FileInputStream.java:120) ~[na:1.6.0_25] at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1203) ~[org.apache.felix.framework-3.2.2.jar:na] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_25] at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:423) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.cache.DirectoryContent.getEntryAsStream(DirectoryContent.java:140) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.security.util.BundleInputStream.readNext(BundleInputStream.java:147) ~[org.apache.felix.framework.security-1.4.2.jar:na] at org.apache.felix.framework.security.util.BundleInputStream.read(BundleInputStream.java:123) ~[org.apache.felix.framework.security-1.4.2.jar:na] at java.io.InputStream.read(InputStream.java:154) ~[na:1.6.0_25] at java.io.FilterInputStream.read(FilterInputStream.java:116) ~[na:1.6.0_25] at java.io.PushbackInputStream.read(PushbackInputStream.java:169) ~[na:1.6.0_25] at java.util.zip.ZipInputStream.readFully(ZipInputStream.java:407) ~[na:1.6.0_25] at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:238) ~[na:1.6.0_25] at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:82) ~[na:1.6.0_25] at java.util.jar.JarInputStream.checkManifest(JarInputStream.java:86) ~[na:1.6.0_25] at java.util.jar.JarInputStream.init(JarInputStream.java:68) ~[na:1.6.0_25] at org.apache.felix.framework.security.verifier.BundleDNParser.getCertificates(BundleDNParser.java:274) ~[org.apache.felix.framework.security-1.4.2.jar:na] at org.apache.felix.framework.security.verifier.BundleDNParser._getDNChains(BundleDNParser.java:237) ~[org.apache.felix.framework.security-1.4.2.jar:na] at org.apache.felix.framework.security.verifier.BundleDNParser.checkDNChains(BundleDNParser.java:145) ~[org.apache.felix.framework.security-1.4.2.jar:na] at org.apache.felix.framework.SecurityProviderImpl.checkBundle(SecurityProviderImpl.java:64) ~[org.apache.felix.framework.security-1.4.2.jar:na] at org.apache.felix.framework.BundleImpl.addModule(BundleImpl.java:1135) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:82) ~[org.apache.felix.framework-3.2.2.jar:na] at org.apache.felix.framework.Felix.installBundle(Felix.java:2593) ~[org.apache.felix.framework-3.2.2.jar:na] ... 10 common frames omitted jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050777#comment-13050777 ] Andrei Pozolotin commented on FELIX-2993: - answer to myself: re: per framework.Felix.init() source, it is expected behavior; why? what is the work around? the workaround: System.setSecurityManager(null); // SET TO NULL config.put(org.osgi.framework.security, osgi); framework = factory.newFramework(config); framework.init(); but why? jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050860#comment-13050860 ] Andrei Pozolotin commented on FELIX-2993: - re: (probably framework.security can not handle exploded jar during the signature check?) should I file a separate bug for this? jnlp felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: maven-bundle-plugin roadmap
few suggestions: 1) currently, unpackBundletrue/unpackBundle works only with goalbundle/goal this is a slow step with m2e, since it seems it really builds a bundle jar first and then unpacks it; I think it would help to make unpackBundle available for goalmanifest/goal and avoid building actual bundle jar, just fetch dependencies and place them in target/classes in the spirit of fast incremental builds in eclipse, you know :-) 2) currently, default m2e goals for resource save are: process-resources resources:testResources these are before process-classes, which is a default binding for maven-scr-plugin:scr and maven-bundle-plugin:manifest and hence serviceComponents.xml MANIFEST.MF are NOT updated when you edit save your scr java component; you must run project-clean instead; if you have any say at sonatype, can you please ask them to expose extra global m2e config option goals for *.java save with default mapping to process-classes; that should resolve this nicely? Original Message Subject: maven-bundle-plugin roadmap From: Stuart McCulloch mccu...@gmail.com To: dev@felix.apache.org Date: Thu 16 Jun 2011 01:04:08 PM CDT FYI, I'm doing a triage of maven-bundle-plugin issues this week with the aim of fixing small bugs before staging a new maintenance release. I'll also be planning what features should go into the next major release, so now's the time to vote / flag issues so they get some attention :) -- Cheers, Stuart
Re: [VOTE] Release Gogo Runtime, Shell, Command version 0.10.0
+1 On 6/16/11 12:27, Richard S. Hall wrote: We solved these issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12316048 https://issues.apache.org/jira/browse/FELIX/fixforversion/12316049 [Note that Gogo Shell didn't have any JIRA issues, but there was a minor fix in it too, which is in it's change log.] Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-021/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 021 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
