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

[JBoss JIRA] (JBOSGI-667) OSGi: "Export-EJB" header is not supported to install/start EJB3 bundle from repository

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-667?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1382 to JBOSGI-667: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-667 (was: WFLY-1382) Workflow: jira (was: GIT Pull Request workflow ) Affects Version/s: (was: 8.0.0.Alpha2) Component/s: (was: OSGi) > OSGi: "Export-EJB" header is not supported to install/start EJB3 bundle from repository > --------------------------------------------------------------------------------------- > > Key: JBOSGI-667 > URL: https://issues.jboss.org/browse/JBOSGI-667 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Igor Shulika > > I am using the latest WildFly 8.0.0.Alpha2-SNAPSHOT server to install/start all of my OSGi bundles from Maven repository. The EJB 3 MDB is not starting if I am just declare capability in the standalone-osgi.xml file. > > Here is my capability configuration. > <capability name="org.test.ejb3.mdb:ejb-high-velocity-queue-mdb:1.0" startlevel="4"/> > > Note: When I just simply drop my EJB 3 MDB JAR file inside "deployments" directory the message driven bean starting successfully (see below). > INFO [org.jboss.as.ejb3] (MSC service thread 1-2) JBAS014142: Started message driven bean 'HighVelocityQueueMessageBean' with 'hornetq-ra' resource adapter. -- 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-668) Attribute read for uninstalled bundle breaks console

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-668?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-879 to JBOSGI-668: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-668 (was: WFLY-879) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Attribute read for uninstalled bundle breaks console > ---------------------------------------------------- > > Key: JBOSGI-668 > URL: https://issues.jboss.org/browse/JBOSGI-668 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Thomas Diesler > Labels: Console > Attachments: unread_bundle_stacktrace.txt, unread_bundle_stacktrace_cli.txt > > -- 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-670) OSGi: "Web-ContextPath" header is not supported to install/start WAB bundle from repository

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-670?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1381 to JBOSGI-670: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-670 (was: WFLY-1381) Workflow: jira (was: GIT Pull Request workflow ) Affects Version/s: (was: 8.0.0.Alpha2) Component/s: (was: OSGi) > OSGi: "Web-ContextPath" header is not supported to install/start WAB bundle from repository > ------------------------------------------------------------------------------------------- > > Key: JBOSGI-670 > URL: https://issues.jboss.org/browse/JBOSGI-670 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Igor Shulika > > I am using the latest WildFly 8.0.0.Alpha2-SNAPSHOT server to install/start all of my OSGi bundles from Maven repository. The WAB is not starting if I am just declare capability in the standalone-osgi.xml file. > > Here is my capability configuration. > <capability name="org.test.sample.webapp:my-sample-webapp:1.0" startlevel="4"/> > > Note: When I just simply drop my WAB file inside "deployments" directory the web application starting successfully. -- 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-672) DuplicateServiceException on undertow deployment replace

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-672?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1557 to JBOSGI-672: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-672 (was: WFLY-1557) Workflow: jira (was: GIT Pull Request workflow ) Component/s: WebApp (was: OSGi) (was: Web (Undertow)) > DuplicateServiceException on undertow deployment replace > -------------------------------------------------------- > > Key: JBOSGI-672 > URL: https://issues.jboss.org/browse/JBOSGI-672 > Project: JBoss OSGi > Issue Type: Bug > Components: WebApp > Reporter: Thomas Diesler > > {code} > 07:21:52,095 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "webapp-v101.wab" (runtime-name: "webapp-v101.wab") > 07:21:52,119 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: webapp-v101.wab:1.0.1 > 07:21:52,119 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS018224: Unregister web context: /simple-bundle > 07:21:52,119 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011003: Bundle stopped: webapp-v100.wab:1.0.0 > 07:21:52,124 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."webapp-v101.wab".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v101.wab".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "webapp-v101.wab" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13] > Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.undertow.deployment.default-host./simple-bundle.UndertowDeploymentInfoService is already registered > at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2382) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2382) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentProcessor.processDeployment(UndertowDeploymentProcessor.java:235) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentProcessor.deploy(UndertowDeploymentProcessor.java:102) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > {code} > http://teamcity.cafe-babe.org/viewLog.html?buildId=5380&tab=buildResultsD... -- 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 moved WFLY-783 to JBOSGI-671: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-671 (was: WFLY-783) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > 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 > Reporter: Thomas Diesler > > 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-673) Invalid bundle deployment does not fail in domain

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-673?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-793 to JBOSGI-673: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-673 (was: WFLY-793) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: Domain Management) (was: OSGi) > Invalid bundle deployment does not fail in domain > ------------------------------------------------- > > Key: JBOSGI-673 > URL: https://issues.jboss.org/browse/JBOSGI-673 > Project: JBoss OSGi > Issue Type: Bug > Reporter: Thomas Diesler > Priority: Minor > > Running org.jboss.as.test.integration.domain.suites.OSGiBundleLifecyleTestCase > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 35.653 sec <<< FAILURE! > on the server I see > {code} > 15:20:28,619 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit.bad-bundle.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.bad-bundle.STRUCTURE: Failed to process phase STRUCTURE of deployment "bad-bundle" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29] > Caused by: java.lang.NumberFormatException: For input string: "bogus" > at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) [rt.jar:1.6.0_29] > at java.lang.Integer.parseInt(Integer.java:449) [rt.jar:1.6.0_29] > at java.lang.Integer.parseInt(Integer.java:499) [rt.jar:1.6.0_29] > at org.osgi.framework.Version.<init>(Version.java:125) > at org.osgi.framework.Version.parseVersion(Version.java:218) > at org.jboss.osgi.spi.BundleInfo.validateBundleManifest(BundleInfo.java:204) > at org.jboss.osgi.spi.BundleInfo.isValidBundleManifest(BundleInfo.java:153) > at org.jboss.as.osgi.deployment.OSGiManifestStructureProcessor.deploy(OSGiManifestStructureProcessor.java:63) > {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-655) Cannot access jboss-osgi API docs

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-655?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-655: ---------------------------------- Assignee: (was: Thomas Diesler) Fix Version/s: Awaiting Volunteers (was: JBossOSGi 2.0.1) > Cannot access jboss-osgi API docs > ---------------------------------- > > Key: JBOSGI-655 > URL: https://issues.jboss.org/browse/JBOSGI-655 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distribution > Reporter: Thomas Diesler > Fix For: Awaiting Volunteers > > > http://docs.jboss.org/osgi/apidocs > 403 Forbidden > You don't have permission to access /osgi/apidocs on this server. -- 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, 10 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: ---------------------------------- Assignee: (was: Thomas Diesler) Fix Version/s: Awaiting Volunteers (was: 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: Awaiting Volunteers > > -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-665) OSGiMetaDataBuilder can be used with invalid manifest

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-665?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-665: ---------------------------------- Assignee: (was: Thomas Diesler) Fix Version/s: Awaiting Volunteers (was: JBossOSGi 2.0.1) > OSGiMetaDataBuilder can be used with invalid manifest > ----------------------------------------------------- > > Key: JBOSGI-665 > URL: https://issues.jboss.org/browse/JBOSGI-665 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core Framework > Reporter: Thomas Diesler > Fix For: Awaiting Volunteers > > -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-589) Support reference: URLs

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-589?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-589: ---------------------------------- Assignee: (was: Thomas Diesler) Fix Version/s: Awaiting Volunteers (was: JBossOSGi 2.0.1) > Support reference: URLs > ----------------------- > > Key: JBOSGI-589 > URL: https://issues.jboss.org/browse/JBOSGI-589 > Project: JBoss OSGi > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core Framework > Affects Versions: JBossOSGi 1.1.1 > Reporter: Harald Wellmann > Fix For: Awaiting Volunteers > > > While this is not an official OSGi standard, Equinox, Felix and Knopflerfish all support {{reference:file:}} URLs for provisioning bundles in place, without copying them to the OSGi storage area. > This works both for JARs and for directories (exploded bundles), e.g. > {noformat} > reference:file:/path/to/my/bundle.jar > reference:file:target/classes/ > {noformat} > For interoperability of frameworks, it would be useful for JBoss OSGi to support this protocol. -- 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, 10 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