June 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-555) Complete support for Bundle start/stop

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-555?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved WFLY-555. --------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Complete support for Bundle start/stop > --------------------------------------- > > Key: WFLY-555 > URL: https://issues.jboss.org/browse/WFLY-555 > Project: WildFly > Issue Type: Sub-task > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Labels: roadmap > Fix For: 9.0.0.CR1 > > > A Bundle start/stop operation activates/deactivates the bundle services. The associated class loader and wiring is unaffected. > Approach #1 - start/stop is not mapped to deployment operations > Bundle deploy installs the Bundle to the Framework > Bundle is not resolved/started as part of the deploy operation > No module/classloader is created during deployment > All deployment processing that needs load classes/resources is skipped > No service provided by the bundle deployment is created > Bundle needs to be started/stopped explicitly > Bundle start/stop management operations are specific to bundle deployments > The POST_MODULE processing for OSGi enabled deployments (e.g. webapp) would need to be executed in an OSGi specific processor chain > OSGi enabled POST_MODULE DUPs have their functionality externalised such that it can get reused for start/stop operations > The start/stop processing chain must be traversable in both directions repeatedly > Approach #2 - start/stop is mapped to deployment operations > Bundle deploy installs the Bundle to the Framework and attempts to resolve/start the Bundle > If the Bundle can get resolved, a module/classloader is created as part of the DU processing > In case the Bundle cannot get resolved, DUP processing is deferred and MODULE phase processing is reattempted later based on an external trigger > Has the benefit that any deployment type can also be a Bundle > Bundle stop must reverse work that is done in POST_MODULE DUPs > POST_MODULE DUPs must be traversable in both direction multiple times > Currently, we use approach #2 with limited support from POST_MODULE DUPs (i.e. they are not designed to be executed multiple times for the same deployment). There is also the cleanup phase which breaks multiple executions of POST_MODULE DUPs. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1100) Complete support for OSGi JNDI

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1100?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1100. ---------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Complete support for OSGi JNDI > ------------------------------ > > Key: WFLY-1100 > URL: https://issues.jboss.org/browse/WFLY-1100 > Project: WildFly > Issue Type: Feature Request > Components: Naming, OSGi > Reporter: Thomas Diesler > Labels: roadmap > > As expected because of the missing integration with the NamingManger singletons, all tests that go through NamingManager to obtain the InitialContextFactory or the ObjectFactory fail. > {code} > Running org.jboss.test.osgi.example.jndi.JNDITestCase > Tests run: 12, Failures: 1, Errors: 2, Skipped: 2, Time elapsed: 15.574 sec <<< FAILURE! > Results : > Failed tests: testContextManagerReferenceBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): expected:<bar> but was:<Reference Class Name: java.lang.String(..) > Tests in error: > testTraditionalAPIValueBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): JBAS011843: Failed instantiate InitialContextFactory org.jboss.test.osgi.example.jndi.bundle.JNDITestActivator$SimpleInitalContextFactory from classloader ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader > testTraditionalAPIReferenceBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): JBAS011843: Failed instantiate InitialContextFactory org.jboss.test.osgi.example.jndi.bundle.JNDITestActivator$SimpleInitalContextFactory from classloader ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader > {code} > In reality it means that OSGi Bundles cannot use JNDI with object References and cannot expect the traditional JNDI API to work. These findings generally raise the question how a spec compliant OSGI JNDI Implementation is supposed to work in a container environment. Specifically, in an environment that has already set the NamingManager singletons. > IMHO there is a layer of abstraction missing. Perhaps the container should register a NamingManger service that the JNDI Implementation can use to register its InitialContextFactoryBuilder and ObjectFactoryBuilder. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1273) Remove hard wired dependency on configadmin

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1273?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1273. ---------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Remove hard wired dependency on configadmin > ------------------------------------------- > > Key: WFLY-1273 > URL: https://issues.jboss.org/browse/WFLY-1273 > Project: WildFly > Issue Type: Task > Components: ConfigAdmin, OSGi > Reporter: Thomas Diesler > > {code} > interface SystemPackagesIntegration { > String[] DEFAULT_SYSTEM_MODULES = new String[] { > "javax.api", > "javax.inject.api", > "org.apache.xerces", > "org.jboss.as.configadmin", > "org.jboss.as.controller-client", > "org.jboss.as.osgi", > "org.jboss.dmr", > "org.jboss.logging", > "org.jboss.modules", > "org.jboss.msc", > "org.jboss.osgi.framework", > "org.jboss.osgi.repository", > "org.jboss.osgi.resolver" > }; > {code} > A modular build that contains osgi must currently also contain configadmin -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-793) Invalid bundle deployment does not fail in domain

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-793?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved WFLY-793. --------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Invalid bundle deployment does not fail in domain > ------------------------------------------------- > > Key: WFLY-793 > URL: https://issues.jboss.org/browse/WFLY-793 > Project: WildFly > Issue Type: Bug > Components: Domain Management, OSGi > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1089) Failure detection/handling in deployment operation start

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1089?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1089. ---------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Failure detection/handling in deployment operation start > -------------------------------------------------------- > > Key: WFLY-1089 > URL: https://issues.jboss.org/browse/WFLY-1089 > Project: WildFly > Issue Type: Feature Request > Components: OSGi, Server > Reporter: Thomas Diesler > Priority: Minor > -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1244) Dynamic dependencies for non OSGi deployments

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1244?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1244. ---------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Dynamic dependencies for non OSGi deployments > --------------------------------------------- > > Key: WFLY-1244 > URL: https://issues.jboss.org/browse/WFLY-1244 > Project: WildFly > Issue Type: Task > Components: OSGi, REST > Reporter: Thomas Diesler > > Currently the RestEasyIntegrationTestCase deploys a JAXRS endpoint that integrates with an OSGi service. The endoint deployment does not trigger the OSGi subsystem to start up, but depends on the compendium being deployed. The compendium gets deployed during OSGi subsystem startup. > There is currently no way for deployment foo to declare a dependency on deployment bar when bar gets deployed during subsystem startup, which gets triggered by deployment foo. > OSGi has the notion of dynamic package import which seems to be required here for non-osgi deployments -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1095) Complete support for OSGi JDBC

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1095?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1095. ---------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Complete support for OSGi JDBC > ------------------------------ > > Key: WFLY-1095 > URL: https://issues.jboss.org/browse/WFLY-1095 > Project: WildFly > Issue Type: Feature Request > Components: JCA, OSGi > Reporter: Thomas Diesler > Labels: roadmap > > R5 TCK compliance for JDBC -- 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, 4 months

