[jira] Created: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assigned to: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is model -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-200?page=comments#action_12374764 ] Jeremy Boynes commented on TUSCANY-200: --- Jim started to make this change in r394333 but that only impacts the builder. During loading, introspection on the class explicitly sets the scope to INSTANCE Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is model -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-200?page=all ] Jeremy Boynes updated TUSCANY-200: -- Description: The default scope for system components is currently INSTANCE but the typical usage is module (was: The default scope for system components is currently INSTANCE but the typical usage is model) Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is module -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r394667 - in /incubator/tuscany/java/sca: containers/container.java/src/test/java/org/apache/tuscany/container/java/mock/ core/src/main/java/org/apache/tuscany/core/context/ core/src/m
I think we may need something like this again when we support nested
configuration...what do you think?
On Apr 17, 2006, at 6:37 AM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Mon Apr 17 06:37:49 2006
New Revision: 394667
URL: http://svn.apache.org/viewcvs?rev=394667view=rev
Log:
refactor to remove ConfigurationContext.configure()
the only implementation is empty and all the action happens in build()
Modified:
incubator/tuscany/java/sca/containers/container.java/src/test/
java/org/apache/tuscany/container/java/mock/MockConfigContext.java
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/impl/AbstractCompositeContext.java
incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/runtime/RuntimeContextImpl.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/
tuscany/core/mock/MockConfigContext.java
Modified: incubator/tuscany/java/sca/containers/container.java/src/
test/java/org/apache/tuscany/container/java/mock/
MockConfigContext.java
URL: http://svn.apache.org/viewcvs/incubator/tuscany/java/sca/
containers/container.java/src/test/java/org/apache/tuscany/
container/java/mock/MockConfigContext.java?
rev=394667r1=394666r2=394667view=diff
==
--- incubator/tuscany/java/sca/containers/container.java/src/test/
java/org/apache/tuscany/container/java/mock/MockConfigContext.java
(original)
+++ incubator/tuscany/java/sca/containers/container.java/src/test/
java/org/apache/tuscany/container/java/mock/MockConfigContext.java
Mon Apr 17 06:37:49 2006
@@ -21,12 +21,10 @@
import org.apache.tuscany.core.builder.WireBuilder;
import org.apache.tuscany.core.builder.impl.AssemblyVisitorImpl;
import org.apache.tuscany.core.builder.impl.DefaultWireBuilder;
-import org.apache.tuscany.core.config.ConfigurationException;
import org.apache.tuscany.core.context.ConfigurationContext;
import org.apache.tuscany.core.context.ScopeContext;
import org.apache.tuscany.core.wire.ProxyFactory;
import org.apache.tuscany.model.assembly.AssemblyObject;
-import org.apache.tuscany.model.assembly.Extensible;
/**
* A mock configuration context
@@ -38,7 +36,7 @@
private ListContextFactoryBuilder builders;
private DefaultWireBuilder wireBuilder = new DefaultWireBuilder
();
-
+
public MockConfigContext(ListContextFactoryBuilder builders,
ListWireBuilder wireBuilders) {
this.builders = (builders == null) ? new ArrayList(1) :
builders;
if (wireBuilders != null){
@@ -48,16 +46,13 @@
}
}
-public void configure(Extensible model) throws
ConfigurationException {
-}
-
public void build(AssemblyObject model) throws
BuilderConfigException {
AssemblyVisitorImpl visitor = new AssemblyVisitorImpl
(builders);
visitor.start(model);
}
public void connect(ProxyFactory sourceFactory, ProxyFactory
targetFactory, Class targetType, boolean downScope,
-ScopeContext targetScopeContext) throws
BuilderConfigException {
+ScopeContext targetScopeContext) throws
BuilderConfigException {
wireBuilder.connect(sourceFactory, targetFactory,
targetType, downScope, targetScopeContext);
}
Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java
URL: http://svn.apache.org/viewcvs/incubator/tuscany/java/sca/core/
src/main/java/org/apache/tuscany/core/context/
ConfigurationContext.java?rev=394667r1=394666r2=394667view=diff
==
--- incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/ConfigurationContext.java Mon Apr 17 06:37:49
2006
@@ -15,8 +15,6 @@
import org.apache.tuscany.core.builder.ContextFactoryBuilder;
import org.apache.tuscany.core.builder.WireBuilder;
-import org.apache.tuscany.core.config.ConfigurationException;
-import org.apache.tuscany.model.assembly.Extensible;
/**
* Offers configuration services in the runtime. A
ConfigurationContext is able to configure a model and then build the
@@ -29,13 +27,4 @@
* @version $Rev$ $Date$
*/
public interface ConfigurationContext extends
ContextFactoryBuilder, WireBuilder {
-
-/**
- * Adds additional configuration information to a model object.
- *
- * @param model the model object to be configured
- * @throws ConfigurationException
- */
-public void configure(Extensible model) throws
ConfigurationException;
-
}
Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/
tuscany/core/context/impl/AbstractCompositeContext.java
URL:
Re: svn commit: r394667 - in /incubator/tuscany/java/sca: containers/container.java/src/test/java/org/apache/tuscany/container/java/mock/ core/src/main/java/org/apache/tuscany/core/context/ core/src/m
Jim Marino wrote: I think we may need something like this again when we support nested configuration...what do you think? I couldn't think of why. The model for the whole configuration is created by the loaders and the AssemblyVisitor walks the whole tree to build it. No problem with adding it back if we need it, I just couldn't see why and was trying to keep the API simple. -- Jeremy
[jira] Resolved: (TUSCANY-39) SDO TypeHelper.define not implemented
[ http://issues.apache.org/jira/browse/TUSCANY-39?page=all ] Frank Budinsky resolved TUSCANY-39: --- Resolution: Fixed Committed svn revision 394728. See DefineTypeTestCase for examples of how to use it. SDO TypeHelper.define not implemented - Key: TUSCANY-39 URL: http://issues.apache.org/jira/browse/TUSCANY-39 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: Brent Daniel Opening this JIRA to track the implementation of TypeHelper.define(DataObject). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
IRC-Log (April-17-2006)
(08:31:21 AM) ant_: Hi everyone. 16:30 by my clock, shall we begin? (08:31:48 AM) haleh: yes (08:32:06 AM) jboynes: yep (08:32:16 AM) jboynes: where should we start? (08:33:06 AM) cr22rc: go around and interoduce ourselfs ? .. (just kidding) (08:33:13 AM) *jsdelfino:* are we going to discuss our java1 release? (08:33:35 AM) *jsdelfino:* dates, contents, who volunteers for what? (08:33:36 AM) haleh: makes sense since we are so close to Java1 (08:33:59 AM) *ant_:* jsdelfino: could you paste the wiki to the release details wiki? (08:34:14 AM) ant_: (the wiki url...) (08:34:15 AM) *jsdelfino:* I can paste the link yes (08:34:16 AM) jboynes: http://wiki.apache.org/ws/Tuscany/Tasks (08:34:23 AM) jboynes: (I was there already) (08:35:57 AM) *jsdelfino:* do you guys want to start going over that page? or do we talk about a date for the release first? javaone starts may 16th (08:36:31 AM) ant_: date first. how long do we have? (08:36:36 AM) haleh: Let's work from a date and figure out how much time we have to fit content. (08:36:46 AM) *jsdelfino:* k, sounds good (08:38:16 AM) *jsdelfino:* what about we try to cut the release fri 12 (08:38:37 AM) haleh: Is that enough time to run the release by PMC and get OK for go ahead? (08:38:52 AM) jmarino: Is Java one Monday? (08:39:17 AM) haleh: starts Tuesday (08:39:44 AM) jmarino: so working back from that, do we need to take a vote? (08:40:06 AM) *jsdelfino:* so to be sure we'd have to have run the release by PMC on fri 12 (08:40:10 AM) jboynes: there are two votes (08:40:14 AM) haleh: Is anyone familiar how long it takes to go through PMC for a release? (08:40:18 AM) *jsdelfino:* meaning we need to have the release before then (08:40:31 AM) jboynes: one from the project to actually do the release, the second from the IPMC to appove it (08:40:47 AM) jmarino: there are two votes, do they require the same length of time? (08:41:05 AM) jboynes: first one should take no more than 72 hours, the second may vary depending on how attentive the IPMC folk are being (08:41:26 AM) ant_: does the sponsoring (WS) PMC need to vote? (they used to, but they may have changed?) (08:42:08 AM) jboynes: not sure (08:42:29 AM) jmarino: the other vote is the Tuscany commiters? (08:42:46 AM) jboynes: when we are out of incubation, yes but in incubation I think its just the IPMC (08:42:58 AM) *jsdelfino:* so, if we cut a release 72hours before Fri 12, do we think it's reasonable? (08:43:12 AM) jboynes: ideally we would also have WS-PMC folk voting (08:43:39 AM) jboynes: I would do it a little earlier - there is test time as well (08:44:04 AM) jboynes: I'd hate to put out a bad release (08:44:27 AM) haleh: Agree (08:45:03 AM) *jsdelfino:* I was thinking that 72hours before Fri we'd have the tested / clean release, that's what I meant (08:45:18 AM) haleh: how much time we need for testing and running samples? (08:45:48 AM) *jsdelfino:* and 2 weeks of testing / controlled fixes before... (08:47:15 AM) *BrentDaniel [/[EMAIL PROTECTED]/] entered the room.* (08:47:40 AM) haleh: so, you are saying.. April 28th (controlled fix and test cycle starts), May 9th submitt to PMC and May 12th read (08:47:42 AM) haleh: ready (08:48:03 AM) *jsdelfino:* that's what I had in mind, yes (08:48:45 AM) ant_: I think it has to be ready when we submit to the inc PMC doesn't it, we can't fiddle with the binary after that can we? (08:49:11 AM) jboynes: no (08:49:48 AM) jboynes: they'll check things like the right legal notices etc are in place (and we call it the right name etc.) (08:50:08 AM) jboynes: some may check to see that it runs (08:50:45 AM) jboynes: I think we'd want to do a few dry-runs first to check that the distro looks ok (08:51:46 AM) jboynes: one approach may be to start doing nightlies and then just pick one we want to release (08:51:55 AM) *fbudinsky [/[EMAIL PROTECTED]/] entered the room.* (08:53:16 AM) haleh: Should we announce May 9th as a release candidate and have everyone try it. We can put binaries somewhere. (08:54:14 AM) *jsdelfino:* I think we should put nightly build binaries up for download for the 2 week cycle, and this is what people test (08:54:26 AM) haleh: good idea (08:54:34 AM) *jsdelfino:* goal is: we have selected good binary on or before May 9th (08:54:50 AM) *jsdelfino:* then we go through the approval process (08:54:54 AM) ant_: ok +1 (08:55:13 AM) *jsdelfino:* and adjust anything reported by the PMC b/w 9th and 12th (08:56:12 AM) ant_: is everyone else ok with this? (08:56:33 AM) rfeng: seems to be good (08:56:43 AM) jmarino: it depends on the details but in general it seems ok (08:56:43 AM) haleh: looks good assuming PMC approval is only 72 hours (08:57:41 AM) ant_: its 72 hours minimum. or longer till there's at least three +1 votes (08:58:13 AM) haleh: do we need to let them know that this is our intend to make them aware? (08:58:19 AM) haleh: intent (08:59:08 AM) ant_: we could make our mentors aware so they can vote promptly
WSDL's and extensors....
Ran into a slight snag Several of the more advanced things in Celtix are defined/activated based on extension elements in the WSDL. In celtix, those extensors are defined by a schema and code generated using JAXB. We register an ExtensionRegistry with the WSDLReader so the extensors get parsed into the correct concrete types. However, there doesn't seem to be a way to add an ExtensionRegistry into SCDLAssemblyModelLoader. Thus, none of our extensors are coming out as the expected concrete type. Anyway, there was a mention on the chat today about the wsdl import stuff. Is this something that is known and being addressed? Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
wsdl extension patch
I've attached the patch for core. It's very simple.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
Index: src/main/java/org/apache/tuscany/core/loader/impl/WSDLDefinitionRegistryImpl.java
===
--- src/main/java/org/apache/tuscany/core/loader/impl/WSDLDefinitionRegistryImpl.java (revision 394706)
+++ src/main/java/org/apache/tuscany/core/loader/impl/WSDLDefinitionRegistryImpl.java (working copy)
@@ -26,6 +26,7 @@
import javax.wsdl.PortType;
import javax.wsdl.Service;
import javax.wsdl.WSDLException;
+import javax.wsdl.extensions.ExtensionRegistry;
import javax.wsdl.factory.WSDLFactory;
import javax.wsdl.xml.WSDLReader;
import javax.xml.namespace.QName;
@@ -38,6 +39,7 @@
@org.osoa.sca.annotations.Service(interfaces = {WSDLDefinitionRegistry.class})
public class WSDLDefinitionRegistryImpl implements WSDLDefinitionRegistry {
private final WSDLFactory wsdlFactory;
+private final ExtensionRegistry registry;
private final MapURL, Definition definitionsByLocation = new HashMapURL, Definition();
private final MapString, ListDefinition definitionsByNamespace = new HashMapString, ListDefinition();
@@ -46,6 +48,7 @@
public WSDLDefinitionRegistryImpl() throws WSDLException {
wsdlFactory = WSDLFactory.newInstance();
+registry = wsdlFactory.newPopulatedExtensionRegistry();
}
@org.apache.tuscany.core.system.annotation.Monitor
@@ -63,6 +66,7 @@
monitor.readingWSDL(namespace, location);
WSDLReader reader = wsdlFactory.newWSDLReader();
reader.setFeature(javax.wsdl.verbose, false);
+reader.setExtensionRegistry(registry);
definition = reader.readWSDL(location.toString());
String definitionNamespace = definition.getTargetNamespace();
Index: src/main/java/org/apache/tuscany/core/loader/WSDLDefinitionRegistry.java
===
--- src/main/java/org/apache/tuscany/core/loader/WSDLDefinitionRegistry.java (revision 394706)
+++ src/main/java/org/apache/tuscany/core/loader/WSDLDefinitionRegistry.java (working copy)
@@ -22,6 +22,7 @@
import javax.wsdl.PortType;
import javax.wsdl.Service;
import javax.wsdl.WSDLException;
+import javax.wsdl.extensions.ExtensionRegistry;
import javax.xml.namespace.QName;
/**
@@ -54,4 +55,13 @@
* @return the Service for the supplied name, or null if none has been defined
*/
Service getService(QName name);
+
+
+/**
+ * Returns the ExtensionRegistry that is used when parsing WSDL documents during the
+ * loadDefinition call.
+ *
+ * @return the ExtensionRegistry that is used when parsing WSDL documents.
+ */
+ExtensionRegistry getExtensionRegistry();
}
Re: WSDL's and extensors....
Talked to Jeremy on the IRC (isn't IRC nice for resolving these issues) and we've come up with a plan to add an ExtensionRegistry to the WSDLDefinitionRegistry that can be used to solve this problem. Celtix can use and anyone else that needs it can also use it. Thanks! Dan On Monday 17 April 2006 14:11, Daniel Kulp wrote: Ran into a slight snag Several of the more advanced things in Celtix are defined/activated based on extension elements in the WSDL. In celtix, those extensors are defined by a schema and code generated using JAXB. We register an ExtensionRegistry with the WSDLReader so the extensors get parsed into the correct concrete types. However, there doesn't seem to be a way to add an ExtensionRegistry into SCDLAssemblyModelLoader. Thus, none of our extensors are coming out as the expected concrete type. Anyway, there was a mention on the chat today about the wsdl import stuff. Is this something that is known and being addressed? Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
[jira] Created: (TUSCANY-201) Allow extensions to WSDL processing
Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned to: Jeremy Boynes Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Daniel Kulp updated TUSCANY-201: Attachment: wsdl_patch Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jeremy Boynes Attachments: wsdl_patch Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-203) SDO: Calling getProperty() freezes property list
SDO: Calling getProperty() freezes property list Key: TUSCANY-203 URL: http://issues.apache.org/jira/browse/TUSCANY-203 Project: Tuscany Type: Bug Components: Java SDO Implementation Reporter: Brent Daniel Priority: Minor I'm trying to create properties for a Type. In this particular case, I'm checking to see if I've created the Property already. Calling Type.getProperty(String) causes a property name to Property Map object to be cached in ClassImpl. Any Property objects added to the Type after this will not be returned by Type.getProperty(String). I think I can remove this check without any issues for the time being, so this is a minor problem for me right now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Jeremy Boynes updated TUSCANY-201: -- Attachment: wsdl_patch Attached patch originally sent to mailing list by Dan Kulp Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jeremy Boynes Attachments: wsdl_patch Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-204) DAS should allow for convention to reduce need for configuration
DAS should allow for convention to reduce need for configuration Key: TUSCANY-204 URL: http://issues.apache.org/jira/browse/TUSCANY-204 Project: Tuscany Type: New Feature Components: Java DAS RDB Reporter: Kevin Williams DAS should allow users to avoid configuration items by following specific conventions. For example, in the absence of configuration specifying the prmary key for a table, the DAS could assume that a table column named ID is the PK. Taking this a step further, in the absence of config info specifying a relationship, the DAS could assume any column named _ID is a foreign key key to table . A column named _c could be assumed to be a collision column while _v could be considered a version column. This feature will enable a large set of DAS clients to operate without specifying any separate configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Fw: [continuum] BUILD FAILURE: Tuscany Project
Hi, Here's a sample report from the Tuscany Continuum build. Please let me know if it provides any value if I add tuscany-dev@ws.apache.org to the notfication list. Raymond - Original Message - From: Tuscany Continuum Build tuscany-dev@ws.apache.org To: [EMAIL PROTECTED] Sent: Monday, April 17, 2006 3:02 PM Subject: [continuum] BUILD FAILURE: Tuscany Project Online report : http://localhost:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/967 Build statistics: State: Failed Previous State: Ok Started at: Mon, 17 Apr 2006 15:00:30 -0700 Finished at: Mon, 17 Apr 2006 15:02:45 -0700 Total time: 2m 15s Build Trigger: Schedule Exit code: 1 Building machine hostname: rfeng Operating system : Windows XP Java version : 1.5.0(IBM Corporation) Changes sca\core\src\main\java\org\apache\tuscany\core\loader\impl\WSDLDefinitionRegistryImpl.java sca\core\src\main\java\org\apache\tuscany\core\loader\WSDLDefinitionRegistry.java Output: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] OSOA Specification API jars [INFO] SDO API [INFO] SCA API [INFO] Tuscany Project [INFO] Tuscany SDO Implementation Project [INFO] Tuscany SDO Implementation [INFO] Tuscany SDO Tools [INFO] Tuscany SDO Maven Plugin [INFO] Tuscany DAS [INFO] Tuscany DAS for Relational Databases [INFO] Tuscany SCA Implementation Project [INFO] Tuscany Common [INFO] Tuscany Assembly Model [INFO] Tuscany Core [INFO] Tuscany SCA Containers [INFO] Tuscany Java IoC Container [INFO] Tuscany SCA Bindings [INFO] Tuscany Axis2 Binding [INFO] Tuscany JSON-RPC Binding [INFO] Tuscany JavaScript Component Implementation Type [INFO] Tuscany Apache Tomcat Integration [INFO] Tuscany SCA Tools [INFO] Tuscany SCA Maven Plugin [INFO] Tuscany Samples [INFO] Tuscany HelloWorld Samples [INFO] Tuscany sample HelloWorld [INFO] Tuscany sample multi-component HelloWorld [INFO] Tuscany sample HelloWorld WEB [INFO] Tuscany sample HelloWorld Axis2 [INFO] Tuscany sample HelloWorld JSON-RPC [INFO] Tuscany sample HelloWorld WS Service [INFO] Tuscany sample HelloWorld Webservice SCA Client [INFO] Tuscany BigBank Samples [INFO] Tuscany sample BigBank customer [INFO] Tuscany sample BigBank account [INFO] Tuscany sample BigBank webclient [INFO] Tuscany DAS Samples [INFO] Tuscany DAS sample Company WEB [INFO] Tuscany Samples JavaScript [INFO] Tuscany Samples - JavaScript - Sample 1 - HelloWorld [INFO] Tuscany Samples - JavaScript - Sample 2 - Properties [INFO] Tuscany Samples - JavaScript - Sample 3 - References [INFO] Tuscany Samples - JavaScript - Sample 4 - Initialization [INFO] Tuscany Samples - JavaScript - Sample 5 - Importing Java classes [INFO] Tuscany Samples - JavaScript - Sample 7 - E4X [INFO] [INFO] Building OSOA Specification API jars [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\target [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\target\classes [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\target\test-classes [INFO] Skipping missing optional mojo: org.apache.maven.plugins:maven-site-plugin:attach-descriptor [INFO] [install:install] [INFO] Installing C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\pom.xml to C:\Documents and Settings\zfeng\.m2\repository\org\osoa\spec\SNAPSHOT\spec-SNAPSHOT.pom [INFO] [INFO] Building SDO API [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\sdo\target [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\sdo\target\classes [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\sdo\target\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 17 source files to C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\sdo\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 3 source files to C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\sdo\target\test-classes [INFO] [surefire:test] [INFO] Setting
Summer of Code 2006
Google are re-running their Summer of Code program this year. Project ideas are due before May 1st so that they can be presented to students. For more info see http://wiki.apache.org/general/SummerOfCode2006 I'm willing to help mentor interested students if we have any proposals that we would like to present. -- Jeremy
[jira] Commented: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=comments#action_12374829 ] Jeremy Boynes commented on TUSCANY-201: --- The InterfaceWSDLLoader has been modified to intialize portType information using the WSDLDefinitionRegistry so these extensions should be available there. Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assignee: Jeremy Boynes Attachments: wsdl_patch Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
effects of WSDL Definition caching on WS URLs
Hi, This is my first post. I work on SCA for IBM. I found an issue (which I mentioned on the phone to Sebastien today). I'm not sure if it was a purposeful or accidental design decision, so before opening up a JIRA I thought I'd write this up. In short.. do you really want to cache the URLs along with the WSDL Definitions for both EntryPoints and ExternalServices (for WS binding) together? In detail: When invoking over a WS binding, it might be nice to say that, although both client and server have a copy of the WSDL, that only the client URL matters, but not the server's. I'm talking about the wsdlsoap:address tag, for example in sample HelloWorldWSClient as: wsdlsoap:address location= http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService/ As long as the client is invoked from a separate J2SE environment, you don't have to match your server-side WSDL's wsdlsoap:address URL with the actual deployment location and you can set the server-side WSDL to a URL that can't receive HTTP requests. However, when you call the same service over an external service WS binding from a service co-hosted in the same Tomcat server as the module with the WS Binding entry point, you have a new issue. You generally must keep three pieces of data in synch: client URL, server URL, and deployment URL. Unless you are lucky enough for the client module to be started up first. In that case the server URL no longer matters.Generally speaking, I don't know when the order of module loading is allowed to matter, but I wonder if this is unintended. The low-level reason is the definitionsByNamespace map used by the method org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions , which maps namespaces to WSDL Definitions. If the map and WSDL Definition processing were refactored somehow to save the common portion of the Definition but to only cache the URL portion for ExternalServices, not for EntryPoints, (or something like that), we could eliminate the extra piece of redundant data. Thanks, Scott Kurz
Re: Fw: [continuum] BUILD FAILURE: Tuscany Project
I'd vote for seeing this report only when there are failures. Who will file JIRA issues for failures? On 4/17/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here's a sample report from the Tuscany Continuum build. Please let me know if it provides any value if I add tuscany-dev@ws.apache.org to the notfication list. Raymond - Original Message - From: Tuscany Continuum Build tuscany-dev@ws.apache.org To: [EMAIL PROTECTED] Sent: Monday, April 17, 2006 3:02 PM Subject: [continuum] BUILD FAILURE: Tuscany Project Online report : http://localhost:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/967 Build statistics: State: Failed Previous State: Ok Started at: Mon, 17 Apr 2006 15:00:30 -0700 Finished at: Mon, 17 Apr 2006 15:02:45 -0700 Total time: 2m 15s Build Trigger: Schedule Exit code: 1 Building machine hostname: rfeng Operating system : Windows XP Java version : 1.5.0(IBM Corporation) Changes sca\core\src\main\java\org\apache\tuscany\core\loader\impl\WSDLDefinitionRegistryImpl.java sca\core\src\main\java\org\apache\tuscany\core\loader\WSDLDefinitionRegistry.java Output: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] OSOA Specification API jars [INFO] SDO API [INFO] SCA API [INFO] Tuscany Project [INFO] Tuscany SDO Implementation Project [INFO] Tuscany SDO Implementation [INFO] Tuscany SDO Tools [INFO] Tuscany SDO Maven Plugin [INFO] Tuscany DAS [INFO] Tuscany DAS for Relational Databases [INFO] Tuscany SCA Implementation Project [INFO] Tuscany Common [INFO] Tuscany Assembly Model [INFO] Tuscany Core [INFO] Tuscany SCA Containers [INFO] Tuscany Java IoC Container [INFO] Tuscany SCA Bindings [INFO] Tuscany Axis2 Binding [INFO] Tuscany JSON-RPC Binding [INFO] Tuscany JavaScript Component Implementation Type [INFO] Tuscany Apache Tomcat Integration [INFO] Tuscany SCA Tools [INFO] Tuscany SCA Maven Plugin [INFO] Tuscany Samples [INFO] Tuscany HelloWorld Samples [INFO] Tuscany sample HelloWorld [INFO] Tuscany sample multi-component HelloWorld [INFO] Tuscany sample HelloWorld WEB [INFO] Tuscany sample HelloWorld Axis2 [INFO] Tuscany sample HelloWorld JSON-RPC [INFO] Tuscany sample HelloWorld WS Service [INFO] Tuscany sample HelloWorld Webservice SCA Client [INFO] Tuscany BigBank Samples [INFO] Tuscany sample BigBank customer [INFO] Tuscany sample BigBank account [INFO] Tuscany sample BigBank webclient [INFO] Tuscany DAS Samples [INFO] Tuscany DAS sample Company WEB [INFO] Tuscany Samples JavaScript [INFO] Tuscany Samples - JavaScript - Sample 1 - HelloWorld [INFO] Tuscany Samples - JavaScript - Sample 2 - Properties [INFO] Tuscany Samples - JavaScript - Sample 3 - References [INFO] Tuscany Samples - JavaScript - Sample 4 - Initialization [INFO] Tuscany Samples - JavaScript - Sample 5 - Importing Java classes [INFO] Tuscany Samples - JavaScript - Sample 7 - E4X [INFO] [INFO] Building OSOA Specification API jars [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Apache\continuum-1.0.2\apps\continuum\working-directory\1\spec\target [INFO] Deleting directory C:\Apache\continuum- 1.0.2\apps\continuum\working-directory\1\spec\target\classes [INFO] Deleting directory C:\Apache\continuum- 1.0.2\apps\continuum\working-directory\1\spec\target\test-classes [INFO] Skipping missing optional mojo: org.apache.maven.plugins:maven-site-plugin:attach-descriptor [INFO] [install:install] [INFO] Installing C:\Apache\continuum- 1.0.2\apps\continuum\working-directory\1\spec\pom.xml to C:\Documents and Settings\zfeng\.m2\repository\org\osoa\spec\SNAPSHOT\spec-SNAPSHOT.pom [INFO] [INFO] Building SDO API [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Apache\continuum- 1.0.2\apps\continuum\working-directory\1\spec\sdo\target [INFO] Deleting directory C:\Apache\continuum- 1.0.2\apps\continuum\working-directory\1\spec\sdo\target\classes [INFO] Deleting directory C:\Apache\continuum- 1.0.2\apps\continuum\working-directory\1\spec\sdo\target\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 17 source files to
