June 2011 - jboss-osgi-issues - Jboss List Archives

[JBoss JIRA] Created: (JBOSGI-424) Integration of EventAdmin with AS7 components

by Thomas Diesler (JIRA)

Integration of EventAdmin with AS7 components --------------------------------------------- Key: JBOSGI-424 URL: https://jira.jboss.org/browse/JBOSGI-424 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Non-OSGi components should be able to publish/receive events through EventAdmin and vice versa of course -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBOSGI-437) Felix Web Console occasionally fails to start

by David Bosschaert (JIRA)

Felix Web Console occasionally fails to start --------------------------------------------- Key: JBOSGI-437 URL: https://issues.jboss.org/browse/JBOSGI-437 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Framework, jboss-osgi-webconsole Affects Versions: JBossOSGi 1.0.0 Beta10 Environment: Fedora 13 with Sun/Oracle Java 1.6.0_20 Reporter: David Bosschaert When I run the JBoss OSGi installer (from master) with AS7 Beta2 integration and then start up AS7 the following error appears. When I restart everything works fine. 16:34:50,520 ERROR [org.jboss.as.osgi] (MSC service thread 1-1) Cannot start bundle: org.apache.felix.webconsole:3.1.6.SP1: org.osgi.framework.BundleException: Cannot start bundle: org.apache.felix.webconsole:3.1.6.SP1 at org.jboss.osgi.framework.bundle.HostBundle.transitionToActive(HostBundle.java:332) at org.jboss.osgi.framework.bundle.HostBundle.startInternal(HostBundle.java:218) at org.jboss.osgi.framework.bundle.AbstractBundle.start(AbstractBundle.java:411) at org.jboss.as.osgi.deployment.OSGiDeploymentService$OSGiDeploymentListener.processDeployment(OSGiDeploymentService.java:229) at org.jboss.as.osgi.deployment.OSGiDeploymentService$OSGiDeploymentListener.serviceStarted(OSGiDeploymentService.java:180) at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1149) at org.jboss.msc.service.ServiceControllerImpl.access$2300(ServiceControllerImpl.java:44) at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1513) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] Caused by: java.lang.NullPointerException at org.jboss.osgi.framework.bundle.HostRevision.loadClass(HostRevision.java:112) at org.jboss.osgi.framework.bundle.AbstractBundle.loadClass(AbstractBundle.java:586) at org.jboss.osgi.framework.bundle.HostBundle.transitionToActive(HostBundle.java:298) ... 10 more 16:34:50,592 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC00002: Invocation of listener "org.jboss.as.osgi.deployment.OSGiDeploymentService$OSGiDeploymentListener@a218a5" failed: java.lang.IllegalStateException: Module already exists: jbosgi.org.apache.felix.webconsole:3.1.6.SP1 at org.jboss.osgi.framework.bundle.OSGiModuleLoader.addModule(OSGiModuleLoader.java:47) at org.jboss.osgi.framework.plugin.internal.ModuleManagerPluginImpl.createHostModule(ModuleManagerPluginImpl.java:315) at org.jboss.osgi.framework.plugin.internal.ModuleManagerPluginImpl.addModule(ModuleManagerPluginImpl.java:202) at org.jboss.osgi.framework.plugin.internal.ResolverPluginImpl.addModules(ResolverPluginImpl.java:207) at org.jboss.osgi.framework.plugin.internal.ResolverPluginImpl.applyResolverResults(ResolverPluginImpl.java:186) at org.jboss.osgi.framework.plugin.internal.ResolverPluginImpl.resolve(ResolverPluginImpl.java:127) at org.jboss.osgi.framework.bundle.HostBundle.ensureResolved(HostBundle.java:129) at org.jboss.osgi.framework.bundle.HostBundle.startInternal(HostBundle.java:206) at org.jboss.osgi.framework.bundle.AbstractBundle.start(AbstractBundle.java:411) at org.jboss.as.osgi.deployment.OSGiDeploymentService$OSGiDeploymentListener.processDeployment(OSGiDeploymentService.java:229) at org.jboss.as.osgi.deployment.OSGiDeploymentService$OSGiDeploymentListener.serviceStarted(OSGiDeploymentService.java:180) at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1149) at org.jboss.msc.service.ServiceControllerImpl.access$2300(ServiceControllerImpl.java:44) at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1513) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBOSGI-453) JMX related exception when starting OSGi subsystem

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-453?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-453: ---------------------------------- Fix Version/s: JBossOSGi 1.0.1 (was: JBossOSGi 1.0.0) Revisit for next release > JMX related exception when starting OSGi subsystem > -------------------------------------------------- > > Key: JBOSGI-453 > URL: https://issues.jboss.org/browse/JBOSGI-453 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jboss-osgi-jmx > Reporter: David Bosschaert > Assignee: Thomas Diesler > Fix For: JBossOSGi 1.0.1 > > > Very often when the OSGi subsystem comes up, I'm seeing the following exception: > 08:32:43,709 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-1) Bundle started: org.apache.aries.jmx:0.1.0.incubating > 08:32:43,710 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.compendium:service=cm,version=1.3 > 08:32:43,711 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.framework.BundleStateMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.core:type=bundleState,version=1.5 > 08:32:43,724 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.framework.ServiceStateMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.core:type=serviceState,version=1.5 > 08:32:43,725 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.compendium:service=cm,version=1.3 > 08:32:43,726 ERROR [org.apache.aries.jmx] (Thread-14) MBean is already registered: org.apache.felix.log.LogException: javax.management.InstanceAlreadyExistsException: osgi.compendium:service=cm,version=1.3 > at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) [:1.6.0_23] > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484) [:1.6.0_23] > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963) [:1.6.0_23] > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) [:1.6.0_23] > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) [:1.6.0_23] > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [:1.6.0_23] > at org.jboss.as.jmx.tcl.TcclMBeanServer.registerMBean(TcclMBeanServer.java:238) > at org.apache.aries.jmx.agent.JMXAgentImpl.registerMBeans(JMXAgentImpl.java:129) > at org.apache.aries.jmx.agent.JMXAgentContext.registerMBeans(JMXAgentContext.java:58) > at org.apache.aries.jmx.MBeanServiceTracker$1.run(MBeanServiceTracker.java:61) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_23] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_23] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_23] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23] > at java.lang.Thread.run(Thread.java:662) [:1.6.0_23] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBOSGI-464) Felix web console does not appear any more on http://localhost:8090/jboss-osgi

