[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604217#action_12604217 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604050#action_12604050 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602965#action_12602965 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603038#action_12603038 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602583#action_12602583
]
Rajini Sivaram commented on TUSCANY-2343:
-
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
OSGi bundle design leads to class loading issues
Key: TUSCANY-2343
URL: https://issues.apache.org/jira/browse/TUSCANY-2343
Project: Tuscany
Issue Type: Bug
Reporter: Georg Schmidt
Attachments: Libary Versions.xls, test_bundles.zip
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602606#action_12602606 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602655#action_12602655 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602242#action_12602242 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602292#action_12602292 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602324#action_12602324 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602063#action_12602063 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601495#action_12601495 ] Rajini Sivaram commented on TUSCANY-2343: - 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 [EMAIL PROTECTED]) ? 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-2330: Attachment: samples-calculator-osgi-runtime-patch.txt Graham, I have attached the patch for the OSGi calculator sample as I have it on my machine. It could help in the discussion on whether this should be a sample or an itest. - Rajini Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next Attachments: calculator-osgi-sample.patch, samples-calculator-osgi-runtime-patch.txt Original Estimate: 2h Remaining Estimate: 2h It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601179#action_12601179 ] Rajini Sivaram commented on TUSCANY-2343: - 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... OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601192#action_12601192 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600697#action_12600697 ] Rajini Sivaram commented on TUSCANY-2343: - 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 OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600398#action_12600398 ] Rajini Sivaram commented on TUSCANY-2343: - 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? OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600437#action_12600437 ] Rajini Sivaram commented on TUSCANY-2343: - 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. OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598635#action_12598635
]
Rajini Sivaram commented on TUSCANY-2330:
-
Graham,
I tried out the test (listed below), using your patch, and it seems to work
fine. So if you want, I can check in this code, along with the rest of your
patch tonight, and you can continue from there.
If this is going to be a sample, I think it should use Felix rather than
Equinox to avoid both Felix and Equinox being added to the Tuscany distribution
(depending on the order in which they appear in tuscany-sca-manifest.jar file,
they can result in conflicts when running Tuscany outside OSGi).
The test that I ran looks like:
public class CalculatorTestCase {
private BundleContext bundleContext;
@Before
public void setUp() throws Exception {
String[] equinoxArgs = new String[] {-clean, -console,
-configuration, target/configuration};
bundleContext = EclipseStarter.startup(equinoxArgs, null);
}
@After
public void tearDown() throws Exception {
if (bundleContext != null) {
bundleContext.getBundle().stop();
}
}
@Test
public void runCalculator() throws Exception {
Bundle tuscanyInstallerBundle =
bundleContext.installBundle(file:../tuscany-osgi-installer/target/tuscany-sca-osgi-installer.jar);
tuscanyInstallerBundle.start();
Bundle calculatorBundle =
bundleContext.installBundle(file:../calculator/target/sample-calculator-bundle.jar);
calculatorBundle.start();
}
}
Calculator sample running in OSGi
-
Key: TUSCANY-2330
URL: https://issues.apache.org/jira/browse/TUSCANY-2330
Project: Tuscany
Issue Type: Wish
Components: Java SCA Samples
Affects Versions: Java-SCA-Next
Environment: All
Reporter: Graham Charters
Fix For: Java-SCA-Next
Attachments: calculator-osgi-sample.patch
Original Estimate: 2h
Remaining Estimate: 2h
It would help with preserving OSGi support if an OSGi sample were run as a
matter of course, rather than only by a small number of developers. This
wish is to add the smallest sample possible based on existing Tuscany module
dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2330) Calculator sample running in OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598433#action_12598433 ] Rajini Sivaram commented on TUSCANY-2330: - Graham, For some reason, I was expecting this to be an itest, but I notice you intended it to be a sample. That is good, since we currently dont have a sample which runs Tuscany under OSGi. So this module can be a sample as well as a sniff test for OSGi-based Tuscany. However, to enable this to be really used as a sample, it might help if code was simplified. Currently it uses the test harness from itest/osgi-tuscany which builds test bundles on-the-fly from the classes in the samples directories. I feel that is too complicated for use in a sample (yes, that is all my fault). It would be really nice to have a sample which simply does: 1. Create an OSGi runtime 2. Install and start Tuscany OSGi installer bundle 3. Install and start calculator bundle and away it goes and runs the calculator sample on Tuscany inside an OSGi runtime. Step 2 could be replaced later with whatever mechanism we choose to provide for installing Tuscany into OSGi. What do you think? I can help with the code if you like (but it will have to wait till the weekend). PS: Sorry, I should have noticed that you were referring to this as 'sample' all along. - Rajini Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next Attachments: calculator-osgi-sample.patch Original Estimate: 2h Remaining Estimate: 2h It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2307) Calling OSGi Service with SDO data
[ https://issues.apache.org/jira/browse/TUSCANY-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595937#action_12595937 ] Rajini Sivaram commented on TUSCANY-2307: - Roshan, Is the Java component (which is invoking the OSGi service) inside an OSGi bundle contribution? If not, will it be possible to make it an OSGi bundle contribution (jar file with OSGi manifest headers)? Calling OSGi Service with SDO data -- Key: TUSCANY-2307 URL: https://issues.apache.org/jira/browse/TUSCANY-2307 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP, Java Tuscany Sca runtime Reporter: Roshan Joseph Fix For: Java-SDO-Next Hi, I am trying to call an OSGi service from my sca java service running in the Tuscany SCA runtime. I uses the itest\osgi-implementation sample for SDO as my osgi service and calls the getGreetings method with SDO data as the input parameter for this call. I am reusing the HelloWorldService.jar which is in the itest\osgi-implementation folder for my OSGi service component. The composite file of my java service is something like as shown below. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://com.siemens.hintegration; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0; xmlns:hw=http://com.siemens.hintegration; name=motionreactorComposite dbsdo:import.sdo factory=com.siemens.hintegration.sdo.MotionReactorFactory / component name=MotionReactorServiceComponent implementation.java class=com.siemens.hintegration.MotionReactorImpl / service name=MotionReactorService interface.java interface=com.siemens.hintegration.MotionReactorService/ !--JMS Binding-- binding.jms initialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61616 destination name=activemq/queue/sendQueue create=always/ /binding.jms /service !-- Reference to the OSGi Service -- reference name=helloWorldService target=OSGiHelloWorldServiceComponent / /component component name=OSGiHelloWorldServiceComponent implementation.osgi xmlns=http://tuscany.apache.org/xmlns/sca/1.0; bundleSymbolicName=ds.helloworld.sdo.HelloWorldService/ /component /composite The actual code in my java component where I make the call to OSGi service is as follows: // Call the OSGi service Name name = HelloworldFactory.INSTANCE.createName(); name.setFirst(firstName); name.setLast(lastName); String hello = helloWorldService.getGreetings(name); getLogger().info(OSGi iTest Sample Call: + Hello); getLogger().info(OsgiService called); In the debug mode when the call reaches the OSgi component, I get a illegal argument exception. The error log looks like as shown below. - Exception occured while calling OSGi service java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeMethod(OSGiTargetInvoker.java:171) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiRemotableInvoker.invokeMethod(OSGiRemotableInvoker.java:75) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget(OSGiTargetInvoker.java:143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke(OSGiTargetInvoker.java:188) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy8.getGreetings(Unknown Source) at
[jira] Closed: (TUSCANY-2294) Add OSGi manifest entries to Tuscany modules
[
https://issues.apache.org/jira/browse/TUSCANY-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajini Sivaram closed TUSCANY-2294.
---
Resolution: Fixed
Changes checked in under revision 654236.
Add OSGi manifest entries to Tuscany modules
Key: TUSCANY-2294
URL: https://issues.apache.org/jira/browse/TUSCANY-2294
Project: Tuscany
Issue Type: Bug
Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-1.2
Reporter: Rajini Sivaram
Assignee: Rajini Sivaram
Fix For: Java-SCA-Next
Details on the discussion on adding manifest entries to Tuscany modules are
on this thread:
http://marc.info/?l=tuscany-devm=120936893510825w=2.
Modules will continue to be built as jars, and maven-bundle-plugin will be
used to generate the jar manifest (with OSGi headers). This will not have any
impact on the normal usage of the jars outside OSGi.
Each module pom.xml will contain an entry that looks like:
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
configuration
instructions
Bundle-Version${tuscany.version}/Bundle-Version
Bundle-SymbolicNameorg.apache.tuscany.sca.assembly/Bundle-SymbolicName
Bundle-Description${pom.name}/Bundle-Description
Export-Packageorg.apache.tuscany.sca.assembly*/Export-Package
/instructions
/configuration
/plugin
/plugins
/build
If the module dynamically loads classes from packages which are not visible
to the module (and yes, we do this in some places), there should also
be an additional DynamicImport-Package/ entry which lists the packages
(packages can be wildcarded).
When a new module is added, the section above (which is from
modules/assembly) can be cut-and-paste with the following changes:
1) Bundle-SymbolicName/ should be unique across all modules, and use the
format org.apache.tuscany.sca.module.name
2) Export-Package/ Comma separated list of packages exported by the module.
Package name can be wildcarded. To start with, all modules will use
wildcarded package names to avoid breakage when new subpackages are added.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2292) Remove split-packages across modules in Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2292. --- Resolution: Fixed Assignee: Rajini Sivaram Fixed under revision 654236. Remove split-packages across modules in Tuscany --- Key: TUSCANY-2292 URL: https://issues.apache.org/jira/browse/TUSCANY-2292 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next There are three packages which are split across two modules each in Tuscany: 1) org.apache.tuscany.sca.domain - split across domain and domain-api 2) org.apache.tuscany.sca.node - split across node and node-api 3) org.apache.tuscany.sca.policy.xml - split across policy-xml and policy-xml-ws It will be good to remove these split packages and have cleaner package definitions to enable modules to be built as OSGi bundles. OSGi can cope with split packages with Require-Bundle, but it would be much neater if we didn't have to treat these six modules differently. Can anyone think of any reason why these packages should be split across modules? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2293) Assembly-xsd module defines xsds in the default package
[ https://issues.apache.org/jira/browse/TUSCANY-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2293. --- Resolution: Fixed Assignee: Rajini Sivaram Temporary fix to use TCCL to load the schema applied under revision 654236. But I agree with Hasan (https://issues.apache.org/jira/browse/TUSCANY-2295) that schema loading should use extension points. Assembly-xsd module defines xsds in the default package --- Key: TUSCANY-2293 URL: https://issues.apache.org/jira/browse/TUSCANY-2293 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next All xsds in assembly-xsd are defined in the default package. tuscany-sca.xsd is currently read by ReallySmallRuntimeBuilder using the following code: ReallySmallRuntimeBuilder.class.getClassLoader().getResource(tuscany-sca.xsd); For this code to work under OSGi, ReallySmallRuntimeBuilder has to be in the same bundle as tuscany-sca.xsd. To enable Tuscany modules to be built as separate OSGi bundles, either this classloading needs to be modified (to use Thread context classloader perhaps), or the xsd needs to move into a package (which can then be imported by host-embedded). The use of default package should be avoided wherever possible... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2292) Remove split-packages across modules in Tuscany
Remove split-packages across modules in Tuscany --- Key: TUSCANY-2292 URL: https://issues.apache.org/jira/browse/TUSCANY-2292 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next There are three packages which are split across two modules each in Tuscany: 1) org.apache.tuscany.sca.domain - split across domain and domain-api 2) org.apache.tuscany.sca.node - split across node and node-api 3) org.apache.tuscany.sca.policy.xml - split across policy-xml and policy-xml-ws It will be good to remove these split packages and have cleaner package definitions to enable modules to be built as OSGi bundles. OSGi can cope with split packages with Require-Bundle, but it would be much neater if we didn't have to treat these six modules differently. Can anyone think of any reason why these packages should be split across modules? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2293) Assembly-xsd module defines xsds in the default package
Assembly-xsd module defines xsds in the default package --- Key: TUSCANY-2293 URL: https://issues.apache.org/jira/browse/TUSCANY-2293 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.2 Reporter: Rajini Sivaram Priority: Minor Fix For: Java-SCA-Next All xsds in assembly-xsd are defined in the default package. tuscany-sca.xsd is currently read by ReallySmallRuntimeBuilder using the following code: ReallySmallRuntimeBuilder.class.getClassLoader().getResource(tuscany-sca.xsd); For this code to work under OSGi, ReallySmallRuntimeBuilder has to be in the same bundle as tuscany-sca.xsd. To enable Tuscany modules to be built as separate OSGi bundles, either this classloading needs to be modified (to use Thread context classloader perhaps), or the xsd needs to move into a package (which can then be imported by host-embedded). The use of default package should be avoided wherever possible... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2294) Add OSGi manifest entries to Tuscany modules
Add OSGi manifest entries to Tuscany modules
Key: TUSCANY-2294
URL: https://issues.apache.org/jira/browse/TUSCANY-2294
Project: Tuscany
Issue Type: Bug
Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-1.2
Reporter: Rajini Sivaram
Assignee: Rajini Sivaram
Fix For: Java-SCA-Next
Details on the discussion on adding manifest entries to Tuscany modules are on
this thread:
http://marc.info/?l=tuscany-devm=120936893510825w=2.
Modules will continue to be built as jars, and maven-bundle-plugin will be used
to generate the jar manifest (with OSGi headers). This will not have any impact
on the normal usage of the jars outside OSGi.
Each module pom.xml will contain an entry that looks like:
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
configuration
instructions
Bundle-Version${tuscany.version}/Bundle-Version
Bundle-SymbolicNameorg.apache.tuscany.sca.assembly/Bundle-SymbolicName
Bundle-Description${pom.name}/Bundle-Description
Export-Packageorg.apache.tuscany.sca.assembly*/Export-Package
/instructions
/configuration
/plugin
/plugins
/build
If the module dynamically loads classes from packages which are not visible to
the module (and yes, we do this in some places), there should also
be an additional DynamicImport-Package/ entry which lists the packages
(packages can be wildcarded).
When a new module is added, the section above (which is from modules/assembly)
can be cut-and-paste with the following changes:
1) Bundle-SymbolicName/ should be unique across all modules, and use the
format org.apache.tuscany.sca.module.name
2) Export-Package/ Comma separated list of packages exported by the module.
Package name can be wildcarded. To start with, all modules will use wildcarded
package names to avoid breakage when new subpackages are added.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2285) Make sca-api automatically build as an OSGi bundle
[ https://issues.apache.org/jira/browse/TUSCANY-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593731#action_12593731 ] Rajini Sivaram commented on TUSCANY-2285: - Raymond, Was the issue with maven-bundle-plugin and SDO related to building on JDK 1.4 (which is not supported with Tuscany-SCA)? If not, could you describe the problem and/or how to recreate it? We can use the manifest goal for sca-api, but we may want to use bundle/bundleall goals to generate the high-level combinations for distribution. I am sure the Felix team will help to fix the problem if we can identify what the issue was. Thank you... Make sca-api automatically build as an OSGi bundle -- Key: TUSCANY-2285 URL: https://issues.apache.org/jira/browse/TUSCANY-2285 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime, Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Priority: Minor Fix For: Java-SCA-Next Attachments: sca-api-bundle.patch Original Estimate: 0.5h Remaining Estimate: 0.5h Itest/osgi-tuscany creates an OSGi bundle for the sca-api module. As a step towards providing better support for OSGi, it has been suggested on the dev-list that we simply make sca-api automatically build as an OSGi bundle. This does not preclude it being used as a normal jar. I have a patch which I will attached shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2209) Question about Conversational OSGi Services and Service References
[ https://issues.apache.org/jira/browse/TUSCANY-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram reassigned TUSCANY-2209: --- Assignee: Rajini Sivaram Question about Conversational OSGi Services and Service References -- Key: TUSCANY-2209 URL: https://issues.apache.org/jira/browse/TUSCANY-2209 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Rajini Sivaram Attachments: OneWay_Conversation_OSGi_SCA_test.zip For an overview of the problem please check this thread on the mailing-list: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2209) Question about Conversational OSGi Services and Service References
[ https://issues.apache.org/jira/browse/TUSCANY-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587100#action_12587100 ] Rajini Sivaram commented on TUSCANY-2209: - Daniel, I think you were seeing three instances of Gamma being created because the first instance was created before the annotations were processed, due to a race in OSGiImplementationProvider.startBundle, which is not synchronized. I have committed a fix under revision 646232. Could you try it out? Thank you. Question about Conversational OSGi Services and Service References -- Key: TUSCANY-2209 URL: https://issues.apache.org/jira/browse/TUSCANY-2209 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Assignee: Rajini Sivaram Attachments: OneWay_Conversation_OSGi_SCA_test.zip For an overview of the problem please check this thread on the mailing-list: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2197) Conversations with OSGi services expire immediately
[ https://issues.apache.org/jira/browse/TUSCANY-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586173#action_12586173 ] Rajini Sivaram commented on TUSCANY-2197: - Patch applied under revision 645290. Thank you for the patch, Juergen. Conversations with OSGi services expire immediately --- Key: TUSCANY-2197 URL: https://issues.apache.org/jira/browse/TUSCANY-2197 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: Windows XP, Eclipse 3.3.2 Reporter: Jürgen Schumacher Attachments: tuscany-implosgi-osgiannotation.patch This occurred with current revision from sca-java-1.2 branch. I use the Tuscany OSGi bundles created by itests/osgi-tuscany in Eclipse Equinox, the SCA domain is started in a BundleActivator of my test projects. When I use implementation.osgi for a conversational service, the first method call after the init method throws a org.osoa.sca.ConversationEndedException: Conversation 44c36d6c-68af-4ba9-a9ba-354ccc5dd9d0 has expired. I debugged this and it seems that is caused by org.apache.tuscany.sca.implementation.osgi.context.OSGiAnnotations, which uses Long.MAX_VALUE as the default values for maxAge and maxIdleTime which in turn causes an overflow in the initializeConversationAttributes() of org.apache.tuscany.sca.core.conversation.ExtendedConversationImpl. This results in a negative expirationTime which is of course always smaller than the current time. When I change the default values to -1 (as in org.apache.tuscany.sca.implementation.java.impl.JavaImplementationImpl), it works. See attached patch for modules/implementation-osgi. I'm not sure if this is the best or correct solution, but it may be a hint to someone with more knowledge about this code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2105) NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain
[ https://issues.apache.org/jira/browse/TUSCANY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580717#action_12580717 ] Rajini Sivaram commented on TUSCANY-2105: - Luciano, I modified all the OSGi modules to use Felix 1.0.3 rather than 1.0.1 in the 1.2 branch. Sorry, I wasn't trying to overwrite your changes, but the we had some fixes for classloading and deadlocks in Felix that went into 1.0.3. I hope you don't mind. - Rajini NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain - Key: TUSCANY-2105 URL: https://issues.apache.org/jira/browse/TUSCANY-2105 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Priority: Blocker Fix For: Java-SCA-1.2 run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/osgi/framework/BundleException [java] at org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89) [java] at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:150) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:207) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:74) [java] at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:248) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:876) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:80) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:129) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:52) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:464) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:161) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:155) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) [java] at supplychain.SupplyChainClient.main(SupplyChainClient.java:33) [java] Java Result: 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580732#action_12580732 ] Rajini Sivaram commented on TUSCANY-2097: - Simon, Thank you for trying out the latest build. cachedir directory is created by the calculator-script sample when it is running under OSGi. I think it is created by one of the script engines, but I couldn't figure out if the directory name is specified somewhere in Tuscany. I also have no idea why the directory is not created when the sample is run outside of OSGi. Does anyone have any clues? Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580800#action_12580800 ] Rajini Sivaram commented on TUSCANY-2097: - Thank you, Ant. I have modified the OSGi testcase which runs calculator-script to set the system property python.cachedir to target/cachedir (revision 639327). So mvn clean should now clear that as well. Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2105) NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain
[ https://issues.apache.org/jira/browse/TUSCANY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580285#action_12580285 ] Rajini Sivaram commented on TUSCANY-2105: - The version of Felix in the Tuscany 1.2 distribution is an old released version, while the Felix jars listed in tuscany-sca-manifest.jar are 1.1.0-SNAPSHOT. Shall I modify all OSGi-related modules and tests in Tuscany for the 1.2 branch to use the latest released version of Felix ? The tests which require a fix from the Felix snapshot are turned off in the 1.2 build anyway. NoClassDefFoundError: org/osgi/framework/BundleException running osgi-supplychain - Key: TUSCANY-2105 URL: https://issues.apache.org/jira/browse/TUSCANY-2105 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Fix For: Java-SCA-1.2 run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/osgi/framework/BundleException [java] at org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89) [java] at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:150) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:207) [java] at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:74) [java] at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:248) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:876) [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:80) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:129) [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:52) [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:464) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:348) [java] at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:161) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:155) [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) [java] at supplychain.SupplyChainClient.main(SupplyChainClient.java:33) [java] Java Result: 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580333#action_12580333 ] Rajini Sivaram commented on TUSCANY-2097: - Simon, Could you update to the latest version of itest/osgi-tuscany and modules/osgi-runtime and retry the test? Before running the test, please run mvn clean and also delete the directory itest/osgi-tuscany/.felix.test. Revision 638794 reuses bundles from .felix.test rather than clean it up everytime. That should hopefully avoid the errors you are seeing. The caching of bundles in .felix.test also improves the performance of the tests. It does mean that a clean build is required to test osgi-tuscany when changes are made to the Tuscany runtime. I have moved .felix.test to the target directory so that it is deleted by mvn clean. Thank you Rajini Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580384#action_12580384 ] Rajini Sivaram commented on TUSCANY-2093: - Revision 638836 removes Felix console from all the OSGi tests. I have now added itest/osgi-implementation to the main build. If any of the problems with implementation.osgi tests recur, I will take it out. Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579763#action_12579763 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, If you can recreate the hang under maven, could you generate a javacore by pressing Ctrl-Break (on Windows) when the process is hanging? Thank you. Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579786#action_12579786 ] Rajini Sivaram commented on TUSCANY-2093: - Thank you for the thread dump. I am not sure what happened to the thread which was running OSGi test code. I have tried with the Sun JDK, and still can't recreate the hang (but I am using a slightly later version of the JDK). What version of maven are you using? Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579839#action_12579839 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, Thank you for the stack trace - this is very useful (even though I still dont know what the problem is). There are two threads there which look suspicious: Felix Shell TUI This thread is doing a System.out.println, which should be piped into the other maven process, and the wait could be because the other process was killed. I am fairly certain this is not the cause since you were able to recreate the hang under Eclipse. But to be absolutely sure, could you remove the line containing org.apache.felix.shell.tui from osgi-implementation\src\test\resources\osgi\felix\felix.config.properties, and see if the hang recurs? main This thread is doing a non-blocking invocation. And looking at the three stack traces you had at the start, they are all doing non-blocking invocations. I wonder what could cause this thread from not completing. It seems to be in RUNNING state, and from the stack trace I can't see anything causing it to block before it completes the call (and the calls results in a print, so it didn't complete in any of your hanging runs). I will dig into the code a bit further. Do you have any ideas? Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2097) Build errors in itest/osgi-tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579925#action_12579925 ] Rajini Sivaram commented on TUSCANY-2097: - Simon, Could you delete the directory itest\osgi-tuscany\osgi-tuscany-test\.felix.test and rerun the test? Thank you... Build errors in itest/osgi-tuscany -- Key: TUSCANY-2097 URL: https://issues.apache.org/jira/browse/TUSCANY-2097 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows, Sun JDK 1.5.0_14 Reporter: Simon Nash Fix For: Java-SCA-Next Attachments: jira2097.log Here is a summary of the build errors I am seeing. I will attach my full build log to this JIRA. 1. revision.location error creating archive. This seems to show up on every test, and it does not seem to cause a hard failure in the test. java.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany- test\.felix.test\bundle1\version0.0\revision.location (The system cannot find th e file specified) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (ja va.io.FileNotFoundException: F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-te st\.felix.test\bundle1\version0.0\revision.location (The system cannot find the file specified)) 2. InvocationTargetException in CalculatorRMIReferencetestCase. java.lang.reflect.InvocationTargetException . Caused by: java.rmi.server.ExportException: Port already in use: 8099; nested ex ception is: java.net.BindException: Address already in use: JVM_Bind 3. Various errors in testOSGiTuscany_BindingWS - ERROR: org.apache.felix.framework.cache.BundleArchive: Unable to delete archi ve directory - F:\tuscany63\sca\itest\osgi-tuscany\osgi-tuscany-test\.felix.test \bundle5 java.util.zip.ZipException: The system cannot find the file specified org.osgi.framework.BundleException: Could not create bundle object. . Caused by: java.util.zip.ZipException: The system cannot find the file specified -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2086. --- Resolution: Fixed implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Attachments: tuscany-equinox-runtime.patch, tuscany.osgi.sample.launch.zip, tuscany.osgi.sample.zip This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2096) When itest/osgi-tuscany bundles run in Equinox, OSGiRuntime does not find EquinoxRuntime, but uses FelixRuntime
[ https://issues.apache.org/jira/browse/TUSCANY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579934#action_12579934 ] Rajini Sivaram commented on TUSCANY-2096: - Jurgen, Thank you for the patch. It has been applied under revision 638445. I am not sure if the .mar file is used anywhere, so I didn't want to remove it without being sure. Is there a problem with having these files in the bundle or is it because they have been added to the Bundle-ClassPath? When itest/osgi-tuscany bundles run in Equinox, OSGiRuntime does not find EquinoxRuntime, but uses FelixRuntime --- Key: TUSCANY-2096 URL: https://issues.apache.org/jira/browse/TUSCANY-2096 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Affects Versions: Java-SCA-Next Environment: Windows XP, Sun JDK 1.5.0_11, Eclipse 3.3.2 (Equinox 3.3.2) Reporter: Jürgen Schumacher Priority: Minor Attachments: itest-osgituscany-runtime-pom.patch I used the OSGi bundles generated by itest/osgi-tuscany in Equinox. The BundleActivator of the tuscany-runtime bundle calls OSGiRuntime.findRuntime(), which creates a org.apache.tuscany.sca.osgi.runtime.FelixRuntime. This seems not to disturb operation very much, because the main difference to EquinoxRuntime is in starting and stopping a Felix or Equinox runtime. But it can be easily fixed by adding the package of EclipseStarter, org.eclipse.core.runtime.adaptor, to the DynamicImport-Package statement of the manifest of the tuscany-runtime bundle. See attached patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2089) java.lang.NoClassDefFoundError: running sample Calculator using ant script
[ https://issues.apache.org/jira/browse/TUSCANY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579359#action_12579359 ] Rajini Sivaram commented on TUSCANY-2089: - The dependency on OSGi API for non-OSGi samples has been fixed under revision 637797. The dependency on Felix snapshots for OSGi modules in Tuscany is still outstanding. java.lang.NoClassDefFoundError: running sample Calculator using ant script -- Key: TUSCANY-2089 URL: https://issues.apache.org/jira/browse/TUSCANY-2089 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 run: [java] Exception in thread main java.lang.NoClassDefFoundError: org/apache/tuscany/sca/host/embedded/SCADomain [java] at calculator.CalculatorClient.main(CalculatorClient.java:31) [java] Java Result: 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579509#action_12579509 ] Rajini Sivaram commented on TUSCANY-2086: - Thank you for the patch. It has been applied under revision 637970. I will take a look at your tests. implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Attachments: tuscany-equinox-runtime.patch, tuscany.osgi.sample.launch.zip, tuscany.osgi.sample.zip This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2093) Hangs in osgi itests
[ https://issues.apache.org/jira/browse/TUSCANY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579514#action_12579514 ] Rajini Sivaram commented on TUSCANY-2093: - Ant, Can you recreate the hang in itest/osgi-contribution or itest/osgi-implementation under Eclipse in debug mode? If you can, could you generate a stack trace of all the threads when it is hanging? Otherwise, would it be possible to generate a javacore when the test is hanging? What platform are you running the test on? Could you also check the version of Felix (the date on the snapshot) that is in your maven repository, so that I can try using the same one? Thank you. Hangs in osgi itests Key: TUSCANY-2093 URL: https://issues.apache.org/jira/browse/TUSCANY-2093 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next I get hangs running various of the osgi itests, the test run part way through then just appear to hang for ever, no IO or CPU activity on the process. Eg, the output on the console for some hangs are: Running org.apache.tuscany.sca.test.osgi.tuscany.OSGiSupplyChainTestCase - Run tests from : ../../../samples/osgi-supplychain Loaded Tuscany, time taken = 31625 ms Running test null(supplychain.SupplyChainClientTestCase) Started OSGi bundle with activator OSGiCustomerImpl Started OSGi bundle with activator OSGiShipperImpl another: [INFO] Building Apache Tuscany OSGi Contribution tests [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\Tuscany\SVN\LATEST\itest\osgi-contribution\contribution-test\target\surefire-reports --- T E S T S --- Running org.apache.tuscany.sca.contribution.osgi.test.OSGiResolverTestCase - Created supplychain.customer.JavaCustomerComponentImpl using classloader 6.0 Created supplychain.retailer.JavaRetailerComponentImpl using classloader 7.0 Created supplychain.warehouse.JavaWarehouseComponentImpl using classloader 8.0 Created supplychain.shipper.JavaShipperComponentImpl using classloader 9.0 another: Running supplychain.wiring.DSWiring1TestCase - Main thread Thread[main,5,main] Created OSGiCustomerComponentImpl [EMAIL PROTECTED] Activated OSGiCustomerComponentImpl bundle OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED] Activated OSGiRetailerComponentImpl bundle Activated OSGiRetailerComponentImpl bundle OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED] JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED] Activated OSGiShipperComponentImpl bundle Activated OSGiShipperComponentImpl bundle OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED] This is easily recreateable so i can help debug, just right now i'm not sure where to look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579629#action_12579629 ] Rajini Sivaram commented on TUSCANY-2086: - For your bundle named /./tuscany.osgi.sample/, the componentType file that implementation.osgi looks for is tuscany/osgi/sample.componentType. At least it should be - the code used to assume that all bundles were .jar files. I have put it another fix, so hopefully it will now look for tuscany/osgi/sample.componentType. Tuscany processes componentType files only from SCA contributions. In your test, contribution.jar is the SCA contribution. The componentType file should be in that jar file for Tuscany to process it. The bundle that is in your OSGi runtime can be referred to from an implementation.osgi component in an SCA composite, but that bundle is not used to resolve SCA artifacts. Hope this helps. implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Attachments: tuscany-equinox-runtime.patch, tuscany.osgi.sample.launch.zip, tuscany.osgi.sample.zip This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-2083) GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2083. --- Resolution: Fixed GroovyClassLoader is now created using the Tuscany classloader as parent since it is used to find Groovy classes, and not contribution classes. This change will not have any effect during normal Tuscany run outside of OSGi since Tuscany classloader will be the TCCL. GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi - Key: TUSCANY-2083 URL: https://issues.apache.org/jira/browse/TUSCANY-2083 Project: Tuscany Issue Type: Bug Components: Java SCA Groovy Implementation Extension Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 When Tuscany is run under OSGi, calculator-script sample throws the following exception: java.lang.NoClassDefFoundError: groovy.lang.Script at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:264) at java.security.SecureClassLoader.defineClass(Unknown Source) at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:57) at groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:445) at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode(GroovyClassLoader.java:463) at groovy.lang.GroovyClassLoader$ClassCollector.call(GroovyClassLoader.java:467) at org.codehaus.groovy.control.CompilationUnit$10.call(CompilationUnit.java:701) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:885) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:436) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:277) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:248) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:243) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:225) at org.apache.tuscany.sca.contribution.groovy.GroovyModelResolver.addModel(GroovyModelResolver.java:55) at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.addModel(ExtensibleModelResolver.java:132) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:454) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:386) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:203) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:158) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:231) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:35) GroovyModelResolver creates a GroovyClassLoader with the thread context classloader as its parent. The class is already loaded from the 3rd party OSGi bundle and this bundle classloader is part of TCCL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2068) itest/osgi-implementation is broken due to recent changes
[ https://issues.apache.org/jira/browse/TUSCANY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578830#action_12578830 ] Rajini Sivaram commented on TUSCANY-2068: - Ant, Thank you for applying the patch. Could you raise a JIRA for the hang? I haven't been able to recreate a hang, and I think Graham had the tests running to completion as well. Are you using the latest version of itest/osgi-implementation? itest/osgi-implementation is broken due to recent changes - Key: TUSCANY-2068 URL: https://issues.apache.org/jira/browse/TUSCANY-2068 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: ant elder Fix For: Java-SCA-1.2 Attachments: implementation.osgi.txt Recent changes related to Pass-by-value and callbacks have broken many of the itest/osgi-implementationt tests. The tests need to be added back to the itest pom to ensure that breakages are caught earlier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-2067) URL Handling in Tuscany breaks when Tuscany is run under OSGi
[ https://issues.apache.org/jira/browse/TUSCANY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-2067. --- Resolution: Fixed Revision 637139 adds support for bundle URLs as contributions and contribution artifacts in Tuscany. Both bundle:// and bundleresource:// URLs are supported, but the code has only been tested under Apache Felix, so I am not sure if any extra work is required for Equinox. URL Handling in Tuscany breaks when Tuscany is run under OSGi - Key: TUSCANY-2067 URL: https://issues.apache.org/jira/browse/TUSCANY-2067 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 Code in the old DefaultSCADomain and the new domain/node APIs manipulate URLs returned by classloader.getResource() to open a directory or jar file corresponding to a contribution. This breaks when Tuscany is run under OSGi since OSGi returns bundle:// or bundleresource:// URLs instead of the file:// and jar:// URLs supported under Tuscany. A full description of the problem and possible solutions are described in the thread http://www.mail-archive.com/[EMAIL PROTECTED]/msg02213.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram reassigned TUSCANY-2086: --- Assignee: Rajini Sivaram implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2086) implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace
[ https://issues.apache.org/jira/browse/TUSCANY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578873#action_12578873 ] Rajini Sivaram commented on TUSCANY-2086: - I have modified OSGiBundleReferenceModelResolver.getBundleFilename to return the last segment of the name when the path corresponds to a directory. I am not sure if you will run into other problems though. implementation.osgi cannot find compomentType file when referring to bundles in Eclipse Workspace - Key: TUSCANY-2086 URL: https://issues.apache.org/jira/browse/TUSCANY-2086 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Environment: Windows XP, Eclipse 3.3.2 (org.eclipse.osgi 3.3.2) Reporter: Jürgen Schumacher Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 This issue refers to activities described in http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/[EMAIL PROTECTED] When trying to test implementation.osgi I ended with this error message: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:276) ... caused by Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: missing .componentType side file .componentType at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:227) ... While Tuscany is right in that I did not provide a componentType file, it seems to be wrong in how it has created the filename. I debugged a bit and found the following: org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleReferenceModelResolver has a method getBundleFilename(...) that tries to extract the bundles filename from its location by looking for the last / in the location and using the rest afterwards. But when the bundle is located in my Eclipse workspace as a Plugin project under development and not packed as a JAR and I run my examples in a Equinox runtime, the reported location is e.g. [EMAIL PROTECTED]:file:../workspace/EILF/tuscany.osgi.sample/ where tuscany.osgi.sample is the actual bundle name. Therefore getBundleFilename returns just an empty string. And this empty string is used later in org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(...) to build the filename for the component type file, which results in .componentType as the complete filename in this case. I suppose the current code is meant to look for the componentType file next to a bundle JAR with the same basename as the bundle JAR. I'm not sure where it should look for it in my case, probably inside the workspace bundle directory, as the workspace directory itself is usually not visible in Eclipse and so it would be inconvenient to edit the file in the IDE. Sorry that I cannot provide a test case currently because had to create own Tuscany bundles to get this far (see mail thread linked above for details), which would be a bit large to attach, I suppose (-; Also I cannot provide a patch yet, because I'm quite new to OSGi and Tuscany myself and therefore cannot estimate what would be a valid solution currently. Of course if you have any ideas how to solve this, I can test it in my setup and give more feedback. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2083) GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi
GroovyClassLoader throws NoClassDefFoundError when Tuscany is run inside OSGi - Key: TUSCANY-2083 URL: https://issues.apache.org/jira/browse/TUSCANY-2083 Project: Tuscany Issue Type: Bug Components: Java SCA Groovy Implementation Extension Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-1.2 When Tuscany is run under OSGi, calculator-script sample throws the following exception: java.lang.NoClassDefFoundError: groovy.lang.Script at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:264) at java.security.SecureClassLoader.defineClass(Unknown Source) at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:57) at groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:445) at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode(GroovyClassLoader.java:463) at groovy.lang.GroovyClassLoader$ClassCollector.call(GroovyClassLoader.java:467) at org.codehaus.groovy.control.CompilationUnit$10.call(CompilationUnit.java:701) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:885) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:436) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:277) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:248) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:243) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:225) at org.apache.tuscany.sca.contribution.groovy.GroovyModelResolver.addModel(GroovyModelResolver.java:55) at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.addModel(ExtensibleModelResolver.java:132) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:454) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:386) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:203) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:272) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:158) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:231) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:35) GroovyModelResolver creates a GroovyClassLoader with the thread context classloader as its parent. The class is already loaded from the 3rd party OSGi bundle and this bundle classloader is part of TCCL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2067) URL Handling in Tuscany breaks when Tuscany is run under OSGi
URL Handling in Tuscany breaks when Tuscany is run under OSGi - Key: TUSCANY-2067 URL: https://issues.apache.org/jira/browse/TUSCANY-2067 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: Rajini Sivaram Code in the old DefaultSCADomain and the new domain/node APIs manipulate URLs returned by classloader.getResource() to open a directory or jar file corresponding to a contribution. This breaks when Tuscany is run under OSGi since OSGi returns bundle:// or bundleresource:// URLs instead of the file:// and jar:// URLs supported under Tuscany. A full description of the problem and possible solutions are described in the thread http://www.mail-archive.com/[EMAIL PROTECTED]/msg02213.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2068) itest/osgi-implementation is broken due to recent changes
itest/osgi-implementation is broken due to recent changes - Key: TUSCANY-2068 URL: https://issues.apache.org/jira/browse/TUSCANY-2068 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: Rajini Sivaram Recent changes related to Pass-by-value and callbacks have broken many of the itest/osgi-implementationt tests. The tests need to be added back to the itest pom to ensure that breakages are caught earlier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1897) OSGi-based Tuscany runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram resolved TUSCANY-1897. - Resolution: Fixed Assignee: Rajini Sivaram Code has been added to Tuscany under revisions 630151 and 630153. Integration tests for OSGi-based Tuscany have not been added to the build, since they require more than 100MB to create an OSGi bundle-ized version of Tuscany. OSGi-based Tuscany runtime -- Key: TUSCANY-1897 URL: https://issues.apache.org/jira/browse/TUSCANY-1897 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-Next Attachments: osgi-tuscany-patch.txt The attached patch provides support for running Tuscany runtime inside OSGi. Tuscany bundle activator sets the thread context classloader, and the classloader used for service discovery. Both are set to a bundle classloader which uses OSGi bundle API to resolve classes. The patch does not add bundle manifest entries into the Tuscany jars created by distribution. At the moment, OSGi bundles are created inside itest/osgi-tuscany. A set of tests have been added to verify these bundles. Tuscany is currently built as five bundles (API, SPI, Runtime, Extensions and 3rd party code). The dependencies across the bundles are hardcoded (these will be modified later to use maven-bundle-plugin wherever possible). The purpose of these tests are: 1. Verify classloader-based isolation across Tuscany bundles introduced recently. 2. Provide a testbed to build and test bundle-ized Tuscany. The Tuscany extensions bundle and 3rd party bundle should be split into smaller chunks. 3. Provide OSGi-based Tuscany bundles to build a reference implementation for Distributed-OSGi based on Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1897) OSGi-based Tuscany runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram closed TUSCANY-1897. --- OSGi-based Tuscany runtime -- Key: TUSCANY-1897 URL: https://issues.apache.org/jira/browse/TUSCANY-1897 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: Rajini Sivaram Fix For: Java-SCA-Next Attachments: osgi-tuscany-patch.txt The attached patch provides support for running Tuscany runtime inside OSGi. Tuscany bundle activator sets the thread context classloader, and the classloader used for service discovery. Both are set to a bundle classloader which uses OSGi bundle API to resolve classes. The patch does not add bundle manifest entries into the Tuscany jars created by distribution. At the moment, OSGi bundles are created inside itest/osgi-tuscany. A set of tests have been added to verify these bundles. Tuscany is currently built as five bundles (API, SPI, Runtime, Extensions and 3rd party code). The dependencies across the bundles are hardcoded (these will be modified later to use maven-bundle-plugin wherever possible). The purpose of these tests are: 1. Verify classloader-based isolation across Tuscany bundles introduced recently. 2. Provide a testbed to build and test bundle-ized Tuscany. The Tuscany extensions bundle and 3rd party bundle should be split into smaller chunks. 3. Provide OSGi-based Tuscany bundles to build a reference implementation for Distributed-OSGi based on Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2015) OSGI iTests are referencing Felix SNAPSHOTs
[ https://issues.apache.org/jira/browse/TUSCANY-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570156#action_12570156 ] Rajini Sivaram commented on TUSCANY-2015: - Because of a deadlock in the latest released version of Felix (https://issues.apache.org/jira/browse/FELIX-489), which has been fixed in the latest Felix snapshot, we need to wait for the next Felix release before migrating from the snapshot of the Felix framework. Revision 629049 has moved other Felix components (org.apache.felix.configadmin, org.apache.felix.bundlerepository and org.apache.felix.scr) from snapshot versions to their latest releases. Felix framework (org.apache.felix.main) has been set to 1.1.0-SNAPSHOT for now. I will change that when the next release is out. OSGI iTests are referencing Felix SNAPSHOTs --- Key: TUSCANY-2015 URL: https://issues.apache.org/jira/browse/TUSCANY-2015 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-1.1 Reporter: Luciano Resende Fix For: Java-SCA-Next -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568011#action_12568011
]
Rajini Sivaram commented on TUSCANY-1293:
-
The first block tries to run bundle.start() on SDO bundles and its dependent
bundles (EMF). It will throw an exception if one of these bundles could not be
resolved. There is a testBundle.start() outside the loop which has dependencies
on SDO (and hence on its dependencies). So if an exception is thrown by the
loop, the following testBundle.start() will throw an uncaught exception
,causing the test to fail. I put the code to catch and print the exception from
the loop rather than fail at the first exception so that all the bundles which
failed to resolve can be identified in one run, rather than have to rerun after
fixing one-by-one. The tests shouldn't really throw an exception now anyway, so
please feel free to remove the try-catch block if you prefer.
The second catch block corresponds to delegation to the parent classloader
during ClassLoader.loadClass(), and the exception there is deliberately caught
and ignored (the child classloader loads the class if the parent classloader
cannot). So the try-catch is necessary, and the exception doesn't reflect a
failure.
SDO does not work with OSGi
---
Key: TUSCANY-1293
URL: https://issues.apache.org/jira/browse/TUSCANY-1293
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
Fix For: Java-SDO-Next
Attachments: sdo-osgi.txt
When I execute:
XSDHelper.INSTANCE.define(schema, null);
I end up with a NullPointerException. I've tracked down root cause ...
The static initializer of the HelperProvider executes this code:
provider = getInstance(HelperProvider.class.getClassLoader());
which ends up calling:
HelperProvider provider = loadImplementation(cl, implName);
implName is null so
if (implName == null) {
implName = getImplementationName(cl);
}
ends up calling
implName = getImplementationName(cl);
which ends up calling:
InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
where SERVICE_RESORUCE_NAME =
META-INF/services/commonj.sdo.impl.HelperProvider
getResourceAsStream() return null because META-INF/services does not exist in
the API bundle. It exists in the IMPL bundle and since you are using the
class loader from the API bundle, it won't work.
You can set
-Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
to get around the above problem, but as soon as
return (HelperProvider) cl.loadClass(implName).newInstance();
executes, you get a CalssNotFoundException. Again, this is because you are
trying to load a class outside the bundle with the wrong class loader.
tried modifying the API manifest by hand to add
Eclipse-BuddyPolicy: dependent
and
Eclipse-BuddyPolicy: global
Either of those buddy policies will get past the class loader problem
(although I believe this is specific to eclipse and won't work for OSGi in
general), but when HelperProvider is initializing, you get the following
exception:
java.lang.ExceptionInInitializerError
at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
at java.lang.reflect.Field.get(Field.java:357)
at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
at
org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
[jira] Updated: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajini Sivaram updated TUSCANY-1293:
Attachment: sdo-osgi-export-patch.txt
I have tried to recreate the problem with IBM JDK 1.4.2, 5.0 and 6.0, and the
tests work fine with all of them with a clean build.
Based on the errors in continuum, the attached patch explictly exports/imports
the packages that reported missing classes. I am not sure if they are
sufficient to fix the test, but it is worth a try.
SDO does not work with OSGi
---
Key: TUSCANY-1293
URL: https://issues.apache.org/jira/browse/TUSCANY-1293
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
Fix For: Java-SDO-Next
Attachments: sdo-osgi-export-patch.txt, sdo-osgi.txt
When I execute:
XSDHelper.INSTANCE.define(schema, null);
I end up with a NullPointerException. I've tracked down root cause ...
The static initializer of the HelperProvider executes this code:
provider = getInstance(HelperProvider.class.getClassLoader());
which ends up calling:
HelperProvider provider = loadImplementation(cl, implName);
implName is null so
if (implName == null) {
implName = getImplementationName(cl);
}
ends up calling
implName = getImplementationName(cl);
which ends up calling:
InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
where SERVICE_RESORUCE_NAME =
META-INF/services/commonj.sdo.impl.HelperProvider
getResourceAsStream() return null because META-INF/services does not exist in
the API bundle. It exists in the IMPL bundle and since you are using the
class loader from the API bundle, it won't work.
You can set
-Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
to get around the above problem, but as soon as
return (HelperProvider) cl.loadClass(implName).newInstance();
executes, you get a CalssNotFoundException. Again, this is because you are
trying to load a class outside the bundle with the wrong class loader.
tried modifying the API manifest by hand to add
Eclipse-BuddyPolicy: dependent
and
Eclipse-BuddyPolicy: global
Either of those buddy policies will get past the class loader problem
(although I believe this is specific to eclipse and won't work for OSGi in
general), but when HelperProvider is initializing, you get the following
exception:
java.lang.ExceptionInInitializerError
at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
at java.lang.reflect.Field.get(Field.java:357)
at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
at
org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:31)
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
[jira] Commented: (TUSCANY-1987) Build break in osgi-implementation itest
[ https://issues.apache.org/jira/browse/TUSCANY-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559401#action_12559401 ] Rajini Sivaram commented on TUSCANY-1987: - Felix have provided a proper fix for this issue (http://www.mail-archive.com/[EMAIL PROTECTED]/msg03002.html). This is available from the latest Felix snapshot (1.1.0-SNAPSHOT). At the moment, we are using Felix release 1.0.1. There are some other changes required to Tuscany to move to the newer Felix version, so I will provide another patch to remove the workaround introduced by this one and switch to the latest Felix release. For this release of Tuscany, it would be better to stay with this patch. Tuscany could move to the newer version of Felix when the next version of Felix is released, rather than switch to using the current snapshots (unless the failures reappear). Build break in osgi-implementation itest Key: TUSCANY-1987 URL: https://issues.apache.org/jira/browse/TUSCANY-1987 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Environment: Daily build Reporter: Jean-Sebastien Delfino Assignee: Simon Laws Priority: Blocker Fix For: Java-SCA-1.1 Attachments: implementation-osgi-patch.txt See http://vmbuild.apache.org/continuum/buildResult.action?buildId=37962projectId=277 Error in the osgi-implementation itest, breaking the daily build. I think that this is the random break issue I've seen several times on Linux already discussed with Rajini on the tuscany-dev list a while ago. Rajini was not seeing that issue on Windows and I was seeing it randomly on Linux. I'm putting this issue in the SCA 1.1 release category as I believe it'll probably happen on 1.1 as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1987) Build break in osgi-implementation itest
[ https://issues.apache.org/jira/browse/TUSCANY-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1987: Attachment: implementation-osgi-patch.txt The attached patch introduces some synchronization in the areas where there could potentially be some problems. There seems to be some reloading of classes by Felix (it happens rarely and I haven't been able to figure out what is triggering it) causing SCA proxies to be not found by the OSGi clients. I am forcing a package refresh before creating proxies to avoid this. It seems to work, though I am not sure if it is only because I have slowed things down. I am waiting for a response from the Felix team to see if there is anything unsafe about the way SCA proxies are created for OSGi. Could you please apply the patch, and if the problem reappears, rename ConversationTestCase to stop it running? Thank you, Rajini Build break in osgi-implementation itest Key: TUSCANY-1987 URL: https://issues.apache.org/jira/browse/TUSCANY-1987 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Environment: Daily build Reporter: Jean-Sebastien Delfino Priority: Blocker Fix For: Java-SCA-1.1 Attachments: implementation-osgi-patch.txt See http://vmbuild.apache.org/continuum/buildResult.action?buildId=37962projectId=277 Error in the osgi-implementation itest, breaking the daily build. I think that this is the random break issue I've seen several times on Linux already discussed with Rajini on the tuscany-dev list a while ago. Rajini was not seeing that issue on Windows and I was seeing it randomly on Linux. I'm putting this issue in the SCA 1.1 release category as I believe it'll probably happen on 1.1 as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajini Sivaram updated TUSCANY-1293:
Attachment: sdo-osgi.txt
The attached patch sets up HelperProvider implementation when the SDO
implementation bundle is loaded (in its bundle activator). Tests for running
SDO in a multi-classloader environment and inside a Felix OSGi runtime have
also been added.
SDO does not work with OSGi
---
Key: TUSCANY-1293
URL: https://issues.apache.org/jira/browse/TUSCANY-1293
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
Fix For: Java-SDO-Next
Attachments: sdo-osgi.txt
When I execute:
XSDHelper.INSTANCE.define(schema, null);
I end up with a NullPointerException. I've tracked down root cause ...
The static initializer of the HelperProvider executes this code:
provider = getInstance(HelperProvider.class.getClassLoader());
which ends up calling:
HelperProvider provider = loadImplementation(cl, implName);
implName is null so
if (implName == null) {
implName = getImplementationName(cl);
}
ends up calling
implName = getImplementationName(cl);
which ends up calling:
InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
where SERVICE_RESORUCE_NAME =
META-INF/services/commonj.sdo.impl.HelperProvider
getResourceAsStream() return null because META-INF/services does not exist in
the API bundle. It exists in the IMPL bundle and since you are using the
class loader from the API bundle, it won't work.
You can set
-Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
to get around the above problem, but as soon as
return (HelperProvider) cl.loadClass(implName).newInstance();
executes, you get a CalssNotFoundException. Again, this is because you are
trying to load a class outside the bundle with the wrong class loader.
tried modifying the API manifest by hand to add
Eclipse-BuddyPolicy: dependent
and
Eclipse-BuddyPolicy: global
Either of those buddy policies will get past the class loader problem
(although I believe this is specific to eclipse and won't work for OSGi in
general), but when HelperProvider is initializing, you get the following
exception:
java.lang.ExceptionInInitializerError
at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
at java.lang.reflect.Field.get(Field.java:357)
at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(SDOUtil.java:196)
at
org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.init(ModelFactoryImpl.java:731)
at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41)
at
org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelperImpl.java:61)
at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java:79)
at
org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:46)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(HelperProviderImpl.java:38)
at
org.apache.tuscany.sdo.rtlib.helper.HelperProviderBase.init(HelperProviderBase.java:78)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderImpl.java:31)
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 java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at
[jira] Updated: (TUSCANY-1941) NPE and classcast exceptions when putting all SCA jars from libs and modules on classpath
[ https://issues.apache.org/jira/browse/TUSCANY-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1941: Attachment: ReallySmallRuntime-patch.txt Attached patch loads each module (as determined by the classname inside META-INF/services/org.apache.tuscany.sca.core.ModuleActivator) and runs its module activator only once, even if multiple versions of these modules are on the CLASSPATH.. NPE and classcast exceptions when putting all SCA jars from libs and modules on classpath - Key: TUSCANY-1941 URL: https://issues.apache.org/jira/browse/TUSCANY-1941 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0.1 Environment: windows, jdk1.6.0_02 Reporter: andrej koelewijn Priority: Trivial Fix For: Java-SCA-1.1 Attachments: ReallySmallRuntime-patch.txt When i put all jars from the libs and modules directories on my classpath (modules first, then libs), i get a nullpointer exception (when running standalone), or a classcast exception (when running as part of a webapp). In both stacktraces i can see that it's using axion in the axis2 binding code. Stacktrace for cli application: Dec 19, 2007 12:15:55 AM org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver invokeBusinessLogic SEVERE: java.lang.ClassCastException: java.lang.String org.osoa.sca.ServiceRuntimeException: java.lang.ClassCastException: java.lang.String at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:127) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke (RuntimeWireInvoker.java:89) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:83) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWireImpl.java :127) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:587) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic (Axis2ServiceInOutSyncMessageReceiver.java:59) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42) at org.apache.axis2.receivers.AbstractMessageReceiver.receive (AbstractMessageReceiver.java:96) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle (Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:835) at org.mortbay.jetty.HttpParser.parseNext (HttpParser.java:641) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.io.nio.SelectChannelEndPoint.run (SelectChannelEndPoint.java:368) at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:61) at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java :205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run( Thread.java:595) Caused by: java.lang.ClassCastException: java.lang.String at org.apache.tuscany.sca.databinding.axiom.OMElementWrapperHandler.getChildren(OMElementWrapperHandler.java:46) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform (Input2InputTransformer.java:176) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:73) at
[jira] Updated: (TUSCANY-1940) Dynamic Wiring for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1940: Attachment: osgi-dynamic-wiring-test.jar tuscany-modules-patch.txt Dynamic Wiring for implementation.osgi -- Key: TUSCANY-1940 URL: https://issues.apache.org/jira/browse/TUSCANY-1940 Project: Tuscany Issue Type: New Feature Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: osgi-dynamic-wiring-test.jar, tuscany-modules-patch.txt This is a placeholder for the work required to support Distributed-OSGi using SCA metadata and the Tuscany runtime. This is not expected to be committed into Tuscany until the changes are discussed and finalized on the mailing list. Graham Charters will be following this up in the new year. The attached patch supports the following scenarios (based on the BeerOrder example from RFC 119 for Distributed-OSGi): component name=BeerOrderComponent implementation.osgi/ reference name=warehouse wiredByImpl=true requires=integrity /component 1) There are two Warehouse Services in the SCA domain. Proxies to both services are installed by Tuscany in the OSGi registry. One of the services is chosen by OSGi for BeerOrderComponent/warehouse. At the moment, OSGi properties of the service are not set on the proxy, but this will be added once the component description of the service component can be obtained from the SCA domain. Property matching will be done by OSGi. 2) The warehouse service that the BeerOrderComponent is wired to is removed from the SCA domain. The proxy corresponding to that warehouse service is removed from the OSGi registry. OSGi service listener will be used by the application to rewire to the other warehouse service. 3) The second warehouse service is also removed from the SCA domain. The second proxy is removed, and the OSGi application's service listener is notified. Any attempt to use cached proxies will throw an exception. 4) A new warehouse service is added to the SCA domain. A new proxy is installed in the OSGi registry, and the application's service listener can wire to this service. 5) Another warehouse service is added to the SCA domain. Another proxy is installed in the OSGi registry, and the application is notified. But the proxy to the previously installed service can be used without any disruption. The changes to the Tuscany runtime to support these scenarios: 1) For references marked wiredByImpl inside a component using implementation.osgi, the implementation.osgi provider is notified whenever a matching service becomes available or unavailable. Proxies are registered/unregistered into the OSGi registry by implementation.osgi. Matching of interfaces/intents/policies is done by Tuscany, property matching using OSGi filters is done by OSGi. OSGi applications will be notified when matching services are available/removed. 2) If a service being used by an OSGi reference becomes unavailable, the OSGi application will be notified (as long the SCA domain knows about the change). It is upto the application to wire to a different service. implementation.osgi registers/unregisters all matching services for references in the service registry whenever the domain is updated. The rest is handled by OSGi. For OSGi procedural services, services provided by the bundle will not be affected if references are not satisfied. For OSGi declarative services, the component will be deactivated by OSGi if mandatory references are not satisfied. 3) If an additional matching service becomes available, references to other services should work without exception. And there should be no impact on services provided by the component. The bundle should not be restarted. Tuscany will add new wires to the new service, but the wires to previously installed services will not be modified. This is different from the way non-OSGi components are handled, where changes to domain cause whole components to be restarted (causing disruption as well as restarting the scope). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1897) OSGi-based Tuscany runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1897: Attachment: (was: osgi-tuscany-patch.txt) OSGi-based Tuscany runtime -- Key: TUSCANY-1897 URL: https://issues.apache.org/jira/browse/TUSCANY-1897 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram The attached patch provides support for running Tuscany runtime inside OSGi. Tuscany bundle activator sets the thread context classloader, and the classloader used for service discovery. Both are set to a bundle classloader which uses OSGi bundle API to resolve classes. The patch does not add bundle manifest entries into the Tuscany jars created by distribution. At the moment, OSGi bundles are created inside itest/osgi-tuscany. A set of tests have been added to verify these bundles. Tuscany is currently built as five bundles (API, SPI, Runtime, Extensions and 3rd party code). The dependencies across the bundles are hardcoded (these will be modified later to use maven-bundle-plugin wherever possible). The purpose of these tests are: 1. Verify classloader-based isolation across Tuscany bundles introduced recently. 2. Provide a testbed to build and test bundle-ized Tuscany. The Tuscany extensions bundle and 3rd party bundle should be split into smaller chunks. 3. Provide OSGi-based Tuscany bundles to build a reference implementation for Distributed-OSGi based on Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1897) OSGi-based Tuscany runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1897: Attachment: osgi-tuscany-patch.txt OSGi-based Tuscany runtime -- Key: TUSCANY-1897 URL: https://issues.apache.org/jira/browse/TUSCANY-1897 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: osgi-tuscany-patch.txt The attached patch provides support for running Tuscany runtime inside OSGi. Tuscany bundle activator sets the thread context classloader, and the classloader used for service discovery. Both are set to a bundle classloader which uses OSGi bundle API to resolve classes. The patch does not add bundle manifest entries into the Tuscany jars created by distribution. At the moment, OSGi bundles are created inside itest/osgi-tuscany. A set of tests have been added to verify these bundles. Tuscany is currently built as five bundles (API, SPI, Runtime, Extensions and 3rd party code). The dependencies across the bundles are hardcoded (these will be modified later to use maven-bundle-plugin wherever possible). The purpose of these tests are: 1. Verify classloader-based isolation across Tuscany bundles introduced recently. 2. Provide a testbed to build and test bundle-ized Tuscany. The Tuscany extensions bundle and 3rd party bundle should be split into smaller chunks. 3. Provide OSGi-based Tuscany bundles to build a reference implementation for Distributed-OSGi based on Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1897) OSGi-based Tuscany runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1897: Attachment: osgi-tuscany-patch.txt OSGi-based Tuscany runtime -- Key: TUSCANY-1897 URL: https://issues.apache.org/jira/browse/TUSCANY-1897 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram The attached patch provides support for running Tuscany runtime inside OSGi. Tuscany bundle activator sets the thread context classloader, and the classloader used for service discovery. Both are set to a bundle classloader which uses OSGi bundle API to resolve classes. The patch does not add bundle manifest entries into the Tuscany jars created by distribution. At the moment, OSGi bundles are created inside itest/osgi-tuscany. A set of tests have been added to verify these bundles. Tuscany is currently built as five bundles (API, SPI, Runtime, Extensions and 3rd party code). The dependencies across the bundles are hardcoded (these will be modified later to use maven-bundle-plugin wherever possible). The purpose of these tests are: 1. Verify classloader-based isolation across Tuscany bundles introduced recently. 2. Provide a testbed to build and test bundle-ized Tuscany. The Tuscany extensions bundle and 3rd party bundle should be split into smaller chunks. 3. Provide OSGi-based Tuscany bundles to build a reference implementation for Distributed-OSGi based on Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1887) Classloading: Remove unnecessary use of thread context classloader
[ https://issues.apache.org/jira/browse/TUSCANY-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1887: Attachment: new-tuscany-tccl-patch.txt New patch generated after the integration of TUSCANY-1877. Classloading: Remove unnecessary use of thread context classloader -- Key: TUSCANY-1887 URL: https://issues.apache.org/jira/browse/TUSCANY-1887 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Attachments: new-tuscany-tccl-patch.txt The attached patch removes some of the uses of TCCL in Tuscany code. ModelResolver (and hence the contribution classloader) is now used to resolve: Property file specified as component property, if the filename specified is relative Script file specified for implementation.script Xquery file specified for implementation.xquery/ There are some uses of TCCL in testing, which have been left as is. TCCL will continue to be used as the parent classloader for all classloaders created within Tuscany. implementation.spring/ and binding.ejb/ still use TCCL. I didn't want to remove the use of TCCL in this code because I wasn't sure if Spring and EJB have additional requirements on TCCL which are not obvious from the Tuscany code. I will raise another JIRA issue to handle deserializing of CallableReference, which currently uses TCCL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1887) Classloading: Remove unnecessary use of thread context classloader
[ https://issues.apache.org/jira/browse/TUSCANY-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539559 ] Rajini Sivaram commented on TUSCANY-1887: - Venkat, Thank you for integrating https://issues.apache.org/jira/browse/TUSCANY-1877. I will provide a new patch for this one. - Rajini Classloading: Remove unnecessary use of thread context classloader -- Key: TUSCANY-1887 URL: https://issues.apache.org/jira/browse/TUSCANY-1887 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Attachments: tuscany-tccl-patch.txt The attached patch removes some of the uses of TCCL in Tuscany code. ModelResolver (and hence the contribution classloader) is now used to resolve: Property file specified as component property, if the filename specified is relative Script file specified for implementation.script Xquery file specified for implementation.xquery/ There are some uses of TCCL in testing, which have been left as is. TCCL will continue to be used as the parent classloader for all classloaders created within Tuscany. implementation.spring/ and binding.ejb/ still use TCCL. I didn't want to remove the use of TCCL in this code because I wasn't sure if Spring and EJB have additional requirements on TCCL which are not obvious from the Tuscany code. I will raise another JIRA issue to handle deserializing of CallableReference, which currently uses TCCL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1887) Classloading: Remove unnecessary use of thread context classloader
Classloading: Remove unnecessary use of thread context classloader -- Key: TUSCANY-1887 URL: https://issues.apache.org/jira/browse/TUSCANY-1887 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram The attached patch removes some of the uses of TCCL in Tuscany code. ModelResolver (and hence the contribution classloader) is now used to resolve: Property file specified as component property, if the filename specified is relative Script file specified for implementation.script Xquery file specified for implementation.xquery/ There are some uses of TCCL in testing, which have been left as is. TCCL will continue to be used as the parent classloader for all classloaders created within Tuscany. implementation.spring/ and binding.ejb/ still use TCCL. I didn't want to remove the use of TCCL in this code because I wasn't sure if Spring and EJB have additional requirements on TCCL which are not obvious from the Tuscany code. I will raise another JIRA issue to handle deserializing of CallableReference, which currently uses TCCL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1887) Classloading: Remove unnecessary use of thread context classloader
[ https://issues.apache.org/jira/browse/TUSCANY-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1887: Attachment: tuscany-tccl-patch.txt This patch also contains the changes from 1877 (https://issues.apache.org/jira/browse/TUSCANY-1877), since there are dependencies. Classloading: Remove unnecessary use of thread context classloader -- Key: TUSCANY-1887 URL: https://issues.apache.org/jira/browse/TUSCANY-1887 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Attachments: tuscany-tccl-patch.txt The attached patch removes some of the uses of TCCL in Tuscany code. ModelResolver (and hence the contribution classloader) is now used to resolve: Property file specified as component property, if the filename specified is relative Script file specified for implementation.script Xquery file specified for implementation.xquery/ There are some uses of TCCL in testing, which have been left as is. TCCL will continue to be used as the parent classloader for all classloaders created within Tuscany. implementation.spring/ and binding.ejb/ still use TCCL. I didn't want to remove the use of TCCL in this code because I wasn't sure if Spring and EJB have additional requirements on TCCL which are not obvious from the Tuscany code. I will raise another JIRA issue to handle deserializing of CallableReference, which currently uses TCCL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1879) Sample webapps fails with java.lang.NoClassDefFoundError: org/apache/tuscany/sca/definitions/xml/SCADefinitionsDocumentProcessor
[ https://issues.apache.org/jira/browse/TUSCANY-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538749 ] Rajini Sivaram commented on TUSCANY-1879: - I looked at this failure to check if it had anything to do with the classloading changes I made. But I think the failure is because tuscany-definitions.jar is not included the war file by build.xml. Are the dependencies in build.xml for the sample generated or hand-coded? If they are handcoded, it looks rather error-prone since it contains hardcoded versions of third party libraries and list of tuscany modules (which could presumably be obtained from maven). Since I hadn't deployed and run any of the webapp samples after making classloading changes, I would like to understand if SCA contributions running in a webapp server would require access to classes that are not in the webapp container. Sample webapps fails with java.lang.NoClassDefFoundError: org/apache/tuscany/sca/definitions/xml/SCADefinitionsDocumentProcessor Key: TUSCANY-1879 URL: https://issues.apache.org/jira/browse/TUSCANY-1879 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.0.1 Reporter: Luciano Resende Fix For: Java-SCA-1.0.1 The following webapps are failing with NoClassDefFoundError when built from ant script sample-calculator-ws-webapp - error sample-chat-webapp - error sample-feed-aggregator-webapp - error sample-helloworld-dojo-webapp - error sample-helloworld-jsonrpc-webapp - error Oct 29, 2007 5:06:41 PM org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter tuscany java.lang.NoClassDefFoundError: org/apache/tuscany/sca/definitions/xml/SCADefinitionsDocumentProcessor at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService(ReallySmallRuntimeBuilder.java:209) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:117) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:104) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:159) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:223) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:304) at org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:77) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3634) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4217) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) 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.catalina.startup.Bootstrap.start(Bootstrap.java:294)
[jira] Created: (TUSCANY-1873) Imported contributions not used in resolving component type files
Imported contributions not used in resolving component type files -- Key: TUSCANY-1873 URL: https://issues.apache.org/jira/browse/TUSCANY-1873 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Rajini Sivaram The details of the failing scenario and Luciano's response are on the dev mailing list at: http://marc.info/?l=tuscany-devm=119332616624723w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1877) Classloading: Tuscany runtime extension classloading
Classloading: Tuscany runtime extension classloading Key: TUSCANY-1877 URL: https://issues.apache.org/jira/browse/TUSCANY-1877 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Details of the discussion on classloading in Tuscany can be found on the mailing list: http://marc.info/?l=tuscany-devm=119210552631425w=2 Details specific to this patch are here: http://marc.info/?l=tuscany-devm=119340004217949w=2 This patch introduces a service discovery class with a set of registered classloaders which enables extensions to be added to Tuscany without requiring the SPI classloader to have visibility of the extension classes. By default, Tuscany will continue to run in a single-classloader mode. A multi-classloader test has been added which runs Tuscany runtime with four classloaders forming the hierarchy: 3rd party -- SCA-API -- Tuscany SPI + runtime -- Tuscany extensions where -- denotes a parent--child relation. This patch does not address classloading requirements specific to the Node API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1877) Classloading: Tuscany runtime extension classloading
[ https://issues.apache.org/jira/browse/TUSCANY-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1877: Attachment: tuscany-extension-classloading-patch.txt Classloading: Tuscany runtime extension classloading Key: TUSCANY-1877 URL: https://issues.apache.org/jira/browse/TUSCANY-1877 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Attachments: tuscany-extension-classloading-patch.txt Details of the discussion on classloading in Tuscany can be found on the mailing list: http://marc.info/?l=tuscany-devm=119210552631425w=2 Details specific to this patch are here: http://marc.info/?l=tuscany-devm=119340004217949w=2 This patch introduces a service discovery class with a set of registered classloaders which enables extensions to be added to Tuscany without requiring the SPI classloader to have visibility of the extension classes. By default, Tuscany will continue to run in a single-classloader mode. A multi-classloader test has been added which runs Tuscany runtime with four classloaders forming the hierarchy: 3rd party -- SCA-API -- Tuscany SPI + runtime -- Tuscany extensions where -- denotes a parent--child relation. This patch does not address classloading requirements specific to the Node API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1871) Classloading : Application contribution classloaders
[ https://issues.apache.org/jira/browse/TUSCANY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1871: Attachment: application-classloading-patch.txt Classloading : Application contribution classloaders Key: TUSCANY-1871 URL: https://issues.apache.org/jira/browse/TUSCANY-1871 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Attachments: application-classloading-patch.txt Details of the discussion on classloading changes for Tuscany are on the dev mailing list on this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24774.html And on the WIKI http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java Changes in this patch introduce separate classloaders for each contribution. SCA contribution import/export spec cannot be implemented using a standard Java parent-child classloader delegation model. But SCA contribution import/export spec is a subset of OSGi package import/export (wiring of import/export is more complex in OSGi since it includes versions and other attributes). Hence an OSGi-style classloader is ideal for Tuscany to enforce SCA contribution spec. Each contribution will have an associated classloader. This will be an subclass of URLClassLoader, and will have the Java application classloader based on CLASSPATH as its parent (the parent classloader will be obtained from the thread context). The defining classloader for any application class will be the classloader corresponding to the SCA contribution containing the class. ContributionClassLoader.findClass will search the contribution for the class, and if not found, it will search other classloaders of other contributions wired using SCA import/export. Like OSGi, an overlapping class space will be defined for each contribution which consists of the classes in the contribution and imported packages from other contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1871) Classloading : Application contribution classloaders
Classloading : Application contribution classloaders Key: TUSCANY-1871 URL: https://issues.apache.org/jira/browse/TUSCANY-1871 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Details of the discussion on classloading changes for Tuscany are on the dev mailing list on this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24774.html And on the WIKI http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java Changes in this patch introduce separate classloaders for each contribution. SCA contribution import/export spec cannot be implemented using a standard Java parent-child classloader delegation model. But SCA contribution import/export spec is a subset of OSGi package import/export (wiring of import/export is more complex in OSGi since it includes versions and other attributes). Hence an OSGi-style classloader is ideal for Tuscany to enforce SCA contribution spec. Each contribution will have an associated classloader. This will be an subclass of URLClassLoader, and will have the Java application classloader based on CLASSPATH as its parent (the parent classloader will be obtained from the thread context). The defining classloader for any application class will be the classloader corresponding to the SCA contribution containing the class. ContributionClassLoader.findClass will search the contribution for the class, and if not found, it will search other classloaders of other contributions wired using SCA import/export. Like OSGi, an overlapping class space will be defined for each contribution which consists of the classes in the contribution and imported packages from other contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1871) Classloading : Application contribution classloaders
[ https://issues.apache.org/jira/browse/TUSCANY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537973 ] Rajini Sivaram commented on TUSCANY-1871: - Ant, Thank you for integrating the patch... - Rajini Classloading : Application contribution classloaders Key: TUSCANY-1871 URL: https://issues.apache.org/jira/browse/TUSCANY-1871 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Rajini Sivaram Assignee: ant elder Attachments: application-classloading-patch.txt Details of the discussion on classloading changes for Tuscany are on the dev mailing list on this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24774.html And on the WIKI http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java Changes in this patch introduce separate classloaders for each contribution. SCA contribution import/export spec cannot be implemented using a standard Java parent-child classloader delegation model. But SCA contribution import/export spec is a subset of OSGi package import/export (wiring of import/export is more complex in OSGi since it includes versions and other attributes). Hence an OSGi-style classloader is ideal for Tuscany to enforce SCA contribution spec. Each contribution will have an associated classloader. This will be an subclass of URLClassLoader, and will have the Java application classloader based on CLASSPATH as its parent (the parent classloader will be obtained from the thread context). The defining classloader for any application class will be the classloader corresponding to the SCA contribution containing the class. ContributionClassLoader.findClass will search the contribution for the class, and if not found, it will search other classloaders of other contributions wired using SCA import/export. Like OSGi, an overlapping class space will be defined for each contribution which consists of the classes in the contribution and imported packages from other contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1757) Fixes for implementation.osgi callbacks and AllowsPassByReference
[ https://issues.apache.org/jira/browse/TUSCANY-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1757: Attachment: samples-osgi-supplychain-patch.txt Fixes for implementation.osgi callbacks and AllowsPassByReference - Key: TUSCANY-1757 URL: https://issues.apache.org/jira/browse/TUSCANY-1757 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt, modules-osgi-runtime-patch.txt, samples-osgi-supplychain-patch.txt Scoping for callbacks is broken in implementation.osgi. In OSGi, instances are associated with services rather than components (which are based on the bundle). To implement SCA scoping for callbacks, the callback should be associated to one of the instances from the component. @AllowsPassByReference is not handled correctly for implementation.osgi since annotations are not read until the implementation provider is started and all the bundles are resolved. If the names of the implementation classes in the bundle are not listed in implementation.osgi/, annotations will not be read until the first service instance is obtained from OSGi. Since pass-by-value interceptor relies on obtaining the list of methods which support pass-by-reference before this stage, we need to bypass the interceptor and leave it to the OSGi invoker to decide whether pass-by-reference is allowed. The patch also modifies itest/osgi-implementation to use a subdirectory under target/classes as the contribution URL for each of its tests since there are a large number of tests under this project, and at the moment all the composites are loaded when each test is run. Conversation and callback tests have also been added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1760) User Doc for implementation.osgi
User Doc for implementation.osgi Key: TUSCANY-1760 URL: https://issues.apache.org/jira/browse/TUSCANY-1760 Project: Tuscany Issue Type: Bug Components: Website Reporter: Rajini Sivaram Priority: Trivial I have added documentation for implementation.osgi at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+implementation.osgi Please include it in the extension documentation in the Wiki. Thank you. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1757) Fixes for implementation.osgi callbacks and AllowsPassByReference
[ https://issues.apache.org/jira/browse/TUSCANY-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1757: Attachment: (was: modules-osgi-runtime-patch.txt) Fixes for implementation.osgi callbacks and AllowsPassByReference - Key: TUSCANY-1757 URL: https://issues.apache.org/jira/browse/TUSCANY-1757 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-contribution-osgi-patch.txt, modules-implementation-osgi-patch.txt, modules-osgi-runtime-patch.txt, samples-osgi-supplychain-patch.txt Scoping for callbacks is broken in implementation.osgi. In OSGi, instances are associated with services rather than components (which are based on the bundle). To implement SCA scoping for callbacks, the callback should be associated to one of the instances from the component. @AllowsPassByReference is not handled correctly for implementation.osgi since annotations are not read until the implementation provider is started and all the bundles are resolved. If the names of the implementation classes in the bundle are not listed in implementation.osgi/, annotations will not be read until the first service instance is obtained from OSGi. Since pass-by-value interceptor relies on obtaining the list of methods which support pass-by-reference before this stage, we need to bypass the interceptor and leave it to the OSGi invoker to decide whether pass-by-reference is allowed. The patch also modifies itest/osgi-implementation to use a subdirectory under target/classes as the contribution URL for each of its tests since there are a large number of tests under this project, and at the moment all the composites are loaded when each test is run. Conversation and callback tests have also been added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1757) Fixes for implementation.osgi callbacks and AllowsPassByReference
[ https://issues.apache.org/jira/browse/TUSCANY-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1757: Attachment: modules-contribution-osgi-patch.txt modules-osgi-runtime-patch.txt Fixes for implementation.osgi callbacks and AllowsPassByReference - Key: TUSCANY-1757 URL: https://issues.apache.org/jira/browse/TUSCANY-1757 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-contribution-osgi-patch.txt, modules-implementation-osgi-patch.txt, modules-osgi-runtime-patch.txt, samples-osgi-supplychain-patch.txt Scoping for callbacks is broken in implementation.osgi. In OSGi, instances are associated with services rather than components (which are based on the bundle). To implement SCA scoping for callbacks, the callback should be associated to one of the instances from the component. @AllowsPassByReference is not handled correctly for implementation.osgi since annotations are not read until the implementation provider is started and all the bundles are resolved. If the names of the implementation classes in the bundle are not listed in implementation.osgi/, annotations will not be read until the first service instance is obtained from OSGi. Since pass-by-value interceptor relies on obtaining the list of methods which support pass-by-reference before this stage, we need to bypass the interceptor and leave it to the OSGi invoker to decide whether pass-by-reference is allowed. The patch also modifies itest/osgi-implementation to use a subdirectory under target/classes as the contribution URL for each of its tests since there are a large number of tests under this project, and at the moment all the composites are loaded when each test is run. Conversation and callback tests have also been added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1757) Fixes for implementation.osgi callbacks and AllowsPassByReference
[ https://issues.apache.org/jira/browse/TUSCANY-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1757: Attachment: (was: samples-osgi-supplychain-patch.txt) Fixes for implementation.osgi callbacks and AllowsPassByReference - Key: TUSCANY-1757 URL: https://issues.apache.org/jira/browse/TUSCANY-1757 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-contribution-osgi-patch.txt, modules-implementation-osgi-patch.txt, modules-osgi-runtime-patch.txt Scoping for callbacks is broken in implementation.osgi. In OSGi, instances are associated with services rather than components (which are based on the bundle). To implement SCA scoping for callbacks, the callback should be associated to one of the instances from the component. @AllowsPassByReference is not handled correctly for implementation.osgi since annotations are not read until the implementation provider is started and all the bundles are resolved. If the names of the implementation classes in the bundle are not listed in implementation.osgi/, annotations will not be read until the first service instance is obtained from OSGi. Since pass-by-value interceptor relies on obtaining the list of methods which support pass-by-reference before this stage, we need to bypass the interceptor and leave it to the OSGi invoker to decide whether pass-by-reference is allowed. The patch also modifies itest/osgi-implementation to use a subdirectory under target/classes as the contribution URL for each of its tests since there are a large number of tests under this project, and at the moment all the composites are loaded when each test is run. Conversation and callback tests have also been added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1757) Fixes for implementation.osgi callbacks and AllowsPassByReference
[ https://issues.apache.org/jira/browse/TUSCANY-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1757: Attachment: samples-osgi-supplychain-patch.txt Samples patch fixes the ant build script for samples/osgi-supplychain Fixes for implementation.osgi callbacks and AllowsPassByReference - Key: TUSCANY-1757 URL: https://issues.apache.org/jira/browse/TUSCANY-1757 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-contribution-osgi-patch.txt, modules-implementation-osgi-patch.txt, modules-osgi-runtime-patch.txt, samples-osgi-supplychain-patch.txt Scoping for callbacks is broken in implementation.osgi. In OSGi, instances are associated with services rather than components (which are based on the bundle). To implement SCA scoping for callbacks, the callback should be associated to one of the instances from the component. @AllowsPassByReference is not handled correctly for implementation.osgi since annotations are not read until the implementation provider is started and all the bundles are resolved. If the names of the implementation classes in the bundle are not listed in implementation.osgi/, annotations will not be read until the first service instance is obtained from OSGi. Since pass-by-value interceptor relies on obtaining the list of methods which support pass-by-reference before this stage, we need to bypass the interceptor and leave it to the OSGi invoker to decide whether pass-by-reference is allowed. The patch also modifies itest/osgi-implementation to use a subdirectory under target/classes as the contribution URL for each of its tests since there are a large number of tests under this project, and at the moment all the composites are loaded when each test is run. Conversation and callback tests have also been added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1701) Support for OSGi Contribution bundles
Support for OSGi Contribution bundles - Key: TUSCANY-1701 URL: https://issues.apache.org/jira/browse/TUSCANY-1701 Project: Tuscany Issue Type: New Feature Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Support for OSGi bundles as contributions - SCA contributions can be packaged as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). implementation.osgi/ can use SCA bundle contributions as their implementation artifact, and can also refer to nested bundles inside contributions. implementation.osgi/ will now use the symbolic name and version of the bundle instead of its location URL, and the bundle will be located by Tuscany from the contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1701) Support for OSGi Contribution bundles
[ https://issues.apache.org/jira/browse/TUSCANY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1701: Attachment: contribution-osgi.zip modules-contribution-java-patch.txt The attachment modules-contribution-java-patch.txt contain a patch for ClassReferenceModelResolver to invoke OSGi resolver before resolving classes using the classloader. Since the changes to OSGi-specific code is very extensive, I have created a zip rather than a patch containing all the OSGi-specific modules. Support for OSGi Contribution bundles - Key: TUSCANY-1701 URL: https://issues.apache.org/jira/browse/TUSCANY-1701 Project: Tuscany Issue Type: New Feature Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: contribution-osgi.zip, modules-contribution-java-patch.txt Support for OSGi bundles as contributions - SCA contributions can be packaged as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). implementation.osgi/ can use SCA bundle contributions as their implementation artifact, and can also refer to nested bundles inside contributions. implementation.osgi/ will now use the symbolic name and version of the bundle instead of its location URL, and the bundle will be located by Tuscany from the contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1701) Support for OSGi Contribution bundles
[ https://issues.apache.org/jira/browse/TUSCANY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1701: Attachment: itest-osgi-implementation-patch.txt modules-osgi-implementation-patch.txt contribution-osgi.zip Support for OSGi Contribution bundles - Key: TUSCANY-1701 URL: https://issues.apache.org/jira/browse/TUSCANY-1701 Project: Tuscany Issue Type: New Feature Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: contribution-osgi.zip, itest-osgi-implementation-patch.txt, modules-contribution-java-patch.txt, modules-osgi-implementation-patch.txt Support for OSGi bundles as contributions - SCA contributions can be packaged as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). implementation.osgi/ can use SCA bundle contributions as their implementation artifact, and can also refer to nested bundles inside contributions. implementation.osgi/ will now use the symbolic name and version of the bundle instead of its location URL, and the bundle will be located by Tuscany from the contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1701) Support for OSGi Contribution bundles
[ https://issues.apache.org/jira/browse/TUSCANY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1701: Attachment: (was: contribution-osgi.zip) Support for OSGi Contribution bundles - Key: TUSCANY-1701 URL: https://issues.apache.org/jira/browse/TUSCANY-1701 Project: Tuscany Issue Type: New Feature Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: contribution-osgi.zip, itest-osgi-implementation-patch.txt, modules-contribution-java-patch.txt, modules-osgi-implementation-patch.txt Support for OSGi bundles as contributions - SCA contributions can be packaged as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). implementation.osgi/ can use SCA bundle contributions as their implementation artifact, and can also refer to nested bundles inside contributions. implementation.osgi/ will now use the symbolic name and version of the bundle instead of its location URL, and the bundle will be located by Tuscany from the contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1701) Support for OSGi Contribution bundles
[ https://issues.apache.org/jira/browse/TUSCANY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1701: Attachment: samples-osgi-supplychain-patch.txt Support for OSGi Contribution bundles - Key: TUSCANY-1701 URL: https://issues.apache.org/jira/browse/TUSCANY-1701 Project: Tuscany Issue Type: New Feature Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: contribution-osgi.zip, itest-osgi-implementation-patch.txt, modules-contribution-java-patch.txt, modules-osgi-implementation-patch.txt, samples-osgi-supplychain-patch.txt Support for OSGi bundles as contributions - SCA contributions can be packaged as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). implementation.osgi/ can use SCA bundle contributions as their implementation artifact, and can also refer to nested bundles inside contributions. implementation.osgi/ will now use the symbolic name and version of the bundle instead of its location URL, and the bundle will be located by Tuscany from the contributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1672) Annotation support for implementation.osgi
Annotation support for implementation.osgi -- Key: TUSCANY-1672 URL: https://issues.apache.org/jira/browse/TUSCANY-1672 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Support SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. Remove the non-standard attributes for implementation.osgi/ which currently support scope, allowsPassByReference etc. and replace tests which using these with annotations. Add a new attribute for implementation.osgi/ to list the classes in the bundle which should be introspected. Along with annotations, property injection support is also added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1672) Annotation support for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1672: Attachment: itest-osgi-implementation-patch.txt samples-osgi-supplychain-patch.txt modules-implementation-osgi-patch.txt Attached are patches for modules/implementation.osgi, samples/osgi-supplychain and itest/osgi-implementation. Annotation support for implementation.osgi -- Key: TUSCANY-1672 URL: https://issues.apache.org/jira/browse/TUSCANY-1672 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt, samples-osgi-supplychain-patch.txt Support SCA annotations in implementation classes used inside OSGi bundles to make implementation.osgi consistent with implementation.java. Remove the non-standard attributes for implementation.osgi/ which currently support scope, allowsPassByReference etc. and replace tests which using these with annotations. Add a new attribute for implementation.osgi/ to list the classes in the bundle which should be introspected. Along with annotations, property injection support is also added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1569) Minor fixes for implementation.osgi
Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1569) Minor fixes for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1569: Attachment: modules-implementation-osgi-patch.txt itest-osgi-implementation-patch.txt Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1424) More Apache Felix API changes
[ https://issues.apache.org/jira/browse/TUSCANY-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1424: Attachment: FelixRuntime-patch.txt More Apache Felix API changes - Key: TUSCANY-1424 URL: https://issues.apache.org/jira/browse/TUSCANY-1424 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: FelixRuntime-patch.txt There is one more API change in Apache Felix described in https://issues.apache.org/jira/browse/FELIX-324 implementation.osgi/ should support the new API for starting Felix in embedded mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1424) More Apache Felix API changes
More Apache Felix API changes - Key: TUSCANY-1424 URL: https://issues.apache.org/jira/browse/TUSCANY-1424 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Attachments: FelixRuntime-patch.txt There is one more API change in Apache Felix described in https://issues.apache.org/jira/browse/FELIX-324 implementation.osgi/ should support the new API for starting Felix in embedded mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1424) More Apache Felix API changes
[ https://issues.apache.org/jira/browse/TUSCANY-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512128 ] Rajini Sivaram commented on TUSCANY-1424: - Thank you, Raymond. More Apache Felix API changes - Key: TUSCANY-1424 URL: https://issues.apache.org/jira/browse/TUSCANY-1424 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: Raymond Feng Attachments: FelixRuntime-patch.txt There is one more API change in Apache Felix described in https://issues.apache.org/jira/browse/FELIX-324 implementation.osgi/ should support the new API for starting Felix in embedded mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1414) Support for new Felix API and callback support for OSGi implementation type.
Support for new Felix API and callback support for OSGi implementation type. Key: TUSCANY-1414 URL: https://issues.apache.org/jira/browse/TUSCANY-1414 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Apache Felix is introducing a new API for embedding the OSGi runtime. The changes enable SCA to use both old and new APIs for starting up Felix. Also added support for callback interfaces to be used with OSGi implementation type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1414) Support for new Felix API and callback support for OSGi implementation type.
[ https://issues.apache.org/jira/browse/TUSCANY-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1414: Attachment: tuscany-implementation-osgi-patch.txt Support for new Felix API and callback support for OSGi implementation type. Key: TUSCANY-1414 URL: https://issues.apache.org/jira/browse/TUSCANY-1414 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: tuscany-implementation-osgi-patch.txt Apache Felix is introducing a new API for embedding the OSGi runtime. The changes enable SCA to use both old and new APIs for starting up Felix. Also added support for callback interfaces to be used with OSGi implementation type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1414) Support for new Felix API and callback support for OSGi implementation type.
[ https://issues.apache.org/jira/browse/TUSCANY-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1414: Attachment: FelixRuntime.java Could you please replace modules\implementation-osgi\src\main\java\org\apache\tuscany\sca\implementation\osgi\runtime\FelixRuntime.java with this attachment? Thank you. Support for new Felix API and callback support for OSGi implementation type. Key: TUSCANY-1414 URL: https://issues.apache.org/jira/browse/TUSCANY-1414 Project: Tuscany Issue Type: Improvement Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: FelixRuntime.java, tuscany-implementation-osgi-patch.txt Apache Felix is introducing a new API for embedding the OSGi runtime. The changes enable SCA to use both old and new APIs for starting up Felix. Also added support for callback interfaces to be used with OSGi implementation type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
