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

[JBoss JIRA] Created: (JBOSGI-347) Cannot deploy jbosgi36-mbean.jar to AS601

by Thomas Diesler (JIRA)

Cannot deploy jbosgi36-mbean.jar to AS601 ----------------------------------------- Key: JBOSGI-347 URL: https://jira.jboss.org/browse/JBOSGI-347 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: JBossOSGi 1.0.0 Beta8 Caused by: java.lang.NullPointerException at org.jboss.classpool.plugins.jbosscl.BootstrapParentUnitFinder.findParentUnitLoader(BootstrapParentUnitFinder.java:42) at org.jboss.classpool.plugins.jbosscl.ParentUnitLoaderFinders.findParentUnitLoader(ParentUnitLoaderFinders.java:71) at org.jboss.classpool.plugins.jbosscl.VFSClassLoaderDomainRegistry.findParentUnitLoader(VFSClassLoaderDomainRegistry.java:256) at org.jboss.classpool.plugins.jbosscl.VFSClassLoaderDomainRegistry.initMapsForModule(VFSClassLoaderDomainRegistry.java:114) at org.jboss.classpool.plugins.jbosscl.RegisterModuleCallback.registerModule(RegisterModuleCallback.java:87) at org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPoolFactory.create(JBossClDelegatingClassPoolFactory.java:92) at org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPoolFactory.create(JBossClDelegatingClassPoolFactory.java:52) at org.jboss.aop.asintegration.jboss5.JBoss5Integration.create(JBoss5Integration.java:147) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-353) Remove dependency on jboss-osgi-vfs

by Thomas Diesler (JIRA)

Remove dependency on jboss-osgi-vfs ----------------------------------- Key: JBOSGI-353 URL: https://jira.jboss.org/browse/JBOSGI-353 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: JBossOSGi 1.0.x Resolve when all supported target containers run on vfs30 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBOSGI-196) Provide a DeployerAdaptor for LifecycleInterceptors

by Thomas Diesler (JIRA)

Provide a DeployerAdaptor for LifecycleInterceptors --------------------------------------------------- Key: JBOSGI-196 URL: https://jira.jboss.org/jira/browse/JBOSGI-196 Project: JBoss OSGi Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Other Reporter: Thomas Diesler Fix For: JBossOSGi 1.0.x This is to re-use existing Deployer logic. -- 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

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-236) XML Binding example fails in JBossAS

by Thomas Diesler (JIRA)

XML Binding example fails in JBossAS ------------------------------------ Key: JBOSGI-236 URL: https://jira.jboss.org/jira/browse/JBOSGI-236 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: Integration (JBoss) Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: JBossOSGi 1.0.0 Beta6 Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: bundleentry://20.fwk25544092/booking.xml at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:147) at org.jboss.osgi.jbossxb.internal.UnmarshallerServiceImpl.unmarshal(UnmarshallerServiceImpl.java:249) ... 31 more Caused by: java.lang.ExceptionInInitializerError at org.apache.xerces.impl.xs.XMLSchemaValidator.<clinit>(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.configurePipeline(Unknown Source) at org.apache.xerces.parsers.XIncludeAwareParserConfiguration.configurePipeline(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173) ... 33 more Caused by: org.apache.xerces.impl.dv.DVFactoryException: Schema factory class org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl does not extend from SchemaDVFactory. at org.apache.xerces.impl.dv.SchemaDVFactory.getInstance(Unknown Source) at org.apache.xerces.impl.dv.SchemaDVFactory.getInstance(Unknown Source) at org.apache.xerces.impl.xs.SchemaGrammar$BuiltinSchemaGrammar.<init>(Unknown Source) -- 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

15 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBOSGI-325) JTA example cannot run without implicit boot delegation

by Thomas Diesler (JIRA)