by David Bosschaert (JIRA)

Felix web console does not appear any more on http://localhost:8090/jboss-osgi ------------------------------------------------------------------------------ Key: JBOSGI-464 URL: https://issues.jboss.org/browse/JBOSGI-464 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-osgi-webconsole Affects Versions: JBossOSGi 1.0.0 Beta10 Reporter: David Bosschaert Assignee: David Bosschaert When increasing the start level in AS7 to 3, the web console bundle is being started, however it's not accessible from http://localhost:8090/jboss-osgi 12:19:33,190 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-15) Bundle started: org.apache.felix.webconsole:3.1.6.SP1 12:19:33,218 INFO [org.apache.aries.jmx] (Thread-28) Registering MBean with ObjectName [osgi.compendium:service=cm,version=1.3] for service with service.id [23] 12:19:33,221 INFO [org.apache.aries.jmx] (Thread-28) Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@556292a4 with name osgi.compendium:service=cm,version=1.3 12:19:33,226 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-15) Bundle started: org.apache.felix.configadmin:1.2.8 12:19:33,260 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-15) Bundle started: org.apache.felix.metatype:1.0.4 12:19:33,325 INFO [org.eclipse.jetty.util.log] (MSC service thread 1-15) jetty-7.x.y-SNAPSHOT 12:19:33,363 INFO [org.eclipse.jetty.util.log] (MSC service thread 1-15) Started [NIOSocketConnectorWrapper@0.0.0.0:8090] 12:19:33,428 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-15) Bundle started: jboss-osgi-http:1.0.3 12:19:33,438 INFO [org.eclipse.jetty.util.log] (CM Configuration Updater (ManagedService Update: pid=org.ops4j.pax.web)) jetty-7.x.y-SNAPSHOT 12:19:33,440 INFO [org.eclipse.jetty.util.log] (CM Configuration Updater (ManagedService Update: pid=org.ops4j.pax.web)) Started [NIOSocketConnectorWrapper@0.0.0.0:8090] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-449) Problem deploying Blueprint in AS7

by David Bosschaert (JIRA)

Problem deploying Blueprint in AS7 ---------------------------------- Key: JBOSGI-449 URL: https://issues.jboss.org/browse/JBOSGI-449 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-osgi-blueprint Affects Versions: JBossOSGi 1.0.x Reporter: David Bosschaert Assignee: Thomas Diesler When deploying the jbosgi-blueprint bundle in AS7 (post Beta3, pre CR1) the deployment fails with a linkage error for org/jboss/osgi/deployment/interceptor/LifecycleInterceptor. Caused by: java.lang.LinkageError: Failed to link org/jboss/osgi/blueprint/internal/BlueprintInterceptor (Module "deployment.jbosgi-blueprint:1.0.2" from Service Module Loader) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:372) [:1.0.0.Beta17] at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:248) [:1.0.0.Beta17] at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:72) [:1.0.0.Beta17] at org.jboss.modules.Module.loadModuleClass(Module.java:576) [:1.0.0.Beta17] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:176) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17] at org.jboss.osgi.blueprint.internal.BlueprintActivator.start(BlueprintActivator.java:56) at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:271) ... 10 more Caused by: java.lang.NoClassDefFoundError: org/jboss/osgi/deployment/interceptor/LifecycleInterceptor at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_20] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_20] at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_20] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_20] at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:368) [:1.0.0.Beta17] ... 20 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-429) BundleUpdateTestCase in functional tests throws NoClassDefFoundError

by David Bosschaert (JIRA)

