July 2013 - jboss-osgi-issues - Jboss List Archives

[JBoss JIRA] (JBOSGI-733) Complete implementation of the FrameworkFactory

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-733?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-733: ---------------------------------- Labels: (was: roadmap) > Complete implementation of the FrameworkFactory > ----------------------------------------------- > > Key: JBOSGI-733 > URL: https://issues.jboss.org/browse/JBOSGI-733 > Project: JBoss OSGi > Issue Type: Task > Components: Core Framework, WildFly > Reporter: David Bosschaert > Fix For: Awaiting Volunteers > > > The OSGi CT is currently run with the JBoss OSGi framework standalone. It should also be possible to run the CT with the AS7 integration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-720) Complete support for HttpService

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-720?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-720: ---------------------------------- Labels: (was: roadmap) > Complete support for HttpService > -------------------------------- > > Key: JBOSGI-720 > URL: https://issues.jboss.org/browse/JBOSGI-720 > Project: JBoss OSGi > Issue Type: Task > Components: Enterprise OSGi, WildFly > Reporter: Thomas Diesler > Fix For: Awaiting Volunteers > > > #1 Add support for MimeType, Content-Lenght, etc > #2 Delegate authentication/authorisation to HttpContext > #3 Add support for "/" root context > #4 Make HttpService an optional capability > #5 Make virtual host/port configurable > This issue is complete when the TCK passes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-690) Complete support for OSGi JMX

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-690?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-690: ---------------------------------- Labels: (was: roadmap) > Complete support for OSGi JMX > ----------------------------- > > Key: JBOSGI-690 > URL: https://issues.jboss.org/browse/JBOSGI-690 > Project: JBoss OSGi > Issue Type: Feature Request > Components: Enterprise OSGi > Reporter: Thomas Diesler > Fix For: Awaiting Volunteers > > > R5 TCK compliance for JMX -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-519) InitialContextFactoryBuilder already registered in AS

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-519?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-519: ---------------------------------- Fix Version/s: Awaiting WildFly Support > InitialContextFactoryBuilder already registered in AS > ----------------------------------------------------- > > Key: JBOSGI-519 > URL: https://issues.jboss.org/browse/JBOSGI-519 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Enterprise OSGi, WildFly > Reporter: Thomas Diesler > Labels: jndi > Fix For: Awaiting WildFly Support > > > In AS we see > {code} > 09:59:52,782 INFO [org.apache.aries.jndi.startup.Activator] (pool-4-thread-1) It was not possible to register an InitialContextFactoryBuilder with the NamingManager because another builder called org.jboss.as.naming.InitialContextFactoryBuilder was already registered. Support for calling new InitialContext() will not be enabled.: java.lang.IllegalStateException: InitialContextFactoryBuilder already set > at javax.naming.spi.NamingManager.setInitialContextFactoryBuilder(NamingManager.java:692) [rt.jar:1.6.0_29] > at org.apache.aries.jndi.startup.Activator.start(Activator.java:76) > at org.apache.aries.jndi.priv.Activator.start(Activator.java:38) > at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300) > at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223) > at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:488) > at org.jboss.test.osgi.NamingSupport.provideJNDIIntegration(NamingSupport.java:44) > at org.jboss.test.osgi.example.jndi.JNDITestCase.testOSGiNamingContext(JNDITestCase.java:91) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-671) Cannot get bytes from InputStream for DEPLOYMENT_ROOT VirtualFile.openStream() on second call

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-671?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-671: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > Cannot get bytes from InputStream for DEPLOYMENT_ROOT VirtualFile.openStream() on second call > --------------------------------------------------------------------------------------------- > > Key: JBOSGI-671 > URL: https://issues.jboss.org/browse/JBOSGI-671 > Project: JBoss OSGi > Issue Type: Bug > Components: WildFly > Reporter: Thomas Diesler > Fix For: JBossOSGi 2.0.1 > > > The effect is that the copy of a installed OSGi bundle is 0bytes in the data/osgi-store area > Digging into this shows that during the first call isDirectory() is false and the file gets mounted. The returned stream works fine. For the second call isDirectory() is true and e read() on the returned InputStream returns -1 > {code} > public InputStream openStream() throws IOException { > if(isDirectory()) { > return new VirtualJarInputStream(this); > } > final VFS.Mount mount = VFS.getMount(this); > return mount.getFileSystem().openInputStream(mount.getMountPoint(), this); > } > {code} > I assume that the root VirtualFile > {code} > VirtualFile virtualFile = deploymentUnit.getAttachment(Attachments.DEPLOYMENT_ROOT).getRoot(); > {code} > should be readable twice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-564) Provide documentation on module/bundle integration in AS7

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-564?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-564: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > Provide documentation on module/bundle integration in AS7 > --------------------------------------------------------- > > Key: JBOSGI-564 > URL: https://issues.jboss.org/browse/JBOSGI-564 > Project: JBoss OSGi > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Distribution > Reporter: Thomas Diesler > Fix For: JBossOSGi 2.0.1 > > > Awaiting volunteers. The module/bundle integration is documented in the test suite -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-548) ConfigurationAdminMBean registered twice

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-548?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-548: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > ConfigurationAdminMBean registered twice > ---------------------------------------- > > Key: JBOSGI-548 > URL: https://issues.jboss.org/browse/JBOSGI-548 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Enterprise OSGi > Reporter: Thomas Diesler > Fix For: JBossOSGi 2.0.1 > > > https://issues.apache.org/jira/browse/ARIES-663 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-633) Extend Resolver API such that FrameworkWiring.resolveBundles() can report problems

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-633?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-633: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > Extend Resolver API such that FrameworkWiring.resolveBundles() can report problems > ---------------------------------------------------------------------------------- > > Key: JBOSGI-633 > URL: https://issues.jboss.org/browse/JBOSGI-633 > Project: JBoss OSGi > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core Framework > Reporter: Thomas Diesler > Fix For: JBossOSGi 2.0.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-582) Update Aries JMX to 1.1.0

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-582?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-582: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > Update Aries JMX to 1.1.0 > ------------------------- > > Key: JBOSGI-582 > URL: https://issues.jboss.org/browse/JBOSGI-582 > Project: JBoss OSGi > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Enterprise OSGi > Reporter: David Bosschaert > Fix For: JBossOSGi 2.0.1 > > > The JMX integration should be updated to version 1.1.0 which maps to the jmx-next work done in Apache Aries. > The jmx-next work implements the OSGi Enterprise 5.0 JMX specification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-666) Cannot lookup owner context using standard naming API

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-666?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-666: ---------------------------------- Fix Version/s: Awaiting WildFly Support > Cannot lookup owner context using standard naming API > ----------------------------------------------------- > > Key: JBOSGI-666 > URL: https://issues.jboss.org/browse/JBOSGI-666 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Enterprise OSGi, WildFly > Affects Versions: JBossOSGi 2.0.0 > Reporter: Thomas Diesler > Labels: jndi > Fix For: Awaiting WildFly Support > > > {code} > Context initialContext = new InitialContext(); > BundleContext context = (BundleContext) initialContext.lookup("osgi:framework/bundleContext"); > {code} > fails with > {code} > testTraditionalAPIOwnerContext(org.jboss.test.osgi.example.jndi.NamingStandaloneTestCase) Time elapsed: 0.062 sec <<< FAILURE! > java.lang.AssertionError: expected:<BundleContext[jndi-tests:0.0.0]> but was:<BundleContext[arquillian-osgi-bundle:2.0.0.CR4]> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-issues July 2013