[jira] Updated: (TUSCANY-1002) When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded
[ https://issues.apache.org/jira/browse/TUSCANY-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-1002: --- Comment: was deleted When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded -- Key: TUSCANY-1002 URL: https://issues.apache.org/jira/browse/TUSCANY-1002 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Frank Budinsky Priority: Minor Fix For: Java-SDO-Mx Currently there is a temporary hack in datagraph.xsd (in sdo-api project) to allow us to regenerate sdoModel.xsd with the proper ChangeSummaryType behavior. We need to: 1. Remove the temporary hack in datagraph.xsd which is redefining ChangeSummaryType to be a simple type - i.e., put it back to the way it was defined in the spec. 2. Add code in XSDHelperImpl ctor to preload the special ChangeSummaryType (which is defined in impl/src/main/resources/xml/sdoModelChangeSummary.xsd) when redefineBuiltIn.equals(ModelFactoryImpl,NAMESPACE_URI). With these changes, we will be working as the spec says: The definition of ChangeSummaryType is a complex type in XML (datagraph.xsd), but is treated as a simple data type at the model level. -- 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-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-826: -- Comment: was deleted Containment cycle should result in Exception Key: TUSCANY-826 URL: https://issues.apache.org/jira/browse/TUSCANY-826 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Windows XP, both Sun and IBM JVMs Reporter: Brian Murray Fix For: Java-SDO-Mx Attachments: ContainmentCycle.patch, ContainmentCycleError.java, ContainmentTest.zip Near the bottom of page 19 in the 2.0.1 specification it is stated that Containment cannot have cycles. If a set or add would create a containment cycle an exception is thrown. However, I have found that no such exception is thrown. I will attach a test case showing the creation of (and the potential to infinitely loop through) a containment cycle. -- 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-1114) Unable to download resource from repository on build
[ https://issues.apache.org/jira/browse/TUSCANY-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473217 ] Jeremy Boynes commented on TUSCANY-1114: This POM is also included in the samples distribution so mvn -N from the root of that distribution will install it locally for you. Unable to download resource from repository on build Key: TUSCANY-1114 URL: https://issues.apache.org/jira/browse/TUSCANY-1114 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Environment: WinXP Reporter: Justin Stewart Just downloaded and installed SCA Java M2 release - binary and samples. When building the calculator sample using Maven, I get: $ mvn [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). ... Sure enough, http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent /1.0-incubator-M2/parent-1.0-incubator-M2.pom doesn't exist. Thanks, Justin -- 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] Reopened: (TUSCANY-1039) axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError
[ https://issues.apache.org/jira/browse/TUSCANY-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes reopened TUSCANY-1039: Assignee: Rick Rineholt Reopening as we need to remove the workaround from the assembly before we release the runtime axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError -- Key: TUSCANY-1039 URL: https://issues.apache.org/jira/browse/TUSCANY-1039 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Rick Rineholt Assigned To: Rick Rineholt axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError This was fixed a few days ago ... seems to be back again. -- 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-1039) axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError
[ https://issues.apache.org/jira/browse/TUSCANY-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-1039: --- Priority: Blocker (was: Major) axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError -- Key: TUSCANY-1039 URL: https://issues.apache.org/jira/browse/TUSCANY-1039 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Rick Rineholt Assigned To: Rick Rineholt Priority: Blocker axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError This was fixed a few days ago ... seems to be back again. -- 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-1069) Cannot access default service of a component implemented by a composite using locateService
Cannot access default service of a component implemented by a composite using locateService --- Key: TUSCANY-1069 URL: https://issues.apache.org/jira/browse/TUSCANY-1069 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes If the port part of the name supplied to locateService(Class, String) is empty then the class name of the supplied service is used. There is no guarantee that the composite has a single exposed service with that name. If the port name is null then we need to check that the component just has one exposed service and use that regardless of it's name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory
[ https://issues.apache.org/jira/browse/TUSCANY-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes resolved TUSCANY-1066. Resolution: Won't Fix This should work with just the runtime/standalone assembly. We should remove the old distribution. Failing to run samples with Standalone distributions : Unable to locate profile directory - Key: TUSCANY-1066 URL: https://issues.apache.org/jira/browse/TUSCANY-1066 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Luciano Resende Fix For: Java-SCA-M3 Build a distribution and try to run standalone sample calculator Exception in thread main java.io.FileNotFoundException: Unable to locate profile directory: d:\temp\sca_standalone_distribution\profiles\launcher at org.apache.tuscany.runtime.standalone.DirectoryHelper.getProfileDirectory(DirectoryHelper.java:124) at org.apache.tuscany.launcher.Main.createRuntimeInfo(Main.java:89) at org.apache.tuscany.launcher.Main.main(Main.java:56) Workaround : build : java/sca/runtime/standalone/assembly then overlap the generated zip in the standalone distribution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1028) Autowire should support all compatible services interfaces in class hierarchy
[ https://issues.apache.org/jira/browse/TUSCANY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes resolved TUSCANY-1028. Resolution: Fixed This is fixed although the solution is not very elegant. Autowire should support all compatible services interfaces in class hierarchy - Key: TUSCANY-1028 URL: https://issues.apache.org/jira/browse/TUSCANY-1028 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-SCA-M3 When a component registers as an autowire target other components should be able to autowire to is using any super-interface rather than just the interface it registers with. For example, if X1 extends X and a component offers service X1 then it should be a valid target for clients with X references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1028) Autowire should support all compatible services interfaces in class hierarchy
Autowire should support all compatible services interfaces in class hierarchy - Key: TUSCANY-1028 URL: https://issues.apache.org/jira/browse/TUSCANY-1028 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Assigned To: Jeremy Boynes When a component registers as an autowire target other components should be able to autowire to is using any super-interface rather than just the interface it registers with. For example, if X1 extends X and a component offers service X1 then it should be a valid target for clients with X references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1000) Components do not support multiple services
[
http://issues.apache.org/jira/browse/TUSCANY-1000?page=comments#action_12459432
]
Jeremy Boynes commented on TUSCANY-1000:
This should happen if you do not specify componentName/serviceName in the call
to locateService.
Please could you attach the code where you make that call (showing the name
passed in).
Components do not support multiple services
---
Key: TUSCANY-1000
URL: http://issues.apache.org/jira/browse/TUSCANY-1000
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-M2
Reporter: Lou Amodeo
I have a component that implements multiple service interfaces at runtime the
locateService() receives an exception indicating that components can only
have 1 service. The CI spec states that a component can declare using
@Service an array of interfaces.
@Service(interfaces={ConversationsClient.class,ConversationsClient2.class})
public class ConversationsClientImpl implements ConversationsClient,
ConversationsClient2, ConversationsCallback {
---
Test set: org.apache.tuscany.sca.test.ConversationsITest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec
FAILURE!
testCallBackSetCallback(org.apache.tuscany.sca.test.ConversationsITest) Time
elapsed: 0 sec ERROR!
org.apache.tuscany.spi.component.TargetException: Component must have exactly
one service
at
org.apache.tuscany.core.implementation.java.JavaAtomicComponent.getServiceInstance(JavaAtomicComponent.java:72)
at
org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:268)
at
org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65)
at
org.apache.tuscany.sca.test.ConversationsITest.setUp(ConversationsITest.java:17)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at
org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.run(TuscanyITestMojo.java:122)
at
org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.runSurefire(TuscanyITestMojo.java:88)
at
org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.execute(TuscanyITestMojo.java:77)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
[jira] Commented: (TUSCANY-949) Incorrect set of extensions published to the maven repo
[ http://issues.apache.org/jira/browse/TUSCANY-949?page=comments#action_12454069 ] Jeremy Boynes commented on TUSCANY-949: --- I don't think we should use profiles in this way. We already use profiles (e.g. in SDO) to determine the type of content that gets built (e.g. in SDO we use them to generate aggregated vs. non-aggregated javadoc, in SCA we have a sourcecheck profile that enables checkstyle and pmd) but this is using them to determine which modules get built. I don't think this allows us to do something like run sourcecheck on the release modules for example. This is really just trying to get modularity without doing the modularity work. It would be better to do that by restructuring the build into an appropriately modular tree. Incorrect set of extensions published to the maven repo --- Key: TUSCANY-949 URL: http://issues.apache.org/jira/browse/TUSCANY-949 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-M2 Environment: all Reporter: Simon Nash Attachments: jira949.diff mvn deploy publishes a number of extensions to the maven repo that should not be published there because they are not fully tested and endorsed parts of the Tuscany M2 release. Specifically, the following jars should not be published: groovy-1.0-incubator-M2.jar databinding-castor-1.0-incubator-M2.jar databinding-jaxb-1.0-incubator-M2.jar databinding-xmlbeans-1.0-incubator-M2.jar databinding-test-1.0-incubator-M2.jar celtix-1.0-incubator-M2.jar binding-jsonrpc-1.0-incubator-M2.jar An option should be provided on the build to selectively publish only those extensions that have been endorsed as part of the Tuscany M2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-862) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-862?page=all ] Jeremy Boynes updated TUSCANY-862: -- Fix Version/s: Java-Mx (was: Java-M2) Big enough change that it's probably too much for M2 NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl - Key: TUSCANY-862 URL: http://issues.apache.org/jira/browse/TUSCANY-862 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: Jeremy Boynes Fix For: Java-Mx If you do CurrentCompositeContext.locateService on a reference which uses interface.wsdl you get a NPE: java.lang.NullPointerException at org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) at org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) at org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:275) at org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) at helloworld.HelloWorldWSClient.setUp(HelloWorldWSClient.java:46) Thats becuase the wire.getServiceContract().getInterfaceClass() returns null. To demonstrate change the helloworldwsclient to use the reference 'HelloWorldService' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-862) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-862?page=all ] Jeremy Boynes reassigned TUSCANY-862: - Assignee: Jeremy Boynes NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl - Key: TUSCANY-862 URL: http://issues.apache.org/jira/browse/TUSCANY-862 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: Jeremy Boynes Fix For: Java-Mx If you do CurrentCompositeContext.locateService on a reference which uses interface.wsdl you get a NPE: java.lang.NullPointerException at org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) at org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) at org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:275) at org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) at helloworld.HelloWorldWSClient.setUp(HelloWorldWSClient.java:46) Thats becuase the wire.getServiceContract().getInterfaceClass() returns null. To demonstrate change the helloworldwsclient to use the reference 'HelloWorldService' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-733) Version information should not be in war plugin source code
[ http://issues.apache.org/jira/browse/TUSCANY-733?page=all ] Jeremy Boynes reassigned TUSCANY-733: - Assignee: Jeremy Boynes (was: Meeraj Kunnumpurath) Version information should not be in war plugin source code --- Key: TUSCANY-733 URL: http://issues.apache.org/jira/browse/TUSCANY-733 Project: Tuscany Issue Type: Bug Components: Maven Plugins Affects Versions: Java-M2 Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-M2 Attachments: tuscany-773.patch The version of the runtime to use should be a configuration property of the war plugin and not hard coded in Dependency. Ideally, the default value for runtime version should come from a POM property, perhaps the version of the POM plugin itself. A user of the plugin should be able to override this in their own project with a configuration property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-733) Version information should not be in war plugin source code
[ http://issues.apache.org/jira/browse/TUSCANY-733?page=comments#action_12443530 ] Jeremy Boynes commented on TUSCANY-733: --- Patch applied to trunk - thanks JoJo Version information should not be in war plugin source code --- Key: TUSCANY-733 URL: http://issues.apache.org/jira/browse/TUSCANY-733 Project: Tuscany Issue Type: Bug Components: Maven Plugins Affects Versions: Java-M2 Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-M2 Attachments: tuscany-773.patch The version of the runtime to use should be a configuration property of the war plugin and not hard coded in Dependency. Ideally, the default value for runtime version should come from a POM property, perhaps the version of the POM plugin itself. A user of the plugin should be able to override this in their own project with a configuration property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-867) DAS M2 Branch updates
[ http://issues.apache.org/jira/browse/TUSCANY-867?page=comments#action_12443136 ] Jeremy Boynes commented on TUSCANY-867: --- I applied this patch (sans bat script and still have SNAPSHOT references in the project tree: $ grep -ri --exclude=*.svn-base snapshot . ./BUILDING.txt: 1.If the mvn command completed successfully, you will see BUILD SUCCESSFUL in the output and tuscany-das-rdb-1.0-SNAPSHOT.jar is created under local tuscany dir/java/das/rdb/target directory. ./BUILDING.txt:* sdo-api-r2.0.1-1.0-SNAPSHOT.jar - SDO 2.0 Interfaces ./BUILDING.txt:* tuscany-sdo-impl-1.0-SNAPSHOT.jar - SDO 2.0 implementation ./BUILDING.txt:* emf-common-2.2.0-SNAPSHOT.jar - some common framework utility and base classes ./BUILDING.txt:* emf-ecore-2.2.0-SNAPSHOT.jar - the EMF core runtime implementation classes (the Ecore metamodel) ./BUILDING.txt:* emf-ecore-change-2.2.0-SNAPSHOT.jar - the EMF change recorder and framework ./BUILDING.txt:* emf-ecore-xmi-2.2.0-SNAPSHOT.jar - EMF's default XML (and XMI) serializer and loader ./BUILDING.txt:* xsd-2.2.0-SNAPSHOT.jar - the XML Schema model ./distribution/binary/pom.xml:version2.2-SNAPSHOT/version ./distribution/samples/pom.xml:version2.2-SNAPSHOT/version ./pom.xml:idapache.snapshots/id ./pom.xml:nameApache Snapshot Repository/name ./pom.xml: urlhttp://people.apache.org/repo/m2-snapshot-repository/url ./pom.xml:snapshots ./pom.xml:/snapshots ./pom.xml:snapshots ./pom.xml:/snapshots ./samples/companyweb/readme.htm: class=SpellEcompanyweb-xxx.war (e.g. sample-companyweb-1.0-incubator-M2-SNAPSHOT.war)/span/li DAS M2 Branch updates - Key: TUSCANY-867 URL: http://issues.apache.org/jira/browse/TUSCANY-867 Project: Tuscany Issue Type: Improvement Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Blocker Fix For: Java-M2 Attachments: tuscany867-take1.lresende.20061017.txt, tuscany867-take2.lresende.20061017.txt Need to add/update some files before cuting das tag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441857 ] Jeremy Boynes commented on TUSCANY-833: --- Jim's proposal to the mailing list sounds like a better long-term solution but I am concerned that doing it this close to the release of M2 will be destabilizing. Propogating the approach used by the script containers does not provide the full function that we need from sidefiles - for example, it does not support scope and lifecycle method configuration that is available via annotation. I think we should tackle this problem as follows: 1. Create the branch using the code as it is today and document that sidefiles are not supported for Java components. This is the status quo. 2. Fix this in head the right way (whatever that is), assess the impact of that patch and consider applying it to the M2 branch before release. 3. Create a patch for the M2 branch that provides sidefile support with minimal destablization (however that can be done). The patches from 2 and 3 provide concrete implementations that we can evaluate for incorporation into M2, balancing the benefit of fixing the bug vs. the potential destabilization. ComponentType sidefiles do not work for Pojo Implementation --- Key: TUSCANY-833 URL: http://issues.apache.org/jira/browse/TUSCANY-833 Project: Tuscany Issue Type: Bug Components: Java SCA POJO Container Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Jim Marino Priority: Critical If you have a component type sidefile for a Pojo implementation we end up with an exception. The reason for this is that the JavaComponentTypeLoader passes the PojoComponenType.class to the loader registry to be returned as a result. However what gets created is an instance of the base ComponentType and then there is an attempt to narrrow this to a PojoComponentType which results in an exception. A quick alternative in the interest of M2 fast approaching would be to take the approach that the containers have to get over this problem which is for the containers to get the base ComponentType and copy it over to the special ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-797) standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ] Jeremy Boynes closed TUSCANY-797. - Assignee: (was: Jeremy Boynes) Thanks Simon standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files --- Key: TUSCANY-797 URL: http://issues.apache.org/jira/browse/TUSCANY-797 Project: Tuscany Issue Type: Bug Components: Build System, Java SCA Core Affects Versions: Java-M2 Environment: Windows XP SP2, Sun JDK 1.5.0_06-b5 Reporter: Simon Nash Fix For: Java-M2 standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing the following jar files from its bin directory: tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar tuscany-api-1.0-incubator-M2-SNAPSHOT.jar These jars are present in the bin directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. Without these jars, attempting to run the calculator sample produces the error Exception in thread main java.lang.NoClassDefFoundError: org/apache/tuscany/host/RuntimeInfo With these jars, the calculator sample runs OK I checked the contents of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip and standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz for other differences and I found that the same 2 jars tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar tuscany-api-1.0-incubator-M2-SNAPSHOT.jar are present in the boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz but not in the boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. Having these jars missing from the boot directory does not impact successful execution of the calculator sample. It appears that the following actions are needed: 1. Add these 2 jars to the bin directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip 2. Determine whether or not these jars are also needed in the boot directory. If so, add them to the boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. If not, remove them from the boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-806) Licensing issues around DTDs used by checkstyle
Licensing issues around DTDs used by checkstyle --- Key: TUSCANY-806 URL: http://issues.apache.org/jira/browse/TUSCANY-806 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Priority: Blocker The buildtools module contains two DTDs that are used by the checkstyle plugin. They have no license info in them just a reference to the online source at http://www.puppycrawl.com which appears to be (c) Oliver Burn All Rights Reserved As such we may not be able to redistribute them. We need to clarify any redistribution rights and include those in the NOTICE for that module or remove them from any distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-806) Licensing issues around DTDs used by checkstyle
[ http://issues.apache.org/jira/browse/TUSCANY-806?page=all ] Jeremy Boynes reassigned TUSCANY-806: - Assignee: Jim Marino Assigning to jmarino as the original contributor to the project. Licensing issues around DTDs used by checkstyle --- Key: TUSCANY-806 URL: http://issues.apache.org/jira/browse/TUSCANY-806 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Assigned To: Jim Marino Priority: Blocker The buildtools module contains two DTDs that are used by the checkstyle plugin. They have no license info in them just a reference to the online source at http://www.puppycrawl.com which appears to be (c) Oliver Burn All Rights Reserved As such we may not be able to redistribute them. We need to clarify any redistribution rights and include those in the NOTICE for that module or remove them from any distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-797) standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ]
Jeremy Boynes resolved TUSCANY-797.
---
Fix Version/s: Java-M2
Resolution: Fixed
Assignee: Jeremy Boynes
I added a lib directory for jars that get pulled in on the manifest classpath
for the command (using ../lib/${dep} ) and updated the standalone assembly so
that all of them get added to the zip/tgz archive
They are not needed in the boot directory as the classloader used for those
jars is a child of the system classloader containing the ones from lib (via
manifest Class-Path inclusion in the command jar).
Hopefully this resolves this issue - I tested running the calculator sample
from the command line and it worked for me
standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
---
Key: TUSCANY-797
URL: http://issues.apache.org/jira/browse/TUSCANY-797
Project: Tuscany
Issue Type: Bug
Components: Build System, Java SCA Core
Affects Versions: Java-M2
Environment: Windows XP SP2, Sun JDK 1.5.0_06-b5
Reporter: Simon Nash
Assigned To: Jeremy Boynes
Fix For: Java-M2
standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing the following jar
files from its bin directory:
tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar
tuscany-api-1.0-incubator-M2-SNAPSHOT.jar
These jars are present in the bin directory of
standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz.
Without these jars, attempting to run the calculator sample produces the error
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/tuscany/host/RuntimeInfo
With these jars, the calculator sample runs OK
I checked the contents of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip and
standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz for other differences and I
found that the same 2 jars
tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar
tuscany-api-1.0-incubator-M2-SNAPSHOT.jar
are present in the boot directory of
standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz but not in the boot directory
of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip.
Having these jars missing from the boot directory does not impact successful
execution of the calculator sample.
It appears that the following actions are needed:
1. Add these 2 jars to the bin directory of
standalone-1.0-incubator-M2-SNAPSHOT-bin.zip
2. Determine whether or not these jars are also needed in the boot
directory. If so, add them to the boot directory of
standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. If not, remove them from the
boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-736) Upgrade to XmlSchema 1.1
Upgrade to XmlSchema 1.1 Key: TUSCANY-736 URL: http://issues.apache.org/jira/browse/TUSCANY-736 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes XmlSchema 1.1 has been released so we should migrate off SNAPSHOTs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-738) tuscany war plugin and default runtime location of extensions seem to be out of sync
[ http://issues.apache.org/jira/browse/TUSCANY-738?page=all ] Jeremy Boynes reassigned TUSCANY-738: - Assignee: Jeremy Boynes tuscany war plugin and default runtime location of extensions seem to be out of sync Key: TUSCANY-738 URL: http://issues.apache.org/jira/browse/TUSCANY-738 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration, Maven Plugins Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jeremy Boynes Priority: Critical Fix For: Java-M2 By default the tuscany war plugin is put extensions in WEB-INF/tuscany/extensions while by default the runtime is searching for it here: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-733) Version information should not be in war plugin source code
Version information should not be in war plugin source code --- Key: TUSCANY-733 URL: http://issues.apache.org/jira/browse/TUSCANY-733 Project: Tuscany Issue Type: Bug Components: Maven Plugins Affects Versions: Java-M2 Reporter: Jeremy Boynes The version of the runtime to use should be a configuration property of the war plugin and not hard coded in Dependency. Ideally, the default value for runtime version should come from a POM property, perhaps the version of the POM plugin itself. A user of the plugin should be able to override this in their own project with a configuration property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-731) Update jsonRPC pom files to fix compilation errors
[ http://issues.apache.org/jira/browse/TUSCANY-731?page=all ] Jeremy Boynes closed TUSCANY-731. - Resolution: Cannot Reproduce Looks like this has already been fixed Update jsonRPC pom files to fix compilation errors -- Key: TUSCANY-731 URL: http://issues.apache.org/jira/browse/TUSCANY-731 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Reporter: Luciano Resende Fix For: Java-M2 Attachments: tuscany731.lresende.20060918.txt jsonRPC not building due to wrong references in pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-723) Repository entry missing in SCA tools
[ http://issues.apache.org/jira/browse/TUSCANY-723?page=all ] Jeremy Boynes closed TUSCANY-723. - Resolution: Fixed Patch applied - thanks Repository entry missing in SCA tools - Key: TUSCANY-723 URL: http://issues.apache.org/jira/browse/TUSCANY-723 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Environment: WinXP Reporter: Lee Surprenant Priority: Blocker Attachments: SCAToolsPomUpdate.patch SCA tools build fails due to missing repository for org.eclipse.emf Missing: -- 1) org.eclipse.emf:codegen-ecore:jar:2.2.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen-e ore \ -Dversion=2.2.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany:sca-tools:jar:1.0-incubator-M2-SNAPSHOT 2) org.eclipse.emf:codegen-ecore:jar:2.2.0 2) org.eclipse.emf:codegen:jar:2.2.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen \ -Dversion=2.2.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany:sca-tools:jar:1.0-incubator-M2-SNAPSHOT 2) org.eclipse.emf:codegen:jar:2.2.0 -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-642) Composite references and services - model and runtime representations
[ http://issues.apache.org/jira/browse/TUSCANY-642?page=comments#action_12434472 ] Jeremy Boynes commented on TUSCANY-642: --- CommentsOut patch applied - thanks Composite references and services - model and runtime representations - Key: TUSCANY-642 URL: http://issues.apache.org/jira/browse/TUSCANY-642 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Assigned To: Jim Marino Fix For: Java-Mx Attachments: CommentsOut.patch, CompositeRefsAndSvcs.txt, CompositeRefsAndSvcs2.txt, InnerComposite.patch, InnerCompositeCallback.patch, InnerCompositeCallback2.patch, RevisedInnerCompositeCallback.patch Support is added to represent composite references and services (those in a composite and without a binding) in the model and runtime. The CompositeBuilder is updated to build a composite component that includes composite references and services without bindings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-715) Update tools module to use latest XmlSchema version
[ http://issues.apache.org/jira/browse/TUSCANY-715?page=comments#action_12434221 ] Jeremy Boynes commented on TUSCANY-715: --- Patch applied - thanks Update tools module to use latest XmlSchema version --- Key: TUSCANY-715 URL: http://issues.apache.org/jira/browse/TUSCANY-715 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Jeremy Boynes Priority: Critical Attachments: Tuscany-SCA-Tools-Patch-Sept-12.diff The API for XmlSchema has changed since the 1.0.2 version. We are using a newer version due to updates in Axis2 and the tools need to be modified to use its new API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version
Update tools module to use latest XmlSchema version --- Key: TUSCANY-715 URL: http://issues.apache.org/jira/browse/TUSCANY-715 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Jeremy Boynes Priority: Critical The API for XmlSchema has changed since the 1.0.2 version. We are using a newer version due to updates in Axis2 and the tools need to be modified to use its new API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12433190 ] Jeremy Boynes commented on TUSCANY-688: --- Patches applied - thanks. I did have a slight problem with the sample before applying the sample patch in that the archiver objected to a duplicate entry. It would perhaps be helpful if the plugin could detect duplicates and only add them once. This may prevent duplicates as well - e.g. api ends up in both WEB-INF/lib and in WEB-INF/tuscany/boot WAR Maven Plugin for Tuscany Key: TUSCANY-688 URL: http://issues.apache.org/jira/browse/TUSCANY-688 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Meeraj Kunnumpurath Assigned To: Jeremy Boynes Priority: Minor Attachments: tuscany-war-patch-20060906.txt, tuscany-war-plugin-patch-20060906-2.txt, tuscany-war-plugin-src.jar, tuscany-webapp-sample-patch-20060906.txt Hi, This is the first cut for the Maven plugin for the Tuscany war plugin. The plugin is attached to the packaged phase and works on the WAR file produced by the Maven WAR plugin. It accepts the boot and extension libraries as configuration parameteres and adds them to the original WAR at relavant locations. Outstanding stuff, liVerify the presence of the required context listeners in web XML and add them if not present./li liDefaults handling, don't know what the defaults are :-)/li Here is a usage pattern, code project modelVersion4.0.0/modelVersion artifactIdMyWar/artifactId packagingwar/packaging groupIdMyCompany/groupId descriptionMy War/description version1.0/version build plugins plugin groupIdorg.apache.tuscany/groupId artifactIdtuscany-war-plugin/artifactId extensionstrue/extensions executions execution idtuscany-war/id goals goaltuscany-war/goal /goals /execution /executions configuration bootLibs dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.2/version /dependency /bootLibs extensions dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2/version /dependency /extensions /configuration /plugin /plugins /build /project /code -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12433202 ] Jeremy Boynes commented on TUSCANY-688: --- The duplicate problem seems to occur if I run the build twice: $ mvn -o clean $ mvn -o package # OK $ mvn -o package # Fails WAR Maven Plugin for Tuscany Key: TUSCANY-688 URL: http://issues.apache.org/jira/browse/TUSCANY-688 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Meeraj Kunnumpurath Assigned To: Jeremy Boynes Priority: Minor Attachments: tuscany-war-patch-20060906.txt, tuscany-war-plugin-patch-20060906-2.txt, tuscany-war-plugin-src.jar, tuscany-webapp-sample-patch-20060906.txt Hi, This is the first cut for the Maven plugin for the Tuscany war plugin. The plugin is attached to the packaged phase and works on the WAR file produced by the Maven WAR plugin. It accepts the boot and extension libraries as configuration parameteres and adds them to the original WAR at relavant locations. Outstanding stuff, liVerify the presence of the required context listeners in web XML and add them if not present./li liDefaults handling, don't know what the defaults are :-)/li Here is a usage pattern, code project modelVersion4.0.0/modelVersion artifactIdMyWar/artifactId packagingwar/packaging groupIdMyCompany/groupId descriptionMy War/description version1.0/version build plugins plugin groupIdorg.apache.tuscany/groupId artifactIdtuscany-war-plugin/artifactId extensionstrue/extensions executions execution idtuscany-war/id goals goaltuscany-war/goal /goals /execution /executions configuration bootLibs dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.2/version /dependency /bootLibs extensions dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2/version /dependency /extensions /configuration /plugin /plugins /build /project /code -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=comments#action_12432929 ] Jeremy Boynes commented on TUSCANY-699: --- I would (strongly) prefer we do not introduce a dependency on clogging. Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Attachments: springlaunch.patch Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ] Jeremy Boynes reassigned TUSCANY-699: - Assignee: Jeremy Boynes Allow bootstrap of tuscanny from spring web apps / struts apps etc -- Key: TUSCANY-699 URL: http://issues.apache.org/jira/browse/TUSCANY-699 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Andy Piper Assigned To: Jeremy Boynes Attachments: springlaunch.patch Spring provides a wealth of web app integration components. To reimplement these in Tuscany would be prohibitive, instead we need to allow Spring to bootstrap Tuscany and use its standard extension mechanisms. I have a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12432526 ] Jeremy Boynes commented on TUSCANY-688: --- Patch applied - thanks WAR Maven Plugin for Tuscany Key: TUSCANY-688 URL: http://issues.apache.org/jira/browse/TUSCANY-688 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Meeraj Kunnumpurath Assigned To: Jeremy Boynes Priority: Minor Attachments: tuscany-war-plugin-src.jar Hi, This is the first cut for the Maven plugin for the Tuscany war plugin. The plugin is attached to the packaged phase and works on the WAR file produced by the Maven WAR plugin. It accepts the boot and extension libraries as configuration parameteres and adds them to the original WAR at relavant locations. Outstanding stuff, liVerify the presence of the required context listeners in web XML and add them if not present./li liDefaults handling, don't know what the defaults are :-)/li Here is a usage pattern, code project modelVersion4.0.0/modelVersion artifactIdMyWar/artifactId packagingwar/packaging groupIdMyCompany/groupId descriptionMy War/description version1.0/version build plugins plugin groupIdorg.apache.tuscany/groupId artifactIdtuscany-war-plugin/artifactId extensionstrue/extensions executions execution idtuscany-war/id goals goaltuscany-war/goal /goals /execution /executions configuration bootLibs dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.2/version /dependency /bootLibs extensions dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2/version /dependency /extensions /configuration /plugin /plugins /build /project /code -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]
Jeremy Boynes closed TUSCANY-679.
-
Resolution: Fixed
Patch applied fine - thanks
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
Attachments: InterfaceWSDLLoader.ConstructorFix.patch
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry)
{
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-673) support scdlLocation attribute on implementation.composite
support scdlLocation attribute on implementation.composite Key: TUSCANY-673 URL: http://issues.apache.org/jira/browse/TUSCANY-673 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned To: Ignacio Silva-Lepe When using a composite as an implementation, we should provide a way for the user to specify the location of the SCDL for the composite component name=Foo implementation.composite name=Bar scdlLocation=bar.scdl/ ... The location should be resolved relative to the location of the outer composite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-673) support scdlLocation attribute on implementation.composite
[ http://issues.apache.org/jira/browse/TUSCANY-673?page=all ] Jeremy Boynes closed TUSCANY-673. - Resolution: Fixed Patch applied - thanks support scdlLocation attribute on implementation.composite Key: TUSCANY-673 URL: http://issues.apache.org/jira/browse/TUSCANY-673 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned To: Ignacio Silva-Lepe Attachments: ImplementationCompositeLoader.patch, ImplementationCompositeLoaderAndTest.patch When using a composite as an implementation, we should provide a way for the user to specify the location of the SCDL for the composite component name=Foo implementation.composite name=Bar scdlLocation=bar.scdl/ ... The location should be resolved relative to the location of the outer composite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-639) support for dependencies when referencing artifacts
[ http://issues.apache.org/jira/browse/TUSCANY-639?page=comments#action_12428586 ] Jeremy Boynes commented on TUSCANY-639: --- Another place where this applies is on include eg: include name=foo group=org.bar version=1.0/ support for dependencies when referencing artifacts --- Key: TUSCANY-639 URL: http://issues.apache.org/jira/browse/TUSCANY-639 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Reporter: Jervis Liu support for dependencies when referencing artifacts, for example, . implementation.composite name=foo group=org.bar version=1.0/. In this case, we can probably use some maven APIs to access the repo to resolve dependencies. See ArtifactRepository and it's implementation as a starting point. Enclosed below is IRC chat related to this topic. (01:55:14) jervisliu: I dont quite understand what you mean by I think this can be handled by the dependency mechanism and the use of the applicable location attributes e.g. wsdlLocation (01:55:35) jervisliu: what kind of dependency mechanism are you refering to? (01:56:08) jboynes: the ability to add dependency elements into SCDL to extend the classpath for the composite (01:56:55) jervisliu: this is not part of spec, right? (01:57:07) jboynes: no, it's a tuscany feature (01:57:33) jboynes: given the spec doesn't talk about packaging yet :-( (01:58:19) jervisliu: see. but it looks like there is an easier way to achieve same result. for example, the celtix-binding.jar can have a default.scdl (01:58:31) jboynes: sure (01:58:34) jboynes: you can do both (01:58:37) jervisliu: and the dependency of celtix-binding.jar can be specified in MANIFEST (01:58:48) jboynes: ah, no not really (01:59:09) jboynes: people hate manifest Class-Paths (01:59:19) jboynes: they still work and can be used (01:59:24) jervisliu: this can be done very easily in maven, and is a well understood way to resolve classpath dependencies (01:59:31) jboynes: yes (01:59:53) jboynes: dependency is quite maven friendly ;-) (02:00:36) jboynes: I also mentioned having the implementation use maven metadata if present in the jar (02:00:48) jervisliu: sure. I remember there was talk about a maven like dependency element. (02:00:58) jboynes: yep - - I just went and did it (02:01:19) jboynes: see ArtifactRepository and it's implementation (02:01:54) jboynes: having an implementation that used maven itself to locate the artifacts would be real cool (02:01:54) jervisliu: oh, i dont know its done already. ;-) (02:03:57) jervisliu: cool. so the scdl file under ext dir (using dependency) can only used for one binding implementation. right? (02:04:32) jboynes: well, it's a composite so it could contain components implemented by other nested composites (02:05:35) jervisliu: but then all dependencies will be merged to compose a classpath, (02:05:50) jboynes: no, the composite classloader is hierarchical (02:06:20) jboynes: the nested composites would be in child classloades (02:06:40) jervisliu: oklets have a concrete example. (02:07:08) jervisliu: how to write this scdl if we have both axis and celtix libraries under ext? (02:07:27) jboynes: well, you could just put them both in the ext directory (02:07:43) jboynes: then you wouldn't need any scdl (02:07:54) jboynes: s/libraries/bindings (02:08:41) jboynes: i.e put binding-axis.jar and binding-celtix.jar in ext (02:08:56) jervisliu: then when using binding.ws, which one is actually being used? (02:09:07) jboynes: why does it matter? (02:09:24) jervisliu: well, i just sent out an email to discuss this. (02:09:24) jboynes: it could be either but they both impl the spec (02:09:43) jboynes: by saying binding.ws the user us saying they don't care (02:10:01) jervisliu: maybe it does not matter. but users still wants to know whichi implementation they are actually using (02:10:41) jboynes: why? (02:10:56) jervisliu: and in the real world, it still matters. for example, both axis2 and celtix have their own configuration files, the default config file shipped with binding probably works for 99% situations (02:11:12) jervisliu: but it might be the case that they need to modify the config file. (02:11:29) jboynes: so in the real world how many users will actually use both concurrently? (02:11:32) jervisliu: in this case, they do need to know which implementation is loaded by tuscany (02:11:35) jboynes: no (02:11:48) jboynes: they need to make sure that they use the implementation they modified (02:12:05) jboynes: so if they modified celtix they should use binding.celtix.ws (02:12:21) jboynes: as that application will not work on a runtime that only has axis (02:12:59) jervisliu: ok. i think i m convinced on this. (02:14:06) jervisliu: the reason why i came
[jira] Created: (TUSCANY-640) Service and Reference do not support multiple binding elements
Service and Reference do not support multiple binding elements Key: TUSCANY-640 URL: http://issues.apache.org/jira/browse/TUSCANY-640 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Priority: Critical According to the spec, Service and Reference definitions can have multiple bindings associated with them. Our config model and the associated loaders and builders only support a single binding -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-619) Fix classloader hierarchy for extensions
Fix classloader hierarchy for extensions Key: TUSCANY-619 URL: http://issues.apache.org/jira/browse/TUSCANY-619 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned To: Jeremy Boynes We have the start of a classloader hierarchy working for extension code but it is not being set up correctly in some environments e.g. the current web launcher. This is causing problems when loading extensions such as Axis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-616) JavaServiceContract introspection should use the ImplementationProcessor mechanism
JavaServiceContract introspection should use the ImplementationProcessor mechanism -- Key: TUSCANY-616 URL: http://issues.apache.org/jira/browse/TUSCANY-616 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes On the devlist, jboynes wrote: Thinking a little more, using the ImplementationProcessor mechanisms seems like a better way to tackle this. One major advantage would be that we could add metadata to the service contract based on data type or annotations (e.g. adding metadata saying that a parameter should be bound using SDO which could be detected through the marker interface or an @SDO annotation). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-615) The SCDL syntax for reference doesn't conform to SCA spec 0.95
[ http://issues.apache.org/jira/browse/TUSCANY-615?page=comments#action_12427625 ] Jeremy Boynes commented on TUSCANY-615: --- There seem to be quite a few changes in this patch unrelated to the problem described above. Please can you submit these separately. The SCDL syntax for reference doesn't conform to SCA spec 0.95 -- Key: TUSCANY-615 URL: http://issues.apache.org/jira/browse/TUSCANY-615 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Raymond Feng Assigned To: Raymond Feng Priority: Critical Attachments: rfeng-scdl.txt With Rick check-in of r430621, I'm seeing the EchoBinding test case is failing with the following exception: org.apache.tuscany.spi.loader.InvalidReferenceException: No target for service [ClientService] at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I adjusted the scdl file per SCA 0.95 spec: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=echo.sample service name=ClientService interface.java class=echo.Client/ binding.echo/ referenceClient/reference /service component name=Client implementation.java class=echo.ClientImpl/ reference name=echoReferenceEchoReference/reference /component reference name=EchoReference interface.java interface=echo.Echo/ binding.echo/ /reference /composite Now the ServiceLoader.java is problematic because it assumes it'll get reference before the binding which is not case per SCA 0.95 spec: service name=xs:NCName multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* referencewire-target-URI/reference+ /service component name=xs:NCName* implementation/ property name=xs:NCName source=sca:Property?* property-value /property reference name=xs:NCName/* wire-target-URI /reference /component The ComponentLoader.java cannot handle the reference element either since the SCA spec 0.95 also use the element content instead of target attribute. I attached a patch to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-609) Remove dependency on Geronimo work manager
[ http://issues.apache.org/jira/browse/TUSCANY-609?page=all ] Jeremy Boynes reassigned TUSCANY-609: - Assignee: Jeremy Boynes Remove dependency on Geronimo work manager -- Key: TUSCANY-609 URL: http://issues.apache.org/jira/browse/TUSCANY-609 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Environment: N/A Reporter: Meeraj Kunnumpurath Assigned To: Jeremy Boynes Priority: Minor Attachments: remove-geronimo-work-manager.txt Remove dependency on Geronimo work manager. Following classes have been removed, 1. org.apache.tuscany.core.services.workmanager.DefaultWorkManager 2. org.apache.tuscany.core.services.workmanager.DefaultWorkManagerTestCase 3. org.apache.tuscany.core.services.workmanager.GeronimoWorkManagerTestCase Following files have been amended 1. sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncPolicyBuilder.java 2. sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncInterceptor.java 3. sca/core/pom.xml 4. sca/core/src/test/java/org/apache/tuscany/core/policy/async/AsyncInterceptorTestCase.java Please find the patch attached Ta Meeraj -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-609) Remove dependency on Geronimo work manager
[ http://issues.apache.org/jira/browse/TUSCANY-609?page=all ] Jeremy Boynes closed TUSCANY-609. - Resolution: Fixed Patch applied thanks Remove dependency on Geronimo work manager -- Key: TUSCANY-609 URL: http://issues.apache.org/jira/browse/TUSCANY-609 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Environment: N/A Reporter: Meeraj Kunnumpurath Assigned To: Jeremy Boynes Priority: Minor Attachments: remove-geronimo-work-manager.txt Remove dependency on Geronimo work manager. Following classes have been removed, 1. org.apache.tuscany.core.services.workmanager.DefaultWorkManager 2. org.apache.tuscany.core.services.workmanager.DefaultWorkManagerTestCase 3. org.apache.tuscany.core.services.workmanager.GeronimoWorkManagerTestCase Following files have been amended 1. sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncPolicyBuilder.java 2. sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncInterceptor.java 3. sca/core/pom.xml 4. sca/core/src/test/java/org/apache/tuscany/core/policy/async/AsyncInterceptorTestCase.java Please find the patch attached Ta Meeraj -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-573) Race condition in ThreadPoolWorkManager
[ http://issues.apache.org/jira/browse/TUSCANY-573?page=all ] Jeremy Boynes closed TUSCANY-573. - Resolution: Fixed Applied patch from Meeraj Race condition in ThreadPoolWorkManager --- Key: TUSCANY-573 URL: http://issues.apache.org/jira/browse/TUSCANY-573 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Problems running testSchedule testcase on single processor machines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-574) URISyntaxException from launcher when jars reside in windows Maven repository
[ http://issues.apache.org/jira/browse/TUSCANY-574?page=all ]
Jeremy Boynes resolved TUSCANY-574.
---
Resolution: Fixed
Assignee: Jeremy Boynes
Fix applied.
I tested running a single sample on a Windows machine where the maven repo has
a space in it
I also tested running the launcher on OSX from an install directory with a
space in it
Please confirm this fix works for you
URISyntaxException from launcher when jars reside in windows Maven repository
-
Key: TUSCANY-574
URL: http://issues.apache.org/jira/browse/TUSCANY-574
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Environment: Win XP, J2RE 1.5.0 IBM Windows 32 build
pwi32dev-20060511 (SR2)
Reporter: Matthew Sykes
Assigned To: Jeremy Boynes
Priority: Trivial
When attempting to run maven from various samples directories:
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\cygwin\home\sykesm\oss-code\tuscany\java\samples\sca\calculator\target\surefire-reports
---
T E S T S
---
Running calculator.CalculatorTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.38 sec
FAILURE!
testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.31 sec
ERROR!
java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:854)
at
org.apache.tuscany.core.launcher.Launcher.getInstallDirectory(Launcher.java:177)
at
org.apache.tuscany.core.launcher.Launcher.bootRuntime(Launcher.java:104)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:40)
at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:32)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
Caused by: java.net.URISyntaxException: Illegal character in path at index
18: file:/C:/Documents and
Settings/sykesm/.m2/repository/org/apache/tuscany/core/1.0-SNAPSHOT/core-1.0-SNAPSHOT.jar
at java.net.URI$Parser.fail(URI.java:2821)
at java.net.URI$Parser.checkChars(URI.java:2994)
at java.net.URI$Parser.parseHierarchical(URI.java:3078)
at java.net.URI$Parser.parse(URI.java:3026)
at java.net.URI.init(URI.java:590)
at java.net.URI.create(URI.java:852)
This appears to be due to how the Launcher teases out the directory
containing the Tuscany code. Since the default location for the maven
repository on windows has spaces in the directory names, the URI that was
used was not valid. In order to get past this I made a very simple change:
$ svn diff
Index: sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
===
--- sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
(revision 425392)
+++ sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
(working copy)
@@ -168,13 +168,15 @@
if (!jar.equals(url.getProtocol())) {
throw new IllegalStateException(Must be run from a jar: +
url);
}
+
[jira] Created: (TUSCANY-573) Race condition in ThreadPoolWorkManager
Race condition in ThreadPoolWorkManager --- Key: TUSCANY-573 URL: http://issues.apache.org/jira/browse/TUSCANY-573 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Problems running testSchedule testcase on single processor machines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-550) Supply chain sample for chianti
[ http://issues.apache.org/jira/browse/TUSCANY-550?page=all ] Jeremy Boynes reassigned TUSCANY-550: - Assignee: Jeremy Boynes (was: Ignacio Silva-Lepe) Supply chain sample for chianti --- Key: TUSCANY-550 URL: http://issues.apache.org/jira/browse/TUSCANY-550 Project: Tuscany Issue Type: Test Components: Java SCA Samples Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Assigned To: Jeremy Boynes Fix For: Java-Mx Attachments: supplychain.zip Upgrading supply chain sample to work with new version of spec under chianti -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-550) Supply chain sample for chianti
[ http://issues.apache.org/jira/browse/TUSCANY-550?page=all ] Jeremy Boynes closed TUSCANY-550. - Resolution: Fixed Patch applied - thank you Ignacio Supply chain sample for chianti --- Key: TUSCANY-550 URL: http://issues.apache.org/jira/browse/TUSCANY-550 Project: Tuscany Issue Type: Test Components: Java SCA Samples Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Assigned To: Jeremy Boynes Fix For: Java-Mx Attachments: supplychain.zip Upgrading supply chain sample to work with new version of spec under chianti -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-538) Refactor Celtix binding
[ http://issues.apache.org/jira/browse/TUSCANY-538?page=comments#action_12420621 ] Jeremy Boynes commented on TUSCANY-538: --- I applied the patch but needed to tweak some files where the delta was applied twice. It built but please check I didn't mess up. Thanks Refactor Celtix binding --- Key: TUSCANY-538 URL: http://issues.apache.org/jira/browse/TUSCANY-538 Project: Tuscany Type: Improvement Components: Java SCA Celtix Binding Versions: Java-M2 Reporter: Jervis Liu Priority: Minor Attachments: jira538.patch We need to refactor the Celtix binding in sandbox to reflect changes in the new recursive framework. Also more tests need to be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-537) Update version in POM
Update version in POM - Key: TUSCANY-537 URL: http://issues.apache.org/jira/browse/TUSCANY-537 Project: Tuscany Type: Improvement Components: Java SDO Implementation, Java SDO Tools, Java SDO Samples Reporter: Jeremy Boynes Assigned to: Jeremy Boynes The project POMs should be updated to reflect the future version (to avoid conflict with the M1 release). We should also update the EMF dependency to their final 2.2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=comments#action_12420083 ] Jeremy Boynes commented on TUSCANY-527: --- Geronimo produce a version of the spec API but the latest released version has a couple of problems with it. They have been fixed and once they publish a SNAPSHOT I can update our build to use it. First cut of the work scheduler implementation -- Key: TUSCANY-527 URL: http://issues.apache.org/jira/browse/TUSCANY-527 Project: Tuscany Type: New Feature Components: Java SCA Core Reporter: Meeraj Kunnumpurath Assignee: Jeremy Boynes Priority: Trivial Attachments: jsr237.jar, workmanager.jar First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=comments#action_12419907 ] Jeremy Boynes commented on TUSCANY-527: --- Looks good. Which version of the commonj API are you using and is there a version of it in the maven repo? First cut of the work scheduler implementation -- Key: TUSCANY-527 URL: http://issues.apache.org/jira/browse/TUSCANY-527 Project: Tuscany Type: New Feature Components: Java SCA Core Reporter: Meeraj Kunnumpurath Assignee: Jeremy Boynes Priority: Trivial Attachments: workmanager.jar First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=all ] Jeremy Boynes reassigned TUSCANY-527: - Assign To: Jeremy Boynes First cut of the work scheduler implementation -- Key: TUSCANY-527 URL: http://issues.apache.org/jira/browse/TUSCANY-527 Project: Tuscany Type: New Feature Components: Java SCA Core Reporter: Meeraj Kunnumpurath Assignee: Jeremy Boynes Priority: Trivial Attachments: workmanager.jar First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-395) Incorrect copyright statement
Incorrect copyright statement -- Key: TUSCANY-395 URL: http://issues.apache.org/jira/browse/TUSCANY-395 Project: Tuscany Type: Bug Components: Java SCA Samples Versions: Java-M1 Reporter: Jeremy Boynes Priority: Blocker Contains: !-- Copyright (c) 2005 BEA Sytems Inc. Copyright (c) 2005 International Business Machines ... Files found by grep are: ./sca/containers/container.java/src/test/resources/helloworld/sca.module ./sca/containers/container.java/target/test-classes/helloworld/sca.module ./samples/sca/helloworld/src/main/resources/sca.module ./samples/sca/helloworld/target/classes/sca.module ./samples/sca/calculator/src/main/resources/sca.module ./samples/sca/calculator/target/classes/sca.module ./samples/sca/customerinfo/src/main/resources/sca.module ./samples/sca/customerinfo/target/classes/sca.module ./samples/sca/helloworlde4xws/src/main/resources/sca.module ./samples/sca/helloworlde4xws/target/sample-helloworlde4xws-incubating-M1/WEB-INF/classes/sca.module ./samples/sca/helloworlde4xws/target/classes/sca.module ./samples/sca/helloworldjsclient/src/main/resources/sca.module ./samples/sca/helloworldjsclient/target/sample-helloworldjsclient-incubating-M1/WEB-INF/classes/sca.module ./samples/sca/helloworldjsclient/target/classes/sca.module ./samples/sca/helloworld-jms/server/src/main/resources/sca.module ./samples/sca/helloworld-jms/server/target/classes/sca.module -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Jeremy Boynes closed TUSCANY-201: - Resolution: Fixed Patch applied - thanks. Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Reporter: Jeremy Boynes Assignee: Jeremy Boynes Fix For: M1 Attachments: wsdl_patch Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-239) Need access to WSDLs by namespace
[ http://issues.apache.org/jira/browse/TUSCANY-239?page=all ] Jeremy Boynes closed TUSCANY-239: - Resolution: Fixed Patch applied - thanks Need access to WSDLs by namespace - Key: TUSCANY-239 URL: http://issues.apache.org/jira/browse/TUSCANY-239 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Reporter: Daniel Kulp Assignee: Jeremy Boynes Fix For: M1 Attachments: core.patch In order to replace usage of the SCDLAssemblyModelLoaderImpl with the WSDLDefinitionRegistry, the registry needs to have a method to lookup the definitions based on a namespace. Patch is included. Patch for the Celtix binding will be forthcoming. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-261) Tuscany-generated WAR should not package runtime jars under WEB-INF/lib
[ http://issues.apache.org/jira/browse/TUSCANY-261?page=all ] Jeremy Boynes resolved TUSCANY-261: --- Resolution: Fixed Patch applied - thanks I verified that the jars are not in the generated war, I have not verified that the sample still runs. Please close this issue (or let me know if you can't) if the changes works for you. Tuscany-generated WAR should not package runtime jars under WEB-INF/lib --- Key: TUSCANY-261 URL: http://issues.apache.org/jira/browse/TUSCANY-261 Project: Tuscany Type: Bug Components: Java BigBank Scenario Versions: M1 Reporter: Raymond Feng Priority: Critical Fix For: M1 Three jars (axiom-api, stax-api and wstx-asl) are packaged by the account-SNAPSHOT.war under WEB-INF/lib. Since the by default the Tomcat web application classloader uses parent-last classloading policy (delegate=false), it creates different instances of classes/interfaces from the jars in the application context and confuses the Tucany and Axis2 runtime which in turn throws ClassCastException. Here's the patch: Index: C:/Tuscany/Apache/java/samples/bigbank/account/pom.xml === --- C:/Tuscany/Apache/java/samples/bigbank/account/pom.xml(revision 399340) +++ C:/Tuscany/Apache/java/samples/bigbank/account/pom.xml(working copy) @@ -57,21 +57,21 @@ groupIdstax/groupId artifactIdstax-api/artifactId version1.0/version -scopecompile/scope +scopeprovided/scope /dependency dependency groupIdwoodstox/groupId artifactIdwstx-asl/artifactId version2.8.2/version -scoperuntime/scope +scopeprovided/scope /dependency dependency groupIdws-commons/groupId artifactIdaxiom-api/artifactId version0.95/version -scopecompile/scope +scopeprovided/scope /dependency /dependencies -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-303) Single package override in tuscany-sca-plugin and tuscany-sdo-plugin insufficient
[ http://issues.apache.org/jira/browse/TUSCANY-303?page=all ] Jeremy Boynes updated TUSCANY-303: -- Component: Java SCA Tools Java SDO Tools Single package override in tuscany-sca-plugin and tuscany-sdo-plugin insufficient -- Key: TUSCANY-303 URL: http://issues.apache.org/jira/browse/TUSCANY-303 Project: Tuscany Type: New Feature Components: Java SCA Tools, Java SDO Tools Reporter: Rick Rineholt WSDL and schemas may reference many namespaces, a more general mapping scheme that can override many target namespace to map to a java package is ultimately required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-46) Scope for system components is not read from sidefile
[ http://issues.apache.org/jira/browse/TUSCANY-46?page=all ] Jeremy Boynes closed TUSCANY-46: Fix Version: M1 (was: Mx) Resolution: Won't Fix System Implementation does not support sidefiles. Scope for system components is not read from sidefile - Key: TUSCANY-46 URL: http://issues.apache.org/jira/browse/TUSCANY-46 Project: Tuscany Type: Bug Components: Specification Versions: Mx Reporter: Jeremy Boynes Fix For: M1 I have a sidefile with a aervice declaration service name=SCDLModelLoader scope=module but in the logical model the scope is set to INSTANCE -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-275) Define and implement Transport binding extension API
[ http://issues.apache.org/jira/browse/TUSCANY-275?page=all ] Jeremy Boynes closed TUSCANY-275: - Resolution: Duplicate Define and implement Transport binding extension API Key: TUSCANY-275 URL: http://issues.apache.org/jira/browse/TUSCANY-275 Project: Tuscany Type: New Feature Components: Java SCA Core Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: Jeremy Boynes Fix For: M1 This was identified as a task for our first release (see http://wiki.apache.org/ws/Tuscany/Tasks). This will allow bindings to register with multiple transports (HTTP, JMS etc). Used by the Axis2, Celtix and Jsonrpc bindings. Jim and Jeremy volunteered to work on this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-177) Need a specification for autowire?
[ http://issues.apache.org/jira/browse/TUSCANY-177?page=all ] Jeremy Boynes updated TUSCANY-177: -- type: New Feature (was: Bug) Need a specification for autowire? -- Key: TUSCANY-177 URL: http://issues.apache.org/jira/browse/TUSCANY-177 Project: Tuscany Type: New Feature Components: Specification Versions: Mx Reporter: Jean-Sebastien Delfino Assignee: Jeremy Boynes Fix For: Mx Tuscany has introduced an Autowire capability. This needs to be contributed back to the SCA spec collaboration assembly workgroup. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL PROTECTED] and the associated discussion thread for the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-60) Need to externalize bootstrap process for the runtime
[ http://issues.apache.org/jira/browse/TUSCANY-60?page=all ] Jeremy Boynes closed TUSCANY-60: Resolution: Fixed Need to externalize bootstrap process for the runtime - Key: TUSCANY-60 URL: http://issues.apache.org/jira/browse/TUSCANY-60 Project: Tuscany Type: Improvement Components: Java SCA Core Versions: M1 Reporter: Jeremy Boynes Assignee: Jeremy Boynes Fix For: M1 Currently there is a bunch of duplicate code in various places that boots a runtime. I know of: * TuscanyRuntime * TuscanyServletListener * TuscantContextListener These all bootstrap in very similar but slightly ways. We should externalize the bootstrap process so that it can be shared by these implementations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-262) The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy
[ http://issues.apache.org/jira/browse/TUSCANY-262?page=comments#action_12377639 ] Jeremy Boynes commented on TUSCANY-262: --- In short, yes this is by design, at least of Tomcat and the integration code for it. Tomcat does this to create isolation between the classes and libraries it itself uses and those that the applications that it is running might use. This prevents classes from the container leaking in to an application's classpath and overriding versions that the application may want. It also prevents security problems caused by exposing the container's internals to applications or potential conflicts when static fields are used. The integration code follows Tomcat's classloading model and places the Tuscany implementation code in the container's classloading scope. The only classes that should be shared are the standard org.osoa interfaces (which are currently located in the common classloader just like the servlet API classes). One of the complexities of this scheme is that the container code does not have access to application classes using its own classloader. To address this, the J2EE programming model makes use of the Thread context classloader (TCCL) which allows the container to associate the application classloader with the currently running Thread before a request is handed over to application code. When the application calls back into the container, the container code can retrieve the application classloader from the Thread whenever it needs to access the application code. Application code should not need to access this classloader as it has access to its own using getClass().getClassLoader(); in fact, in a strict security environment, it will not even be able to access the TCCL (unless it happens to be the application classloader itself). Many of the problems we are seeing are because code is not making this separation between container and application classloaders a top level concept. For example, the SDO implementation always keys its type system off the TCCL which means that any time the container needs to interact with SDO it needs to ensure the TCCL is set to the application classloader. Moreover, due to the use of static initializers, it must set the TCCL every time it does anything that may touch an application class. The real solution here is for the libraries to provide mechanisms that allow operations to be performed by the container on behalf of the application using an explicitly provided classloader. Work has start on this with SDO, I am not sure what the situation is with Axis2. Placing all the Tuscany implementation on the application classpath by moving the jars to common will only cause greater problems in the long run and is not something that should be done. The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy -- Key: TUSCANY-262 URL: http://issues.apache.org/jira/browse/TUSCANY-262 Project: Tuscany Type: Bug Components: Java SCA Tomcat Integration Reporter: Raymond Feng Priority: Critical As a result from the investigation on JIRA issue Tuscany-258, I found the following problem. Right now, most of the Tuscany and dependency jars are copied to $CATALINA_HOME/server/lib. Is it by design? I think it's problematic and it's the root cause of the problem described by 258. Here's a quote from the Tomcat 5.0 document @ http://tomcat.apache.org/tomcat-5.0-doc/class-loader-howto.html: Catalina - This class loader is initialized to include all classes and resources required to implement Tomcat 5 itself. These classes and resources are TOTALLY invisible to web applications. All unpacked classes and resources in $CATALINA_HOME/server/classes, as well as classes and resources in JAR files under $CATALINA_HOME/server/lib, are made visible through this class loader. It leads to a very messy classloading story. The classloader for the Tuscany runtime classes/interfaces is NOT part of the web application's classloader chain. Some classes in the runtime (including Tuscany and Axis2) uses Thread context classloader as the starting point to resolve resources/classes and it'll fail without the hacky classloader switching all over the place. I did some experiement and found out the following should be the correct packaging scheme: 1) Only tuscany-tomcat-SNAPSHOT.jar should be copied to $CATALINA_HOME/server/lib since it contains a class org.apache.tuscany.tomcat.TuscanyHost extending org.apache.catalina.core.StandardHost which is packaged in catalina.jar under $CATALINA_HOME/server/lib. 2) All the other Tuscany jars should be copied to $CATALINA_HOME/common/lib With the new strategy, we can remove the classloader switching
[jira] Closed: (TUSCANY-262) The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy
[ http://issues.apache.org/jira/browse/TUSCANY-262?page=all ] Jeremy Boynes closed TUSCANY-262: - Resolution: Invalid Assign To: Jeremy Boynes Closing as invalid as we need to handle classloaders in an appropriate manner. The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy -- Key: TUSCANY-262 URL: http://issues.apache.org/jira/browse/TUSCANY-262 Project: Tuscany Type: Bug Components: Java SCA Tomcat Integration Reporter: Raymond Feng Assignee: Jeremy Boynes Priority: Critical As a result from the investigation on JIRA issue Tuscany-258, I found the following problem. Right now, most of the Tuscany and dependency jars are copied to $CATALINA_HOME/server/lib. Is it by design? I think it's problematic and it's the root cause of the problem described by 258. Here's a quote from the Tomcat 5.0 document @ http://tomcat.apache.org/tomcat-5.0-doc/class-loader-howto.html: Catalina - This class loader is initialized to include all classes and resources required to implement Tomcat 5 itself. These classes and resources are TOTALLY invisible to web applications. All unpacked classes and resources in $CATALINA_HOME/server/classes, as well as classes and resources in JAR files under $CATALINA_HOME/server/lib, are made visible through this class loader. It leads to a very messy classloading story. The classloader for the Tuscany runtime classes/interfaces is NOT part of the web application's classloader chain. Some classes in the runtime (including Tuscany and Axis2) uses Thread context classloader as the starting point to resolve resources/classes and it'll fail without the hacky classloader switching all over the place. I did some experiement and found out the following should be the correct packaging scheme: 1) Only tuscany-tomcat-SNAPSHOT.jar should be copied to $CATALINA_HOME/server/lib since it contains a class org.apache.tuscany.tomcat.TuscanyHost extending org.apache.catalina.core.StandardHost which is packaged in catalina.jar under $CATALINA_HOME/server/lib. 2) All the other Tuscany jars should be copied to $CATALINA_HOME/common/lib With the new strategy, we can remove the classloader switching hacks in the code base. I can upload the patch if you guys agree with me. The patch includes the changes against the build.xml (testing/tomcat), TuscanyContextListener.java (sca/tomcat) and the rollbacks of the workaround committed by Ant under 258. Thanks, Raymond -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-141) interface.wsdl doesn't work in .componentType side files
[ http://issues.apache.org/jira/browse/TUSCANY-141?page=all ] Jeremy Boynes closed TUSCANY-141: - Closing as the import issue is fixed and the other problems are not related to the sidefile. interface.wsdl doesn't work in .componentType side files Key: TUSCANY-141 URL: http://issues.apache.org/jira/browse/TUSCANY-141 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: ant elder Assignee: Jeremy Boynes Using interface.wsdl in .componentType side file fails as it can't find the WSDL. It looks like the import.wsdl doesn't get processed until after the side file is processed. The JavaScript sample 7 can be used to recreate the problem, look in HelloWorldImpl.componentType and there's a commented out interface.wsdl, change to use that gives this exception: java.lang.IllegalArgumentException: Cannot find WSDL definition for http://helloworld.samples.tuscany.apache.org at org.apache.tuscany.model.types.wsdl.impl.WSDLServiceContractImpl.getPortType(WSDLServiceContractImpl.java:158) at org.apache.tuscany.model.types.wsdl.impl.WSDLServiceContractImpl.initialize(WSDLServiceContractImpl.java:103) at org.apache.tuscany.model.assembly.impl.PortImpl.initialize(PortImpl.java:77) at org.apache.tuscany.model.assembly.impl.ComponentTypeImpl.initialize(ComponentTypeImpl.java:117) at org.apache.tuscany.model.assembly.impl.ComponentImplementationImpl.initialize(ComponentImplementationImpl.java:62) at org.apache.tuscany.container.js.assembly.impl.JavaScriptImplementationImpl.initialize(JavaScriptImplementationImpl.java:73) at org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:115) at org.apache.tuscany.model.scdl.loader.impl.SCDLModelContentHandlerImpl$9.run(SCDLModelContentHandlerImpl.java:409) at org.apache.tuscany.model.util.ModelTransformerImpl.transformPass2(ModelTransformerImpl.java:122) at org.apache.tuscany.model.util.ModelTransformerImpl.transform(ModelTransformerImpl.java:42) at org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.transform(SCDLAssemblyModelLoaderImpl.java:198) at org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadModule(SCDLAssemblyModelLoaderImpl.java:107) at org.apache.tuscany.core.config.impl.ModuleComponentConfigurationLoaderImpl.loadModule(ModuleComponentConfigurationLoaderImpl.java:48) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:98) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:88) at org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:61) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:100) at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:64) at sample.Sample7Client.invoke(Sample7Client.java:38) at sample.Sample7TestCase.testGeetings(Sample7TestCase.java:28) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-43) Cannot autowire within module
[ http://issues.apache.org/jira/browse/TUSCANY-43?page=all ] Jeremy Boynes closed TUSCANY-43: Resolution: Fixed Fixed by jmarino's refactor of autowire Cannot autowire within module - Key: TUSCANY-43 URL: http://issues.apache.org/jira/browse/TUSCANY-43 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Autowire references between components in the same module do not work. Due to chicken-egg issues a org.apache.tuscany.core.builder.BuilderConfigException: No autowire found for ... exception is thrown during the build phase. This occurs because the builder is being too aggressive in wiring by trying to create a SingletonObjectFactory - instead, this should be deferred until the component is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-57) MonitorFactory should be a system service
[ http://issues.apache.org/jira/browse/TUSCANY-57?page=all ] Jeremy Boynes closed TUSCANY-57: Resolution: Fixed Injection of monitors is now directly supported MonitorFactory should be a system service - Key: TUSCANY-57 URL: http://issues.apache.org/jira/browse/TUSCANY-57 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes The MonitorFactory should be a system service rather than part of the RuntimeContext -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-238) Unhelpful namespace for Tuscany schemata
Unhelpful namespace for Tuscany schemata Key: TUSCANY-238 URL: http://issues.apache.org/jira/browse/TUSCANY-238 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes We define XML namespaces with the URI beginning http://org.apache.tuscany/xmlns/... This is not resolvable to a web address. It would be better if we changed these to a valid FQDN http://tuscany.apache.org/xmlns/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-219) @Property on a setter method does not work
[ http://issues.apache.org/jira/browse/TUSCANY-219?page=all ]
Jeremy Boynes reassigned TUSCANY-219:
-
Assign To: Jim Marino
Should go away when Jim changes the annotation introspector but assigning it to
him so he does not forget.
@Property on a setter method does not work
--
Key: TUSCANY-219
URL: http://issues.apache.org/jira/browse/TUSCANY-219
Project: Tuscany
Type: Bug
Components: Java SCA Core
Reporter: Jean-Sebastien Delfino
Assignee: Jim Marino
This is a significant problem as following the recommended practice for
JavaBean properties causes an exception.
To reproduce the problem, modify
org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentImpl as
follows:
private String greetingMiddle;
@Property
public void setGreetingMiddle(String greetingMiddle) {
this.greetingMiddle = greetingMiddle;
}
public String getGreetingMiddle() {
return greetingMiddle;
}
run mvn from helloworldmc.
Here's the surefire report:
---
Battery:
org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase
---
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.034 sec
testGeetings(org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase)
Time elapsed: 1.008 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
org.apache.tuscany.core.config.InvalidSetterException: public void
org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentImpl.setGreetingMiddle(java.lang.String)
at
org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.addProperty(Java5ComponentTypeIntrospector.java:332)
at
org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.introspectPublicMethods(Java5ComponentTypeIntrospector.java:288)
at
org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.introspectAnnotatedMembers(Java5ComponentTypeIntrospector.java:201)
at
org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.introspect(Java5ComponentTypeIntrospector.java:80)
at
org.apache.tuscany.container.java.loader.JavaImplementationLoader.loadComponentTypeByIntrospection(JavaImplementationLoader.java:119)
at
org.apache.tuscany.container.java.loader.JavaImplementationLoader.loadComponentType(JavaImplementationLoader.java:112)
at
org.apache.tuscany.container.java.loader.JavaImplementationLoader.load(JavaImplementationLoader.java:91)
at
org.apache.tuscany.container.java.loader.JavaImplementationLoader.load(JavaImplementationLoader.java:51)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:64)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:80)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:53)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:64)
at
org.apache.tuscany.core.loader.assembly.AggregateLoader.loadAggregate(AggregateLoader.java:43)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:39)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:32)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:64)
at
org.apache.tuscany.core.config.impl.StAXModuleComponentConfigurationLoaderImpl.loadModule(StAXModuleComponentConfigurationLoaderImpl.java:51)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:98)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:88)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:61)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67)
at
org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase.testGeetings(HelloWorldServiceComponentTestCase.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] Assigned: (TUSCANY-208) Fix eclipse warnings for sca/bindings/bindings.axis2
[ http://issues.apache.org/jira/browse/TUSCANY-208?page=all ] Jeremy Boynes reassigned TUSCANY-208: - Assign To: Jeremy Boynes (was: ant elder) Fix eclipse warnings for sca/bindings/bindings.axis2 Key: TUSCANY-208 URL: http://issues.apache.org/jira/browse/TUSCANY-208 Project: Tuscany Type: Improvement Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Minor Attachments: axis2_patch FIx all eclipse warnings in bindings.axis2. Also make it 99% compliant with the checkstyle and pmd rules included in the celtix patch. To fix many of the warnings, I had to propertly type all the collections as well as use generics in a few other areas. Thus, the patch is a bit more than just reformatting and general cleanup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-209) Fix more eclipse warnings for sca/model
[ http://issues.apache.org/jira/browse/TUSCANY-209?page=all ] Jeremy Boynes closed TUSCANY-209: - Resolution: Fixed Applied patch. I assume Eclipse is still happy but IDEA complains (serialUID, non-static inner classes, ArrayList.remove(), complexity of CompositeImpl.initialize()) Fix more eclipse warnings for sca/model --- Key: TUSCANY-209 URL: http://issues.apache.org/jira/browse/TUSCANY-209 Project: Tuscany Type: Improvement Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Trivial Attachments: sca_model.patch Small patch to fix some eclipse (and -Xlint) warnings in the model package that were recently introduced. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-208) Fix eclipse warnings for sca/bindings/bindings.axis2
[ http://issues.apache.org/jira/browse/TUSCANY-208?page=all ] Jeremy Boynes closed TUSCANY-208: - Resolution: Fixed Patch applied Fix eclipse warnings for sca/bindings/bindings.axis2 Key: TUSCANY-208 URL: http://issues.apache.org/jira/browse/TUSCANY-208 Project: Tuscany Type: Improvement Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Minor Attachments: axis2_patch FIx all eclipse warnings in bindings.axis2. Also make it 99% compliant with the checkstyle and pmd rules included in the celtix patch. To fix many of the warnings, I had to propertly type all the collections as well as use generics in a few other areas. Thus, the patch is a bit more than just reformatting and general cleanup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-206) Implement Celtix WS Binding
[ http://issues.apache.org/jira/browse/TUSCANY-206?page=comments#action_12375224 ] Jeremy Boynes commented on TUSCANY-206: --- Patches applied to create projects in the sandbox under celtix Implement Celtix WS Binding --- Key: TUSCANY-206 URL: http://issues.apache.org/jira/browse/TUSCANY-206 Project: Tuscany Type: New Feature Components: Java SCA Common Reporter: Daniel Kulp Assignee: Jeremy Boynes Attachments: binding.celtix.tar.gz, sunjars.tar.gz Issue to track the patches and stuff related to creating a Celtix based ws binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assigned to: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is model -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-200?page=comments#action_12374764 ] Jeremy Boynes commented on TUSCANY-200: --- Jim started to make this change in r394333 but that only impacts the builder. During loading, introspection on the class explicitly sets the scope to INSTANCE Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is model -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-200?page=all ] Jeremy Boynes updated TUSCANY-200: -- Description: The default scope for system components is currently INSTANCE but the typical usage is module (was: The default scope for system components is currently INSTANCE but the typical usage is model) Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is module -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-201) Allow extensions to WSDL processing
Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned to: Jeremy Boynes Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Jeremy Boynes updated TUSCANY-201: -- Attachment: wsdl_patch Attached patch originally sent to mailing list by Dan Kulp Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jeremy Boynes Attachments: wsdl_patch Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=comments#action_12374829 ] Jeremy Boynes commented on TUSCANY-201: --- The InterfaceWSDLLoader has been modified to intialize portType information using the WSDLDefinitionRegistry so these extensions should be available there. Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jeremy Boynes Attachments: wsdl_patch Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-149) Messages logged by Tomcat integration don't appear in log files
[ http://issues.apache.org/jira/browse/TUSCANY-149?page=all ] Jeremy Boynes closed TUSCANY-149: - Resolution: Fixed Assign To: Jeremy Boynes The test setup was copying log4j into server/lib causing Tomcat (through its use of clogging) to switch from JSR-47 to log4j logging. Unfortunately, the ws-commons/policy jar contains a minimal log4j.properties file which configured log4j in a way that resulted in the suppression of most messages. I changed the configuration script so that it no longer installs log4j as part of test setup. I also updated the wiki to remove log4j from the list of jars to be installed. Messages logged by Tomcat integration don't appear in log files --- Key: TUSCANY-149 URL: http://issues.apache.org/jira/browse/TUSCANY-149 Project: Tuscany Type: Bug Components: Java SCA Tomcat Integration Reporter: Jeremy Boynes Assignee: Jeremy Boynes Priority: Blocker Messages (informational or error) logged by the Tomcat integration code do not get output to the screen or to the log files. Call to log.info() or getLogger().error() are being made but the logging implementation decides that the log level is not enabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-149) Messages logged by Tomcat integration don't appear in log files
Messages logged by Tomcat integration don't appear in log files --- Key: TUSCANY-149 URL: http://issues.apache.org/jira/browse/TUSCANY-149 Project: Tuscany Type: Bug Components: Java SCA Tomcat Integration Reporter: Jeremy Boynes Priority: Blocker Messages (informational or error) logged by the Tomcat integration code do not get output to the screen or to the log files. Call to log.info() or getLogger().error() are being made but the logging implementation decides that the log level is not enabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-131) Fix eclipse warnings for sca/model
[ http://issues.apache.org/jira/browse/TUSCANY-131?page=all ] Jeremy Boynes reassigned TUSCANY-131: - Assign To: Jeremy Boynes Fix eclipse warnings for sca/model -- Key: TUSCANY-131 URL: http://issues.apache.org/jira/browse/TUSCANY-131 Project: Tuscany Type: Improvement Components: Java SCA Model Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Minor Attachments: sca.model.patch Fix eclipse warnings in sca/model Add types to most of the untyped collections (within limits, stuff from jwsdl and sdo cannot) Reformat some code to conform to the rest of the code, wrap some very long lines, replace some tabs with spaces, etc... Pretty much, all cosmetic changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-131) Fix eclipse warnings for sca/model
[ http://issues.apache.org/jira/browse/TUSCANY-131?page=all ] Jeremy Boynes resolved TUSCANY-131: --- Resolution: Fixed applied patch - thanks As I went through reviewing the changes I also fixed others that IDEA was reporting. Please can you review these to see if I introduced anything to upset Eclipse and either comment here or close the issue. Thanks Fix eclipse warnings for sca/model -- Key: TUSCANY-131 URL: http://issues.apache.org/jira/browse/TUSCANY-131 Project: Tuscany Type: Improvement Components: Java SCA Model Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Minor Attachments: sca.model.patch Fix eclipse warnings in sca/model Add types to most of the untyped collections (within limits, stuff from jwsdl and sdo cannot) Reformat some code to conform to the rest of the code, wrap some very long lines, replace some tabs with spaces, etc... Pretty much, all cosmetic changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-6) Method names in ResourceLoader are inconsistent with ClassLoader
[ http://issues.apache.org/jira/browse/TUSCANY-6?page=all ] Jeremy Boynes reassigned TUSCANY-6: --- Assign To: Jeremy Boynes Method names in ResourceLoader are inconsistent with ClassLoader Key: TUSCANY-6 URL: http://issues.apache.org/jira/browse/TUSCANY-6 Project: Tuscany Type: Improvement Components: Java SCA Common Reporter: Jeremy Boynes Assignee: Jeremy Boynes The getResouces(String) method behaves differently to the similar method on ClassLoader in that it only searches the current resource loader but not its parents. I would suggest renaming: getAllResources(String) to getResources(String) and getResources(String) to getDeclaredResources(String) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-6) Method names in ResourceLoader are inconsistent with ClassLoader
[ http://issues.apache.org/jira/browse/TUSCANY-6?page=all ] Jeremy Boynes closed TUSCANY-6: --- Resolution: Fixed Removed version that did not search parent and renamed to match ClassLoader Method names in ResourceLoader are inconsistent with ClassLoader Key: TUSCANY-6 URL: http://issues.apache.org/jira/browse/TUSCANY-6 Project: Tuscany Type: Improvement Components: Java SCA Common Reporter: Jeremy Boynes Assignee: Jeremy Boynes The getResouces(String) method behaves differently to the similar method on ClassLoader in that it only searches the current resource loader but not its parents. I would suggest renaming: getAllResources(String) to getResources(String) and getResources(String) to getDeclaredResources(String) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-127) Fix for spec eclipse warnings
[ http://issues.apache.org/jira/browse/TUSCANY-127?page=all ] Jeremy Boynes closed TUSCANY-127: - Resolution: Fixed Applied fix for the changes to CurrentModuleContext I did not apply the fix to CallbackType as the test is checking that annotations on private fields are accessible. The spec allows this even though it can be annoying when IDEs report (correctly) that the field is not being used. Fix for spec eclipse warnings --- Key: TUSCANY-127 URL: http://issues.apache.org/jira/browse/TUSCANY-127 Project: Tuscany Type: Improvement Components: Java Spec APIs Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Minor Attachments: spec.patch Minor changes to fix all the compiler warnings in eclipse for all of spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-128) Fix eclipse warnings for sca/common
[ http://issues.apache.org/jira/browse/TUSCANY-128?page=all ] Jeremy Boynes closed TUSCANY-128: - Resolution: Fixed Patch applied - thanks Fix eclipse warnings for sca/common --- Key: TUSCANY-128 URL: http://issues.apache.org/jira/browse/TUSCANY-128 Project: Tuscany Type: Improvement Components: Java SCA Common Reporter: Daniel Kulp Priority: Minor Attachments: common.patch Fixes all the eclipse warnings for sca/common -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-133) Upgrade to AXIOM 0.95
Upgrade to AXIOM 0.95 - Key: TUSCANY-133 URL: http://issues.apache.org/jira/browse/TUSCANY-133 Project: Tuscany Type: Task Components: Java SCA Axis Integration Reporter: Jeremy Boynes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-133) Upgrade to AXIOM 0.95
[ http://issues.apache.org/jira/browse/TUSCANY-133?page=all ] Jeremy Boynes reassigned TUSCANY-133: - Assign To: Rick Rineholt Assigning to Rick as he provided the SNAPSHOT we are currently using Upgrade to AXIOM 0.95 - Key: TUSCANY-133 URL: http://issues.apache.org/jira/browse/TUSCANY-133 Project: Tuscany Type: Task Components: Java SCA Axis Integration Reporter: Jeremy Boynes Assignee: Rick Rineholt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-134) Upgrade to WS Commons Policy 1.0
Upgrade to WS Commons Policy 1.0 Key: TUSCANY-134 URL: http://issues.apache.org/jira/browse/TUSCANY-134 Project: Tuscany Type: Task Components: Java SCA Axis Integration Reporter: Jeremy Boynes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-134) Upgrade to WS Commons Policy 1.0
[ http://issues.apache.org/jira/browse/TUSCANY-134?page=all ] Jeremy Boynes reassigned TUSCANY-134: - Assign To: Rick Rineholt Assigning to Rick as he provided the SNAPSHOT we are using Upgrade to WS Commons Policy 1.0 Key: TUSCANY-134 URL: http://issues.apache.org/jira/browse/TUSCANY-134 Project: Tuscany Type: Task Components: Java SCA Axis Integration Reporter: Jeremy Boynes Assignee: Rick Rineholt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-135) Samples setup is wrong on website
Samples setup is wrong on website - Key: TUSCANY-135 URL: http://issues.apache.org/jira/browse/TUSCANY-135 Project: Tuscany Type: Bug Components: Website Reporter: Jeremy Boynes Assigned to: Rick Rineholt I have been told the directions here don't work any more: http://incubator.apache.org/tuscany/samples/java/readme.htm I have not had a chance to try them yet but didn't want to lose the issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-127) Fix for spec eclipse warnings
[ http://issues.apache.org/jira/browse/TUSCANY-127?page=all ] Jeremy Boynes reassigned TUSCANY-127: - Assign To: Jeremy Boynes Fix for spec eclipse warnings --- Key: TUSCANY-127 URL: http://issues.apache.org/jira/browse/TUSCANY-127 Project: Tuscany Type: Improvement Components: Java Spec APIs Reporter: Daniel Kulp Assignee: Jeremy Boynes Priority: Minor Attachments: spec.patch Minor changes to fix all the compiler warnings in eclipse for all of spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
[ http://issues.apache.org/jira/browse/TUSCANY-118?page=comments#action_12371116 ] Jeremy Boynes commented on TUSCANY-118: --- I assume having the SDO API depend on the StAX API would not be a problem? There should perhaps in a StaxHelper interface that would mean that the dependency was only triggered by people using StAX. Our SDO implementation should depend only on having an implementation of StAX available. Perhaps having the user pass the XMLStreamReader/XMLStreamWriter in the API would be sufficient. I think this is better than having a load(URL) type method that requires the implementation discover a StAX implementation. If the only dependency on AXIOM is for testing then we can just inlcude it as a test depdency and it would never impact a distribution. If we are proving a helper for reading/writing an AXIOM model then it should be isolated to the AXIOM helper class itself so the only users that need to provide that dependency are the ones using AXIOM. Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration --- Key: TUSCANY-118 URL: http://issues.apache.org/jira/browse/TUSCANY-118 Project: Tuscany Type: Improvement Components: Java SCA Axis Integration, Java SDO Implementation Reporter: Raymond Feng Attachments: rfeng_stax.diff, rfeng_stax_axis_095.diff Here are the key classes: 1) DataObjectStAXWrapper Implements org.apache.axis2.databinding.ADBBean interface by feeding elements and attibutes to org.apache.axis2.databinding.utils.ADBPullParser. It can be used as a Serializer for DataObject to be serialized as OMElement. 2) StAXXMLResourceImpl and StAX2SAXAdapter StAXXMLResourceImpl extends org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl to provide additional methods to load DataObject directly from XMLStreamReader. StAX2SAXAdpter is responsible to pull StAX events from XMLSreamReader and generate SAX events so that they can be consumed by XMLResourceImpl. 3) DataObjectStAXWrapperTestCase It tests the round trip for DataObject -- OMElment -- DataObject. Both static SDO model (pre-generated) and dynamic SDO model (loaded from WSDL/XSD) are covered. It also test the cost of the optimized roundtrip against the old quick and dirty way (DataObject -- OutputStream -- InputStream -- OMElement -- OutputStream -- InputStream -- DataObject). It shows more that 400% performance gain. It seems that files in set 1 and 2 are more fit to be included in the SDO sub-project. The following helper method is desirable. void SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object options) XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument document, Object options) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-117) HTTP Status not set by Axis2 servlet
[ http://issues.apache.org/jira/browse/TUSCANY-117?page=all ] Jeremy Boynes closed TUSCANY-117: - Resolution: Invalid Closing this as Invalid as this is probably an Axis2 issue. Added a workaround to the itest by having it default the status to 200 as the Coyote connector does. HTTP Status not set by Axis2 servlet Key: TUSCANY-117 URL: http://issues.apache.org/jira/browse/TUSCANY-117 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: Jeremy Boynes Assignee: Rick Rineholt The HttpResponse status code is not set by the Axis2 servlet so is returned as 0 rather than 200 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-117) HTTP Status not set by Axis2 servlet
HTTP Status not set by Axis2 servlet Key: TUSCANY-117 URL: http://issues.apache.org/jira/browse/TUSCANY-117 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: Jeremy Boynes The HttpResponse status code is not set by the Axis2 servlet so is returned as 0 rather than 200 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-67) ClassLoader issues with SDO
ClassLoader issues with SDO --- Key: TUSCANY-67 URL: http://issues.apache.org/jira/browse/TUSCANY-67 Project: Tuscany Type: Bug Components: Java Spec APIs, Java SDO Implementation Reporter: Jeremy Boynes The SDO spec makes extensive use of INSTANCE static fields on the helper interfaces which results in a solution that is complex to use and error prone in any environment where more than one ClassLoader is involved. We should work with the spec group to formulate a model that is easier for people to use in today's more complex environments (including build frameworks like Maven and Ant, IDE environments like Eclipse, server environments like Tomcat and Geronimo, application frameworks like Spring, etc. etc.). I will open a sub-task specfically for this. We should also ensure that the Tuscany implementation of SDO is easy to use in these environments irrespective of what the spec says. We need to define a set of APIs that make it easy to handle multiple type spaces in the same JVM and/or ClassLoader without requiring the user to play tricks with the Thread's context classloader (which they may not even have permission to do). We should also ensure any usage of SDO by the SCA runtime uses these APIs, reserving the default SDO type space for user applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-69) Provide an extension API in Tucany's SDO implementation to support environments with multiple classloaders
[ http://issues.apache.org/jira/browse/TUSCANY-69?page=all ] Jeremy Boynes updated TUSCANY-69: - Component: Java SDO Implementation Description: Provide a documented API in Tuscany's SDO implementation that provides an interface to SDO for applications that utilize multiple classloaders. Remove any implicit assumptions on the Thread context ClassLoader. (was: ) Provide an extension API in Tucany's SDO implementation to support environments with multiple classloaders -- Key: TUSCANY-69 URL: http://issues.apache.org/jira/browse/TUSCANY-69 Project: Tuscany Type: Sub-task Components: Java SDO Implementation Reporter: Jeremy Boynes Provide a documented API in Tuscany's SDO implementation that provides an interface to SDO for applications that utilize multiple classloaders. Remove any implicit assumptions on the Thread context ClassLoader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-66) WebServiceEntryPointServlet doesn't popluate all the WS entry points into the Axis2 service registry (It only handles the 1st module)
[ http://issues.apache.org/jira/browse/TUSCANY-66?page=comments#action_12368896 ] Jeremy Boynes commented on TUSCANY-66: -- Patch applied - the build works but I have not run the sample code In a separate change I did an extensive reformat and clean up on that class to fix the warnings, inconsistent code styles etc. The functionality should be the same but I may have goofed. The reason mention this is that if you do run into problems it would be appreciated if you could supply any new patches against the reformatted version WebServiceEntryPointServlet doesn't popluate all the WS entry points into the Axis2 service registry (It only handles the 1st module) - Key: TUSCANY-66 URL: http://issues.apache.org/jira/browse/TUSCANY-66 Project: Tuscany Type: Bug Environment: Windows XP Reporter: Raymond Feng Priority: Blocker Attachments: rfeng.diff, rfeng1.diff Caused by: java.lang.Exception: org.apache.axis2.AxisFault: AxisService Not found yet at org.apache.axis2.engine.InstanceDispatcher.fillContextsFromSessionContext(InstanceDispatcher.java:99) at org.apache.axis2.engine.InstanceDispatcher.invoke(InstanceDispatcher.java:56) at org.apache.axis2.engine.Phase.invoke(Phase.java:376) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:351) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:322) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:274) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doPost(WebServiceEntryPointServlet.java:179) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