BundleUpdateTestCase in functional tests throws NoClassDefFoundError -------------------------------------------------------------------- Key: JBOSGI-429 URL: https://jira.jboss.org/browse/JBOSGI-429 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossOSGi 1.0.0 Beta10 Environment: Running against AS7 Alpha2 SNAPSHOT Reporter: David Bosschaert After fixing the Arquillian callback issue (JBOSGI-418) the BundleUpdateTestCase still fails with the exception below [1]. Seems like the exception comes from the side running in AS7 so the test possibly needs to import javax.naming... [1] testUpdateBundle(org.jboss.test.osgi.bundles.BundleUpdateTestCase) Time elapsed: 0.036 sec <<< ERROR! java.lang.NoClassDefFoundError: javax/naming/InitialContext at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at org.junit.runners.model.TestClass.<init>(TestClass.java:38) at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65) at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59) at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:74) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:33) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.jboss.arquillian.junit.JUnitTestRunner.execute(JUnitTestRunner.java:69) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:157) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:119) 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 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at javax.management.StandardMBean.invoke(StandardMBean.java:391) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:214) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
3
0 / 0

[JBoss JIRA] Resolved: (JBOSGI-459) URL.openStream() on URL returned from bundle.getResource() returns a zero-byte stream

by David Bosschaert (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-459?page=com.atlassian.jira.plugin... ] David Bosschaert resolved JBOSGI-459. ------------------------------------- Resolution: Done Fix pulled into jbosgi-framework master > URL.openStream() on URL returned from bundle.getResource() returns a zero-byte stream > ------------------------------------------------------------------------------------- > > Key: JBOSGI-459 > URL: https://issues.jboss.org/browse/JBOSGI-459 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: JBossOSGi 1.0.0 Beta10 > Reporter: David Bosschaert > Assignee: David Bosschaert > Attachments: org.apache.aries.spifly.examples.provider1.bundle-0.4-SNAPSHOT.jar, org.apache.aries.spifly.examples.spi.bundle-0.4-SNAPSHOT.jar > > > The attached bundle contains an embedded jar file which is referenced to by the Bundle-ClassPath. > Calling bundle.getResource("org.apache.aries.spifly.examples.provider1.jar-0.4-SNAPSHOT.jar") does return a URL. > {code}bundle.getResource("org.apache.aries.spifly.examples.provider1.jar-0.4-SNAPSHOT.jar") > (java.net.URL) bundle://org.apache.aries.spifly.examples.provider1.bundle-22-0-0/org.apache.aries.spifly.examples.provider1.jar-0.4-SNAPSHOT.jar/{code} > but opening that URL and reading the bytes yields 0 bytes. > This only seems to be an issue with URLs that refer to jar files. Other resources are readable without problems. > BTW this works fine on Equinox and Felix. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBOSGI-459) URL.openStream() on URL returned from bundle.getResource() returns a zero-byte stream

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-459?page=com.atlassian.jira.plugin... ] Thomas Diesler moved AS7-937 to JBOSGI-459: ------------------------------------------- Project: JBoss OSGi (was: Application Server 7) Key: JBOSGI-459 (was: AS7-937) Workflow: jira (was: GIT Pull Request workflow ) Affects Version/s: JBossOSGi 1.0.0 Beta10 (was: 7.0.0.CR1) Component/s: (was: OSGi) Security: Public > URL.openStream() on URL returned from bundle.getResource() returns a zero-byte stream > ------------------------------------------------------------------------------------- > > Key: JBOSGI-459 > URL: https://issues.jboss.org/browse/JBOSGI-459 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: JBossOSGi 1.0.0 Beta10 > Reporter: David Bosschaert > Assignee: David Bosschaert > Attachments: org.apache.aries.spifly.examples.provider1.bundle-0.4-SNAPSHOT.jar, org.apache.aries.spifly.examples.spi.bundle-0.4-SNAPSHOT.jar > > > The attached bundle contains an embedded jar file which is referenced to by the Bundle-ClassPath. > Calling bundle.getResource("org.apache.aries.spifly.examples.provider1.jar-0.4-SNAPSHOT.jar") does return a URL. > {code}bundle.getResource("org.apache.aries.spifly.examples.provider1.jar-0.4-SNAPSHOT.jar") > (java.net.URL) bundle://org.apache.aries.spifly.examples.provider1.bundle-22-0-0/org.apache.aries.spifly.examples.provider1.jar-0.4-SNAPSHOT.jar/{code} > but opening that URL and reading the bytes yields 0 bytes. > This only seems to be an issue with URLs that refer to jar files. Other resources are readable without problems. > BTW this works fine on Equinox and Felix. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBOSGI-179) Setup JBoss OSGi on jboss.org

by Thomas Diesler (JIRA)

Setup JBoss OSGi on jboss.org ----------------------------- Key: JBOSGI-179 URL: https://jira.jboss.org/jira/browse/JBOSGI-179 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Thomas Diesler Fix For: JBossOSGi 1.0.0 Beta5 The current homepage is http://www.jboss.org/community/wiki/JBossOSGi another good source of information is http://jbossosgi.blogspot.com/ The entry point however should be a project on jboss.org http://www.jboss.org/projects/matrix -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-issues June 2011