JTA example cannot run without implicit boot delegation ------------------------------------------------------- Key: JBOSGI-325 URL: https://jira.jboss.org/jira/browse/JBOSGI-325 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: JBossOSGi 1.0.x jboss-osgi-felix.properties cannot contain # Felix config properties felix.bootdelegation.implicit=false ------------------------------------------------------------------------------- Test set: org.jboss.test.osgi.example.jta.TransactionTestCase ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.837 sec <<< FAILURE! testUserTransaction(org.jboss.test.osgi.example.jta.TransactionTestCase) Time elapsed: 1.803 sec <<< ERROR! org.osgi.framework.BundleException: Activator start error in bundle jboss-osgi-jta [8]. at org.apache.felix.framework.Felix.activateBundle(Felix.java:1803) at org.apache.felix.framework.Felix.startBundle(Felix.java:1678) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) at org.jboss.osgi.testing.internal.EmbeddedBundle.startInternal(EmbeddedBundle.java:140) at org.jboss.osgi.testing.internal.OSGiBundleImpl.start(OSGiBundleImpl.java:61) at org.jboss.osgi.spi.capability.Capability.start(Capability.java:221) at org.jboss.osgi.testing.internal.OSGiRuntimeImpl.addCapability(OSGiRuntimeImpl.java:102) at org.jboss.osgi.testing.internal.EmbeddedRuntime.addCapability(EmbeddedRuntime.java:169) at org.jboss.test.osgi.example.jta.TransactionTestCase.setUp(TransactionTestCase.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ... Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.jboss.osgi.xml.DocumentBuilderFactoryImpl not found at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:129) at com.arjuna.common.internal.util.propertyservice.plugins.io.XMLFilePlugin.<clinit>(XMLFilePlugin.java:352) 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 java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at com.arjuna.common.internal.util.propertyservice.PropertyManagerImpl.load(PropertyManagerImpl.java:357) at com.arjuna.ats.jta.common.jtaPropertyManager.<clinit>(jtaPropertyManager.java:67) at com.arjuna.ats.jta.utils.JNDIManager.getTransactionManagerImplementationClassname(JNDIManager.java:72) at com.arjuna.ats.jta.TransactionManager.transactionManager(TransactionManager.java:93) at com.arjuna.ats.jta.TransactionManager.transactionManager(TransactionManager.java:76) at org.jboss.osgi.jta.internal.TransactionServiceActivator.start(TransactionServiceActivator.java:61) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1756) -- 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

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBOSGI-203) Define non OSGi bundle handling by the Framework

by Thomas Diesler (JIRA)

Define non OSGi bundle handling by the Framework ------------------------------------------------ Key: JBOSGI-203 URL: https://jira.jboss.org/jira/browse/JBOSGI-203 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Components: Core Framework Reporter: Thomas Diesler Fix For: JBossOSGi 1.0.0 Beta5 There have been changes going forth and back with respect to non-osgi deployment handling. The objectives and scope of functionality need to be defined. -- 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

15 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBOSGI-329) SystemBundle added as MC module

by Thomas Diesler (JIRA)

SystemBundle added as MC module ------------------------------- Key: JBOSGI-329 URL: https://jira.jboss.org/browse/JBOSGI-329 Project: JBoss OSGi Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Framework Reporter: Thomas Diesler Fix For: JBossOSGi 1.0.x Currently we do not create OSGiPackageRequirements that map to system packages defined at the framework level. In various places, especially in resolver integration, that leads to special workaround treatment when a bundle defines a requirement on a system package (possibly with a version qualifier) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-205) Document MC/OSGi Service integration

by Thomas Diesler (JIRA)

Document MC/OSGi Service integration ------------------------------------ Key: JBOSGI-205 URL: https://jira.jboss.org/jira/browse/JBOSGI-205 Project: JBoss OSGi Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assignee: Ales Justin Please create a section in the user guide that explains what added benefit this MC/OSGi Service integration brings to the user. If applicable, there should be examples that the user can run and look at. This integration work is the first piece of functionality that we do to justify our effort to implement an OSGi core framework, hence special care should be taken to explain and show the actual benefits. * OSGi services will be exposed as MC beans I suppose that means you can reference/inject OSGi services in the an MC descriptor. Could you describe/show how this would look like? How would this work with service properties. How would this work with multiple implementations of the same service interface? * MC beans will be listed as a OSGi services I suppose that means you can reference/inject MC beans in a BP descriptor. Here as well, could you please describe/show how this would look like? Do MC beans support service properties i.e. Can I use an LDAP filter to find the target service? Can you have multiple implementations of the same service interface? How would the service event model work i.e. Can I use ServiceTracker to track MC beans? -- 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

15 years, 3 months

1
9
0 / 0

[JBoss JIRA] Created: (JBOSGI-76) Add VFS to microcontainer bundle

by Thomas Diesler (JIRA)

Add VFS to microcontainer bundle -------------------------------- Key: JBOSGI-76 URL: https://jira.jboss.org/jira/browse/JBOSGI-76 Project: JBossOSGi Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler -- 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

15 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBOSGI-141) Service integration with MC

by Thomas Diesler (JIRA)

Service integration with MC --------------------------- Key: JBOSGI-141 URL: https://jira.jboss.org/jira/browse/JBOSGI-141 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Components: Core Reporter: Thomas Diesler Fix For: Framework 1.0.x and vice versa. * Service --> MC The service layer is not so well integrated with the MC. It does just enough to be "OSGi compliant" (of course that's not yet tested). So this is at the moment very simple. The OSGiServiceState which should eventually turn into an MC context implementation has two "facades", the standard ServiceRegistration and ServiceReference interfaces. * MC --> Service Services are also largely complete. What's missing is that we want to expose MC pojos and JMX MBeans etc. as OSGi services. The proper way to do this would be to push the OSGi Filter into kernel project and use the MDR INSTANCE scope as the attributes. There would be a gotcha in that OSGi expect attributes to have case insensitive names, but we would only have to enforce that for OSGi created services. -- 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

15 years, 3 months

2
15
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-issues June 2010