1
0
0 / 0

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

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-783?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved WFLY-783. --------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Cannot get bytes from InputStream for DEPLOYMENT_ROOT VirtualFile.openStream() on second call > --------------------------------------------------------------------------------------------- > > Key: WFLY-783 > URL: https://issues.jboss.org/browse/WFLY-783 > Project: WildFly > Issue Type: Bug > Components: OSGi, Server > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1257) Http Service TCK testLongRegistrationName() failing

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1257?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1257. ---------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Http Service TCK testLongRegistrationName() failing > --------------------------------------------------- > > Key: WFLY-1257 > URL: https://issues.jboss.org/browse/WFLY-1257 > Project: WildFly > Issue Type: Sub-task > Components: OSGi > Reporter: David Bosschaert > > The OSGi HTTP Service TCK test testLongRegistrationName() fails with the following exception: > java.io.FileNotFoundException: http://localhost:8080/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy... > Apparently there is an issue with long registration names. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-560) Support deployment of a set of Bundles

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-560?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved WFLY-560. --------------------------------- Resolution: Won't Fix Won't Fix - OSGi is going to get removed > Support deployment of a set of Bundles > -------------------------------------- > > Key: WFLY-560 > URL: https://issues.jboss.org/browse/WFLY-560 > Project: WildFly > Issue Type: Sub-task > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 9.0.0.CR1 > > > In one deploy cycle, bundles must first get installed and then started. > It generally needs to be discussed how multiple phase deployments should be handled. -- 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, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2013