[jira] Created: (TUSCANY-1612) 0.99 Binary distribution have duplicated stax dependency
0.99 Binary distribution have duplicated stax dependency Key: TUSCANY-1612 URL: https://issues.apache.org/jira/browse/TUSCANY-1612 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Fix For: Java-SCA-0.99 Binary distribution have : - stax-api-1.0.1.jar - stax-api-1.0-2.jar I'm not sure if this is really a problem, but I'm raising the issue -- 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-1611) 0.99 Binary distribution have wrong version of wstx-asf dependency
[ https://issues.apache.org/jira/browse/TUSCANY-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1611: - Component/s: Build System 0.99 Binary distribution have wrong version of wstx-asf dependency -- Key: TUSCANY-1611 URL: https://issues.apache.org/jira/browse/TUSCANY-1611 Project: Tuscany Issue Type: Bug Components: Build System, Java SCA Samples Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Fix For: Java-SCA-0.99 Even though project poms have declared the following : dependency groupIdorg.codehaus.woodstox/groupId artifactIdwstx-asl/artifactId version3.2.1/version scoperuntime/scope /dependency The binary distro have wstx-asl-3.2.0.jar This cause the webapp sample ant script to generate wrong ant file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1575) helloworlds-jsonrpc ant build produces wrong war file... cannot run (using .99 snapshot from 8/23)
[ https://issues.apache.org/jira/browse/TUSCANY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1575: Assignee: Luciano Resende helloworlds-jsonrpc ant build produces wrong war file... cannot run (using .99 snapshot from 8/23) --- Key: TUSCANY-1575 URL: https://issues.apache.org/jira/browse/TUSCANY-1575 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: windows Reporter: haleh mahbod Assignee: Luciano Resende Fix For: Java-SCA-0.99 The fix on jsonrpc sample got me further to the ant build (Thanks Ant for the fix). Using mvn I am able to get a good war file that I can run. Using ant build, I get an incorrect War file although ant output says it built successfully. This seems to be a general problem for all the webapp samples. I am creating this jira to make it clear that this sample also has a problem with ant build. -- 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-1575) helloworlds-jsonrpc ant build produces wrong war file... cannot run (using .99 snapshot from 8/23)
[ https://issues.apache.org/jira/browse/TUSCANY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522679 ] Luciano Resende commented on TUSCANY-1575: -- The ant script for this sample has not been updated and still reference 0.91 dependencies. Working on this. helloworlds-jsonrpc ant build produces wrong war file... cannot run (using .99 snapshot from 8/23) --- Key: TUSCANY-1575 URL: https://issues.apache.org/jira/browse/TUSCANY-1575 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: windows Reporter: haleh mahbod Assignee: Luciano Resende Fix For: Java-SCA-0.99 The fix on jsonrpc sample got me further to the ant build (Thanks Ant for the fix). Using mvn I am able to get a good war file that I can run. Using ant build, I get an incorrect War file although ant output says it built successfully. This seems to be a general problem for all the webapp samples. I am creating this jira to make it clear that this sample also has a problem with ant build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1607) java2wsdl and wsdl2java missing from binary distro
[ https://issues.apache.org/jira/browse/TUSCANY-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1607: Assignee: Luciano Resende java2wsdl and wsdl2java missing from binary distro -- Key: TUSCANY-1607 URL: https://issues.apache.org/jira/browse/TUSCANY-1607 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-0.99 Environment: Windows XP Reporter: Simon Nash Assignee: Luciano Resende Priority: Critical Fix For: Java-SCA-0.99 I don't see Tuscany's java2wsdl and wsdl2java in the 0.99 binary distro. I think these should be included. -- 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-1607) java2wsdl and wsdl2java missing from binary distro
[ https://issues.apache.org/jira/browse/TUSCANY-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522685 ] Luciano Resende commented on TUSCANY-1607: -- This should be in the 0.99 release java2wsdl and wsdl2java missing from binary distro -- Key: TUSCANY-1607 URL: https://issues.apache.org/jira/browse/TUSCANY-1607 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-0.99 Environment: Windows XP Reporter: Simon Nash Assignee: Luciano Resende Priority: Critical Fix For: Java-SCA-0.99 I don't see Tuscany's java2wsdl and wsdl2java in the 0.99 binary distro. I think these should be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1575) helloworlds-jsonrpc ant build produces wrong war file... cannot run (using .99 snapshot from 8/23)
[ https://issues.apache.org/jira/browse/TUSCANY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1575. -- Resolution: Fixed Fixed in 0.99 branch and trunk helloworlds-jsonrpc ant build produces wrong war file... cannot run (using .99 snapshot from 8/23) --- Key: TUSCANY-1575 URL: https://issues.apache.org/jira/browse/TUSCANY-1575 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: windows Reporter: haleh mahbod Assignee: Luciano Resende Fix For: Java-SCA-0.99 The fix on jsonrpc sample got me further to the ant build (Thanks Ant for the fix). Using mvn I am able to get a good war file that I can run. Using ant build, I get an incorrect War file although ant output says it built successfully. This seems to be a general problem for all the webapp samples. I am creating this jira to make it clear that this sample also has a problem with ant build. -- 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-1614) Calculator-webapp-ws ant build produce invalid war file
Calculator-webapp-ws ant build produce invalid war file --- Key: TUSCANY-1614 URL: https://issues.apache.org/jira/browse/TUSCANY-1614 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-0.99 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1614) Calculator-webapp-ws ant build produce invalid war file
[ https://issues.apache.org/jira/browse/TUSCANY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1614. -- Resolution: Fixed Fixed. Ant script updated in both 0.99 branch and trunk Calculator-webapp-ws ant build produce invalid war file --- Key: TUSCANY-1614 URL: https://issues.apache.org/jira/browse/TUSCANY-1614 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-0.99 -- 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-1615) chat-webapp sample not working
chat-webapp sample not working --- Key: TUSCANY-1615 URL: https://issues.apache.org/jira/browse/TUSCANY-1615 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Fix For: Java-SCA-0.99 UI displays ok, but when you try to send message it does not work. Here what you can find on the Tomcat logs. java.lang.NoClassDefFoundError: commonj/sdo/DataObject at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.clinit(SDODataBinding.java:46) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.getDataBinding(DefaultDataBindingExtensionPoint.java:146) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:182) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:221) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:193) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:98) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:57) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:81) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:150) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:64) at org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72) at org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:116) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:405) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63) at org.apache.tuscany.sca.host.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211
[jira] Updated: (TUSCANY-1615) chat-webapp sample not working
[ https://issues.apache.org/jira/browse/TUSCANY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1615: - Similar behavior with ant and maven builds chat-webapp sample not working --- Key: TUSCANY-1615 URL: https://issues.apache.org/jira/browse/TUSCANY-1615 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Fix For: Java-SCA-0.99 UI displays ok, but when you try to send message it does not work. Here what you can find on the Tomcat logs. java.lang.NoClassDefFoundError: commonj/sdo/DataObject at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.clinit(SDODataBinding.java:46) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.getDataBinding(DefaultDataBindingExtensionPoint.java:146) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:182) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:221) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:193) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:98) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:57) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:81) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:150) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:64) at org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72) at org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:116) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:405) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63
[jira] Assigned: (TUSCANY-1615) chat-webapp sample not working
[ https://issues.apache.org/jira/browse/TUSCANY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1615: Assignee: Luciano Resende chat-webapp sample not working --- Key: TUSCANY-1615 URL: https://issues.apache.org/jira/browse/TUSCANY-1615 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-0.99 UI displays ok, but when you try to send message it does not work. Here what you can find on the Tomcat logs. java.lang.NoClassDefFoundError: commonj/sdo/DataObject at org.apache.tuscany.sca.databinding.sdo.SDODataBinding.clinit(SDODataBinding.java:46) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.getDataBinding(DefaultDataBindingExtensionPoint.java:146) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:182) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:221) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:193) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:98) at org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:57) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:81) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:150) at org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:64) at org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72) at org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:116) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:211) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:405) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:673) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:68) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:83) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:392) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:319) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:117) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63
[jira] Resolved: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
[ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1053. -- Resolution: Fixed Check discussion thread for discussion on aprach taken http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21946.html Done under revision #568830 Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: Luciano Resende Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1108) SDO Wsdl tooling does not handle exceptions
[
https://issues.apache.org/jira/browse/TUSCANY-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende reassigned TUSCANY-1108:
Assignee: Luciano Resende
SDO Wsdl tooling does not handle exceptions
---
Key: TUSCANY-1108
URL: https://issues.apache.org/jira/browse/TUSCANY-1108
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-SCA-M2
Reporter: Rick Rineholt
Assignee: Luciano Resende
Fix For: Java-SCA-Next
Attachments: mvn.out, pom.xml, StockExceptionTest.wsdl
Using tuscany maven plugin tuscany-plugin-wsdl2java an exception is generated
for the attached wsdl. Note removing exceptions in the wsdl avoids the
UnmatchedTypeException This maybe due to the sdo generation producing the
fault not as an exception?
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in your
local
repository will be inaccessible.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Test Suite Exception Handling cross bindings
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
E:\dev\tuscany\branches\sca-java-integration\testing\sca\itest\exceptionXbindingTest\target
[INFO] [tuscany-sdo:generate {execution: default}]
[INFO] Generating SDO interfaces from
E:\dev\tuscany\branches\sca-java-integration\testing\sca\itest\exceptionXbindingTest\src\main\resources\wsdl\StockExceptionTest.wsdl
Generating code
Generating packages
Generating package ScatesttoolPackageImpl
Generating Java interface
stockexceptiontestservice.scatesttool.ScatesttoolFactory
Generating
/TargetProject/stockexceptiontestservice/scatesttool/ScatesttoolFactory.java
Generating Java class
stockexceptiontestservice.scatesttool.impl.ScatesttoolFactoryImpl
Generating
/TargetProject/stockexceptiontestservice/scatesttool/impl/ScatesttoolFactoryImpl.java
Generating Invalid Symbol Fault
Generating Java interface
stockexceptiontestservice.scatesttool.InvalidSymbolFault
Generating
/TargetProject/stockexceptiontestservice/scatesttool/InvalidSymbolFault.java
Generating Java class
stockexceptiontestservice.scatesttool.impl.InvalidSymbolFaultImpl
Generating
/TargetProject/stockexceptiontestservice/scatesttool/impl/InvalidSymbolFaultImpl.java
Generating Market Closed Fault
Generating Java interface
stockexceptiontestservice.scatesttool.MarketClosedFault
Generating
/TargetProject/stockexceptiontestservice/scatesttool/MarketClosedFault.java
Generating Java class
stockexceptiontestservice.scatesttool.impl.MarketClosedFaultImpl
Generating
/TargetProject/stockexceptiontestservice/scatesttool/impl/MarketClosedFaultImpl.java
Generating Stock Offer
Generating Java interface stockexceptiontestservice.scatesttool.StockOffer
Generating
/TargetProject/stockexceptiontestservice/scatesttool/StockOffer.java
Generating Java class
stockexceptiontestservice.scatesttool.impl.StockOfferImpl
Generating
/TargetProject/stockexceptiontestservice/scatesttool/impl/StockOfferImpl.java
Generating stock Quote Offer
Generating Java interface
stockexceptiontestservice.scatesttool.stockQuoteOffer
Generating
/TargetProject/stockexceptiontestservice/scatesttool/stockQuoteOffer.java
Generating Java class
stockexceptiontestservice.scatesttool.impl.stockQuoteOfferImpl
Generating
/TargetProject/stockexceptiontestservice/scatesttool/impl/stockQuoteOfferImpl.java
Generating stock Quote Offer Response
Generating Java interface
stockexceptiontestservice.scatesttool.stockQuoteOfferResponse
Generating
/TargetProject/stockexceptiontestservice/scatesttool/stockQuoteOfferResponse.java
Generating Java class
stockexceptiontestservice.scatesttool.impl.stockQuoteOfferResponseImpl
Generating
/TargetProject/stockexceptiontestservice/scatesttool/impl/stockQuoteOfferResponseImpl.java
[INFO] [tuscanywsdl2java:generate {execution: default}]
[INFO] Generating Java service interfaces from
E:\dev\tuscany\branches\sca-java-integration\testing\sca\itest\exceptionXbindingTest\src\main\resources\wsdl\StockExceptionTest.wsdl
log4j:WARN No appenders could be found for logger
(org.apache.axis2.i18n.ProjectResourceBundle).
log4j:WARN Please initialize the log4j system properly.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException:
org.apache.axis2
Re: SCA distribution is really big now
Simon Nash wrote: I think option 1 for 0.99 is the best (and safest) that we can do in the time available. +1 On 8/23/07, Simon Nash [EMAIL PROTECTED] wrote: I think option 1 for 0.99 is the best (and safest) that we can do in the time available. So +1 for the 0.99 part. I need to give more thought to 1.0. Simon Simon Laws wrote: On 8/23/07, ant elder [EMAIL PROTECTED] wrote: On 8/23/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/23/07, haleh mahbod [EMAIL PROTECTED] wrote: I moved all the jars from calculator-webapp to tomcat/lib. calculator-webapp runs fine. What else is there that might cause a problem? Haleh On 8/23/07, ant elder [EMAIL PROTECTED] wrote: On 8/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'll start a different thread to discuss the more long term support for implementation.web. For now, comments inline to cover the immediate WAR size issue for the 0.99 release. Simon Laws wrote: [snip] 1 - what is in the war that is build from these samples - currently all of the tuscany jars required [snip] Doing 1 is a relatively straightforward exercise of refactoring the current war into a slimmed down version. I'm still not convinced that it's a good idea to remove the webapp samples and compress everything into a small number of samples I think we should just document how to copy the required JARs to the Tomcat lib folder and run the stripped down WARs this way, assuming that it works. The problem is likely to be the assuming that it works as last time i tried this it didn't - there's various classloader issues. Changing to use deep integration like we used to also seems like quite a big change to be doing just moments before we cut a release so could we at least postpone looking at that till after this release? For this release I think I'm in favour of just picking a few samples and demos to not ship pre-built and documenting that in their README's as it seems like the most minimal change. ...ant I've been having a bit of a play with this and it's not straighforward to get this to happen in a nice way at the moment. What I was trying to do was knock all of the tuscany jars out of the war and have the deployment of the tuscany jar be a manual step. For some (classloader) reason the it seems to be a bit of an all or nothing, i.e. you have to have all of jars that were orignally in WEB-INF/lib in tomcat/lib or have them all in the web itself. What I wanted to do was package the non tuscany dependencies in the war to reduce the amount of manual picking required when applying tuscany jars to tomcat, i.e. I was prepared to go with copy all of the modules knocking out jetty, tomcat etc. Some options at the moment given where we are 1/ Just fix build.xml for each sample so that the wars can be built as is and we don;t have to ship them. 2/ Variation on 1 - Fix and change the build.xml to build a minimal war and alongside that build either a directory or a zip of all the jars that need to be dropped into tomcat/lib to get the sample to work. 2/ create the minimal war and give detailed manual instructions about which jars to pick out of the distro Anyone else have any other ideas. I worry we'd not get anything other than 1/ done by tomorrow and even then the READMEs etc would have bugs. So my preference would be for 0.99 do 1/ for the big webapps but keep the small prebuilt ones. The big ones are: demo-allert-aggregator.war demo-mortgage-creditcheck.war sample-helloworld-ws-sdo-webapp.war sample-helloworld-ws-service-webapp.war sample-calculator-webapp-ws.war Thats minimum changes to what we have today, just 5 readme updates, and gives a distro size of less the 60Meg. For 1.0 do: - change samples to be simple contribution jar's that can work in all of standalone, webapp distro, Geronimo - maybe keep one existing webapp sample to demonstrate that style of packaging - fix the ClassLoader issues so that Tomcat deep integration works well and have a sample/documentation for deep integration That should give a 1.0 distro size of less than 50Meg. Note also, i'd like to cut the 0.99 branch and create RC1 in about 9 hours so if anyone wants to go for something other than this for 0.99 thats fine by me but it needs to start getting done pretty smartly :) ...ant Ok, +1 for 1 given the time we have. I have to go and get some sleep. But can do some of this first thing. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com
[jira] Updated: (TUSCANY-1567) NPE when hosting calculator-webapp sample under Tomcat when the Tomcat install path contains spaces.
[ https://issues.apache.org/jira/browse/TUSCANY-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1567: - Affects Version/s: Java-SCA-Next Java-SCA-0.99 NPE when hosting calculator-webapp sample under Tomcat when the Tomcat install path contains spaces. -- Key: TUSCANY-1567 URL: https://issues.apache.org/jira/browse/TUSCANY-1567 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: MS windows Vista. Tomcat 6.0.13/jvm 1.5.0_11-b03 java/sca source revision 568049 Reporter: Steve Jones Fix For: Java-SCA-0.99 Running Tuscany calculator-webapp sample under Tomcat. If Tomcat is installed in its default install folder: C:\Program Files\Apache Software Foundation\Tomcat 6.0 A NPE occurs when the samples calc.jsp page is served. Reinstalling Tomcat in: D:\tomcat\tomcat60\ Fixes the problem Cheers. Tomcat log file: SEVERE: exception initializing SCADomain org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: java.lang.IllegalArgumentException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63) at org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4334) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:566) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.IllegalArgumentException at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) ... 27 more Caused by: java.lang.IllegalArgumentException at java.net.URI.create(Unknown Source) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getContributionLocation(DefaultSCADomain.java:246) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:103) ... 28 more Caused by: java.net.URISyntaxException: Illegal character in path at index 16: file:/C:/Program Files/Apache Software Foundation/Tomcat 6.0/webapps/sample-calculator-webapp/ at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.init(Unknown Source) ... 31 more 21-Aug-2007 12
[jira] Resolved: (TUSCANY-1567) NPE when hosting calculator-webapp sample under Tomcat when the Tomcat install path contains spaces.
[ https://issues.apache.org/jira/browse/TUSCANY-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1567. -- Resolution: Fixed Fixed by encoding spaces in contribution URL NPE when hosting calculator-webapp sample under Tomcat when the Tomcat install path contains spaces. -- Key: TUSCANY-1567 URL: https://issues.apache.org/jira/browse/TUSCANY-1567 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: MS windows Vista. Tomcat 6.0.13/jvm 1.5.0_11-b03 java/sca source revision 568049 Reporter: Steve Jones Assignee: Luciano Resende Fix For: Java-SCA-0.99 Running Tuscany calculator-webapp sample under Tomcat. If Tomcat is installed in its default install folder: C:\Program Files\Apache Software Foundation\Tomcat 6.0 A NPE occurs when the samples calc.jsp page is served. Reinstalling Tomcat in: D:\tomcat\tomcat60\ Fixes the problem Cheers. Tomcat log file: SEVERE: exception initializing SCADomain org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: java.lang.IllegalArgumentException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63) at org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4334) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:566) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.IllegalArgumentException at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) ... 27 more Caused by: java.lang.IllegalArgumentException at java.net.URI.create(Unknown Source) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getContributionLocation(DefaultSCADomain.java:246) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:103) ... 28 more Caused by: java.net.URISyntaxException: Illegal character in path at index 16: file:/C:/Program Files/Apache Software Foundation/Tomcat 6.0/webapps/sample-calculator-webapp/ at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.init(Unknown Source
[jira] Updated: (TUSCANY-1576) exception trace for helloworld-ws-sdo using .99 snapshot, 8-23 version
[ https://issues.apache.org/jira/browse/TUSCANY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1576: - Assignee: (was: Luciano Resende) exception trace for helloworld-ws-sdo using .99 snapshot, 8-23 version Key: TUSCANY-1576 URL: https://issues.apache.org/jira/browse/TUSCANY-1576 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: windows Reporter: haleh mahbod Priority: Critical Fix For: Java-SCA-0.99 First, the readme for this sample is incorrect. It is for helloworld-ws-reference and helloworld-ws-service. I'l try to give a patch for that in a separate JIRA. Here is what I did for ant following other Sample's examples: ant ant compile ant run I get the following exception: Total time: 5 seconds C:\tuscany-new\sca-dist\tuscany-sca-1.0-incubating-SNAPSHOT\samples\helloworld-w s-sdoant run Buildfile: build.xml run: [java] log4j:WARN No appenders could be found for logger (org.apache.axiom. om.util.StAXUtils). [java] log4j:WARN Please initialize the log4j system properly. [java] Injected helloWorldService [java] Called getGreetings [java] Exception in thread main java.lang.reflect.UndeclaredThrowableExce ption [java] at $Proxy5.getGreetings(Unknown Source) [java] at helloworld.HelloWorldServiceComponent.getGreetings(HelloWorld ServiceComponent.java:30) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:585) [java] at org.apache.tuscany.sca.implementation.java.invocation.JavaImp lementationInvoker.invoke(JavaImplementationInvoker.java:91) [java] at org.apache.tuscany.sca.implementation.java.invocation.PassByV alueInvoker.invoke(PassByValueInvoker.java:62) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvo ker.invoke(RuntimeSCABindingInvoker.java:48) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:236) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:93) [java] at $Proxy5.getGreetings(Unknown Source) [java] at helloworld.HelloWorldClient.main(HelloWorldClient.java:39) [java] Caused by: org.apache.axis2.AxisFault: Connection refused: connect [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.in voke(CommonsHTTPTransportSender.java:221) [java] at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) [java] at org.apache.axis2.description.OutInAxisOperationClient.send(Ou tInAxisOperation.java:330) [java] at org.apache.axis2.description.OutInAxisOperationClient.execute (OutInAxisOperation.java:294) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.i nvokeTarget(Axis2BindingInvoker.java:87) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.i nvoke(Axis2BindingInvoker.java:67) [java] at org.apache.tuscany.sca.core.databinding.wire.DataTransformati onInteceptor.invoke(DataTransformationInteceptor.java:68) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:236) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:93) [java] ... 13 more [java] Caused by: org.apache.axis2.AxisFault: Connection refused: connect [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.wr iteMessageWithCommons(CommonsHTTPTransportSender.java:314) [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.in voke(CommonsHTTPTransportSender.java:201) [java] ... 21 more [java] Caused by: org.apache.axis2.AxisFault: Connection refused: connect [java] at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSe nder.java:179) [java] at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.ja va:73) [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.wr iteMessageWithCommons(CommonsHTTPTransportSender.java:305) [java] ... 22 more [java] Caused by: java.net.ConnectException: Connection refused: connect [java
[jira] Assigned: (TUSCANY-1576) exception trace for helloworld-ws-sdo using .99 snapshot, 8-23 version
[ https://issues.apache.org/jira/browse/TUSCANY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1576: Assignee: Luciano Resende exception trace for helloworld-ws-sdo using .99 snapshot, 8-23 version Key: TUSCANY-1576 URL: https://issues.apache.org/jira/browse/TUSCANY-1576 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: windows Reporter: haleh mahbod Assignee: Luciano Resende Priority: Critical Fix For: Java-SCA-0.99 First, the readme for this sample is incorrect. It is for helloworld-ws-reference and helloworld-ws-service. I'l try to give a patch for that in a separate JIRA. Here is what I did for ant following other Sample's examples: ant ant compile ant run I get the following exception: Total time: 5 seconds C:\tuscany-new\sca-dist\tuscany-sca-1.0-incubating-SNAPSHOT\samples\helloworld-w s-sdoant run Buildfile: build.xml run: [java] log4j:WARN No appenders could be found for logger (org.apache.axiom. om.util.StAXUtils). [java] log4j:WARN Please initialize the log4j system properly. [java] Injected helloWorldService [java] Called getGreetings [java] Exception in thread main java.lang.reflect.UndeclaredThrowableExce ption [java] at $Proxy5.getGreetings(Unknown Source) [java] at helloworld.HelloWorldServiceComponent.getGreetings(HelloWorld ServiceComponent.java:30) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:585) [java] at org.apache.tuscany.sca.implementation.java.invocation.JavaImp lementationInvoker.invoke(JavaImplementationInvoker.java:91) [java] at org.apache.tuscany.sca.implementation.java.invocation.PassByV alueInvoker.invoke(PassByValueInvoker.java:62) [java] at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvo ker.invoke(RuntimeSCABindingInvoker.java:48) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:236) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:93) [java] at $Proxy5.getGreetings(Unknown Source) [java] at helloworld.HelloWorldClient.main(HelloWorldClient.java:39) [java] Caused by: org.apache.axis2.AxisFault: Connection refused: connect [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.in voke(CommonsHTTPTransportSender.java:221) [java] at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) [java] at org.apache.axis2.description.OutInAxisOperationClient.send(Ou tInAxisOperation.java:330) [java] at org.apache.axis2.description.OutInAxisOperationClient.execute (OutInAxisOperation.java:294) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.i nvokeTarget(Axis2BindingInvoker.java:87) [java] at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.i nvoke(Axis2BindingInvoker.java:67) [java] at org.apache.tuscany.sca.core.databinding.wire.DataTransformati onInteceptor.invoke(DataTransformationInteceptor.java:68) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:236) [java] at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i nvoke(JDKInvocationHandler.java:93) [java] ... 13 more [java] Caused by: org.apache.axis2.AxisFault: Connection refused: connect [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.wr iteMessageWithCommons(CommonsHTTPTransportSender.java:314) [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.in voke(CommonsHTTPTransportSender.java:201) [java] ... 21 more [java] Caused by: org.apache.axis2.AxisFault: Connection refused: connect [java] at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSe nder.java:179) [java] at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.ja va:73) [java] at org.apache.axis2.transport.http.CommonsHTTPTransportSender.wr iteMessageWithCommons(CommonsHTTPTransportSender.java:305) [java] ... 22 more [java] Caused by: java.net.ConnectException: Connection refused: connect [java
[ANNOUNCE] Apache Tuscany Java DAS 1.0-incubating-beta1 released
August 21st 2007 - Apache Tuscany is pleased to announce the 1.0-incubating-beta1 release of the Java DAS project. Data Access Services (DAS) works together with Service Data Objects (SDO) simplifying handling of data when interacting with the back-end data source and frees application developers from dealing with tedious and error-prone transformation between end source types and SDO Data Object Types/properties. Key features of 1.0-incubating-beta1 release are : - Support for J2SE connections in DAS config using Driver Manager. - Added support for multiple database schemas in queries - Enhanced Optimistic Concurrency Control with overqualified updates - Multiple enhancements around ApplyChanges API - Enhanced Documentation : User, Developer and Architect guides as well as javadocs - Enhanced and new sample applications For a complete list of changes on this release, please view the release notes. https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1/distribution/binary/RELEASE_NOTES To download Java DAS please follow the link to http://incubator.apache.org/tuscany/das-downloads.html Apache Tuscany welcomes your help. Any contribution, including code, testing, improving the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany. Thank you for your interest in Apache Tuscany! The Apache Tuscany Team. --- Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] What's next for Tuscany DAS ?
With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question on extension-helper and how to register extensions with specific QNames
I'm updating all Tuscany extensions that are non-spec'd to use a Tuscany namespace, and with this, some bindings or component types will be registered with the SCA 1.0 namespace (e.g binding-ejb) but others will use the Tuscany extension namespace (e.g binding-dwr). In this case, and mainly when they are both implemented using Tuscany extension-helper, how I can use a specific QName for a tuscany binding or component type, and avoid using the default one ? Do we have any support for this today ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on extension-helper and how to register extensions with specific QNames
Well, i gave it a try, and I was able to get further by creating and registering a new module activator that extended BindingsActivator and overriding the getBindingQName method. On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm updating all Tuscany extensions that are non-spec'd to use a Tuscany namespace, and with this, some bindings or component types will be registered with the SCA 1.0 namespace (e.g binding-ejb) but others will use the Tuscany extension namespace (e.g binding-dwr). In this case, and mainly when they are both implemented using Tuscany extension-helper, how I can use a specific QName for a tuscany binding or component type, and avoid using the default one ? Do we have any support for this today ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Done under revision #568830 On 8/22/07, Mike Edwards [EMAIL PROTECTED] wrote: Jean-Sebastien, Jean-Sebastien Delfino wrote: snip Looks like option (B) is the most preferred option with: - one -1 - five +1 - one more spec compliant Do we need more technical discussion? or a new [VOTE] thread to close this issue? Thanks for a great summary. I'm happy with the conclusion. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Welcome Brady !!! On 8/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, Welcome Brady! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
a namespace since I think it is not extensible, unlike SCA which allows all kinds of extension. PS 2 If anyone can think of a better way for SCA to handle its extensibility, that will allow us to drop namespaces, the spec team will be all ears. The spec group debated the use of namespaces at some length before adopting the current spec definition (and I was one of those trying to keep namespaces out of it). No more technical comments on this thread today... So here's a summary of what people have said so far. - Ant: A) +1 B) -1 on only doing B C) - Luciano: A) B) more spec compliant C) - Mike: A) -1, B) +1 C) +0.5 if we do B - Raymond: A) -0.5 B) +1 C) -0.5 - Sebastien: A) +0.5 B) +1 C) proposed in addition to B - Simon: A) -1 B) +1 C) -1 if alone, -0.9 if we do B - Venkat: A) B) +1 C) Looks like option (B) is the most preferred option with: - one -1 - five +1 - one more spec compliant Do we need more technical discussion? or a new [VOTE] thread to close this issue? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
[ https://issues.apache.org/jira/browse/TUSCANY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1523. -- Resolution: Fixed Fixed (568218). We now support file names (file.composite) as well as file types as (.composite). The lookup order is first based on the file name, then on the file type. Enhance ArtifactProcessors to be registered for file names, as well as for file types - Key: TUSCANY-1523 URL: https://issues.apache.org/jira/browse/TUSCANY-1523 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Details on the following thread: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-313) Tuscany SCA and SDO plugins attempt to generate code on incorrect goals
[ https://issues.apache.org/jira/browse/TUSCANY-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende closed TUSCANY-313. --- Resolution: Won't Fix Fix Version/s: Java-SCA-Next I haven't heard anything on the thread discussing some scenarios on this issue. http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21839.html So, I'm closing this for now... feel free to re-open if you think we need to look further into this issue. Tuscany SCA and SDO plugins attempt to generate code on incorrect goals --- Key: TUSCANY-313 URL: https://issues.apache.org/jira/browse/TUSCANY-313 Project: Tuscany Issue Type: Bug Components: Java SCA Tools, Java SDO Tools Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SDO-Next, Java-SCA-Next The tuscany SCA and SDO plugins attempt to generate code on incorrect goals, for example the eclipse:eclipse goal. To reproduce the problem, from the tuscany/java directory do the following: mvn clean eclipse:eclipse The SCA and SDO maven plugins will generate Java interfaces for services and SDO classes. They shouldn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages
[ https://issues.apache.org/jira/browse/TUSCANY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-978. - Resolution: Fixed Fixed under revision #56750. Also added the attached wsdl in test case to validate the fix. Tuscany WSDL2Java can't handle WSDL fault messages -- Key: TUSCANY-978 URL: https://issues.apache.org/jira/browse/TUSCANY-978 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Environment: Tuscany Java-M2 and current trunk Reporter: Matthew Sykes Assignee: Luciano Resende Fix For: Java-SCA-Next Attachments: AccountService.wsdl I've been playing with the BigBank sample and have added a fault to the AccountService's withdraw operation. After changing the AccountService.wsdl (attached), the Tuscany WSDL2Java no longer works: [INFO] Generating Java service interfaces from /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account [INFO] [INFO] Trace java.lang.IllegalArgumentException: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) 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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242) ... 19 more Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement
Tuscany SCA and SDO plugins attempt to generate code on incorrect goals
Looking at TUSCANY-313, I was thinking about the use cases and expected behavior. case 1 - I'm a developer, building an application and I have some broken XSD. I probably just want to get my eclipse project generated so I can continue to work on my application. case 2 - I'm generating my eclipse project, and my application depend on the generated SDO, otherwise I'll get lot's of red x on eclipse and my code won't compile and work. So, in case1, i guess the developer won't really want the broken xsd to be processed, and a quick workaround would be to remove the broken xsd from the list of files to be processed on the project pom, but in case2, I guess the developer would benefit from having the static sdo generated when the eclipse:eclipse phase is processed. Based on this, I was thinking if we really want to change the current behavior. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release Tuscany Java DAS beta1 (RC4)
Release to vote Tuscany Java DAS beta1 has passed with 5 binding +1, 1 non-binding +1 and no -1s. Luciano Resende, Kevin Williams, Ant Elder, Adriano Crestani, Simon Laws, Amita Vadhavkar (non-binding) On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/16/07, Adriano Crestani [EMAIL PROTECTED] wrote: It seems ok for me, everything ran fine ; ) +1 Adriano Crestani On 8/15/07, ant elder [EMAIL PROTECTED] wrote: +1 ...ant On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano, I thought I would set up the DAS tests from the binary distro to make sure they play nice as I go through testing SCA samples. So this is very late +1 from me. The odd thing I found was that the sample urls in companyweb/readme.htm sample-ajax-das/readme.htm Don't work. So something for next time. I haven't gone in and fixed them as the url (http://localhost:8080/sample-companyweb-%7bversion%20tag%7d) looks strangely important. Are these htm pages generated from somewhere? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1546) Continuum build should be fixed to allocate enough heap space to Maven, 63M is not enough
[ https://issues.apache.org/jira/browse/TUSCANY-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1546: - I'm starting to see this issue on the regular local builds as well. Continuum build should be fixed to allocate enough heap space to Maven, 63M is not enough - Key: TUSCANY-1546 URL: https://issues.apache.org/jira/browse/TUSCANY-1546 Project: Tuscany Issue Type: Bug Components: Build System Reporter: Jean-Sebastien Delfino Priority: Critical Fix For: Java-SCA-Next [snip] [EMAIL PROTECTED] wrote: Online report : http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/381/buildId/257310 Build statistics: State: Failed [snip] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Java heap space [INFO] [INFO] Trace java.lang.OutOfMemoryError: Java heap space [INFO] [INFO] Total time: 29 minutes 48 seconds [INFO] Finished at: Wed Aug 15 02:00:26 PDT 2007 [INFO] Final Memory: 63M/63M [INFO] It looks like our nightly build is breaking with out of memory exceptions. Most of us are running with more than 63M allocated to Maven and are not running into this issue in our local builds. What needs to happen for the continuum build to allocate more than 63M heap to Maven as well? -- Jean-Sebastien -- 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]
Re: nullp when running binding-echo sample
I get an exception either from inside Eclipse IDE or from distribution using ant. Could you please create a jira for tracking this issue. On 8/20/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, I am running this sample from the distribution that I built based on the latest code. When I ran the sample following ant instructions, I get the following: C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo ant run Buildfile: build.xml run: [java] Returned message: foo [java] Echo reference = foo [java] Exception in thread main java.lang.NullPointerException [java] at echo.server.EchoServer.sendReceive(EchoServer.java:75) [java] at echo.EchoBindingClient.main(EchoBindingClient.java:44) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 1 second C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo I this a known problem that is being worked on? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nullp when running binding-echo sample
I fixed first :) You sent e-mail first :) On 8/20/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, It was fixed by Luciano a few minutes ago before I tried to check in the same fix :-). Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, August 20, 2007 9:44 PM Subject: Re: nullp when running binding-echo sample I get an exception either from inside Eclipse IDE or from distribution using ant. Could you please create a jira for tracking this issue. On 8/20/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, I am running this sample from the distribution that I built based on the latest code. When I ran the sample following ant instructions, I get the following: C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo ant run Buildfile: build.xml run: [java] Returned message: foo [java] Echo reference = foo [java] Exception in thread main java.lang.NullPointerException [java] at echo.server.EchoServer.sendReceive(EchoServer.java:75) [java] at echo.EchoBindingClient.main(EchoBindingClient.java:44) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 1 second C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo I this a known problem that is being worked on? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Sebastien wrote : IMO application developers shouldn't have to suffer from the complexity of XML... How about supporting composites without namespace declarations at all? I'm trying to understand all the proposals here, what would be the side effects of going with your proposal ? This seems like simple, and simple is good... On 8/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: The last comments have been in favour of keeping things as-is so how about just doing nothing and letting this thread die. ...ant Here are the last comments from the different people who contributed to this thread: - Mike, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21059.html - Luciano, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21068.html - Simon, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21106.html - Sebastien, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21113.html - Ant, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21117.html I don't see a consensus in favor of keeping things as-is in these comments. This has a significant impact on the programming model so IMO this JIRA issue needs a clear resolution. On 8/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/3/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Taking that line of thought and you hit the long thread associated with: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] which is what I was hoping to quietly ignore by just keeping everything in the one SCA namespace. ...ant On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: Wouldn't this cause breakage in the scenario that I described, where foo from Tuscany later turns into foo as part of SCA but with some differences? Any SCDLs written to just use plain foo would break when Tuscany steps up to support the SCA foo. Simon ant elder wrote: How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) I didn't really want to reopen this debate either but I didn't understand both of your last comments so I guess I'm going to have to ask some questions... Ant, what did you mean by having the Tuscany namespace extend the SCA one? I'm not actually sure, my xsd is a bit rusty, i vaguely thought there was a way to say something extend another namespace inheriting all the things from it, but a quick search for it now i cant find how to do that, is it not possible? snip And also give my opinion: +0.5 if people want to keep Tuscany extensions in the SCA namespace for now, hoping that they make it to the SCA spec XSDs at some point I'd be +1 on doing that. The easier we can make things for people trying out Tuscany the better IHMO. ...ant What's the conclusion here? I've seen different opinions from Mike, Simon, Luciano, Ant, myself. Do we need a vote to decide the next step? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Looks like option B is more spec compliant and more aligned to the XML namespaces usage rules. Should I give it a try ? On 8/19/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my opinion about the three options: 1) -0.5 on A) 2) +1 on B) 3) -0.5 on C) A) violates the SCA assembly spec. 2535 ... New interface types, implementation types and binding types that are defined using 2536 this extensibility model, which are not part of these SCA specifications must be defined in 2537 namespaces other than the SCA namespace. C) IMO, the composite file should conform to the XSD defined by the SCA spec. The example listed under C) is not a valid SCA composite definition. We can make the http://www.osoa.org/xmlns/sca/1.0; as the default namespace to avoid the repeating prefixes. B) is right usage of XML namespaces. Hopefully, the SCA tooling can help ease the XML namespace declarations. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, August 19, 2007 5:07 PM Subject: Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions Luciano Resende wrote: Sebastien wrote : IMO application developers shouldn't have to suffer from the complexity of XML... How about supporting composites without namespace declarations at all? I'm trying to understand all the proposals here, what would be the side effects of going with your proposal ? This seems like simple, and simple is good... Before getting into the side effects, here are three examples: [A] What we have right now, standard SCA extensions and tuscany extensions sharing the standard SCA namespace composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:bb=http://bigbank; name=BigBank component name=AccountServiceComponent service name=AccountService binding.jsonrpc uri=/AccountJSONService/ binding.ws wsdlElement=http://bigbank#wsdl.port(AccountService/AccountServiceSoap)/ binding.sca/ /service implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ reference name=calculatorService binding.rmi host=localhost port=8099 serviceName=CalculatorRMIService/ /reference reference name=stockQuoteService binding.ws wsdlElement=http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference property name=currencyEURO/property /component component name=AccountFeedComponent service name=Collection binding.rss uri=/rss/ binding.atom uri=/atom/ /service implementation.java class=bigbank.account.feed.AccountFeedImpl/ reference name=accountService target=AccountServiceComponent/ /component component name=AccountDataServiceComponent implementation.composite name=bb:AccountData/ /component component name=WebResourceComponent service name=Resource binding.resource uri=// /service implementation.resource location=web/ /component /composite (B) What IMO is a more correct use of XML namespaces, standard SCA extensions in the standard SCA namespace, and Tuscany extensions in a Tuscany namespace composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://incubator.apache.org/xmlns/tuscany/1.0; targetNamespace=http://bigbank; xmlns:bb=http://bigbank; name=BigBank component name=AccountServiceComponent service name=AccountService t:binding.jsonrpc uri=/AccountJSONService/ binding.ws wsdlElement=http://bigbank#wsdl.port(AccountService/AccountServiceSoap)/ binding.sca/ /service implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ reference name=calculatorService t:binding.rmi host=localhost port=8099 serviceName=CalculatorRMIService/ /reference reference name=stockQuoteService binding.ws wsdlElement=http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference property name=currencyEURO/property /component component name=AccountFeedComponent service name=Collection t:binding.rss uri=/rss/ t:binding.atom uri=/atom/ /service implementation.java class=bigbank.account.feed.AccountFeedImpl/ reference name=accountService target=AccountServiceComponent/ /component component name=AccountDataServiceComponent
[jira] Assigned: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages
[ https://issues.apache.org/jira/browse/TUSCANY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-978: --- Assignee: Luciano Resende Tuscany WSDL2Java can't handle WSDL fault messages -- Key: TUSCANY-978 URL: https://issues.apache.org/jira/browse/TUSCANY-978 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Environment: Tuscany Java-M2 and current trunk Reporter: Matthew Sykes Assignee: Luciano Resende Fix For: Java-SCA-Next Attachments: AccountService.wsdl I've been playing with the BigBank sample and have added a fault to the AccountService's withdraw operation. After changing the AccountService.wsdl (attached), the Tuscany WSDL2Java no longer works: [INFO] Generating Java service interfaces from /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account [INFO] [INFO] Trace java.lang.IllegalArgumentException: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) 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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242) ... 19 more Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1867) at org.apache.axis2
[jira] Resolved: (TUSCANY-1550) InitialContextCreatorHelper Javadoc
[ https://issues.apache.org/jira/browse/TUSCANY-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1550. -- Resolution: Fixed Fix Version/s: Java-DAS-Next Patch applied, Thanks. InitialContextCreatorHelper Javadoc --- Key: TUSCANY-1550 URL: https://issues.apache.org/jira/browse/TUSCANY-1550 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Priority: Trivial Fix For: Java-DAS-Next Attachments: InitialContextCreatorHelperPatch.txt Javadoc Update to the InitialContextCreatorHelper -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1551) MetaContextCreator.java Patch
[ https://issues.apache.org/jira/browse/TUSCANY-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1551. -- Resolution: Fixed Fix Version/s: Java-DAS-Next Patch applied. Thanks Ole MetaContextCreator.java Patch - Key: TUSCANY-1551 URL: https://issues.apache.org/jira/browse/TUSCANY-1551 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Priority: Trivial Fix For: Java-DAS-Next Attachments: MetaContextCreatorPatch.txt -- 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]
Re: [DAS] Transaction support
, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just looked more at the code and found something more interesting - :) When there is no connectionInfo in DAS Config, managedtx defaults to true, so when connection is passed by user (as in TransactionTests), managedtx is true. So, with the current code case 4) can not occur (which is actually useful) 4)false from caller DAS does not issue commit/rollback, external caller manages TransactionTests - if you look closely, there is just one DAS.applyChanges(root) command which has 2 INSERT statements using same PK. So, 2nd INSERT gives JDBC Exception and DAS uses it to issue rollback. So, TransactionTests is succedding in getting exception and avoiding both INSERTs due to the fact that both INSERTs are under same applyChanges() Command. What will happen in case when there is a client code like das.applyChanges (root1); das.applyChanges(root2); and the client wants both applyChanges() to be part of the same transaction? Is it possible with current DAS? Based on the current code, there will be autocommits for each applyChanges() which may not be desirable. Or is DAS forcing clients to grab all changes somehow in one call to das.applyChanges () to ensure transactional integrity? Is this convenient? ___ I could not understand the below statement - please elaborate. [In the case where client code requires access to the connection, is there any issue with supplying it to DAS ?'} ___ Regards, Amita On 8/14/07, Luciano Resende [EMAIL PROTECTED] wrote: Comments inline On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below is what is happening today:- managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages So what is lacking is a ability to issue commit/rollback on group of commands where connection is managed by DAS (managedtx=true).(case 3)). this will be essential to handle any business unit work. otherwise DAS is ending up today in mimicking autocommit behavior of Database which is not so useful when business transactions need to handle a group of operations as one atomic unit So, the test case below is an example of multiple commands under one transaction. On this scenario, connection is supplied by client, and I think this gives you the same results as if the connection was created by DAS and exposed to client code, and also gives more flexibility to how the client will aquire the connection, or re-use some other connection to be part of the same transaction. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java b what is the reason behind providing case 1)? when client/container provides connection, it can be controlled by client/container. and even if DAS tries to controll it, as user has handle to connection, commits/rollbacks can be issued by client async with what DAS
Re: build failure in java2wsdl
Are you using IBM JDK ? Looks like my latest changes have some issues with that JDK. On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error while executing the compiler - Java heap space
You can also increase the memory options in the sca pom, in the surefire plugin configuration section. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, ant elder [EMAIL PROTECTED] wrote: I always get a Java heap space error during the build while the itests are running these days. Runs fine if i build from within the itests folder but building from the top sca folder always fails. Does anyone else ever see this? Anyone know if there's something i can fiddle with in the mvn config to try to fix it? ...ant Hi ant I don't know if this is exactly the same issue that Luciano was seeing in the Continuum build but I remember he was playing about with MAVEN_OPTS=-Xmx1024m -Xms512m things. I looked back at the mails and see him trying to find out how to set these on the the Continuum machine. Simon Thanks, that does the trick. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1538) InitialContextCreator Patches
[ https://issues.apache.org/jira/browse/TUSCANY-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1538. -- Resolution: Fixed Patch applied InitialContextCreator Patches - Key: TUSCANY-1538 URL: https://issues.apache.org/jira/browse/TUSCANY-1538 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Fix For: Java-DAS-Next Attachments: InitialContextCreatorPatch.txt, InitialContextCreatorTestPatch.txt InitialContextCreator javadoc and test patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can RSS Feed be enabled for Tuscany blog?
You can definetly get Atom feeds using the following URL : http://apache-tuscany.blogspot.com/feeds/posts/default As for RSS, there is some documentation here [1], but that seems not working anymore. As a tip, I also use iGoogle [2] as my homepage, and customized it to give me access to all related Tuscany blog feeds on one page, it's useful to see what's going on... and keep you updated. [1] http://help.blogger.com/bin/answer.py?answer=42662query=rss%20urltopic=type=f [2] http://www.google.com/ig On 8/15/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, There is no RSS Feed on Tuscany blog[1]. Any one knows how to enable this? [1]: http://apache-tuscany.blogspot.com/ Haleh -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1542) BPEL extension to link sca component into a business process
[ https://issues.apache.org/jira/browse/TUSCANY-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520141 ] Luciano Resende commented on TUSCANY-1542: -- We have started this under java/sca/modules/implementation.bpel. Any help is appreciated BPEL extension to link sca component into a business process Key: TUSCANY-1542 URL: https://issues.apache.org/jira/browse/TUSCANY-1542 Project: Tuscany Issue Type: Wish Affects Versions: Java-SCA-Next Reporter: gengshaoguang What I expect next is: extend a bpel engine, make it interact with Tuscany's sca binding. Of course any bpel engine might link wsdl naturaly. But in the latter case, we make no improvement to SOA tech. BPEL-SCA should work in a more direct way and more effect way. I think SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at section 1.4 . I open this issue to arouse collaboration from all of you. Thanks. -- 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]
Updating SCA Distributions
Is there any documentation on how to update the SCA Distributions ? Maybe a quick readme on java/sca/distribution describing how to add dependencies... should new dependencies always go in both bundle and manifest ? what about webapp ? BTW, I have added sdo-tools dependencies under revision #565631, it would be great if someone could review it and let me know if I didn't forget any other place. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
So, let me try to understand this. We are going to remove the -webapp samples from the release binary distribution (due to size constrains), but we are still going to continue supporting the -webapp story. Users can still see these samples on the source distributions, right ? I'm asking this because I think that our users DO use Tuscany in the scenario of a -webapp, and if we are going to remove the -webapp samples, users that are evaluating the new release might think we removed the webapp support, so we need to be clear. If the webapp story is changing, then we should document (wiki) and test so our users can migrate to the new story. If this requires implementation.web I'd think we should implement these changes when it's ready. As an alternative approach, what about creating a samples-webapp distro ? On 8/14/07, ant elder [EMAIL PROTECTED] wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Anderson, Jeff T (CA - Toronto) wrote: I like having the samples, in the absence of extensive documentation these are key to understanding Tuscany... I like the idea of packaging the samples as simple SCA contribution jar's. I think keeping the footprint as little as possible is important, both in terms of optics and managing the complexity and understanding. Just my humble opinion... Jeff +1 to keep the samples as simple SCA contribution JARs. The current webapp packaging is not quite right anyway as it's introducing a half baked mix of J2EE and SCA programming model inside the webapp. I'd suggest the following: - Package SCA sample components as simple SCA contribution JARs, stay away from webapps. - To allow JSP and servlets to invoke SCA service component, support implementation.web Web components as described in [1]. [1] http://www.osoa.org/pages/viewpage.action?pageId=3980 (now back on the dev list) Just to make sure I understand, as an example right now we have sample-helloworld-ws-service and sample-helloworld-ws-service-webapp, do we just delete the -webapp one? Yes And then you can use the jar built by the sample-helloworld-ws-service with either the the Geronimo/Tuscany integration or our webapp runtime or with the standalone runtime we already use it with today? That sounds like the way to go to me but that seems like quite a big change, do we want to try to get this done in time for the upcoming release or wait till after that and just make the changes for 1.0? ...ant I prefer to do it now. I'm not quite sure why it's a big change? Isn't it just about deleting Maven modules? we have equivalent samples already working with the standalone runtime right? Is the Geronimo integration ready to be included in the the release? -- Jean-Sebastien I also think sooner would be better so happy to help go for it. The list of current webapps is: demo-alert-aggregator demo-mortgage-creditcheck sample-calculator-webapp sample-chat-webapp sample-helloworld-dojo sample-helloworld-jsonrpc sample-helloworld-ws-sdo-webapp sample-helloworld-ws-service-webapp Not sure we do have equivalent non-webapp samples for all those, i'll have a go at and seeing if they all those sample- ones run ok out side of a webapp. ..ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: itests: There are no tests to run
Surefire is configure to run test based on the following criteria : include**/*TestCase.java/include The test case java file must match the criteria above, and to take a concrete example (java/sca/itest/callback-api), you can see that the test case is named as CallBackApiTest.java and will not be picked up by surefire, that's why you see the message of no tests to run : --- T E S T S --- There are no tests to run. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 On 8/12/07, venu reddy [EMAIL PROTECTED] wrote: I am trying to execute itests from itest folder with mvn. Everything went fine without any errors including the sample itest that we are trying to write. However I have observed that, while trying to execute itests from each itest folder, for few folders it says There are no tests to run. What does this mean, are those tests incomplete?, or am I missing something here?. Thanks, Venu. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I think Tuscany needs a graph generator for composite layouts
Take a look at this post on Tuscany blog : http://apache-tuscany.blogspot.com/2007/07/sca-tooling.html Looks like the tooling project mentioned there has the ability to introspect components from your workspace, and give you a visual representation of your composite On 8/12/07, shaoguang geng [EMAIL PROTECTED] wrote: as the title, when composite contents comes more and more complicated, a layout graph generator would do greate help to developers. Or did some one see commercial providers of such a grapher? Good day. - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Calling XSD2JavaGenerator from ANT
I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Calling XSD2JavaGenerator from ANT
I was expecting the non-recommended approach to work...but the SDO generator code explicitly interpret and expects the key/value as two separate command line args. The non-recommended approach to emulate the two-argument behavior is arg line=key1 value1/ If this is the expected behavior, we should at least have it documented. Thoughts ? On 8/12/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Hi, The observed behaviour is the documented behavior of Ant arg value=key1/ arg value=value1 means there are two separate command-line arguments i.e. args.length=2 Is different from arg value=key1 value1/ Which means there is one command-line argument of value key1 value1. The non-recommended approach to emulate the two-argument behaviour is arg line=key1 value1/ Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 1:51 AM To: tuscany-dev Subject: Calling XSD2JavaGenerator from ANT I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
[ https://issues.apache.org/jira/browse/TUSCANY-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1524: - Description: See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html was: See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Tuscany Java DAS beta1 (RC4)
Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
[ https://issues.apache.org/jira/browse/TUSCANY-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1524. -- Resolution: Fixed Fixed under revision #565488 Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
[ https://issues.apache.org/jira/browse/TUSCANY-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519545 ] Luciano Resende commented on TUSCANY-1524: -- This was also fixed in trunk under revision #565487 Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
Comments inline
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is what is happening today:-
managedtx(default-true) - config attribute in ConnectionInfo element to
control transactions
managedtx database conn. supplied effect on transaction
--
1)true from caller each DAS command undergoes
commit/rollback
2)false from within DAS this is not handled in any way
3)true from within DAS each DAS command undergoes
commit/rollback
4)false from caller DAS does not issue
commit/rollback, external caller manages
So what is lacking is
a ability to issue commit/rollback on group of commands where connection is
managed by DAS (managedtx=true).(case 3)). this will be essential to handle
any business unit work. otherwise DAS is ending up today in mimicking
autocommit behavior of Database which is not so useful when business
transactions need to handle a group of operations as one atomic unit
So, the test case below is an example of multiple commands under one
transaction. On this scenario, connection is supplied by client, and I
think this gives you the same results as if the connection was created
by DAS and exposed to client code, and also gives more flexibility to
how the client will aquire the connection, or re-use some other
connection to be part of the same transaction.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java
b what is the reason behind providing case 1)? when client/container
provides connection, it can be controlled by client/container. and even if
DAS tries to controll it, as user has handle to connection,
commits/rollbacks can be issued by client async with what DAS is trying to
control. So there will be no meaning in DAS controlling the connection
supplied by client. And so there is no meaning to managedtx either.
c case 2), as of today there is no way to expose connection to client when
it is created by DAS. so neither DAS nor client manages transaction. For
this case exposing connection thru getConnection() will be useful (for other
cases, it can be banned)
In the case where client code requires access to the connection, is
there any issue with supplying it to DAS ?
d as DAS is heterogeneous API, is the DAS config going to be
heterogeneous too? If yes, then it will be advantageousto support the
transactional nature of RDB using such semantics. If the backend (non RDB)
does not support transaction, this semantics will be of no use, but
in this case the DAS config can be different (more tuned to that particular
backend)
So, it all depends on whether we are following the path to support DAS with
heterogeneous APIs or not. Will you please elaborate meaning of
heterogeneous API in context of different flavors of DAS?
Yes, the idea is that each impl would define it's own model,
inheriting from a common root class (xsd element)
e {If you already defined the transaction demarcation flags...}Where are we
doing that at present? What is there is only issue commit/rollback at the
end of each DAS Command. Am I missing some other transaction demarcation
mechanism already available in DAS?
Regards,
Amita
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote:
I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.
So, for this issue, let's take a step back and think around the
scenarios where this new enhancement might be useful, could you please
list a couple here ? It would be great if you could also mention the
deficiencies you found from managedtx parameter on each scenario.
Also, couple questions :
- Could you please elaborate more on why you need to expose
DAS.getConnection() ?
- If you already defined the transaction demarcation flags, why you
still ask the client code to handle start/endTransaction? Why is that
different from passing managedtx = false ?
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection() from DAS to give a ref. of the connection (User already
owns
it, DAS is just providing ref.). DAS will not issue any commit/rollback
-When connection is created internally, managedtx has a meaning.
1When false, DAS.getConnection() should be exposed and user should be
allowed to handle
Re: Release management for next release, was: SCA 0.92 release?
Simon Laws wrote: +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. We could probably get a stable distribution available on the 20th, and we would check that. On 8/12/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: I guess early the following week still leaves time for an August release. It will be real tight though so we'll all need to be quick and thorough with our RC reviews as one problem once we get to the IPMC voting and it could easily slip it into September. So does taking the branch on the 21st sound ok to everyone? ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: Ant talked about cutting the branch very early next week. I'd prefer that to doing it on August 18th. I will be away for a few days, returning home late on the 18th, and I could take advantage of the extra couple of days to help with last-minute things. Simon Venkata Krishnan wrote: Hi, Theres been lots of discussion. So let me summarize my understanding / imaginiation : - - We will cut a branch around Aug 18th for Release 0.95. As always, once the branch is cut we need to be watchful on the commits (including getting the RMs nod to significant ones) to the branch and also ensure the trunk is always in sync. - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Is that all right ? - Venkat On 8/9/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
Memory: 52M/63M [INFO] Figures it would stop on Supply Chain (I'm in the process of of launching mydemandchain.com). Maybe someone is trying to tell me something :-) I ran the build 3 times to make sure that it was not just maven failing to download something...Although that could still be a possibility. I tried building it with 1.6 after the 1.5 run, and it still fails in the same place as before. Strange. Please let me know if you want me to try something else. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribution URLs
I think your current directory, during the execution of the code, will not be mapped to the root of you project, but probably to target/classes or target/test-classes. Could you check that please ? On 8/10/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Simon, Could you please send the exact URL you are passing to the contribution service ? I have added a test case for what I understood your problem is, and that is working fine, but note that in the test case, I'm calling getClass().getResource(/deployables), and that gives me a url like : file://deployables, and that would pass the logic to correct identify a folder. On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: I've just noticed that if I have a contribution directory as follows /my/contribution/dir/mycomposite.composite And I pass the source URL /my/contribution/dir to the contribution service it complains that it can't find /my/contribution/mycomposite.composite. If I pass the source URL /my/contribution/dir/ it works (note slash on end). Is this a fault? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano This was the piece of code that was causing me problems... contributionURL = new URL(file:/ + currentDirectory.getCanonicalPath() + /src/main/resources/ + nodeName + /); // Contribute the SCA application Contribution contribution = contributionService.contribute( http://calculator;, contributionURL, resolver, false); Composite composite = contribution.getDeployables().get(0); // Add the deployable composite to the domain domain.getDomainComposite().getIncludes().add(composite); domain.getCompositeBuilder().build(composite); Where the directory structure is. src/ main/ resources/ nodeA/ META-INF/ sca-contribution.xml wsdl mutiply.wsdl calculator.composite And I want to read the contribution from the nodeA directory. Maybe you can spot something from this. But if nothing comes to mind immediately don't worry. I'll check this test in over the next few days and we can look at it directly. Regards Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1531) Java SDO Documentation page should be updated to default website stype/design
Java SDO Documentation page should be updated to default website stype/design - Key: TUSCANY-1531 URL: https://issues.apache.org/jira/browse/TUSCANY-1531 Project: Tuscany Issue Type: Bug Components: Website Affects Versions: Java-SDO-Next Reporter: Luciano Resende Fix For: Java-SDO-Next The default left side menus are missing or wrong Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http://incubator.apache.org/tuscany/sdo-java-documentation-menu.html as it's one of the pages with more contents on it. User guide has wrong styles : http://incubator.apache.org/tuscany/sdo-java-user-guide.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
[ https://issues.apache.org/jira/browse/TUSCANY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1523: - Component/s: Java SCA Core Runtime Enhance ArtifactProcessors to be registered for file names, as well as for file types - Key: TUSCANY-1523 URL: https://issues.apache.org/jira/browse/TUSCANY-1523 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Details on the following thread: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1532) Add sdo-tools dependency to tuscany-sca distribution
Add sdo-tools dependency to tuscany-sca distribution Key: TUSCANY-1532 URL: https://issues.apache.org/jira/browse/TUSCANY-1532 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next We need to add sdo-tools dependency to tuscany-sca distribution in order to be able to generate static SDO for the sample applications. -- 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]
Re: Policy Attachments Resolution in the Assembly Model
Cool, if you can wait a day, i can take a look at that... Sebastien suggestion seems ok: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml But I guess we also need to change the logic on the algorithm that checks for the right processor to be used, as it's now just checking the file extension. On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Luciano, that's what I am suggesting. - Venkat On 8/8/07, Luciano Resende [EMAIL PROTECTED] wrote: Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: New itest folder: guidelines
You could use some of the other project existing pom[1] as guidelines. The poms are all inheriting the necessary configuration to run the tests from the parent pom [2] and it looks like below : !-- surefire plugin configuration -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.3/version configuration includes include**/*TestCase.java/include /includes reportFormatbrief/reportFormat useFilefalse/useFile forkModeonce/forkMode argLine-ea -Xmx128m/argLine /configuration /plugin [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/contribution/pom.xml [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml On 8/9/07, venu reddy [EMAIL PROTECTED] wrote: Folks, I am planing to create my own folder (venu) in java/sca/itests and write few sample tests. Can any one please post if you have any guidelines on writing pom.xml (\java\sca\itests\venu\pom.xml) to include my sample tests for maven to build and execute. Thanks, Venu. - A 'wish' changes nothing. A 'decision' changes everything! Anon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build problem in binding-ws-axis2
Could you try moving to maven 2.0.5 on the one that does not work ? On 8/9/07, ant elder [EMAIL PROTECTED] wrote: This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
Enhance ArtifactProcessors to be registered for file names, as well as for file types - Key: TUSCANY-1523 URL: https://issues.apache.org/jira/browse/TUSCANY-1523 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Details on the following thread: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1328) can not locate service from a component whose implementation is composite
[
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1328.
--
Resolution: Fixed
This scenario is now working, and I also added a test case in recursive iTest
can not locate service from a component whose implementation is composite
-
Key: TUSCANY-1328
URL: https://issues.apache.org/jira/browse/TUSCANY-1328
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Yang Lei
Assignee: Luciano Resende
Fix For: Java-SCA-Next
default.composite:
composite autowire=false
local=true
name=Iteration3Composite
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
component name=MySimpleServiceInRecursive
implementation.composite
name=foo:MySimpleService/
/component
/composite
MySimpleService.composite:
composite autowire=false
local=true
name=MySimpleService
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
service name=MyServiceOrig1
promote=MyServiceComponentOrig/MyService
interface.java
interface=mysca.test.myservice.MyService/
/service
component name=MyServiceComponentOrig
implementation.java
class=mysca.test.myservice.impl.MyServiceImpl/
/component
/composite
MyServiceImpl
@Service(interfaces={MyService.class, MyServiceByDate.class,
MyListService.class, MyListServiceByYear.class})
public class MyServiceImpl implements MyService, MyServiceByDate,
MyListService, MyListServiceByYear{
...
}
When I try to locateService of MySimpleServiceInRecursive/MyServiceOrig1,
got the following exception
org.osoa.sca.ServiceRuntimeException: Service not found:
MySimpleServiceInRecursive/MyServiceOrig1 at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
at
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke
Thanks.
--
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]
Re: mvn eclipse:eclipse fails on java
What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 -- 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-1328) can not locate service from a component whose implementation is composite
[
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende updated TUSCANY-1328:
-
Test cases in working state added in revision #564288
can not locate service from a component whose implementation is composite
-
Key: TUSCANY-1328
URL: https://issues.apache.org/jira/browse/TUSCANY-1328
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Yang Lei
Assignee: Luciano Resende
Fix For: Java-SCA-Next
default.composite:
composite autowire=false
local=true
name=Iteration3Composite
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
component name=MySimpleServiceInRecursive
implementation.composite
name=foo:MySimpleService/
/component
/composite
MySimpleService.composite:
composite autowire=false
local=true
name=MySimpleService
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
service name=MyServiceOrig1
promote=MyServiceComponentOrig/MyService
interface.java
interface=mysca.test.myservice.MyService/
/service
component name=MyServiceComponentOrig
implementation.java
class=mysca.test.myservice.impl.MyServiceImpl/
/component
/composite
MyServiceImpl
@Service(interfaces={MyService.class, MyServiceByDate.class,
MyListService.class, MyListServiceByYear.class})
public class MyServiceImpl implements MyService, MyServiceByDate,
MyListService, MyListServiceByYear{
...
}
When I try to locateService of MySimpleServiceInRecursive/MyServiceOrig1,
got the following exception
org.osoa.sca.ServiceRuntimeException: Service not found:
MySimpleServiceInRecursive/MyServiceOrig1 at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
at
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke
Thanks.
--
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]
Re: Policy Attachments Resolution in the Assembly Model
Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
+1 for Ant On 8/8/07, Simon Nash [EMAIL PROTECTED] wrote: +1 for Ant. He did a great job with 0.90. Simon Venkata Krishnan wrote: +1 for Ant taking doing the RM since his seasoned hand will help up get things our quickly given the little time we have. Ant, if you are OK with this count me in for any help you might require in this. Thanks. - Venkat On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Subproject News Bulletin? Would it be useful?
interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java DAS beta1 (RC3)
All the maven artifacts are now signed. On 8/6/07, Venkata Krishnan [EMAIL PROTECTED] wrote: I've verified the signatures for the src and bin distros and they seem fine. The License file mentions 'Apache Jackarta'... while I think it is 'Apache Jakarta'. Maybe this very minor thing could be fixed for the next release. So over all, here is my +1 for this release. Thanks - Venkat On 7/30/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in RC1 and RC2 should now be fixed. The Release Candidate RC3 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Propose to create a new Tuscany malling list
Currently we have couple places that can generate e-mail notification : - Apache Continuum build notifications (sucess/failure) - Traffic stats for Apache Tuscany Blog (daily/weekly) - Traffic stats for Apache Tuscany website (daily/weekly) - etc I don't want to pollute the dev or committ list with these notifications, and thus would like to propose creation of a notification list to forward all these e-mails, and the interested people would subscribe (or look into the archives) and have access to these information. If people are OK with this, I'd contact infra@ and ask for the creation of the new notification list. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: August Reports - deadline tomorrow
Just a friendly reminder, tomorrow is the deadline for the Board Reports, please add any updates to the draft report [1], and I'll post it tomorrow. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 On 8/1/07, Luciano Resende [EMAIL PROTECTED] wrote: It's that time again for us, I have started a draft report on our wiki [1], let's get it updated asap. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 -- Forwarded message -- From: Noel J. Bergman [EMAIL PROTECTED] Date: Aug 1, 2007 7:52 PM Subject: August Reports To: [EMAIL PROTECTED] Just getting the reminder in early --- those projects reporting in August, please start working on and posting your reports. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release SDO Java version 1.0-incubating (release candidate 4)
() TUSCANY-1214SDO 2.1 feature: XMLHelper.load (Source) and XMLHelper.save(Result) TUSCANY-1197Sequence composition TUSCANY-1317Provide a way to set default XML load options to be used during Java deserialization Improvement TUSCANY-1350Reorganise SDO build / distribution layout TUSCANY-1459Remove package registry delegation to EPackage.Registry.INSTANCE TUSCANY-1110Improve the performance of TypeHelperImpl.getType(Class) TUSCANY-1391Provide capability to load and save XML with unknown features TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars TUSCANY-513Implement support for dynamic subclasses of statically generated types TUSCANY-1233Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a single pass. Bug TUSCANY-1143Generated code should separate metadata creation from registration to permit proper scoping TUSCANY-1428XSD2JavaGenerator.GeneratePackage information is invalid TUSCANY-1429Using default helper context got ClassCastException due to T-1317 TUSCANY-1446Java SDO samples don't compile with JDK 1.4.2 TUSCANY-1457Unable to code gen SDOModel.xsd TUSCANY-1430SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls TUSCANY-1207TCCL-specific EcoreBuilders must be used by default XSDHelper TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content TUSCANY-1254Codegen on a type inheriting from a type in different namespace will result in mis-mapping the feature IDs TUSCANY-993Problems with sdoModelExtended.xsd TUSCANY-1223XSD base64Binary type mapping to wrong SDO type TUSCANY-1251Code generated from xsd:base64Binary types fail to compile TUSCANY-1333[Java SDO] ClassCastException when defining schema file without .xsd extension TUSCANY-1410DataHelperImpl.toCalendar() with null locale should use default locale TUSCANY-1324DeserializationNoSchemaTestCase took a long time to run TUSCANY-1369EMF 2.2.2 Dependencies from ISU are Stale TUSCANY-1352NPE in SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema TUSCANY-1325Property value with xsd:QName type is not deserialized and serialized correctly TUSCANY-1250Static SDO generator generates an erroneous factory class, when inheritance and different Java packages are used TUSCANY-578Exceptions thrown by SDO runtime not the same as defined in the spec TUSCANY-1421XMLHelper.save on root object of DataGraph gives serialization of href=root.xml#/ TUSCANY-1436TypeHelper.getType(java.util.List.class) throws ClassCastException TUSCANY-1385Duplicate namespace was serialized when SDO QName property value containing existing namespace TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2 TUSCANY-1408Cannot programmatically define a SDO property matching to XSD element TUSCANY-1393ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:int TUSCANY-1305Changesummary of datagraph using static interfaces. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Hey Pinaki Very good to hear that you also added initial support for the Tuscany DAS interfaces. BTW, let me ask you what are your plans to Fluid ? My personal opinion is that this might be a great addition to Tuscany, and we could have it as another DAS option in Tuscany. This could also promote a better integration between Tuscany and OpenJPA communities. Thoughts ? On 7/31/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Hi Luciano, In an earlier response to your question: if would be feasible to add a DAS interface[1] layer on top of Fluid [2]? My answer was: Yes. As backup of that answer, I just added the support for SDO DAS by implementing DASFactory/DAS/Command Using Fluid. These implementations are very thin-wrapper that delegates to Fluid's JPA API. From a usage model, there is conceptual shift though from a SQL-based DAS. Using Fluid based DAS, user code will look like: (there are some TestCases that details it) DataObject person = createPerson(ssn, Fluid, Guy, 17); DAS das = getDAS(); Command insert = das.getCommand(INSERT); insert.setParameter(0, person); insert.execute(); to persist a Person DataObject, or to query DAS das = getDAS(); Command query = das.getCommand(SELECT); String jpql = SELECT o FROM Person o WHERE o.firstName=?1 AND o.age=?2; query.setParameter(0, jpql); query.setParameter(1, Fluid); query.setParameter(2, 17); DataObject list = query.executeQuery(); List result = (List)list.get(0); Few notable points are: 1. There is no SQL. 2. All object level paramaters are set via Command.setParameter() method. Insert command acts on a Person DataObject (insert can be cascaded transitively, btw) which is passed to it as parameter. 3. Query is JPQL. This is a powerful contribution of JPA. The namespace of the query tokens are Object Domain tokens i.e. SDO Type and Property names; not database Table or Column names. Join is navigation across a SDO DataGraph. OpenJPA will take care of creating the appropriate SQL. User can see/monitor what SQL is being generated by OpenJPA. 4. DAS defined return of Command.executeQuery() as a DataObject. One would prefer it to be a ListDataObject but to confirm to the API, I just return a dynamic DataObject whose 0-th Property is a ListDataObject And, last but not the least, applyChanges(): dataObject.setString(firstName, Solid); das.applyChanges(dataObject); Will make an UPDATE to the database. How does user application gets a DAS? DASFactory dasFactory = new FluidDASFactory(SDO-DAS); DAS dasFactory = dasfactory.createDAS(); 1. Everything about persistence service (from database connections to ~200 configurable parameters supported by OpenJPA) is configured in a single file: META-INF/persistence.xml. The unit name in this file should be persistence-unit unitName=SDO-DAS. 2. The overloaded DASFactory.createDAS() that takes org.apache.tuscany.sdo.das.rdb.Config and other parameters are supported simply by ignoring the argument :). Regards Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 3:25 PM To: tuscany-dev@ws.apache.org Subject: Re: Persistence of Service Data Objects using OpenJPA I haven't looked into this with any great detail, but I'd like to ask if would be feasible to add a DAS interface[1] layer on top of Fluid [2]. Thoughts ? [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main /java/org/apache/tuscany/das/rdb/DAS.java [2] http://people.apache.org/~ppoddar/fluid/site/welcome.html On 7/27/07, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Pinaki, I think your project has a lot of potential. Another related aspect is that there is interest in the SDO specification charter to discuss the possibility of converging/supporting JAXB with static SDO in version 3. JAXB2, as you may know, has a similar objective to support standard POJOs. If that happens, then I see even more synergy with your approach. At Tuscany, we'd also be very interested in the bytecode generation that you mentioned you've prototyped in Fluid. Tuscany has done a little bit of sandbox prototyping in that area as well, but nobody has had enough time to really pursue it. Given this work, I think you should consider getting involved with the DAS specification effort, if you haven't already. Frank. Pinaki Poddar [EMAIL PROTECTED] 07/27/2007 12:32 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc [EMAIL PROTECTED] Subject Persistence of Service Data Objects using OpenJPA
[jira] Commented: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure
[ https://issues.apache.org/jira/browse/TUSCANY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517980 ] Luciano Resende commented on TUSCANY-961: - I don't think we should change DAS API to receive the helperContext. Is there any absolute requirement for this ? DAS: Using deprected SDO method causes Type lookup failure -- Key: TUSCANY-961 URL: https://issues.apache.org/jira/browse/TUSCANY-961 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 961.patch The DAS is still using SDOUtil.createTypeHelper() rather than TypeHelper.INSTANCE. This causes the DAS to not have visibility of types defined by TypeHelper or XSDHelper. -- 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]
Re: Tuscany vmbuild
I have created my account : lresende Please give me the administration roles, so I can go ahead and setup it up for Tuscany project builds. On 8/5/07, Brett Porter [EMAIL PROTECTED] wrote: Hi, vmbuild1 is now set up. I have created a group for Tuscany but have not added the projects - I thought that individual projects might like to set them up to their liking (though I'm happy to help with anything). If you'd like to register for an account I can give you the group administration roles so that you can do this and assign rights to other users. http://vmbuild1.apache.org/continuum/security/register.action Cheers, Brett On 12/07/2007, at 3:24 AM, Luciano Resende wrote: Thanks for checking Brett, it would be great to have history moved to the new machine (if possible) as well. Otherwise, just setting up the project on the new machine is fine. [x] you would like the project (and it's build history if possible) moved over On 7/11/07, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm not on this list, so please reply directly - thanks. Tuscany currently have a build set up in vmbuild.apache.org. It's been down for little bit, but is now back up. vmbuild is scheduled to be moved to a faster machine, and I intend to install a more recent build of Continuum (that supports grouping projects and is generally faster, more managable and more stable). I'm able to help get it set up as effectively as possible. There are a lot of failing builds on the machine right now (probably unused by the corresponding projects), so I'm cleaning house before the move. Please let me know if: [ ] you would like the project set up on the new machine with a clean slate [ ] you would like the project (and it's build history if possible) moved over [ ] you are no longer interested in using vmbuild for CI/nightlies/ whatever Thanks! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fisheye view for the Apache Tuscany repository?
I was wondering if it would be possible to get Fisheye setup for Apache Tuscany tree? https://svn.apache.org/repos/asf/incubator/tuscany/ Fisheye is a wonderful tool and the Tuscany community would benefit by having this tool available. Would it be possible to get this setup similar to other ASF projects [1]. [1] http://fisheye6.cenqua.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fisheye view for the Apache Tuscany repository?
Thanks Matthieu The e-mail was already sent to [EMAIL PROTECTED], and they advised us to check with infra first. [TN#106588] Fisheye view for the Apache Tuscany repository? This should not be a problem. Please send an email to [EMAIL PROTECTED] and let them know that you would like this set up and if there are any problems. Once infra ok's this, we'll take it from there. We will usually wait till the weekend for adding a new repo. Who can give an OK from the infra side ? On 8/4/07, Matthieu Riou [EMAIL PROTECTED] wrote: I think there's nothing specific to do on the Apache infra side. You just need to send an e-mail to Cenqua at [EMAIL PROTECTED] to ask them to add your project. Cheers, Matthieu On 8/3/07, Luciano Resende [EMAIL PROTECTED] wrote: I was wondering if it would be possible to get Fisheye setup for Apache Tuscany tree? https://svn.apache.org/repos/asf/incubator/tuscany/ Fisheye is a wonderful tool and the Tuscany community would benefit by having this tool available. Would it be possible to get this setup similar to other ASF projects [1]. [1] http://fisheye6.cenqua.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1506) Fix RAT issues in DAS LDAP
Fix RAT issues in DAS LDAP -- Key: TUSCANY-1506 URL: https://issues.apache.org/jira/browse/TUSCANY-1506 Project: Tuscany Issue Type: Bug Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Luciano Resende Fix For: Java-DAS-Next Attachments: ldap-rat.log Running rat on the LDAP source flaged couple issues that we should look at. I'll attach the rat.log to this JIRA -- 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-1506) Fix RAT issues in DAS LDAP
[ https://issues.apache.org/jira/browse/TUSCANY-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1506: - Attachment: ldap-rat.log Fix RAT issues in DAS LDAP -- Key: TUSCANY-1506 URL: https://issues.apache.org/jira/browse/TUSCANY-1506 Project: Tuscany Issue Type: Bug Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Luciano Resende Fix For: Java-DAS-Next Attachments: ldap-rat.log Running rat on the LDAP source flaged couple issues that we should look at. I'll attach the rat.log to this JIRA -- 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]
Re: BPEL implementation: WSDL and BPEL resolving
The loading of contribution has two phases : read and resolve. * read phase : This is where you read an artifact (a document, an XML element, classes etc.), populate a model representing the artifact and return it. The SCA contribution service calls ArtifactProcessor.read() on all artifacts that have an ArtifactProcessor registered for them. If your model points to other models, instead of trying to load these other models right away, you should just keep the information representing that reference, which you'll turn into a pointer to the referenced model in the resolve() phase. Note that you don't necessarily need to fully read and populate your model at this point, you can choose to complete it later. * resolve phase : This phase gives you the opportunity to resolve references to other models (a WSDL, a class, another composite, a componentType). At this point, all models representing the artifacts in your SCA contribution have been read, registered in the contribution's ArtifactResolver, and are ready to be resolved. The resolution is going to happen when the contribution is loaded, and my understanding is that some recent changes from Raymond will also make some loading/resolution only happen if the artifact is indeed referenced. Some more info here [1] [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Architecture+Guide On 8/3/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi Raymond, Sorry for the late reply, your e-mail passed through my filters :) The approach described in the document sounds good to me, it's similar to what we're doing for import resolution within an ODE deployment package. So that should work. The only part I'm not so clear about though is when the resolution occurs, is it when the contribution is loaded? And thanks for the congrats! Matthieu On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Matthieu. Congratulations on the ODE graduation! We have made some processes in Tuscany regarding to the artifact resolving. Please see more details at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts . I think the strategy will apply to BPEL as well. Would you please take a look? Hopefully, we can get the implementation.bpel working soon. Thanks, Raymond - Original Message - From: Matthieu Riou [EMAIL PROTECTED] To: Luciano Resende [EMAIL PROTECTED] Cc: tuscany-dev@ws.apache.org Sent: Thursday, July 05, 2007 5:08 PM Subject: Re: BPEL implementation: WSDL and BPEL resolving Sure, no problem. And thanks :-) On 7/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Matthieu I'm little overbooked these days, but let me see if I could try to look into the resolution thing over the weekend. Is that OK ? On 7/5/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1397
Hey Andy, It should be OK for you to committ it directly, if you need a review just forward the committ log and ask people to review (but I guess they will be reviewing it anyway from the mail notifications). On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote: Andy, please, check if everything was commited as expected to resolve the JIRA1397. Regards, Adriano Crestani On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote: Applyed the new patch, tests ran OK, commited. Adriano Crestani On 8/3/07, Andy Grove [EMAIL PROTECTED] wrote: Thanks Adriano, Fuhwei, I've re-created the patch using the trunk code as at revision 562418 and attached it to the JIRA. I'm happy to submit the patch directly if everyone is happy with the approach I'm taking on this issue. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: 03 August 2007 05:41 To: tuscany-dev@ws.apache.org Subject: Re: Patch for TUSCANY-1397 I've patched the sdo trunk under revision 562325 with the patch Andy created. All tests ran fine, even though it failed on the tests described on thread [1], but I these fails have nothing to do with Andy patch, so it's ok for me ; ). Anyway, I will wait for a new created patch from Andy, once Fuhwei is saying the actual patch is based on an older version. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/brow ser Regards, Adriano Crestani On 8/2/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: I think the patch is based on an older version of DataObjectUtil.java. Can you create a new patch? Thanks. Adriano Crestani [EMAIL PROTECTED] wrote: I may commit it till the eod if nobody has no objection ; ) Adriano Crestani On 8/2/07, Andy Grove wrote: I've submitted a patch for TUSCANY-1397 and I'd like someone to review this before I apply it since it is my first patch to the Tuscany SDO implementation (I've only been submitting to the CTS until now). The purpose of this patch is to implement on-demand creation of properties in createDataObject(). https://issues.apache.org/jira/browse/TUSCANY-1397 Thanks, Andy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
I have reopened the JIRA and will give it a try... On 8/2/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I agree with Simon's comment - this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Yours, Mike. ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
[ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reopened TUSCANY-1053: -- Assignee: Luciano Resende (was: ant elder) Reopening per latest discussion comments : ...this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: Luciano Resende Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] -- 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]
Re: Maven Build Issues with SCA 0.91 and later
Hi Mike This is a MAVEN issue, and we are trying to get help from the maven developers [1]. In the meantime, a workaround we found was to publish snapshots of all artifacts, the ones you mentioned, for itest/contribution-import-export were renamed recently, let me publish new snapshots in one hour or so, I'll let you know when they are published. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20844.html On 8/1/07, Mike Spendlove [EMAIL PROTECTED] wrote: Hey Tuscany gurus, I've been (unsuccessfully) trying to get the SCA source code to build for the last day or two using Maven. While I eventually got the 0.91 baseline to build, I've had no real progress on the HEAD code. The most common problem when building either the baseline or Head (using mvn or 'mvn -U -cpu') is missing artifacts, although since the absent resource is often a Tuscany file, I've been able to fix some of the issues by just running mvn in the required directory. That only gets me so far with the HEAD, since I either end up trying to build a resource that's missing other dependencies I can't get to build or I get a ClassNotFoundException. For example, my most recent error stated I was missing this artifact: org.apache.tuscany.sca:tuscany-itest-contribution-import-export-contrib-composite:jar:1.0-incubating-SNAPSHOT I tried running maven in Tuscany\java\sca\itest\contribution-import-export but got this error: ... Running helloworld.HelloWorldServerTestCase Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.688 sec FAILURE! testPing(helloworld.HelloWorldServerTestCase) Time elapsed: 2.578 sec ERROR! org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl Other files I've had to build manually include: -org.apache.tuscany.sca:tuscany-interface-java:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT - org.apache.tuscany.sca:tuscany-implementation-notification:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:tuscany-topology:jar:1.0-incubating-SNAPSHOT and a few others... None were available when I navigated to their location using my browser. The POM files all seem to roughly match the directory structure (any missing or commented modules in the POM file are not the ones causing problems in the build) and I've tried clean builds repeatedly (cleaning my local repository and the target directories) with no luck. My setup: -Intel Core 2/2 GB Ram/Win XP -Maven 2.0.7 (although I've also tried 2.0.6) -Java SE 5 (JDK 5.0_12) since Java SE 6 was causing javax problems: Running crud.CRUDTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.625 sec FAILURE! testCRUD(crud.CRUDTestCase) Time elapsed: 0.578 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java :158) ... -going through a web proxy configured as below: (although I've tried direct and not resolved any issues.) proxies proxy activetrue/active protocolhttp/protocol hostgateway.xxx/host port8000/port nonProxyHosts10.*.*.*|172.*.*.*|192.*.*.*|*.xxx|sysgroupsps1|localhost|127.0.0.1/nonProxyHosts /proxy /proxies Any suggestions as to how I can find the missing artifacts (perhaps a better repository?) are greatly appreciated! Thanks for your help, -Mike -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven tries to resolve artifact in the reactor to SNAPSHOT version in Apache Tuscany build
Just trying to give some updates here... looks like this recent build issues we are having might be a side effect of the fix for Maven JIRA MNG-1577 [1], some more details are available here [2] and [3]. While we investigate the issue further, a possible workaround (that worked for me) is to move back to maven 2.0.5 client [4]. Please let me know if this works for you as a temporary workaround. And many thanks to brett_ and others for helping on IRC. [1] http://jira.codehaus.org/browse/MNG-1577 [2] http://maven.apache.org/release-notes.html [3] http://maven.apache.org/plugins/maven-dependency-plugin/examples/preparing-dependencies.html [4] http://archive.apache.org/dist/maven/binaries/maven-2.0.5-bin.zip On 7/27/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Guys We are experiencing some issues in Apache Tuscany build recently as described on this thread [1]. Basically, anyone starting with a clean local maven repo are seeing the artifacts that are supposed to be built in the reactor, to be resolved to a published SNAPSHOT version, and thus, the build is failing if any of the problematic artifacts doesn't have a published snapshot. This only started recently, around July 24th or 25th, and looks like people that have an old maven repository can build things OK. Could someone please give us some help, or guidance on how to investigate the issue. If you need any other information, please let us know, and our source code is available at [2] and we are trying to build [3]. BTW, could you please post a response to both lists. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20739.html [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/ [3] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517080 ] Luciano Resende commented on TUSCANY-1347: -- Although I can't reproduce the error, I have added some new test to exercise the behavior described on this JIRA under revision #561957 (under /java/sca/itest/recursive) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback - Key: TUSCANY-1347 URL: https://issues.apache.org/jira/browse/TUSCANY-1347 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar More complete description and test case to follow Here is the exception thrown... [6/14/07 17:59:55:187 MDT] 0020 SystemErr R java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) at org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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]
Fwd: August Reports
It's that time again for us, I have started a draft report on our wiki [1], let's get it updated asap. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 -- Forwarded message -- From: Noel J. Bergman [EMAIL PROTECTED] Date: Aug 1, 2007 7:52 PM Subject: August Reports To: [EMAIL PROTECTED] Just getting the reminder in early --- those projects reporting in August, please start working on and posting your reports. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1495) LDAP DAS Contribution
[ https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1495: Assignee: Luciano Resende LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Ole Ersoy Assignee: Luciano Resende Priority: Minor Fix For: Java-DAS-Next Attachments: das.ldap.parent.zip Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole -- 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-1495) LDAP DAS Contribution
[ https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1495: - Component/s: Java DAS LDAP Fix Version/s: Java-DAS-Next Patch Info: [Patch Available] Affects Version/s: Java-DAS-Next LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Ole Ersoy Priority: Minor Fix For: Java-DAS-Next Attachments: das.ldap.parent.zip Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole -- 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]
SDO Static Type introspection on web apps, was : Re: svn commit: r561293 - /incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcess
Looks like things are still working because the composite file
explicitly add the SDO factory
dbsdo:import.sdo factory=helloworld.HelloworldFactory/
As for the WEB-INF\classes\, there was some discussion before, and at
that time, we decided to keep the artifact URI as is, so I have
introduced some more logic on the SDO Processor to handle this
scenario, and get the right class name when it's in a web app. I also
removed the import.sdo from the sample application composite file.
BTW, one way or another, I still get an exception on the JSP, did you see that ?
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18008.html
On 7/31/07, ant elder [EMAIL PROTECTED] wrote:
On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: antelder
Date: Tue Jul 31 03:05:21 2007
New Revision: 561293
URL: http://svn.apache.org/viewvc?view=revrev=561293
Log:
Fix NPE when clazz not resolved
Modified:
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
Modified:
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java?view=diffrev=561293r1=561292r2=561293
==
---
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
(original)
+++
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
Tue Jul 31 03:05:21 2007
@@ -56,7 +56,7 @@
String factoryName = getFactoryClassName(artifactURI);
ClassReference clazz = new ClassReference(factoryName);
clazz = contribution.getModelResolver().resolveModel(
ClassReference.class, clazz);
-if (clazz.getClass() != null) {
+if (clazz.getJavaClass() != null) {
try {
//check if it's a SDO factory by introspecting
INSTANCE field
if (isSDOFactory(clazz.getJavaClass())) {
The actual cause of this problem seems to be a different bug where the
class name is prefixed with WEB-INF\classes\ when running in a webapp so
the classes never get resolved. Although that doesn't seem to stop things
from still working ok so I'm not sure what this is code is really trying to
do? Can see this by debugging with a break point in the above code and
running the new helloworld sdo webapp sample.
...ant
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1489) Incorporate artifact signing when building distribution or deploying artifacts
Incorporate artifact signing when building distribution or deploying artifacts
--
Key: TUSCANY-1489
URL: https://issues.apache.org/jira/browse/TUSCANY-1489
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-DAS-Next
By adding this to the DAS pom, we could enhance release creation. This plugin
works together with HPH and sign all artifacts being built or deployed.
!-- We want to sign the artifact, the POM, and all attached artifacts --
plugin
artifactIdmaven-gpg-plugin/artifactId
version1.0-alpha-3/version
!--
configuration
passphrase${gpg.passphrase}/passphrase
/configuration
--
executions
execution
goals
goalsign/goal
/goals
/execution
/executions
/plugin
--
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]
[VOTE] Release Tuscany Java DAS beta1 (RC3)
Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in RC1 and RC2 should now be fixed. The Release Candidate RC3 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Property Definition - resolving 'file' attribute
I guess Venkata is trying to create the deployedArtifact to resolve... To resolve an artifact, you simple need to create a DeployedArtifact - see ContributionFactory.createDeployedArtifact() -, set it's URI to the URI of the artifact inside the SCA contribution, then call ModelResolver.resolve(theDeployedArtifact). But I'll wait to see the code. On 7/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien / Luciano, I have this going in my local. But I've had to pass the ContributionFactory down to the CompositeProcessor thus adding one more argument to the CompositeProcessor contructor. Is there any violation of layering in our design with this passing? Just want to check this up before I commit the changes. Thanks - Venkat I'm not quite sure I understand the relationship between ContributionFactory and resolution of a file. Could you post the code somewhere? It'll help me understand. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A small question about attaching files
The idea is to use open file formats that everybody in the community can use. For example I'm using Linux, Zip, Tar, Jar, Gz work for me. I don't have a 7z tool on my Linux machine. +1 for zip/jar, I also don't have 7z in my windows or linux installations. On 7/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: shaoguang geng wrote: Hi,Raymond: Since you mentioned my attachment format(rar I used). I will have to explain shortly, I just felt zip is bigger. I examed some file compression method today. Then can I suggest that we may use some other format such *.7z which is much more tiny. Of course if only zip is permitted in our community, I would not against. - Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. The idea is to use open file formats that everybody in the community can use. For example I'm using Linux, Zip, Tar, Jar, Gz work for me. I don't have a 7z tool on my Linux machine. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
