Tuscany
  1. Tuscany
  2. TUSCANY-2343

OSGi bundle design leads to class loading issues

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Java-SCA-1.x
    • Component/s: None
    • Labels:
      None

      Description

      Currently the design of the OSGi bundles leads to class loading exceptions.

      There seem to be several reasons for this behavior:

      • reexporting of all libraries without version numbers
      • imports without version numbers

      Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project.

      The current status leads to undefined system behaviour due to the OSGi class loading concept.

      Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us.

      The problems occur with the current snapshot release. Sorry, I do not know which version to take.

      1. Libary Versions.xls
        54 kB
        Georg Schmidt
      2. test_bundles.zip
        19 kB
        Daniel Stucky

        Activity

        Hide
        Rajini Sivaram added a comment -

        Hi all,

        I have started a discussion on versioning Tuscany on the dev list (http://markmail.org/message/waiieq6cvhtqb332). Since you have already faced problems resulting from inadequate versioning in Tuscany, your input will be very useful.

        Thank you...

        • Rajini
        Show
        Rajini Sivaram added a comment - Hi all, I have started a discussion on versioning Tuscany on the dev list ( http://markmail.org/message/waiieq6cvhtqb332 ). Since you have already faced problems resulting from inadequate versioning in Tuscany, your input will be very useful. Thank you... Rajini
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        Do you have a date that you would require a bundle-ized Tuscany to be ready by to match with your release dates? It is definitely not going to be ready in time for the 1.3 release - do you require a released version?

        Sebastian,

        The DynamicImport-Package statements in the 3rd party jars are temporary (they were used to generate virtual bundles on the fly), and will be replaced with explicit versioned import statements, probably generated using maven-bundle-plugin. There may be a few dynamic imports left in Tuscany, but they will be specific ones that are not wildcarded.

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, Do you have a date that you would require a bundle-ized Tuscany to be ready by to match with your release dates? It is definitely not going to be ready in time for the 1.3 release - do you require a released version? Sebastian, The DynamicImport-Package statements in the 3rd party jars are temporary (they were used to generate virtual bundles on the fly), and will be replaced with explicit versioned import statements, probably generated using maven-bundle-plugin. There may be a few dynamic imports left in Tuscany, but they will be specific ones that are not wildcarded. Rajini
        Hide
        Sebastian Voigt added a comment -

        Hi Rajini,

        We have seen that all Tuscany bundles declare DynamicImport-Package: *.
        This should be used rare, because it will cause slow classes loading and may cause errors if few bundles will share class with the same name, for example different versions of one class.

        Beside we don't know if this DynamicImport-Package: * is used for Serialization issues
        because we don't understand how Tuscany can find classes to deserialize objects that were transferred with Tuscany

        Thanks in advance

        Sebastian

        Show
        Sebastian Voigt added a comment - Hi Rajini, We have seen that all Tuscany bundles declare DynamicImport-Package: *. This should be used rare, because it will cause slow classes loading and may cause errors if few bundles will share class with the same name, for example different versions of one class. Beside we don't know if this DynamicImport-Package: * is used for Serialization issues because we don't understand how Tuscany can find classes to deserialize objects that were transferred with Tuscany Thanks in advance Sebastian
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        I finally managed to get the SCADomain and our JUnit tests to run locally on my machine (at least inside eclipse. PDEBuild is running as well, but not the JUnit tests).
        With all the small modifications it is just a temporary solution for testing. At the moment it makes no sense to adopt our bundles / 3rd party bundles as long as the Tuscany bundles will change.
        We're looking forward to a clean integration with Tuscany.

        Could you form an estimate when the the bundle versioning and import/exports might be available?
        Besides, it would be great if the Maven build could generate all bundles (Tuscany and Tuscany 3rd party).

        Thanks in advance.

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, I finally managed to get the SCADomain and our JUnit tests to run locally on my machine (at least inside eclipse. PDEBuild is running as well, but not the JUnit tests). With all the small modifications it is just a temporary solution for testing. At the moment it makes no sense to adopt our bundles / 3rd party bundles as long as the Tuscany bundles will change. We're looking forward to a clean integration with Tuscany. Could you form an estimate when the the bundle versioning and import/exports might be available? Besides, it would be great if the Maven build could generate all bundles (Tuscany and Tuscany 3rd party). Thanks in advance. Bye, Daniel
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        yes, you were right. There were some duplicate SDO bundles - the ones provided by Tuscany.
        I'm a little confused now as SDO bundles are included in the Tuscany 3rd party (the ones created by the installer) and SDO bundles in the Maven repository ( referenced in the installers classpath)
        Not noticing it, I had installed both versions in my OSGi runtime:

        MVN repository
        .m2\repository\org\apache\tuscany\sca\tuscany-databinding-sdo\2.0-incubating-SNAPSHOT\tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
        .m2\repository\org\apache\tuscany\sca\tuscany-databinding-sdo-axiom\2.0-incubating-SNAPSHOT\tuscany-databinding-sdo-axiom-2.0-incubating-SNAPSHOT.jar;
        .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-api-r2.1\1.1-incubating\tuscany-sdo-api-r2.1-1.1-incubating.jar;
        .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-impl\1.1-incubating\tuscany-sdo-impl-1.1-incubating.jar;
        .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-lib\1.1-incubating\tuscany-sdo-lib-1.1-incubating.jar;
        .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-tools\1.1-incubating\tuscany-sdo-tools-1.1-incubating.jar;

        3rd party
        org.apache.tuscany.sca.tuscany-sdo-api-r2.1-1.1-incubating.jar
        org.apache.tuscany.sca.tuscany-sdo-impl-1.1-incubating.jar
        org.apache.tuscany.sca.tuscany-sdo-lib-1.1-incubating.jar
        org.apache.tuscany.sca.tuscany-sdo-tools-1.1-incubating.jar

        Which ones are the right ones to use ?

        For testing I just removed the 3rd party bundles (because it's a subset of the others) and now my SCA Domain starts successfully !!!
        Thanks for your help !!!

        Now I'll try to get our JUnit tests run to check execution of the components.

        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, yes, you were right. There were some duplicate SDO bundles - the ones provided by Tuscany. I'm a little confused now as SDO bundles are included in the Tuscany 3rd party (the ones created by the installer) and SDO bundles in the Maven repository ( referenced in the installers classpath) Not noticing it, I had installed both versions in my OSGi runtime: MVN repository .m2\repository\org\apache\tuscany\sca\tuscany-databinding-sdo\2.0-incubating-SNAPSHOT\tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar .m2\repository\org\apache\tuscany\sca\tuscany-databinding-sdo-axiom\2.0-incubating-SNAPSHOT\tuscany-databinding-sdo-axiom-2.0-incubating-SNAPSHOT.jar; .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-api-r2.1\1.1-incubating\tuscany-sdo-api-r2.1-1.1-incubating.jar; .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-impl\1.1-incubating\tuscany-sdo-impl-1.1-incubating.jar; .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-lib\1.1-incubating\tuscany-sdo-lib-1.1-incubating.jar; .m2\repository\org\apache\tuscany\sdo\tuscany-sdo-tools\1.1-incubating\tuscany-sdo-tools-1.1-incubating.jar; 3rd party org.apache.tuscany.sca.tuscany-sdo-api-r2.1-1.1-incubating.jar org.apache.tuscany.sca.tuscany-sdo-impl-1.1-incubating.jar org.apache.tuscany.sca.tuscany-sdo-lib-1.1-incubating.jar org.apache.tuscany.sca.tuscany-sdo-tools-1.1-incubating.jar Which ones are the right ones to use ? For testing I just removed the 3rd party bundles (because it's a subset of the others) and now my SCA Domain starts successfully !!! Thanks for your help !!! Now I'll try to get our JUnit tests run to check execution of the components. Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        Now that is good progress, though obviously not quite enough .

        The exception shows that SDO API bundle is not able to load the class HelperProviderImpl from the SDO implementation bundle. Do you have another copy of SDO bundles (api/impl/lib)? SDO has been packaged as OSGi bundles for a while now, and I think it has been used with Eclipse for sometime. So I didn't want to break it. But the SDO bundles shipped separately use EMF which has a dependency on Eclipse, and I think they require Buddy-Policy for classloading. Tuscany SCA repackages these bundles to avoid the Eclipse dependency (this is probably not an issue for you) and also to enable the bundles to import from each other without requiring Eclipse-specific Buddy-Policy (I think all the SDO bundles need to be buddies).

        If you do have another set of SDO bundles in your environment, you could either uninstall them and use Tuscany's versions or use Buddy-Policy. If you dont have another version of SDO, it must be a different problem altogether...

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, Now that is good progress, though obviously not quite enough . The exception shows that SDO API bundle is not able to load the class HelperProviderImpl from the SDO implementation bundle. Do you have another copy of SDO bundles (api/impl/lib)? SDO has been packaged as OSGi bundles for a while now, and I think it has been used with Eclipse for sometime. So I didn't want to break it. But the SDO bundles shipped separately use EMF which has a dependency on Eclipse, and I think they require Buddy-Policy for classloading. Tuscany SCA repackages these bundles to avoid the Eclipse dependency (this is probably not an issue for you) and also to enable the bundles to import from each other without requiring Eclipse-specific Buddy-Policy (I think all the SDO bundles need to be buddies). If you do have another set of SDO bundles in your environment, you could either uninstall them and use Tuscany's versions or use Buddy-Policy. If you dont have another version of SDO, it must be a different problem altogether... Rajini
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        Thanks again for your help !
        I removed the exporting of META-INF.services in our xerces and xalan bundles. Now the SCADomain starts without errors.
        However, now I get an exception when adding my contribution to the contribution service:

        java.lang.NullPointerException
        at commonj.sdo.impl.HelperProvider.getDefaultContext(HelperProvider.java:388)
        at org.apache.tuscany.sca.databinding.sdo.SDODataBinding$1.run(SDODataBinding.java:67)
        at org.apache.tuscany.sca.databinding.sdo.SDODataBinding$1.run(SDODataBinding.java:66)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:65)
        at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:195)
        at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:250)
        at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper.introspectFaultDataType(JAXWSFaultExceptionMapper.java:240)
        at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.introspectFaultTypes(JAXWSJavaInterfaceProcessor.java:272)
        at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.visitInterface(JAXWSJavaInterfaceProcessor.java:112)
        at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:114)
        at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:55)
        at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.resolveJavaInterface(JavaInterfaceProcessor.java:131)
        at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.resolve(JavaInterfaceProcessor.java:148)
        at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.resolve(JavaInterfaceProcessor.java:50)
        at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:332)
        at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:156)
        at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:405)
        at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:364)
        at org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor.resolve(ComponentTypeProcessor.java:356)
        at org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor.resolve(ComponentTypeProcessor.java:59)
        at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:332)
        at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:156)
        at org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor.resolve(ComponentTypeDocumentProcessor.java:133)
        at org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor.resolve(ComponentTypeDocumentProcessor.java:47)
        at org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProcessorExtensionPoint$LazyURLArtifactProcessor.resolve(DefaultURLArtifactProcessorExtensionPoint.java:208)
        at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106)
        at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:519)
        at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:394)
        at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:187)
        at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:120)
        at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.start(ScaDomainActivator.java:58)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297)

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, Thanks again for your help ! I removed the exporting of META-INF.services in our xerces and xalan bundles. Now the SCADomain starts without errors. However, now I get an exception when adding my contribution to the contribution service: java.lang.NullPointerException at commonj.sdo.impl.HelperProvider.getDefaultContext(HelperProvider.java:388) at org.apache.tuscany.sca.databinding.sdo.SDODataBinding$1.run(SDODataBinding.java:67) at org.apache.tuscany.sca.databinding.sdo.SDODataBinding$1.run(SDODataBinding.java:66) at java.security.AccessController.doPrivileged(Native Method) at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:65) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:195) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:250) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper.introspectFaultDataType(JAXWSFaultExceptionMapper.java:240) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.introspectFaultTypes(JAXWSJavaInterfaceProcessor.java:272) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.visitInterface(JAXWSJavaInterfaceProcessor.java:112) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:114) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:55) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.resolveJavaInterface(JavaInterfaceProcessor.java:131) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.resolve(JavaInterfaceProcessor.java:148) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.resolve(JavaInterfaceProcessor.java:50) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:332) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:156) at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:405) at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:364) at org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor.resolve(ComponentTypeProcessor.java:356) at org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor.resolve(ComponentTypeProcessor.java:59) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:332) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:156) at org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor.resolve(ComponentTypeDocumentProcessor.java:133) at org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor.resolve(ComponentTypeDocumentProcessor.java:47) at org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProcessorExtensionPoint$LazyURLArtifactProcessor.resolve(DefaultURLArtifactProcessorExtensionPoint.java:208) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:519) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:394) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:187) at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:120) at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.start(ScaDomainActivator.java:58) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297) Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        Thank you for doing this. I think we are getting somewhere finally...

        The current set of 3rd party libraries in Tuscany use DynamicImport-Package rather than generate the real list of imported packages at build time. As a result, the import list changes as classes are loaded.

        The Equinox behaviour is correct - there should only be one source for a package, so once the package is imported, it should not search locally.

        You have another version of xerces in your enviroment, with version 2.9.0 (Tuscany provides 2.8.1). It looks like your xerces bundle exports META-INF.services. Since Tuscany's wstx-asl uses "Dynamic-ImportPackage: *", it is getting wired to your xerces bundle version 2.9 while reading some resource in META-INF/services. We will be modifying Tuscany's 3rd party bundles to use proper import/exports which will avoid this problem, but we need to sort out our versioning story first, so that may take a while. In the meantime, would it be possible to modify your xerces bundle to stop exporting META-INF.services? I dont think META-INF/services should be an exported package anyway - it should be private to ensure that bundles can have their own list of services.

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, Thank you for doing this. I think we are getting somewhere finally... The current set of 3rd party libraries in Tuscany use DynamicImport-Package rather than generate the real list of imported packages at build time. As a result, the import list changes as classes are loaded. The Equinox behaviour is correct - there should only be one source for a package, so once the package is imported, it should not search locally. You have another version of xerces in your enviroment, with version 2.9.0 (Tuscany provides 2.8.1). It looks like your xerces bundle exports META-INF.services. Since Tuscany's wstx-asl uses "Dynamic-ImportPackage: *", it is getting wired to your xerces bundle version 2.9 while reading some resource in META-INF/services. We will be modifying Tuscany's 3rd party bundles to use proper import/exports which will avoid this problem, but we need to sort out our versioning story first, so that may take a while. In the meantime, would it be possible to modify your xerces bundle to stop exporting META-INF.services? I dont think META-INF/services should be an exported package anyway - it should be private to ensure that bundles can have their own list of services. Rajini
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        as suggested I debugged the Equinox code and found out different behavior in class org.eclipse.osgi.framework.internal.core.BundleLoader#findResource(String name, boolean checkParent).

        The 1st call does not find a PackageSource, so it falls back to findLocalResource() which locates the class.
        The 2nd call finds a PackageSource via method findImportedSource(pkgName), as this time org.apache.xerces is in the list of imports. It does not contain the desired class. No fallback logic is executed but null is returned.

        Here are some details

        1st call:
        findImportedSource(pkgName);
        imports =

        {com.ctc.wstx.dtd -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.stax -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.io -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2.validation -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.ent -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2.io -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.util -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.sr -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.sw -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2 -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.exc -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.compat -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.sax -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.evt -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.cfg -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2.evt -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.msv -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.dom -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.api -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1"}

        -> source=null

        findRequiredSource(pkgName);
        -> source=null

        findLocalResource(name);
        -> result = bundleresource://27/META-INF/services/javax.xml.stream.XMLInputFactory

        2nd call:
        findImportedSource(pkgName);
        imports =

        {javax.xml.stream.events -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1", javax.xml.stream.util -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1", org.apache.log4j -> org.apache.tuscany.sca.3rdparty.log4j-1.2.12; bundle-version="1.2.12", javax.xml.stream -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1", META-INF.services -> org.apache.xerces; bundle-version="2.9.0"}

        -> source = META-INF.services -> org.apache.xerces; bundle-version="2.9.0"
        -> result = null

        So the questions are:

        • why is the list of imports different ?
        • is there a bug in the execution logic of org.eclipse.osgi.framework.internal.core.BundleLoader#findResource(String name, boolean checkParent). The search is terminated, as the comment "// 3) found import source terminate search at the source" clearly says. Perhaps it should continue the search nothing is found ?

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, as suggested I debugged the Equinox code and found out different behavior in class org.eclipse.osgi.framework.internal.core.BundleLoader#findResource(String name, boolean checkParent). The 1st call does not find a PackageSource, so it falls back to findLocalResource() which locates the class. The 2nd call finds a PackageSource via method findImportedSource(pkgName), as this time org.apache.xerces is in the list of imports. It does not contain the desired class. No fallback logic is executed but null is returned. Here are some details 1st call: findImportedSource(pkgName); imports = {com.ctc.wstx.dtd -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.stax -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.io -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2.validation -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.ent -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2.io -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.util -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.sr -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.sw -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2 -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.exc -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.compat -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.sax -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.evt -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.cfg -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", org.codehaus.stax2.evt -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.msv -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.dom -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1", com.ctc.wstx.api -> org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1; bundle-version="3.2.1"} -> source=null findRequiredSource(pkgName); -> source=null findLocalResource(name); -> result = bundleresource://27/META-INF/services/javax.xml.stream.XMLInputFactory 2nd call: findImportedSource(pkgName); imports = {javax.xml.stream.events -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1", javax.xml.stream.util -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1", org.apache.log4j -> org.apache.tuscany.sca.3rdparty.log4j-1.2.12; bundle-version="1.2.12", javax.xml.stream -> org.apache.tuscany.sca.3rdparty.stax-api-1.0.1; bundle-version="1.0.1", META-INF.services -> org.apache.xerces; bundle-version="2.9.0"} -> source = META-INF.services -> org.apache.xerces; bundle-version="2.9.0" -> result = null So the questions are: why is the list of imports different ? is there a bug in the execution logic of org.eclipse.osgi.framework.internal.core.BundleLoader#findResource(String name, boolean checkParent). The search is terminated, as the comment "// 3) found import source terminate search at the source" clearly says. Perhaps it should continue the search nothing is found ? Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        I have been staring at OSGiBundleActivator$BundleClassLoader.getResource hoping that something will strike me, but I just can't find any problem with it. I would have been happier if this was a rare timing related issue, but obviously it isn't.

        bundle.getResource() should only return null if 1) the resource is not present 2) the bundle is not resolved or 3) the caller doesn't have permissions. I can't imagine any of these changing between the two calls in such a consistent way. It obviously looks like some code during Tuscany startup is having an impact, but I have no idea what it could be.

        If you have Equinox source on your machine, it will be useful to step through the "bundle.getResource" call in OSGiBundleActivator$BundleClassLoader.getResource for the bundle org.apache.tuscany.sca.wstx-asl-3.2.1.jar in the failing case.

        Otherwise, maybe compare this setup with your test setup - I am still confused as to why this didn't fail with your test since the same Tuscany code was executed with both - in very similar environments perhaps?

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, I have been staring at OSGiBundleActivator$BundleClassLoader.getResource hoping that something will strike me, but I just can't find any problem with it. I would have been happier if this was a rare timing related issue, but obviously it isn't. bundle.getResource() should only return null if 1) the resource is not present 2) the bundle is not resolved or 3) the caller doesn't have permissions. I can't imagine any of these changing between the two calls in such a consistent way. It obviously looks like some code during Tuscany startup is having an impact, but I have no idea what it could be. If you have Equinox source on your machine, it will be useful to step through the "bundle.getResource" call in OSGiBundleActivator$BundleClassLoader.getResource for the bundle org.apache.tuscany.sca.wstx-asl-3.2.1.jar in the failing case. Otherwise, maybe compare this setup with your test setup - I am still confused as to why this didn't fail with your test since the same Tuscany code was executed with both - in very similar environments perhaps? Rajini
        Hide
        Daniel Stucky added a comment -

        One more comment:

        During the 1st call the URL is found in bundle org.apache.tuscany.sca.wstx-asl-3.2.1.jar
        During the 2nd call this bundle is listet in bundles, but the URL is not found!

        Daniel

        Show
        Daniel Stucky added a comment - One more comment: During the 1st call the URL is found in bundle org.apache.tuscany.sca.wstx-asl-3.2.1.jar During the 2nd call this bundle is listet in bundles, but the URL is not found! Daniel
        Hide
        Daniel Stucky added a comment -

        I was not able to set a breakpoint in method findClass(...). Eclipse did just not allow it. It was possible in all other methods, though.

        Here are the results of the breakpoint in getResource(...) and following code

        1st call:
        OSGiBundleActivator$BundleClassLoader (id=84)
        bundle.size() = 230
        resName=META-INF/services/javax.xml.stream.XMLInputFactory
        URL=bundleresource://52/META-INF/services/javax.xml.stream.XMLInputFactory
        factoryClassname=com.ctc.wstx.stax.WstxInputFactory

        2nd call:
        OSGiBundleActivator$BundleClassLoader (id=84)
        bundle.size() = 230
        resName=META-INF/services/javax.xml.stream.XMLInputFactory
        URL=null

        As you can see, the URL in the 2nd call is null.

        Show
        Daniel Stucky added a comment - I was not able to set a breakpoint in method findClass(...). Eclipse did just not allow it. It was possible in all other methods, though. Here are the results of the breakpoint in getResource(...) and following code 1st call: OSGiBundleActivator$BundleClassLoader (id=84) bundle.size() = 230 resName=META-INF/services/javax.xml.stream.XMLInputFactory URL=bundleresource://52/META-INF/services/javax.xml.stream.XMLInputFactory factoryClassname=com.ctc.wstx.stax.WstxInputFactory 2nd call: OSGiBundleActivator$BundleClassLoader (id=84) bundle.size() = 230 resName=META-INF/services/javax.xml.stream.XMLInputFactory URL=null As you can see, the URL in the 2nd call is null.
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        Could you run the test through the debugger with breakpoints on the line " javax.xml.stream.XMLInputFactory.newInstance(); " in both the cases? When you get to this line, could you set breakpoints on the methods "getResource" and "findClass" in OSGiBundleActivator.BundleClassLoader? I would like to make sure that
        1) The same OSGiBundleActivator$BundleClassLoader object is used in both cases
        2) The "bundles" field of this object contains around 200 bundles
        3) getResource("META-INF/services/javax.xml.stream.XMLInputFactory") when called returns a valid URL in both cases
        4) findClass("com.ctc.wstx.stax.WstxInputFactory") should get called in both cases, and should return a class from the bundle (the first return statement).

        Sorry, I really dont have a clue what is broken...

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, Could you run the test through the debugger with breakpoints on the line " javax.xml.stream.XMLInputFactory.newInstance(); " in both the cases? When you get to this line, could you set breakpoints on the methods "getResource" and "findClass" in OSGiBundleActivator.BundleClassLoader? I would like to make sure that 1) The same OSGiBundleActivator$BundleClassLoader object is used in both cases 2) The "bundles" field of this object contains around 200 bundles 3) getResource("META-INF/services/javax.xml.stream.XMLInputFactory") when called returns a valid URL in both cases 4) findClass("com.ctc.wstx.stax.WstxInputFactory") should get called in both cases, and should return a class from the bundle (the first return statement). Sorry, I really dont have a clue what is broken... Rajini
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        I added your code snippet. Here is the output:

        output of 1st snippet just before scaDomain.start(). no exception is thrown

        • TCCL : class org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader

        output of 2nd snippet in catch block after scaDomain.start()

        • TCCL : class org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader
          but this time javax.xml.stream.XMLInputFactory.newInstance() throws the following exception
        • javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, I added your code snippet. Here is the output: output of 1st snippet just before scaDomain.start(). no exception is thrown TCCL : class org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader output of 2nd snippet in catch block after scaDomain.start() TCCL : class org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader but this time javax.xml.stream.XMLInputFactory.newInstance() throws the following exception javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        It still looks like a problem with TCCL, though I dont know why. I think it is too early to be related to the JAXB issue.

        Can you add a try-catch block in ScaDomainActivator.initDomainByContribution around the code which creates and starts the SCA domain, and include this snippet of code twice - just before calling EmbeddedSCADomain.start after you have set TCCL, and in the catch block.

        try

        { System.out.println("TCCL : " + Thread.currentThread().getContextClassLoader().getClass()); javax.xml.stream.XMLInputFactory.newInstance(); }

        catch (Throwable e)

        { e.printStackTrace(); }

        I would expect to see the print "TCCL : class org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader" and no exception thrown from the call in both cases if it works.

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, It still looks like a problem with TCCL, though I dont know why. I think it is too early to be related to the JAXB issue. Can you add a try-catch block in ScaDomainActivator.initDomainByContribution around the code which creates and starts the SCA domain, and include this snippet of code twice - just before calling EmbeddedSCADomain.start after you have set TCCL, and in the catch block. try { System.out.println("TCCL : " + Thread.currentThread().getContextClassLoader().getClass()); javax.xml.stream.XMLInputFactory.newInstance(); } catch (Throwable e) { e.printStackTrace(); } I would expect to see the print "TCCL : class org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader" and no exception thrown from the call in both cases if it works. Rajini
        Hide
        Daniel Stucky added a comment -

        Hi,

        yes, the activator sets TCCL and I also use option -clean.

        The difference is in line 3:

        at org.apache.tuscany.sca.extension.helper.impl.BindingsActivator.start(BindingsActivator.java:72) (former exception)
        vs.
        at org.apache.tuscany.sca.implementation.notification.NotificationModuleActivator.start(NotificationModuleActivator.java:34) (current exception)

        I debugged a little, it happens when Tuscany tries to find the interface org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessorExtensionPoint.
        Perhaps this is somehow related to the problems we encountered with JAXB ?

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi, yes, the activator sets TCCL and I also use option -clean. The difference is in line 3: at org.apache.tuscany.sca.extension.helper.impl.BindingsActivator.start(BindingsActivator.java:72) (former exception) vs. at org.apache.tuscany.sca.implementation.notification.NotificationModuleActivator.start(NotificationModuleActivator.java:34) (current exception) I debugged a little, it happens when Tuscany tries to find the interface org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessorExtensionPoint. Perhaps this is somehow related to the problems we encountered with JAXB ? Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        I am not sure I missed something, but this stack trace looks exactly the same as the previous one.

        Does org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator set TCCL before calling EmbeddedSCADomain.start? If so, is it possible that this bundle is being loaded from the cache (could you try -clean option)? I will try to fix this in Tuscany this weekend, but at the moment it would be safest to set TCCL in all your bundle activators starting SCADomains.

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, I am not sure I missed something, but this stack trace looks exactly the same as the previous one. Does org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator set TCCL before calling EmbeddedSCADomain.start? If so, is it possible that this bundle is being loaded from the cache (could you try -clean option)? I will try to fix this in Tuscany this weekend, but at the moment it would be safest to set TCCL in all your bundle activators starting SCADomains. Rajini
        Hide
        Daniel Stucky added a comment -

        Hi all,

        I just set up a launch configuration for our "productive" bundle.
        Whitout the Activator fix from Rajini I get the same exception as in the "test" bundle. (see above)

        Then I added the to the activator and now I get the following exception:

        java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
        at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:128)
        at org.apache.tuscany.sca.implementation.notification.NotificationModuleActivator.start(NotificationModuleActivator.java:34)
        at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.startModules(ReallySmallRuntime.java:354)
        at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:139)
        at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79)
        at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:96)
        at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.start(ScaDomainActivator.java:57)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297)
        Caused by: java.lang.reflect.InvocationTargetException
        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:494)
        at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:113)
        ... 19 more
        Caused by: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
        at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:122)
        at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.<init>(DefaultStAXArtifactProcessorExtensionPoint.java:68)
        ... 24 more
        Caused by: java.lang.reflect.InvocationTargetException
        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:585)
        at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:120)
        ... 25 more
        Caused by: javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
        at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
        at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178)
        at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
        at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
        ... 30 more

        Are there other Threads that need to get set the ContextClassLoader ?

        Daniel

        Show
        Daniel Stucky added a comment - Hi all, I just set up a launch configuration for our "productive" bundle. Whitout the Activator fix from Rajini I get the same exception as in the "test" bundle. (see above) Then I added the to the activator and now I get the following exception: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:128) at org.apache.tuscany.sca.implementation.notification.NotificationModuleActivator.start(NotificationModuleActivator.java:34) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.startModules(ReallySmallRuntime.java:354) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:139) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79) at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:96) at org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.start(ScaDomainActivator.java:57) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297) Caused by: java.lang.reflect.InvocationTargetException 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:494) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:113) ... 19 more Caused by: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:122) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.<init>(DefaultStAXArtifactProcessorExtensionPoint.java:68) ... 24 more Caused by: java.lang.reflect.InvocationTargetException 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:585) at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:120) ... 25 more Caused by: javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136) ... 30 more Are there other Threads that need to get set the ContextClassLoader ? Daniel
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        yes, calling
        Thread.currentThread().setContextClassLoader(OSGiRuntime.getRuntime().getContextClassLoader());
        befor creating the SCADomain does the trick. At least for this test bundle.

        I will do some more testing with our real bundles (more 3rd party dependencies).

        Thanks a lot!

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, yes, calling Thread.currentThread().setContextClassLoader(OSGiRuntime.getRuntime().getContextClassLoader()); befor creating the SCADomain does the trick. At least for this test bundle. I will do some more testing with our real bundles (more 3rd party dependencies). Thanks a lot! Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        The latest stack trace looks like a problem with thread context classloading. For XML parsing, the classes from third party bundles should be visible from TCCL. Tuscany's bundle activator sets up a TCCL which includes all 3rd party bundles. If this bundle activator is run from a different thread from the one starting the Tuscany runtime (or if you want to modify TCCL), you have to ensure that TCCL has access to classes from 3rd party libs. The TCCL set by Tuscany can be obtained using o.a.t.s.osgi.runtime.OSGiRuntime.getContextClassLoader(). In your test bundle activator, could you try calling
        Thread.currentThread().setContextClassLoader(OSGiRuntime.getContextClassLoader());

        before starting the Tuscany runtime? This should really be fixed properly in Tuscany (at least for straightforward usecases), but for now, could you try this fix?

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, The latest stack trace looks like a problem with thread context classloading. For XML parsing, the classes from third party bundles should be visible from TCCL. Tuscany's bundle activator sets up a TCCL which includes all 3rd party bundles. If this bundle activator is run from a different thread from the one starting the Tuscany runtime (or if you want to modify TCCL), you have to ensure that TCCL has access to classes from 3rd party libs. The TCCL set by Tuscany can be obtained using o.a.t.s.osgi.runtime.OSGiRuntime.getContextClassLoader(). In your test bundle activator, could you try calling Thread.currentThread().setContextClassLoader(OSGiRuntime.getContextClassLoader()); before starting the Tuscany runtime? This should really be fixed properly in Tuscany (at least for straightforward usecases), but for now, could you try this fix? Rajini
        Hide
        Daniel Stucky added a comment -

        Hi,

        I just tried to install and start the same bundles as when using the installer. To achieve this, I had to remove the Import-Package entry for "sun.misc" in tuscany-databinding-xstream-2.0-incubating-SNAPSHOT.jar

        Below is the list, the only difference is that when using the installer it's bundle is started and bundle org.eclipse.eilf.scatestdomain_0.5.0 is started:

        id State Bundle
        0 ACTIVE org.eclipse.osgi_3.3.0.v20070530
        1 RESOLVED org.apache.tuscany.sca.binding.jms_2.0.0
        2 RESOLVED org.apache.tuscany.sca.3rdparty.commons-lang-2.1_2.1.0
        3 RESOLVED org.apache.tuscany.sca.binding.rss.rome_2.0.0
        4 RESOLVED org.apache.tuscany.sca.api_2.0.0
        5 RESOLVED org.apache.tuscany.sca.3rdparty.saxon-api-9.0.0.2_9.0.0.2
        6 RESOLVED org.apache.tuscany.sca.definitions.xml_2.0.0
        7 RESOLVED org.apache.tuscany.sca.implementation.java.runtime_2.0.0
        8 RESOLVED org.apache.tuscany.sca.domain.manager_2.0.0
        9 RESOLVED org.apache.tuscany.sca.3rdparty.commons-discovery-0.2_0.2.0
        10 RESOLVED org.apache.tuscany.sca.3rdparty.xalan-2.7.0_2.7.0
        11 RESOLVED org.apache.tuscany.sca.data.engine.helper_2.0.0
        12 RESOLVED org.apache.tuscany.sca.3rdparty.json-rpc-1.0_1.0.0
        13 RESOLVED org.apache.tuscany.sca.implementation.java_2.0.0
        14 RESOLVED org.apache.tuscany.sca.interface.wsdl.xml_2.0.0
        15 RESOLVED org.apache.tuscany.sca.binding.sca.axis2_2.0.0
        16 RESOLVED org.apache.tuscany.sca.3rdparty.stax-api-1.0.1_1.0.1
        17 RESOLVED org.apache.tuscany.sca.3rdparty.ecore-2.2.3_2.2.3
        18 RESOLVED org.apache.tuscany.sca.3rdparty.codegen-ecore-2.2.3_2.2.3
        19 RESOLVED org.apache.tuscany.sca.3rdparty.stax-api-1.0-2_1.0.0
        20 RESOLVED org.apache.tuscany.sca.3rdparty.axiom-api-1.2.5_1.2.5
        21 RESOLVED org.apache.tuscany.sca.3rdparty.abdera-parser-0.3.0-incubating_0.3.0
        22 RESOLVED org.apache.tuscany.sca.3rdparty.commons-collections-3.1_3.1.0
        23 RESOLVED org.apache.tuscany.sca.3rdparty.backport-util-concurrent-3.0_3.0.0
        24 RESOLVED org.apache.tuscany.sca.binding.sca_2.0.0
        25 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-codegen-1.3_1.3.0
        26 RESOLVED org.apache.tuscany.sdo.spec_2.1.0
        27 RESOLVED org.apache.tuscany.sca.3rdparty.easymock-2.2_2.2.0
        28 RESOLVED org.apache.tuscany.sca.binding.rss_2.0.0
        29 RESOLVED org.apache.tuscany.sca.3rdparty.jaxb2-reflection-2.1.4_2.1.4
        30 RESOLVED org.apache.tuscany.sca.3rdparty.xercesImpl-2.8.1_2.8.1
        31 ACTIVE org.eclipse.osgi.services_3.1.200.v20070605
        32 RESOLVED org.apache.tuscany.sca.databinding.saxon_2.0.0
        33 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-adb-codegen-1.3_1.3.0
        34 RESOLVED org.apache.tuscany.sca.3rdparty.spring-beans-2.0.6_2.0.6
        35 RESOLVED org.mortbay.jetty.server_6.1.7
        36 RESOLVED org.apache.tuscany.sca.contribution_2.0.0
        37 RESOLVED org.apache.tuscany.sca.3rdparty.activation-1.1_1.1.0
        38 RESOLVED org.apache.tuscany.sca.workspace_2.0.0
        39 RESOLVED org.apache.tuscany.sca.interface.java.xml_2.0.0
        40 RESOLVED org.apache.tuscany.sca.binding.feed_2.0.0
        41 RESOLVED org.apache.tuscany.sca.3rdparty.servlet-api-2.5_2.5.0
        42 RESOLVED org.apache.tuscany.sca.3rdparty.mail-1.4_1.4.0
        43 RESOLVED org.apache.tuscany.sca.3rdparty.abdera-core-0.3.0-incubating_0.3.0
        44 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-mtompolicy-1.3_1.3.0
        45 RESOLVED org.apache.tuscany.sca.3rdparty.wsdl4j-1.6.2_1.6.2
        46 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-java2wsdl-1.3_1.3.0
        47 RESOLVED org.apache.tuscany.sca.3rdparty.rampart-trust-1.3_1.3.0
        48 RESOLVED org.apache.tuscany.sca.contribution.groovy_2.0.0
        49 RESOLVED org.apache.tuscany.sca.binding.atom_2.0.0
        50 RESOLVED org.apache.tuscany.sca.3rdparty.saaj-api-1.3_1.3.0
        51 RESOLVED org.apache.tuscany.sca.assembly.xsd_2.0.0
        52 RESOLVED org.apache.tuscany.sca.implementation.xquery_2.0.0
        53 RESOLVED org.apache.tuscany.sca.3rdparty.tuscany-sdo-impl-1.1-incubating_1.1.0
        54 RESOLVED org.apache.tuscany.sca.binding.dwr_2.0.0
        55 RESOLVED org.apache.tuscany.sca.monitor.logging_2.0.0
        56 RESOLVED org.apache.tuscany.sca.3rdparty.woden-1.0-incubating-M7b_1.0.0
        57 RESOLVED org.apache.tuscany.sca.binding.atom.abdera_2.0.0
        58 RESOLVED org.apache.tuscany.sca.definitions_2.0.0
        59 RESOLVED org.apache.tuscany.sca.3rdparty.tuscany-sdo-tools-1.1-incubating_1.1.0
        60 RESOLVED org.apache.tuscany.sca.binding.jsonrpc_2.0.0
        61 RESOLVED org.apache.tuscany.sca.3rdparty.commons-httpclient-3.0.1_3.0.1
        62 RESOLVED org.apache.tuscany.sca.implementation.das_2.0.0
        63 RESOLVED org.apache.tuscany.sca.3rdparty.ecore-xmi-2.2.3_2.2.3
        64 RESOLVED org.apache.tuscany.sca.extension.helper_2.0.0
        65 RESOLVED org.apache.tuscany.sca.3rdparty.axiom-dom-1.2.5_1.2.5
        66 RESOLVED org.apache.tuscany.sca.implementation.spring_2.0.0
        67 RESOLVED org.apache.tuscany.sca.3rdparty.aopalliance-1.0_1.0.0
        68 RESOLVED org.apache.tuscany.sca.3rdparty.saxon-dom-9.0.0.2_9.0.0.2
        69 RESOLVED org.apache.tuscany.sca.implementation.osgi_2.0.0
        70 RESOLVED org.apache.tuscany.sca.3rdparty.xml-apis-1.3.03_1.3.3
        71 RESOLVED org.apache.tuscany.sca.binding.ws.xml_2.0.0
        72 RESOLVED org.apache.tuscany.sca.3rdparty.axiom-impl-1.2.5_1.2.5
        73 RESOLVED org.apache.tuscany.sca.binding.rmi_2.0.0
        74 RESOLVED org.apache.tuscany.sca.3rdparty.activeio-core-3.0.0-incubator_3.0.0
        75 RESOLVED org.apache.tuscany.sca.host.http_2.0.0
        76 RESOLVED org.apache.tuscany.sca.3rdparty.abdera-i18n-0.3.0-incubating_0.3.0
        77 RESOLVED org.apache.tuscany.sca.endpoint_2.0.0
        78 RESOLVED org.apache.tuscany.sca.policy.xml_2.0.0
        79 RESOLVED org.apache.tuscany.sca.databinding.xstream_2.0.0
        80 RESOLVED org.apache.tuscany.sca.3rdparty.ecore-change-2.2.3_2.2.3
        81 RESOLVED org.apache.tuscany.sca.workspace.impl_2.0.0
        82 RESOLVED org.apache.tuscany.sca.3rdparty.spring-core-2.0.6_2.0.6
        83 RESOLVED org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1_3.2.1
        84 RESOLVED org.apache.tuscany.sca.3rdparty.xsd-2.2.3_2.2.3
        85 ACTIVE org.eclipse.equinox.ds_1.0.0.qualifier
        86 RESOLVED org.apache.tuscany.sca.3rdparty.commons-fileupload-1.2_1.2.0
        87 RESOLVED org.apache.tuscany.sca.3rdparty.commons-io-1.2_1.2.0
        88 RESOLVED org.apache.tuscany.sca.workspace.xml_2.0.0
        89 RESOLVED org.apache.tuscany.sca.node.impl_2.0.0
        90 RESOLVED org.apache.tuscany.sca.3rdparty.tuscany-das-rdb-1.0-incubating-SNAPSHOT_1.0.0
        91 ACTIVE org.apache.tuscany.sca.osgi.runtime_2.0.0
        92 RESOLVED org.apache.tuscany.sca.domain_2.0.0
        93 RESOLVED org.apache.tuscany.sca.databinding.xmlbeans_2.0.0
        94 RESOLVED org.apache.tuscany.sca.contribution.java_2.0.0
        95 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-javamail_1.4_spec-1.0-M1_1.0.0
        96 RESOLVED org.apache.tuscany.sca.policy.security_2.0.0
        97 RESOLVED org.apache.tuscany.sca.policy.logging_2.0.0
        98 RESOLVED org.apache.tuscany.sca.3rdparty.codegen-2.2.3_2.2.3
        99 RESOLVED org.apache.tuscany.sca.3rdparty.xmlbeans-2.3.0_2.3.0
        100 RESOLVED org.apache.tuscany.sca.3rdparty.junit-4.2_4.2.0
        101 RESOLVED org.apache.tuscany.sca.3rdparty.opensaml-1.1_1.1.0
        102 RESOLVED org.apache.tuscany.sca.databinding.axiom_2.0.0
        103 RESOLVED org.apache.tuscany.sca.contribution.impl_2.0.0
        104 RESOLVED org.apache.tuscany.sca.3rdparty.jdom-1.0_1.0.0
        105 RESOLVED org.apache.tuscany.sca.host.jetty_2.0.0
        106 RESOLVED org.apache.tuscany.sca.3rdparty.spring-context-2.0.6_2.0.6
        107 RESOLVED org.apache.tuscany.sca.core.spi_2.0.0
        108 RESOLVED org.apache.tuscany.sca.3rdparty.jsr250-api-1.0_1.0.0
        109 RESOLVED org.apache.tuscany.sca.xsd.xml_2.0.0
        110 RESOLVED org.apache.tuscany.sca.3rdparty.rome-0.9_0.9.0
        111 RESOLVED org.apache.tuscany.sca.implementation.data.api_2.0.0
        112 ACTIVE org.eclipse.eilf.scatest_0.5.0
        113 RESOLVED org.apache.tuscany.sca.implementation.resource_2.0.0
        114 ACTIVE org.eclipse.equinox.util_1.0.0.qualifier
        115 RESOLVED org.apache.tuscany.sca.xsd_2.0.0
        116 RESOLVED org.apache.tuscany.sca.databinding.fastinfoset_2.0.0
        117 RESOLVED org.apache.tuscany.sca.3rdparty.XmlSchema-1.3.2_1.3.2
        118 RESOLVED org.apache.tuscany.sca.3rdparty.jaxb-api-2.1_2.1.0
        119 RESOLVED org.apache.tuscany.sca.core_2.0.0
        120 RESOLVED org.eclipse.eilf.scatestdomain_0.5.0
        121 RESOLVED org.apache.tuscany.sca.implementation.notification_2.0.0
        122 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-adb-1.3_1.3.0
        123 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-ejb_3.0_spec-1.0_1.0.0
        125 RESOLVED org.apache.tuscany.sca.policy.xml.ws_2.0.0
        126 RESOLVED org.apache.tuscany.sca.node.api_2.0.0
        127 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-activation_1.0.2_spec-1.1_1.1.0
        128 RESOLVED org.apache.tuscany.sca.3rdparty.neethi-2.0.2_2.0.2
        129 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-jms_1.1_spec-1.1_1.1.0
        130 RESOLVED org.apache.tuscany.sca.3rdparty.jaxws-api-2.1_2.1.0
        131 RESOLVED org.apache.tuscany.sca.databinding.sdo_2.0.0
        132 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-kernel-1.3_1.3.0
        133 RESOLVED org.apache.tuscany.sca.3rdparty.cglib-nodep-2.1_3_2.1.0
        134 RESOLVED org.apache.tuscany.sca.assembly.xml_2.0.0
        135 RESOLVED org.apache.tuscany.sca.binding.notification_2.0.0
        136 RESOLVED org.apache.tuscany.sca.3rdparty.jettison-1.0_1.0.0
        137 RESOLVED org.apache.tuscany.sca.3rdparty.logkit-1.0.1_1.0.1
        138 ACTIVE org.codehaus.groovy_1.5.4
        139 RESOLVED org.apache.tuscany.sca.host.embedded_2.0.0
        140 RESOLVED org.apache.tuscany.sca.3rdparty.bsf-all-3.0-beta2_3.0.0
        141 RESOLVED org.apache.tuscany.sca.contribution.osgi_2.0.0
        142 RESOLVED org.apache.tuscany.sca.extensibility_2.0.0
        143 RESOLVED org.apache.tuscany.sca.policy.security.ws_2.0.0
        144 RESOLVED org.apache.tuscany.sca.databinding.sdo.axiom_2.0.0
        145 RESOLVED org.apache.tuscany.sca.3rdparty.bcprov-jdk15-132_132.0.0
        146 RESOLVED org.apache.tuscany.sca.implementation.node.xml_2.0.0
        147 RESOLVED org.apache.tuscany.sca.monitor_2.0.0
        148 RESOLVED org.apache.tuscany.sca.3rdparty.log4j-1.2.12_1.2.12
        149 RESOLVED org.apache.tuscany.sca.3rdparty.rampart-policy-1.3_1.3.0
        150 RESOLVED org.apache.tuscany.sca.interface.java.jaxws_2.0.0
        151 RESOLVED org.apache.tuscany.sca.databinding.jaxb.axiom_2.0.0
        152 RESOLVED org.apache.tuscany.sca.implementation.widget_2.0.0
        153 RESOLVED org.apache.tuscany.sca.contribution.resource_2.0.0
        154 RESOLVED org.apache.tuscany.sca.3rdparty.wss4j-1.5.3_1.5.3
        155 RESOLVED org.apache.tuscany.sca.core.databinding_2.0.0
        156 RESOLVED org.apache.tuscany.sca.3rdparty.jaxen-1.1-beta-9_1.1.0
        157 RESOLVED org.apache.tuscany.sca.3rdparty.jsr181-api-1.0-MR1_1.0.0
        158 RESOLVED org.apache.tuscany.sca.3rdparty.jruby-complete-1.0_1.0.0
        159 RESOLVED org.apache.tuscany.sca.databinding.jaxb_2.0.0
        160 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-commonj_1.1_spec-1.0_1.0.0
        161 RESOLVED org.apache.tuscany.sca.3rdparty.common-2.2.3_2.2.3
        162 RESOLVED org.apache.tuscany.sca.3rdparty.annogen-0.1.0_0.1.0
        163 RESOLVED org.apache.tuscany.sca.interface_2.0.0
        164 RESOLVED org.apache.tuscany.sca.3rdparty.FastInfoset-1.2.2_1.2.2
        165 RESOLVED org.apache.tuscany.sca.3rdparty.jaxb-impl-2.1.6_2.1.6
        166 RESOLVED org.apache.tuscany.sca.3rdparty.js-1.6R7_1.6.0
        167 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-activation_1.1_spec-1.0-M1_1.0.0
        168 RESOLVED org.apache.tuscany.sca.interface.java_2.0.0
        169 RESOLVED org.apache.tuscany.sca.3rdparty.rampart-core-1.3_1.3.0
        170 RESOLVED org.apache.tuscany.sca.binding.ws_2.0.0
        171 RESOLVED org.apache.tuscany.sca.databinding_2.0.0
        172 RESOLVED org.apache.tuscany.sca.binding.ws.axis2_2.0.0
        173 RESOLVED org.apache.tuscany.sca.binding.http_2.0.0
        174 RESOLVED org.apache.tuscany.sca.3rdparty.jython-2.2_2.2.0
        175 RESOLVED org.apache.tuscany.sca.3rdparty.xstream-1.3_1.3.0
        176 RESOLVED org.apache.tuscany.sca.binding.sca.xml_2.0.0
        177 RESOLVED org.apache.tuscany.sca.host.rmi_2.0.0
        178 RESOLVED org.apache.tuscany.sca.policy_2.0.0
        179 RESOLVED org.apache.tuscany.sca.3rdparty.commons-logging-1.1_1.1.0
        180 RESOLVED org.apache.tuscany.sca.3rdparty.xmlsec-1.4.0_1.4.0
        181 RESOLVED org.apache.tuscany.sca.node_2.0.0
        182 RESOLVED org.apache.tuscany.sca.3rdparty.apache-activemq-4.1.1_4.1.1
        183 RESOLVED org.apache.tuscany.sca.assembly_2.0.0
        184 RESOLVED org.apache.tuscany.sca.contribution.xml_2.0.0
        185 RESOLVED org.apache.tuscany.sca.interface.wsdl_2.0.0
        186 RESOLVED org.apache.tuscany.sca.contribution.namespace_2.0.0
        187 RESOLVED org.apache.tuscany.sdo.lib_1.0.0
        189 RESOLVED org.apache.tuscany.sca.3rdparty.commons-cli-1.0_1.0.0
        190 RESOLVED org.mortbay.jetty.util_6.1.7
        191 RESOLVED org.apache.tuscany.sca.3rdparty.httpcore-niossl-4.0-alpha5_4.0.0
        192 RESOLVED org.apache.tuscany.sca.3rdparty.xpp3_min-1.1.4c_1.1.4
        193 RESOLVED org.apache.tuscany.sca.domain.impl_2.0.0
        194 RESOLVED org.apache.tuscany.sca.implementation.node_2.0.0
        195 RESOLVED org.apache.tuscany.sca.databinding.json_2.0.0
        196 RESOLVED org.apache.tuscany.sca.3rdparty.commons-codec-1.3_1.3.0
        197 RESOLVED org.apache.tuscany.sca.interface.wsdl.java2wsdl_2.0.0
        198 RESOLVED org.apache.tuscany.sca.domain.api_2.0.0
        199 RESOLVED org.apache.tuscany.sca.3rdparty.httpcore-4.0-alpha5_4.0.0
        200 RESOLVED org.apache.tuscany.sca.implementation.java.xml_2.0.0
        201 RESOLVED org.apache.tuscany.sca.implementation.script_2.0.0
        202 RESOLVED org.apache.tuscany.sca.3rdparty.dwr-2.0.1_2.0.1
        203 RESOLVED org.apache.tuscany.sca.3rdparty.httpcore-nio-4.0-alpha5_4.0.0
        204 RESOLVED org.apache.tuscany.sca.3rdparty.saxon-9.0.0.2_9.0.0.2

        This time I get the following exception:

        java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
        at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:128)
        at org.apache.tuscany.sca.extension.helper.impl.BindingsActivator.start(BindingsActivator.java:72)
        at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.startModules(ReallySmallRuntime.java:354)
        at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:139)
        at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79)
        at org.eclipse.eilf.scatestdomain.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:103)
        at org.eclipse.eilf.scatestdomain.ScaDomainActivator.start(ScaDomainActivator.java:59)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297)
        Caused by: java.lang.reflect.InvocationTargetException
        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:494)
        at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:113)
        ... 19 more
        Caused by: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
        at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:122)
        at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.<init>(DefaultStAXArtifactProcessorExtensionPoint.java:68)
        ... 24 more
        Caused by: java.lang.reflect.InvocationTargetException
        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:585)
        at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:120)
        ... 25 more
        Caused by: javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
        at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
        at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178)
        at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
        at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
        ... 30 more

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi, I just tried to install and start the same bundles as when using the installer. To achieve this, I had to remove the Import-Package entry for "sun.misc" in tuscany-databinding-xstream-2.0-incubating-SNAPSHOT.jar Below is the list, the only difference is that when using the installer it's bundle is started and bundle org.eclipse.eilf.scatestdomain_0.5.0 is started: id State Bundle 0 ACTIVE org.eclipse.osgi_3.3.0.v20070530 1 RESOLVED org.apache.tuscany.sca.binding.jms_2.0.0 2 RESOLVED org.apache.tuscany.sca.3rdparty.commons-lang-2.1_2.1.0 3 RESOLVED org.apache.tuscany.sca.binding.rss.rome_2.0.0 4 RESOLVED org.apache.tuscany.sca.api_2.0.0 5 RESOLVED org.apache.tuscany.sca.3rdparty.saxon-api-9.0.0.2_9.0.0.2 6 RESOLVED org.apache.tuscany.sca.definitions.xml_2.0.0 7 RESOLVED org.apache.tuscany.sca.implementation.java.runtime_2.0.0 8 RESOLVED org.apache.tuscany.sca.domain.manager_2.0.0 9 RESOLVED org.apache.tuscany.sca.3rdparty.commons-discovery-0.2_0.2.0 10 RESOLVED org.apache.tuscany.sca.3rdparty.xalan-2.7.0_2.7.0 11 RESOLVED org.apache.tuscany.sca.data.engine.helper_2.0.0 12 RESOLVED org.apache.tuscany.sca.3rdparty.json-rpc-1.0_1.0.0 13 RESOLVED org.apache.tuscany.sca.implementation.java_2.0.0 14 RESOLVED org.apache.tuscany.sca.interface.wsdl.xml_2.0.0 15 RESOLVED org.apache.tuscany.sca.binding.sca.axis2_2.0.0 16 RESOLVED org.apache.tuscany.sca.3rdparty.stax-api-1.0.1_1.0.1 17 RESOLVED org.apache.tuscany.sca.3rdparty.ecore-2.2.3_2.2.3 18 RESOLVED org.apache.tuscany.sca.3rdparty.codegen-ecore-2.2.3_2.2.3 19 RESOLVED org.apache.tuscany.sca.3rdparty.stax-api-1.0-2_1.0.0 20 RESOLVED org.apache.tuscany.sca.3rdparty.axiom-api-1.2.5_1.2.5 21 RESOLVED org.apache.tuscany.sca.3rdparty.abdera-parser-0.3.0-incubating_0.3.0 22 RESOLVED org.apache.tuscany.sca.3rdparty.commons-collections-3.1_3.1.0 23 RESOLVED org.apache.tuscany.sca.3rdparty.backport-util-concurrent-3.0_3.0.0 24 RESOLVED org.apache.tuscany.sca.binding.sca_2.0.0 25 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-codegen-1.3_1.3.0 26 RESOLVED org.apache.tuscany.sdo.spec_2.1.0 27 RESOLVED org.apache.tuscany.sca.3rdparty.easymock-2.2_2.2.0 28 RESOLVED org.apache.tuscany.sca.binding.rss_2.0.0 29 RESOLVED org.apache.tuscany.sca.3rdparty.jaxb2-reflection-2.1.4_2.1.4 30 RESOLVED org.apache.tuscany.sca.3rdparty.xercesImpl-2.8.1_2.8.1 31 ACTIVE org.eclipse.osgi.services_3.1.200.v20070605 32 RESOLVED org.apache.tuscany.sca.databinding.saxon_2.0.0 33 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-adb-codegen-1.3_1.3.0 34 RESOLVED org.apache.tuscany.sca.3rdparty.spring-beans-2.0.6_2.0.6 35 RESOLVED org.mortbay.jetty.server_6.1.7 36 RESOLVED org.apache.tuscany.sca.contribution_2.0.0 37 RESOLVED org.apache.tuscany.sca.3rdparty.activation-1.1_1.1.0 38 RESOLVED org.apache.tuscany.sca.workspace_2.0.0 39 RESOLVED org.apache.tuscany.sca.interface.java.xml_2.0.0 40 RESOLVED org.apache.tuscany.sca.binding.feed_2.0.0 41 RESOLVED org.apache.tuscany.sca.3rdparty.servlet-api-2.5_2.5.0 42 RESOLVED org.apache.tuscany.sca.3rdparty.mail-1.4_1.4.0 43 RESOLVED org.apache.tuscany.sca.3rdparty.abdera-core-0.3.0-incubating_0.3.0 44 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-mtompolicy-1.3_1.3.0 45 RESOLVED org.apache.tuscany.sca.3rdparty.wsdl4j-1.6.2_1.6.2 46 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-java2wsdl-1.3_1.3.0 47 RESOLVED org.apache.tuscany.sca.3rdparty.rampart-trust-1.3_1.3.0 48 RESOLVED org.apache.tuscany.sca.contribution.groovy_2.0.0 49 RESOLVED org.apache.tuscany.sca.binding.atom_2.0.0 50 RESOLVED org.apache.tuscany.sca.3rdparty.saaj-api-1.3_1.3.0 51 RESOLVED org.apache.tuscany.sca.assembly.xsd_2.0.0 52 RESOLVED org.apache.tuscany.sca.implementation.xquery_2.0.0 53 RESOLVED org.apache.tuscany.sca.3rdparty.tuscany-sdo-impl-1.1-incubating_1.1.0 54 RESOLVED org.apache.tuscany.sca.binding.dwr_2.0.0 55 RESOLVED org.apache.tuscany.sca.monitor.logging_2.0.0 56 RESOLVED org.apache.tuscany.sca.3rdparty.woden-1.0-incubating-M7b_1.0.0 57 RESOLVED org.apache.tuscany.sca.binding.atom.abdera_2.0.0 58 RESOLVED org.apache.tuscany.sca.definitions_2.0.0 59 RESOLVED org.apache.tuscany.sca.3rdparty.tuscany-sdo-tools-1.1-incubating_1.1.0 60 RESOLVED org.apache.tuscany.sca.binding.jsonrpc_2.0.0 61 RESOLVED org.apache.tuscany.sca.3rdparty.commons-httpclient-3.0.1_3.0.1 62 RESOLVED org.apache.tuscany.sca.implementation.das_2.0.0 63 RESOLVED org.apache.tuscany.sca.3rdparty.ecore-xmi-2.2.3_2.2.3 64 RESOLVED org.apache.tuscany.sca.extension.helper_2.0.0 65 RESOLVED org.apache.tuscany.sca.3rdparty.axiom-dom-1.2.5_1.2.5 66 RESOLVED org.apache.tuscany.sca.implementation.spring_2.0.0 67 RESOLVED org.apache.tuscany.sca.3rdparty.aopalliance-1.0_1.0.0 68 RESOLVED org.apache.tuscany.sca.3rdparty.saxon-dom-9.0.0.2_9.0.0.2 69 RESOLVED org.apache.tuscany.sca.implementation.osgi_2.0.0 70 RESOLVED org.apache.tuscany.sca.3rdparty.xml-apis-1.3.03_1.3.3 71 RESOLVED org.apache.tuscany.sca.binding.ws.xml_2.0.0 72 RESOLVED org.apache.tuscany.sca.3rdparty.axiom-impl-1.2.5_1.2.5 73 RESOLVED org.apache.tuscany.sca.binding.rmi_2.0.0 74 RESOLVED org.apache.tuscany.sca.3rdparty.activeio-core-3.0.0-incubator_3.0.0 75 RESOLVED org.apache.tuscany.sca.host.http_2.0.0 76 RESOLVED org.apache.tuscany.sca.3rdparty.abdera-i18n-0.3.0-incubating_0.3.0 77 RESOLVED org.apache.tuscany.sca.endpoint_2.0.0 78 RESOLVED org.apache.tuscany.sca.policy.xml_2.0.0 79 RESOLVED org.apache.tuscany.sca.databinding.xstream_2.0.0 80 RESOLVED org.apache.tuscany.sca.3rdparty.ecore-change-2.2.3_2.2.3 81 RESOLVED org.apache.tuscany.sca.workspace.impl_2.0.0 82 RESOLVED org.apache.tuscany.sca.3rdparty.spring-core-2.0.6_2.0.6 83 RESOLVED org.apache.tuscany.sca.3rdparty.wstx-asl-3.2.1_3.2.1 84 RESOLVED org.apache.tuscany.sca.3rdparty.xsd-2.2.3_2.2.3 85 ACTIVE org.eclipse.equinox.ds_1.0.0.qualifier 86 RESOLVED org.apache.tuscany.sca.3rdparty.commons-fileupload-1.2_1.2.0 87 RESOLVED org.apache.tuscany.sca.3rdparty.commons-io-1.2_1.2.0 88 RESOLVED org.apache.tuscany.sca.workspace.xml_2.0.0 89 RESOLVED org.apache.tuscany.sca.node.impl_2.0.0 90 RESOLVED org.apache.tuscany.sca.3rdparty.tuscany-das-rdb-1.0-incubating-SNAPSHOT_1.0.0 91 ACTIVE org.apache.tuscany.sca.osgi.runtime_2.0.0 92 RESOLVED org.apache.tuscany.sca.domain_2.0.0 93 RESOLVED org.apache.tuscany.sca.databinding.xmlbeans_2.0.0 94 RESOLVED org.apache.tuscany.sca.contribution.java_2.0.0 95 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-javamail_1.4_spec-1.0-M1_1.0.0 96 RESOLVED org.apache.tuscany.sca.policy.security_2.0.0 97 RESOLVED org.apache.tuscany.sca.policy.logging_2.0.0 98 RESOLVED org.apache.tuscany.sca.3rdparty.codegen-2.2.3_2.2.3 99 RESOLVED org.apache.tuscany.sca.3rdparty.xmlbeans-2.3.0_2.3.0 100 RESOLVED org.apache.tuscany.sca.3rdparty.junit-4.2_4.2.0 101 RESOLVED org.apache.tuscany.sca.3rdparty.opensaml-1.1_1.1.0 102 RESOLVED org.apache.tuscany.sca.databinding.axiom_2.0.0 103 RESOLVED org.apache.tuscany.sca.contribution.impl_2.0.0 104 RESOLVED org.apache.tuscany.sca.3rdparty.jdom-1.0_1.0.0 105 RESOLVED org.apache.tuscany.sca.host.jetty_2.0.0 106 RESOLVED org.apache.tuscany.sca.3rdparty.spring-context-2.0.6_2.0.6 107 RESOLVED org.apache.tuscany.sca.core.spi_2.0.0 108 RESOLVED org.apache.tuscany.sca.3rdparty.jsr250-api-1.0_1.0.0 109 RESOLVED org.apache.tuscany.sca.xsd.xml_2.0.0 110 RESOLVED org.apache.tuscany.sca.3rdparty.rome-0.9_0.9.0 111 RESOLVED org.apache.tuscany.sca.implementation.data.api_2.0.0 112 ACTIVE org.eclipse.eilf.scatest_0.5.0 113 RESOLVED org.apache.tuscany.sca.implementation.resource_2.0.0 114 ACTIVE org.eclipse.equinox.util_1.0.0.qualifier 115 RESOLVED org.apache.tuscany.sca.xsd_2.0.0 116 RESOLVED org.apache.tuscany.sca.databinding.fastinfoset_2.0.0 117 RESOLVED org.apache.tuscany.sca.3rdparty.XmlSchema-1.3.2_1.3.2 118 RESOLVED org.apache.tuscany.sca.3rdparty.jaxb-api-2.1_2.1.0 119 RESOLVED org.apache.tuscany.sca.core_2.0.0 120 RESOLVED org.eclipse.eilf.scatestdomain_0.5.0 121 RESOLVED org.apache.tuscany.sca.implementation.notification_2.0.0 122 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-adb-1.3_1.3.0 123 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-ejb_3.0_spec-1.0_1.0.0 125 RESOLVED org.apache.tuscany.sca.policy.xml.ws_2.0.0 126 RESOLVED org.apache.tuscany.sca.node.api_2.0.0 127 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-activation_1.0.2_spec-1.1_1.1.0 128 RESOLVED org.apache.tuscany.sca.3rdparty.neethi-2.0.2_2.0.2 129 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-jms_1.1_spec-1.1_1.1.0 130 RESOLVED org.apache.tuscany.sca.3rdparty.jaxws-api-2.1_2.1.0 131 RESOLVED org.apache.tuscany.sca.databinding.sdo_2.0.0 132 RESOLVED org.apache.tuscany.sca.3rdparty.axis2-kernel-1.3_1.3.0 133 RESOLVED org.apache.tuscany.sca.3rdparty.cglib-nodep-2.1_3_2.1.0 134 RESOLVED org.apache.tuscany.sca.assembly.xml_2.0.0 135 RESOLVED org.apache.tuscany.sca.binding.notification_2.0.0 136 RESOLVED org.apache.tuscany.sca.3rdparty.jettison-1.0_1.0.0 137 RESOLVED org.apache.tuscany.sca.3rdparty.logkit-1.0.1_1.0.1 138 ACTIVE org.codehaus.groovy_1.5.4 139 RESOLVED org.apache.tuscany.sca.host.embedded_2.0.0 140 RESOLVED org.apache.tuscany.sca.3rdparty.bsf-all-3.0-beta2_3.0.0 141 RESOLVED org.apache.tuscany.sca.contribution.osgi_2.0.0 142 RESOLVED org.apache.tuscany.sca.extensibility_2.0.0 143 RESOLVED org.apache.tuscany.sca.policy.security.ws_2.0.0 144 RESOLVED org.apache.tuscany.sca.databinding.sdo.axiom_2.0.0 145 RESOLVED org.apache.tuscany.sca.3rdparty.bcprov-jdk15-132_132.0.0 146 RESOLVED org.apache.tuscany.sca.implementation.node.xml_2.0.0 147 RESOLVED org.apache.tuscany.sca.monitor_2.0.0 148 RESOLVED org.apache.tuscany.sca.3rdparty.log4j-1.2.12_1.2.12 149 RESOLVED org.apache.tuscany.sca.3rdparty.rampart-policy-1.3_1.3.0 150 RESOLVED org.apache.tuscany.sca.interface.java.jaxws_2.0.0 151 RESOLVED org.apache.tuscany.sca.databinding.jaxb.axiom_2.0.0 152 RESOLVED org.apache.tuscany.sca.implementation.widget_2.0.0 153 RESOLVED org.apache.tuscany.sca.contribution.resource_2.0.0 154 RESOLVED org.apache.tuscany.sca.3rdparty.wss4j-1.5.3_1.5.3 155 RESOLVED org.apache.tuscany.sca.core.databinding_2.0.0 156 RESOLVED org.apache.tuscany.sca.3rdparty.jaxen-1.1-beta-9_1.1.0 157 RESOLVED org.apache.tuscany.sca.3rdparty.jsr181-api-1.0-MR1_1.0.0 158 RESOLVED org.apache.tuscany.sca.3rdparty.jruby-complete-1.0_1.0.0 159 RESOLVED org.apache.tuscany.sca.databinding.jaxb_2.0.0 160 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-commonj_1.1_spec-1.0_1.0.0 161 RESOLVED org.apache.tuscany.sca.3rdparty.common-2.2.3_2.2.3 162 RESOLVED org.apache.tuscany.sca.3rdparty.annogen-0.1.0_0.1.0 163 RESOLVED org.apache.tuscany.sca.interface_2.0.0 164 RESOLVED org.apache.tuscany.sca.3rdparty.FastInfoset-1.2.2_1.2.2 165 RESOLVED org.apache.tuscany.sca.3rdparty.jaxb-impl-2.1.6_2.1.6 166 RESOLVED org.apache.tuscany.sca.3rdparty.js-1.6R7_1.6.0 167 RESOLVED org.apache.tuscany.sca.3rdparty.geronimo-activation_1.1_spec-1.0-M1_1.0.0 168 RESOLVED org.apache.tuscany.sca.interface.java_2.0.0 169 RESOLVED org.apache.tuscany.sca.3rdparty.rampart-core-1.3_1.3.0 170 RESOLVED org.apache.tuscany.sca.binding.ws_2.0.0 171 RESOLVED org.apache.tuscany.sca.databinding_2.0.0 172 RESOLVED org.apache.tuscany.sca.binding.ws.axis2_2.0.0 173 RESOLVED org.apache.tuscany.sca.binding.http_2.0.0 174 RESOLVED org.apache.tuscany.sca.3rdparty.jython-2.2_2.2.0 175 RESOLVED org.apache.tuscany.sca.3rdparty.xstream-1.3_1.3.0 176 RESOLVED org.apache.tuscany.sca.binding.sca.xml_2.0.0 177 RESOLVED org.apache.tuscany.sca.host.rmi_2.0.0 178 RESOLVED org.apache.tuscany.sca.policy_2.0.0 179 RESOLVED org.apache.tuscany.sca.3rdparty.commons-logging-1.1_1.1.0 180 RESOLVED org.apache.tuscany.sca.3rdparty.xmlsec-1.4.0_1.4.0 181 RESOLVED org.apache.tuscany.sca.node_2.0.0 182 RESOLVED org.apache.tuscany.sca.3rdparty.apache-activemq-4.1.1_4.1.1 183 RESOLVED org.apache.tuscany.sca.assembly_2.0.0 184 RESOLVED org.apache.tuscany.sca.contribution.xml_2.0.0 185 RESOLVED org.apache.tuscany.sca.interface.wsdl_2.0.0 186 RESOLVED org.apache.tuscany.sca.contribution.namespace_2.0.0 187 RESOLVED org.apache.tuscany.sdo.lib_1.0.0 189 RESOLVED org.apache.tuscany.sca.3rdparty.commons-cli-1.0_1.0.0 190 RESOLVED org.mortbay.jetty.util_6.1.7 191 RESOLVED org.apache.tuscany.sca.3rdparty.httpcore-niossl-4.0-alpha5_4.0.0 192 RESOLVED org.apache.tuscany.sca.3rdparty.xpp3_min-1.1.4c_1.1.4 193 RESOLVED org.apache.tuscany.sca.domain.impl_2.0.0 194 RESOLVED org.apache.tuscany.sca.implementation.node_2.0.0 195 RESOLVED org.apache.tuscany.sca.databinding.json_2.0.0 196 RESOLVED org.apache.tuscany.sca.3rdparty.commons-codec-1.3_1.3.0 197 RESOLVED org.apache.tuscany.sca.interface.wsdl.java2wsdl_2.0.0 198 RESOLVED org.apache.tuscany.sca.domain.api_2.0.0 199 RESOLVED org.apache.tuscany.sca.3rdparty.httpcore-4.0-alpha5_4.0.0 200 RESOLVED org.apache.tuscany.sca.implementation.java.xml_2.0.0 201 RESOLVED org.apache.tuscany.sca.implementation.script_2.0.0 202 RESOLVED org.apache.tuscany.sca.3rdparty.dwr-2.0.1_2.0.1 203 RESOLVED org.apache.tuscany.sca.3rdparty.httpcore-nio-4.0-alpha5_4.0.0 204 RESOLVED org.apache.tuscany.sca.3rdparty.saxon-9.0.0.2_9.0.0.2 This time I get the following exception: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:128) at org.apache.tuscany.sca.extension.helper.impl.BindingsActivator.start(BindingsActivator.java:72) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.startModules(ReallySmallRuntime.java:354) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:139) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79) at org.eclipse.eilf.scatestdomain.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:103) at org.eclipse.eilf.scatestdomain.ScaDomainActivator.start(ScaDomainActivator.java:59) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297) Caused by: java.lang.reflect.InvocationTargetException 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:494) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:113) ... 19 more Caused by: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:122) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.<init>(DefaultStAXArtifactProcessorExtensionPoint.java:68) ... 24 more Caused by: java.lang.reflect.InvocationTargetException 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:585) at org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:120) ... 25 more Caused by: javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136) ... 30 more Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        I had installed and started tsucany-sca-installer.jar first, so I had all Tuscany bundles and 3rd party jars installed before starting your bundles. I was expecting that your launch configuration using the installer would also result in the same bundles in Equinox. But yes, I am not using Eclipse, so it could be an Eclipse issue. Could you list the bundles in Equinox when using the installer, and check that all the 3rd party bundles are being installed? Also are all the Tuscany module bundles installed, and in RESOLVED state? The WorkScheduler is in the core module, so do you have a bundle with symbolic name "org.apache.tuscany.sca.core" installed and resolved? Obviously host-embedded was installed and resolved since the classes from this module are on your stack trace. If all the other bundles are present and resolved, but ServiceDiscovery is not finding the classes, there may some additional logic required in the Tuscany activator when running the bundles under Eclipse.

        -Rajini

        Show
        Rajini Sivaram added a comment - Daniel, I had installed and started tsucany-sca-installer.jar first, so I had all Tuscany bundles and 3rd party jars installed before starting your bundles. I was expecting that your launch configuration using the installer would also result in the same bundles in Equinox. But yes, I am not using Eclipse, so it could be an Eclipse issue. Could you list the bundles in Equinox when using the installer, and check that all the 3rd party bundles are being installed? Also are all the Tuscany module bundles installed, and in RESOLVED state? The WorkScheduler is in the core module, so do you have a bundle with symbolic name "org.apache.tuscany.sca.core" installed and resolved? Obviously host-embedded was installed and resolved since the classes from this module are on your stack trace. If all the other bundles are present and resolved, but ServiceDiscovery is not finding the classes, there may some additional logic required in the Tuscany activator when running the bundles under Eclipse. -Rajini
        Hide
        Daniel Stucky added a comment -

        Hi all,
        thanks for your quick response.

        No, we do not use any security. To check I just added 2 lines of code to the BundleActivator:
        String prop = System.getProperty("java.security.manager");
        SecurityManager manager = System.getSecurityManager();
        Both prop and manager are null.

        I also added -clean to the launch. No change there. I still get the NullPointerException.

        Yes, if you see the output
        "Starting ... test.composite ready !!!
        did something"
        the SCADomain was created and a method on the Test service was executed.

        Rajini, did you install and start only the bundles that I used in my launch files or did you use more/less bundles or even all Tuscany and Tuscany 3rd party bundles?
        Could this be some eclipse issue, as you said you are not using eclipse.

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi all, thanks for your quick response. No, we do not use any security. To check I just added 2 lines of code to the BundleActivator: String prop = System.getProperty("java.security.manager"); SecurityManager manager = System.getSecurityManager(); Both prop and manager are null. I also added -clean to the launch. No change there. I still get the NullPointerException. Yes, if you see the output "Starting ... test.composite ready !!! did something" the SCADomain was created and a method on the Test service was executed. Rajini, did you install and start only the bundles that I used in my launch files or did you use more/less bundles or even all Tuscany and Tuscany 3rd party bundles? Could this be some eclipse issue, as you said you are not using eclipse. Bye, Daniel
        Hide
        Rajini Sivaram added a comment -

        Dan,

        I dont know whether Daniel runs with security on, so I will wait for his response. It could be an OSGi classloading issue rather than a security issue.

        Daniel,

        Is there a possibility that the bundles from the previous run are still in the cache? Could you run with "-clean" option to Equinox?

        And to answer the question in your last note - yes, the code creating SCADomain should work in OSGi.

        • Rajini
        Show
        Rajini Sivaram added a comment - Dan, I dont know whether Daniel runs with security on, so I will wait for his response. It could be an OSGi classloading issue rather than a security issue. Daniel, Is there a possibility that the bundles from the previous run are still in the cache? Could you run with "-clean" option to Equinox? And to answer the question in your last note - yes, the code creating SCADomain should work in OSGi. Rajini
        Hide
        Dan Becker added a comment -

        Rajini said: "Dan,
        Doesn't Tuscany throw SecurityExceptions when security is turned on and the required FilePermissions are not granted?"

        Rajini,

        Yes that is true. Do you have J2 security on and a policy file? If not, I wonder if it is going through security-related code and failing for some other reason. I am trying to understand the fail myself.

        Show
        Dan Becker added a comment - Rajini said: "Dan, Doesn't Tuscany throw SecurityExceptions when security is turned on and the required FilePermissions are not granted?" Rajini, Yes that is true. Do you have J2 security on and a policy file? If not, I wonder if it is going through security-related code and failing for some other reason. I am trying to understand the fail myself.
        Hide
        Rajini Sivaram added a comment -

        Daniel,

        I tried out your test by creating bundles and installing them (I am running Equinox, but not using Eclipse plugins) and the output showed:

        osgi> start 238
        creating TestImpl
        osgi> start 239
        Starting ... test.composite ready !!!
        did something

        It looks like it worked, so I will wait and see your response to Dan's question on security.

        Dan,

        Doesn't Tuscany throw SecurityExceptions when security is turned on and the required FilePermissions are not granted?

        • Rajini
        Show
        Rajini Sivaram added a comment - Daniel, I tried out your test by creating bundles and installing them (I am running Equinox, but not using Eclipse plugins) and the output showed: osgi> start 238 creating TestImpl osgi> start 239 Starting ... test.composite ready !!! did something It looks like it worked, so I will wait and see your response to Dan's question on security. Dan, Doesn't Tuscany throw SecurityExceptions when security is turned on and the required FilePermissions are not granted? Rajini
        Hide
        Dan Becker added a comment -

        That last stack trace looks like a security-related issue. You can work around it temporarily by turning Java 2 security off. Or you can add the code base to one of the security policy files that would allow it to run as priviledged. What sort of security policy do you run with?

        Show
        Dan Becker added a comment - That last stack trace looks like a security-related issue. You can work around it temporarily by turning Java 2 security off. Or you can add the code base to one of the security policy files that would allow it to run as priviledged. What sort of security policy do you run with?
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        I build the 3rd party bundles with the installer. I had to remove the activemq bundle (we also use one) because during pdebuild it generated a cycle. After that pdebuild works. However, suddenly our test bundles did not run anymore in eclipse.

        Attached are 2 test bundles that simulate the usage in our project, without any additional 3rd party dependencies). One contains a DeclerativeService, the other starts a SCA Domain that uses this DS (via implementation.type osgi).

        I provided 2 eclipse launch configurations. One uses the the osgi.installer bundle, the other does not use the installer but uses the required tuscany and 3rd party bundles directly. (you will also need the bundles org.eclipse.equinox.ds and org.eclipse.equinox.util)

        The launch with the installer works fine.
        The launch using the bundles stops with the following exception:
        java.lang.NullPointerException
        at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:124)
        at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79)
        at org.eclipse.eilf.scatestdomain.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:100)
        at org.eclipse.eilf.scatestdomain.ScaDomainActivator.start(ScaDomainActivator.java:56)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297)

        The problem ist that the ServiceDiscovery does not find "META-INF/services/org.apache.tuscany.sca.work.WorkScheduler". So in class ReallySmallRuntime the

        • member variable workScheduler is null
        • variable factories is null (wich leads to the NPE)

        This is a classloading problem I was not able to solve.
        BTW: is this a feasible way to create a SCADomain within OSGi ?

        Show
        Daniel Stucky added a comment - Hi Rajini, I build the 3rd party bundles with the installer. I had to remove the activemq bundle (we also use one) because during pdebuild it generated a cycle. After that pdebuild works. However, suddenly our test bundles did not run anymore in eclipse. Attached are 2 test bundles that simulate the usage in our project, without any additional 3rd party dependencies). One contains a DeclerativeService, the other starts a SCA Domain that uses this DS (via implementation.type osgi). I provided 2 eclipse launch configurations. One uses the the osgi.installer bundle, the other does not use the installer but uses the required tuscany and 3rd party bundles directly. (you will also need the bundles org.eclipse.equinox.ds and org.eclipse.equinox.util) The launch with the installer works fine. The launch using the bundles stops with the following exception: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:124) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79) at org.eclipse.eilf.scatestdomain.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:100) at org.eclipse.eilf.scatestdomain.ScaDomainActivator.start(ScaDomainActivator.java:56) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297) The problem ist that the ServiceDiscovery does not find "META-INF/services/org.apache.tuscany.sca.work.WorkScheduler". So in class ReallySmallRuntime the member variable workScheduler is null variable factories is null (wich leads to the NPE) This is a classloading problem I was not able to solve. BTW: is this a feasible way to create a SCADomain within OSGi ?
        Hide
        Georg Schmidt added a comment -

        Hi Rajini,

        thank you for your good support.

        The warning column is mostly for us... When there are larger version differences.

        On the other side you already have dublicate libraries on your class path. e.g. activation. There are three different versions of this lib in your dependencies.

        We will collect the further informations for you and we will attach them to jira.

        • Georg
        Show
        Georg Schmidt added a comment - Hi Rajini, thank you for your good support. The warning column is mostly for us... When there are larger version differences. On the other side you already have dublicate libraries on your class path. e.g. activation. There are three different versions of this lib in your dependencies. We will collect the further informations for you and we will attach them to jira. Georg
        Hide
        Rajini Sivaram added a comment -

        I have committed some changes to the installer, which should hopefully enable you to make more progress.

        There is some more logic to determine the directory to load Tuscany jars from. I am hoping that it will now find the jars relative to the installer.jar in your case. If all else fails, you can set either the environment variable or the system property TUSCANY_HOME to the directory containing the Tuscany jars. Please update to the latest itest/osgi-tuscany (again, sorry).

        I have added some code in the installer to dump the virtual bundles created by the installer onto the disk. If you run the maven build in itest/osgi-tuscany with the environment variable TUSCANY_OSGI_DEBUG set to true, all the 3rd party libs converted to bundles are written out to the directory containing tuscany-sca-osgi-installer.jar (itest/osgi-tuscany/tuscany-osgi-installer/target). Maybe you can copy these to your Tuscany directory to avoid the pdebuild errors? Tuscany uses these 3rd party bundles if they are found in the TUSCANY_HOME directory. So I am hoping that you will be able to use these to isolate versioning/classloading errors.

        I had a look at Georg's list of libraries and versioning clashes. Would it be possible for one of you to send me the third party bundles you are using for the clashing libraries (either attach to this JIRA or email to rajinisivaram@googlemail.com) ? I would first like to understand the problem with jaxb since the versions are identical. For the others, where you have different versions, do you requireTuscany and your application to share classes from these libraries? What does the "warning" column indicate - do these correspond to actual classloading errors?

        Unfortunately, I might not have time during this week to look into this, but if you send me the libraries, depending on how complicated it turns out to be, I will try to respond as soon as I can (I will definitely look at it in the weekend if I can't get to it earlier). Sorry about that.

        • Rajini
        Show
        Rajini Sivaram added a comment - I have committed some changes to the installer, which should hopefully enable you to make more progress. There is some more logic to determine the directory to load Tuscany jars from. I am hoping that it will now find the jars relative to the installer.jar in your case. If all else fails, you can set either the environment variable or the system property TUSCANY_HOME to the directory containing the Tuscany jars. Please update to the latest itest/osgi-tuscany (again, sorry). I have added some code in the installer to dump the virtual bundles created by the installer onto the disk. If you run the maven build in itest/osgi-tuscany with the environment variable TUSCANY_OSGI_DEBUG set to true, all the 3rd party libs converted to bundles are written out to the directory containing tuscany-sca-osgi-installer.jar (itest/osgi-tuscany/tuscany-osgi-installer/target). Maybe you can copy these to your Tuscany directory to avoid the pdebuild errors? Tuscany uses these 3rd party bundles if they are found in the TUSCANY_HOME directory. So I am hoping that you will be able to use these to isolate versioning/classloading errors. I had a look at Georg's list of libraries and versioning clashes. Would it be possible for one of you to send me the third party bundles you are using for the clashing libraries (either attach to this JIRA or email to rajinisivaram@googlemail.com) ? I would first like to understand the problem with jaxb since the versions are identical. For the others, where you have different versions, do you requireTuscany and your application to share classes from these libraries? What does the "warning" column indicate - do these correspond to actual classloading errors? Unfortunately, I might not have time during this week to look into this, but if you send me the libraries, depending on how complicated it turns out to be, I will try to respond as soon as I can (I will definitely look at it in the weekend if I can't get to it earlier). Sorry about that. Rajini
        Hide
        Rajini Sivaram added a comment -

        Sebastian,

        Thank you for the update.

        Yes, I do now understand that the pdebuild is broken because we are not converting 3rd party jars into real bundles. They are converted to virtual bundles when the installer runs, but that obviously does not help with the pdebuild.

        The installer bundle is a temporary solution to enable testing Tuscany under OSGi. We are still discussing the best way to OSGi-enable Tuscany, and this feedback from actual usage has been very helpful.

        For using the installer bundle at runtime (for now), you can either set TUSCANY_HOME (the installer looks for jars in TUSCANY_HOME/modules and TUSCANY_HOME/lib) - you need to update to the latest level of the code. Alternatively, I can update the code to read the jars relative to the installer.jar.

        I do completely agree that the current installer jar is not suitable for deployment. I will look through Georg's list to see how much version constraining we will need for the imports - if they are done in Tuscany.

        • Rajini
        Show
        Rajini Sivaram added a comment - Sebastian, Thank you for the update. Yes, I do now understand that the pdebuild is broken because we are not converting 3rd party jars into real bundles. They are converted to virtual bundles when the installer runs, but that obviously does not help with the pdebuild. The installer bundle is a temporary solution to enable testing Tuscany under OSGi. We are still discussing the best way to OSGi-enable Tuscany, and this feedback from actual usage has been very helpful. For using the installer bundle at runtime (for now), you can either set TUSCANY_HOME (the installer looks for jars in TUSCANY_HOME/modules and TUSCANY_HOME/lib) - you need to update to the latest level of the code. Alternatively, I can update the code to read the jars relative to the installer.jar. I do completely agree that the current installer jar is not suitable for deployment. I will look through Georg's list to see how much version constraining we will need for the imports - if they are done in Tuscany. Rajini
        Hide
        Sebastian Voigt added a comment -

        In addition to Georges post:

        We have tested the latest build (incl. the osgi-installer), and we were able to start our junit-test which starts the sca-domain and tests some method-calls).
        We have to include our jaxb-fix (that is describe https://issues.apache.org/jira/browse/TUSCANY-2346), but it is running now (it wasnt with the older osgi-bundles (5).

        But we have problems to integrate the tuscany-bundles into our pdebuild. The build is done with an ant-script which runs the pde-build. We have installed the tuscany-bundles
        into an extension-location for the eclipse that is used for the pde-build. We have problems with the tuscany-bundles, because there are a lot of
        "Unsatisfied import package"-messages. The installer bundle doesn't help because it doesn't create the needed 3rd-party bundles while building.

        Also the installer-bundle would not help for deploying our product, because it contains the classpath to the local maven repository and not every customer would install maven and
        will build tuscany (par example). Therefore the solution with the installer is for our case not acceptable. We need for every 3rd-party an osgi-bundle, for our technologies we have create them,
        but now the dependencies for tuscany are missing.
        At the moment we are discussing to create all bundles that are needed by tuscany (see the above post from George), but therefore we would know if the tuscany-developer will
        provide these bundles (in the future).

        If we have to build all dependencies ourself it would be interesting how often the tuscany-developer will use newer versions of the 3rdparty-technologies, because we have to update them in this case every time.
        Also it would be interesting if your team can add version-numbers for all imports: that would help implementing all 3rd-party bundles.

        Show
        Sebastian Voigt added a comment - In addition to Georges post: We have tested the latest build (incl. the osgi-installer), and we were able to start our junit-test which starts the sca-domain and tests some method-calls). We have to include our jaxb-fix (that is describe https://issues.apache.org/jira/browse/TUSCANY-2346 ), but it is running now (it wasnt with the older osgi-bundles (5). But we have problems to integrate the tuscany-bundles into our pdebuild. The build is done with an ant-script which runs the pde-build. We have installed the tuscany-bundles into an extension-location for the eclipse that is used for the pde-build. We have problems with the tuscany-bundles, because there are a lot of "Unsatisfied import package"-messages. The installer bundle doesn't help because it doesn't create the needed 3rd-party bundles while building. Also the installer-bundle would not help for deploying our product, because it contains the classpath to the local maven repository and not every customer would install maven and will build tuscany (par example). Therefore the solution with the installer is for our case not acceptable. We need for every 3rd-party an osgi-bundle, for our technologies we have create them, but now the dependencies for tuscany are missing. At the moment we are discussing to create all bundles that are needed by tuscany (see the above post from George), but therefore we would know if the tuscany-developer will provide these bundles (in the future). If we have to build all dependencies ourself it would be interesting how often the tuscany-developer will use newer versions of the 3rdparty-technologies, because we have to update them in this case every time. Also it would be interesting if your team can add version-numbers for all imports: that would help implementing all 3rd-party bundles.
        Hide
        Rajini Sivaram added a comment -

        Georg,

        Thank you for the list of libraries, I will take a look at those in detail and compare them with Tuscany's.

        Daniel,

        I have updated the installer to read jars out of a Tuscany distribution. If you set the enviroment variable TUSCANY_HOME, the installer looks inside TUSCANY_HOME/modules and TUSCANY_HOME/lib for the jars. Is this sufficient for you, or do you require jars to be located relative to the installer jar as well?

        I haven't used pdebuild with Tuscany, sorry...

        Show
        Rajini Sivaram added a comment - Georg, Thank you for the list of libraries, I will take a look at those in detail and compare them with Tuscany's. Daniel, I have updated the installer to read jars out of a Tuscany distribution. If you set the enviroment variable TUSCANY_HOME, the installer looks inside TUSCANY_HOME/modules and TUSCANY_HOME/lib for the jars. Is this sufficient for you, or do you require jars to be located relative to the installer jar as well? I haven't used pdebuild with Tuscany, sorry...
        Hide
        Daniel Stucky added a comment -

        Hi Rajini,

        this week I've been testing the new Tuscany bundles with the installer bundle. In eclipse our bundles compile and the tests run sucessfully.

        There are is a minor issue concerning the InstallerBundleActivator. All Tuscany bundles (including the installer) and all 3rd party jars are located in the same directory. In the installer's classpath all entries are absolute paths to the maven repository. On machines without the repository, the jars are not found. As I unsterstand there should be some code in the InstallerBundleActivator that checks this and tries to find the jars relative to the installer., but this does not work. I guess the boolean logic at line 169 is not correct:
        ...
        if (!jar.isAbsolute()&&!jar.exists())

        { jar = new File(tuscanyInstallDir, jar.getName()); }

        ...

        Another problem is that we are trying to build our application automatically using ant and eclipse pdebuild. So far we did not get it running. An error occurs in the first bundle that makes use of Tuscany classes. If we exclude those bundles from the build everything works fine. There are lots of warnings regarding "Unsatisfied import package".
        Has anyone experience using pdebuild and tuscany ?

        Bye,
        Daniel

        Show
        Daniel Stucky added a comment - Hi Rajini, this week I've been testing the new Tuscany bundles with the installer bundle. In eclipse our bundles compile and the tests run sucessfully. There are is a minor issue concerning the InstallerBundleActivator. All Tuscany bundles (including the installer) and all 3rd party jars are located in the same directory. In the installer's classpath all entries are absolute paths to the maven repository. On machines without the repository, the jars are not found. As I unsterstand there should be some code in the InstallerBundleActivator that checks this and tries to find the jars relative to the installer., but this does not work. I guess the boolean logic at line 169 is not correct: ... if (!jar.isAbsolute()&&!jar.exists()) { jar = new File(tuscanyInstallDir, jar.getName()); } ... Another problem is that we are trying to build our application automatically using ant and eclipse pdebuild. So far we did not get it running. An error occurs in the first bundle that makes use of Tuscany classes. If we exclude those bundles from the build everything works fine. There are lots of warnings regarding "Unsatisfied import package". Has anyone experience using pdebuild and tuscany ? Bye, Daniel
        Hide
        Georg Schmidt added a comment -

        Hi Rajini,

        attached you will find a list of libraries (or better a current snapshot [i am not yet finished]) that we are using in our project.

        The list contains version information. Empty fields are not yet analyzed, but a mismatch would be a potential class loading error.

        Further you could find potential issues regarding a class path hell...

        The list is not yet completed. But we are using currently more than twice the amount of bundles. I will work on that over the weekend.

        I hope the list gives you a idea what we are currently faceing.

        One interesting aspect in this list is that a large amount of these libraries are axis 2 related.

        Show
        Georg Schmidt added a comment - Hi Rajini, attached you will find a list of libraries (or better a current snapshot [i am not yet finished] ) that we are using in our project. The list contains version information. Empty fields are not yet analyzed, but a mismatch would be a potential class loading error. Further you could find potential issues regarding a class path hell... The list is not yet completed. But we are using currently more than twice the amount of bundles. I will work on that over the weekend. I hope the list gives you a idea what we are currently faceing. One interesting aspect in this list is that a large amount of these libraries are axis 2 related.
        Hide
        Georg Schmidt added a comment -

        Thanks. We will do.

        Show
        Georg Schmidt added a comment - Thanks. We will do.
        Hide
        Rajini Sivaram added a comment -

        Georg,

        I realized that some of the bundles installed by Tuscany using the installer did not use export versions for the packages. I have just committed a fix. Could you please update to the latest level before testing your scenario? Sorry about this, I should have checked yesterday....

        • Rajini
        Show
        Rajini Sivaram added a comment - Georg, I realized that some of the bundles installed by Tuscany using the installer did not use export versions for the packages. I have just committed a fix. Could you please update to the latest level before testing your scenario? Sorry about this, I should have checked yesterday.... Rajini
        Hide
        Rajini Sivaram added a comment -

        Georg,

        Thank you for the details on your scenario. It has been very helpful. For now, I think we have enough information to make progress. When we start introducing more versioning information in the jars, it will be very useful to run these against your scenario first.

        With tuscany-sca-osgi-installer.jar, 3rd party jars are installed with the actual jar versions. In the example you used of servlet api, the bundle installed will have:
        Bundle-SymbolicName: org.apache.tuscany.sca.3rdparty.servlet-api-2.5
        Bundle-Version: 2.5

        Import statements in Tuscany however do not specify a version range. So Tuscany can use a different version of javax.servlet installed by an application and share classes from javax.servlet.

        As long as the version range used by the application contains the version 2.5, Tuscany and the application will use the same definitions of javax/servlet (either from this bundle or the one installed by the application). If the application uses a version range (eg. version=2.6) which does not match Tuscany's, the application and Tuscany could end up using javax.servlet from different bundles - in this case the application will always use 2.6, but Tuscany may use 2.6 or 2.5 as chosen by the OSGi framework since it does not specify a version range in its import).

        The issues that we need to address for versioning import statements are:

        1) Version ranges specified in import statements should be broad enough to enable sharing. eg. If Tuscany is able to work with versions between 2.4.8-2.6.2 of javax.servlet, the version range should include the entire range of those versions, enabling applications to choose the version.

        2) Version ranges should be narrow enough to enable isolation when we want two versions to coexist. eg. If one Tuscany extensionA wants to use version 3.1 of foo.jar and another extensionB (or the application) wants to use 3.3 of the same jar, where classes of the jar are not required to be shared, we should be able to specify narrow ranges of versions in the import of org.foo, so that the extensions use different versions.

        3) Versions introduced by tools like the maven-bundle-plugin cannot really provide us 1) and 2). So we will need to carefully analyse the usage of all 3rd party jars to introduce proper version ranges in imports. Hence scenarios like yours can be very useful to ensure that we get it right.

        Back to tuscany-sca-osgi-installer.jar - this is not built as part of the main build in Tuscany. So you need to run maven from itest/osgi-tuscany. You should then be able to install and start this bundle. You should see around 200 bundles installed when bundle.start() returns.

        You will need to modify the build script only if you want to disable the installation of a 3rdparty jar.
        1) If the JAXB bundle you are using is the same version (eg. 2.6.1) as the one installed by Tuscany, you wont need to change anything. A single bundle will be chosen as exported by the framework.
        2) If the JAXB bundle you are using is of a different version (eg. 2.6.2), and the application's import statements use a range which includes both 2.6.1 and 2.6.2, you dont need to change anything. The same export will be used for both application and Tuscany.
        3) If the application uses a version range that is different (application requires 2.6.2), you should change the Tuscany installer build script to exclude version 2.6.1, to ensure that Tuscany does not pick that one.

        Hope this helps.

        Show
        Rajini Sivaram added a comment - Georg, Thank you for the details on your scenario. It has been very helpful. For now, I think we have enough information to make progress. When we start introducing more versioning information in the jars, it will be very useful to run these against your scenario first. With tuscany-sca-osgi-installer.jar, 3rd party jars are installed with the actual jar versions. In the example you used of servlet api, the bundle installed will have: Bundle-SymbolicName: org.apache.tuscany.sca.3rdparty.servlet-api-2.5 Bundle-Version: 2.5 Import statements in Tuscany however do not specify a version range. So Tuscany can use a different version of javax.servlet installed by an application and share classes from javax.servlet. As long as the version range used by the application contains the version 2.5, Tuscany and the application will use the same definitions of javax/servlet (either from this bundle or the one installed by the application). If the application uses a version range (eg. version=2.6) which does not match Tuscany's, the application and Tuscany could end up using javax.servlet from different bundles - in this case the application will always use 2.6, but Tuscany may use 2.6 or 2.5 as chosen by the OSGi framework since it does not specify a version range in its import). The issues that we need to address for versioning import statements are: 1) Version ranges specified in import statements should be broad enough to enable sharing. eg. If Tuscany is able to work with versions between 2.4.8-2.6.2 of javax.servlet, the version range should include the entire range of those versions, enabling applications to choose the version. 2) Version ranges should be narrow enough to enable isolation when we want two versions to coexist. eg. If one Tuscany extensionA wants to use version 3.1 of foo.jar and another extensionB (or the application) wants to use 3.3 of the same jar, where classes of the jar are not required to be shared, we should be able to specify narrow ranges of versions in the import of org.foo, so that the extensions use different versions. 3) Versions introduced by tools like the maven-bundle-plugin cannot really provide us 1) and 2). So we will need to carefully analyse the usage of all 3rd party jars to introduce proper version ranges in imports. Hence scenarios like yours can be very useful to ensure that we get it right. Back to tuscany-sca-osgi-installer.jar - this is not built as part of the main build in Tuscany. So you need to run maven from itest/osgi-tuscany. You should then be able to install and start this bundle. You should see around 200 bundles installed when bundle.start() returns. You will need to modify the build script only if you want to disable the installation of a 3rdparty jar. 1) If the JAXB bundle you are using is the same version (eg. 2.6.1) as the one installed by Tuscany, you wont need to change anything. A single bundle will be chosen as exported by the framework. 2) If the JAXB bundle you are using is of a different version (eg. 2.6.2), and the application's import statements use a range which includes both 2.6.1 and 2.6.2, you dont need to change anything. The same export will be used for both application and Tuscany. 3) If the application uses a version range that is different (application requires 2.6.2), you should change the Tuscany installer build script to exclude version 2.6.1, to ensure that Tuscany does not pick that one. Hope this helps.
        Hide
        Georg Schmidt added a comment -

        About our scenario.

        We are currently developing a architecture for search and unstructured information management. That arcitecture uses Tuscany to handle communication in an abstract manner.

        Samples:

        • We have components that have to be implemented in C++
        • We have adapters to extract information that should be implemented in .NET
        • We have adapters to extract information that should be called out of process (stability).

        We are combining technologies like SCA, BPEL, OSGi a lot of XML and knowledge management.

        Generally our goal is to create an architecture framework for handling commodity aspects of enterprise search that different vendors could focus on differentiators.

        SCA/Tuscany is an important aspect for us because its ability to abstract the communication.

        Our framework should be extensible eg for adding more adaptors for extracting information or for annotating information. For us the flexibility of the OSGi environment is vital (e.g. adding such components at runtime) And we are keen to use it's dynamics with SCA; we are awaiting some issues at that point. And we hope to get closer into touch with your team about those things.

        Our architecture will work in different deployment scenarios. From single machine (as a service) to a large cluster in an enterprise. Generally we have to fight with a real dynamic system that have to be really easy extensible. Few configs, few management, ... That will be a vital point for us.

        If this information is not the expected level, please get into touch with me. Ask questions and I will provide further information. Curretly I just don't know which level to chose for answering.

        Don't be surprised by C++ or .NET we are willing to make investments on that area... and if you are interested we could talk about colaboration.

        Show
        Georg Schmidt added a comment - About our scenario. We are currently developing a architecture for search and unstructured information management. That arcitecture uses Tuscany to handle communication in an abstract manner. Samples: We have components that have to be implemented in C++ We have adapters to extract information that should be implemented in .NET We have adapters to extract information that should be called out of process (stability). We are combining technologies like SCA, BPEL, OSGi a lot of XML and knowledge management. Generally our goal is to create an architecture framework for handling commodity aspects of enterprise search that different vendors could focus on differentiators. SCA/Tuscany is an important aspect for us because its ability to abstract the communication. Our framework should be extensible eg for adding more adaptors for extracting information or for annotating information. For us the flexibility of the OSGi environment is vital (e.g. adding such components at runtime) And we are keen to use it's dynamics with SCA; we are awaiting some issues at that point. And we hope to get closer into touch with your team about those things. Our architecture will work in different deployment scenarios. From single machine (as a service) to a large cluster in an enterprise. Generally we have to fight with a real dynamic system that have to be really easy extensible. Few configs, few management, ... That will be a vital point for us. If this information is not the expected level, please get into touch with me. Ask questions and I will provide further information. Curretly I just don't know which level to chose for answering. Don't be surprised by C++ or .NET we are willing to make investments on that area... and if you are interested we could talk about colaboration.
        Hide
        Georg Schmidt added a comment -

        Thank you for your fast response.

        Yes. we are currently using the 5 bundles.

        The JIRA issue is in correspondence to the request of the mailing list. This report just covers one part of the mail conversation. We have had further information on how to avoid that issue by using version numbers. The granularity level will help also but the versioning must be correct to be a real help. For the 2nd issue we will suggest a patch (hopefully soon).

        In other case the OSGi environment won't be specific enough and there could still be class loading issues e.g. with JAXP.

        Do I understand well that you are e.g. now using javax.servlet 2.5? Meaning the correct version of the lib itself (not Tuscany). That would help really much.

        How do you define versioning in that case? Open for extension by using lower bounds or strictly fixed to one version by setting lower and upper bounds.

        The question is whether we have the need to modify the build scripts... OSGi should solve dependent on how you define the version requirements.

        Could you explain the issues regarding version numbers on import more exactly? I did not understood the possible ways you would like to go.

        Missing import version numbers could lead to old versions of libraries to be loaded by Tuscany. e.g. when a just a old version of that lib is present as OSGi bundle. That should be a general issue. (But it will always depend on loading behavior of the application)

        We would like to use the tuscany-sca-osgi-installer.jar. How did we do that? (Sorry I am just PM; and getting onto this issue because its vital to me)

        Show
        Georg Schmidt added a comment - Thank you for your fast response. Yes. we are currently using the 5 bundles. The JIRA issue is in correspondence to the request of the mailing list. This report just covers one part of the mail conversation. We have had further information on how to avoid that issue by using version numbers. The granularity level will help also but the versioning must be correct to be a real help. For the 2nd issue we will suggest a patch (hopefully soon). In other case the OSGi environment won't be specific enough and there could still be class loading issues e.g. with JAXP. Do I understand well that you are e.g. now using javax.servlet 2.5? Meaning the correct version of the lib itself (not Tuscany). That would help really much. How do you define versioning in that case? Open for extension by using lower bounds or strictly fixed to one version by setting lower and upper bounds. The question is whether we have the need to modify the build scripts... OSGi should solve dependent on how you define the version requirements. Could you explain the issues regarding version numbers on import more exactly? I did not understood the possible ways you would like to go. Missing import version numbers could lead to old versions of libraries to be loaded by Tuscany. e.g. when a just a old version of that lib is present as OSGi bundle. That should be a general issue. (But it will always depend on loading behavior of the application) We would like to use the tuscany-sca-osgi-installer.jar. How did we do that? (Sorry I am just PM; and getting onto this issue because its vital to me)
        Hide
        Rajini Sivaram added a comment -

        Am I right in assuming that you are using the 5 bundles generated using itest/osgi-tuscany?

        These bundles have been superceded by a finer-grained set of (roughly) 200 bundles, where each Tuscany module is converted to a separate bundle, and each third party jar is converted on-the-fly to a separate bundle. itest/osgi-tuscany/tuscany-osgi-installer generates a bundle containing the list of Tuscany modules and 3rd party jars and a bundle activator which installs those. To install Tuscany into an OSGi runtime, you should install and start tuscany-sca-osgi-installer.jar.

        Does this JIRA correspond to the first issue described in http://markmail.org/message/noszcnhr6shqmjt2 ?

        If so, could you try out the latest version of itest/osgi-tuscany, using the installer bundle?

        We haven't yet tackled versioning issues with Tuscany, and clearly the coarse grain bundles which were used earlier cannot handle versioning of individual 3rd party jars.

        The bundles generated by tuscany-sca-osgi-installer.jar for 3rd party jars are versioned (and the version number is the same as the jar version). So it should enable sharing of jars across Tuscany and applications if the application is able to use the same version as Tuscany. If you want to use a different version of 3rd party jar in the application, and force Tuscany to use that version, you can modify the maven dependencies in the installer to exclude the jar (as long as the versions are compatible). Would this be sufficient to handle your scenario?

        There is still the outstanding issue of version numbers in Tuscany imports. This will be an issue if we want to provide isolation and force either two Tuscany extensions, or a Tuscany extension and an application to use two different versions of a 3rd party library.

        As we are only beginning to look at versioning in Tuscany, it will be very useful for us to understand the usage scenarios. The level of versioning we add to import statements in Tuscany modules will really depend on whether we are trying to tackle sharing or isolation of classloaders. Could you give some more detail on the scenario that you are using?

        Show
        Rajini Sivaram added a comment - Am I right in assuming that you are using the 5 bundles generated using itest/osgi-tuscany? These bundles have been superceded by a finer-grained set of (roughly) 200 bundles, where each Tuscany module is converted to a separate bundle, and each third party jar is converted on-the-fly to a separate bundle. itest/osgi-tuscany/tuscany-osgi-installer generates a bundle containing the list of Tuscany modules and 3rd party jars and a bundle activator which installs those. To install Tuscany into an OSGi runtime, you should install and start tuscany-sca-osgi-installer.jar. Does this JIRA correspond to the first issue described in http://markmail.org/message/noszcnhr6shqmjt2 ? If so, could you try out the latest version of itest/osgi-tuscany, using the installer bundle? We haven't yet tackled versioning issues with Tuscany, and clearly the coarse grain bundles which were used earlier cannot handle versioning of individual 3rd party jars. The bundles generated by tuscany-sca-osgi-installer.jar for 3rd party jars are versioned (and the version number is the same as the jar version). So it should enable sharing of jars across Tuscany and applications if the application is able to use the same version as Tuscany. If you want to use a different version of 3rd party jar in the application, and force Tuscany to use that version, you can modify the maven dependencies in the installer to exclude the jar (as long as the versions are compatible). Would this be sufficient to handle your scenario? There is still the outstanding issue of version numbers in Tuscany imports. This will be an issue if we want to provide isolation and force either two Tuscany extensions, or a Tuscany extension and an application to use two different versions of a 3rd party library. As we are only beginning to look at versioning in Tuscany, it will be very useful for us to understand the usage scenarios. The level of versioning we add to import statements in Tuscany modules will really depend on whether we are trying to tackle sharing or isolation of classloaders. Could you give some more detail on the scenario that you are using?

          People

          • Assignee:
            Unassigned
            Reporter:
            Georg Schmidt
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development