Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
I wondered about using Tuscany PolicyBuilders and Interceptors to help with E4X support for the work required in TUSCANY-418, TUSCANY-419, and TUSCANY-420. Right now the E4X code isn't so elegant with the way it works out when and how to convert the Java objects in a message into E4X XML, and with the current code i can't get E4X XML as parameters on reference invocations working. Looking at how the code for async works, it seems like for E4X support there could be source and target policy builders that look at the wires and when required (*) insert an interceptor that converts the message objects from/to XmlObjects, and then the JavaScript container would simply always convert XmlObjects from/to E4X XML objects. (*) the when required would be something like when the wire target is a JavaScript component with interface described by a WSDL portType, or a wire source is a JavaScript component and the wire target has an interface described with WSDL. Does this sound like a reasonable use of PolicyBuilders and Interceptors? It seems like something like this may also be a step on the way to the efficient streaming of messages in TUSCANY-104? ...ant
[jira] Created: (TUSCANY-443) Add further code to support use of string objects
Add further code to support use of string objects - Key: TUSCANY-443 URL: http://issues.apache.org/jira/browse/TUSCANY-443 Project: Tuscany Type: Improvement Components: C++ SDO Versions: Cpp-current Environment: All supported Reporter: Geoff Winn Add further methods that extend the interface to allow parameters to be passed as SDOString objects. Revise the implementation of SDOString to inhertit from std::string On Windows XP all tests pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-443) Add further code to support use of string objects
[ http://issues.apache.org/jira/browse/TUSCANY-443?page=all ] Geoff Winn updated TUSCANY-443: --- Attachment: TUSCANY-443.patch Add further code to support use of string objects - Key: TUSCANY-443 URL: http://issues.apache.org/jira/browse/TUSCANY-443 Project: Tuscany Type: Improvement Components: C++ SDO Versions: Cpp-current Environment: All supported Reporter: Geoff Winn Attachments: TUSCANY-443.patch Add further methods that extend the interface to allow parameters to be passed as SDOString objects. Revise the implementation of SDOString to inhertit from std::string On Windows XP all tests pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board Report for June 2006
Dear WS Folks, It's time for our quarterly report to the board. It's our duty as committers and pmc members to provide an accurate and detailed description of our activities to the board. So please take a few minutes and add information on projects that you are involved in. http://wiki.apache.org/ws/ReportForJune2006 Thanks, dims - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-443) Add further code to support use of string objects
[ http://issues.apache.org/jira/browse/TUSCANY-443?page=all ] Ed Slattery reassigned TUSCANY-443: --- Assign To: Ed Slattery Add further code to support use of string objects - Key: TUSCANY-443 URL: http://issues.apache.org/jira/browse/TUSCANY-443 Project: Tuscany Type: Improvement Components: C++ SDO Versions: Cpp-current Environment: All supported Reporter: Geoff Winn Assignee: Ed Slattery Attachments: TUSCANY-443.patch Add further methods that extend the interface to allow parameters to be passed as SDOString objects. Revise the implementation of SDOString to inhertit from std::string On Windows XP all tests pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SCA Management API for Tuscany
Hi Adi, I already created a Jira issue regarding how to set up Tuscany helloworldws-celtix demo with JMX instrumentation last week, a patch is provided at the same, which includes an updated readme and a celtix config file. http://issues.apache.org/jira/browse/TUSCANY-416 Dan Kulp has kindly offered to help me to commit this patch. Cheers, Jervis -Original Message- From: Sakala, Adinarayana Sent: Friday, June 02, 2006 9:50 PM To: tuscany-dev@ws.apache.org Subject: RE: SCA Management API for Tuscany Jervis FYI, I tried running sca helloworld-celtix server pointing to the celtix configuration file and i could actually bring up the jmx console and see the instrumentation. I had this working for Javaone Tuscany BOF. Add following system property when starting the sca server. -Dceltix.config.file=file:///C:\kittesting\tuscany-incubating-M1\samples\sca\helloworldws-celtix/server.xml Attached is the celtix mgmt configuration file (server.xml). Note: I didnt try this with M1 release kit. you probably may want to do so :) thanks, Adi Sakala -Original Message- From: Liu, Jervis Sent: Friday, June 02, 2006 1:34 AM To: tuscany-dev@ws.apache.org Subject: RE: SCA Management API for Tuscany Hi Jim, Most Celtix management codes are located under trunk\celtix-rt\src\main\java\org\objectweb\celtix\bus\managem ent, an example of how instrumentation component is written can be found in trunk\celtix-rt\src\main\java\org\objectweb\celtix\bus\busimpl \CeltixBusInstrumentation.java. Celtix management design note can be found from https://wiki.objectweb.org/celtix/Wiki.jsp?page=ManamgentDevPl an, and Celtix management manual is available from trunk\celtix-distribution\src\site\docs\UserGuides\management.pdf Let me know if we are considering adding management capabilities into Tuscany. I would be very interested to do some work in this area. Cheers, Jervis Liu -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 1:21 AM To: tuscany-dev@ws.apache.org Subject: Re: SCA Management API for Tuscany Hi Jervis, This is an interesting approach. Could you point the list to a Celtix (Java) package where we could start to look and base a discussion around? Jim On May 31, 2006, at 8:08 PM, Liu, Jervis wrote: Hi Ant, Obviously the easiest way to do this is adding whatever methods we need into classes where those methods reside naturally. But I do not see those methods can be qualified as management APIs. If your intention is to have APIs that potentially can be exposed to management/instrumentation (e.g., to JMX MBeans or SNMP), I think there is a neater way to do this. Instead of having Tuscany core polluted by management stuff, we can have a plugable Tuscany management implementation. For example, each component that needs instrumentation will have a corresponding instrumentation component, management APIs are defined in instrumentation components, the call to management APIs can be delegated to the real runtime APIs or can be implemented using management specific logic (such as service counter). Management APIs in instrumentation component can be marked by management annotations, such way allows the dynamic generation of JMX Mbeans. I am not sure whether or not we have a general Tuscany management/instrumentation story on the roadmap, just something to think about. If you have interest, you can also take a look at Celtix management. Cheers, Jervis Liu -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 31, 2006 11:44 PM To: tuscany-dev@ws.apache.org Subject: SCA Management API for Tuscany How about having a management API for Tuscany? The use case i have right now for this is so a J2SE client to can find out what are the valid service names it can use in the locateService method on the org.osoa.sca.ModuleContext interface. This is to make the JavaScript interactive client able to automatically register all the available services to the JavaScript environment, see: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200605.mbox/ [EMAIL PROTECTED] So that could be a method like: public ListString getServiceNames(); Any suggestions as to where a method like this could go and how to get at one of those things? ...ant See the thread: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200605.mbox/ [EMAIL PROTECTED] - 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]
[jira] Assigned: (TUSCANY-416) Update helloworldws-celtix sample readme on instrumentation support
[ http://issues.apache.org/jira/browse/TUSCANY-416?page=all ] Daniel Kulp reassigned TUSCANY-416: --- Assign To: Daniel Kulp Update helloworldws-celtix sample readme on instrumentation support --- Key: TUSCANY-416 URL: http://issues.apache.org/jira/browse/TUSCANY-416 Project: Tuscany Type: Improvement Components: Java SCA Samples Reporter: Jervis Liu Assignee: Daniel Kulp Priority: Minor Attachments: samples.patch Update helloworldws-celtix sample readme on instrumentation support -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-447) AttributeWithSDOPropertyType and AttributeWithSDOPropertySDOOppositePropertyType not supported
AttributeWithSDOPropertyType and AttributeWithSDOPropertySDOOppositePropertyType not supported --- Key: TUSCANY-447 URL: http://issues.apache.org/jira/browse/TUSCANY-447 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws reading ComplexTypeAttributesTest Attribute=Attribute AttributeWithDefaultValue=AttributeWithDefaultValueDefaultValue AttributeWithFixedValue=AttributeWithFixedValueFixedValue AttributeWithSDOAliasName=AttributeWithSDOAliasName AttributeWithSDODataType=AttributeWithSDODataType AttributeWithSDOName=AttributeWithSDODataType AttributeWithSDOPropertySDOOppositePropertyType=idvalue0 AttributeWithSDOPropertyType=idvalue0 AttributeWithSDOString=AttributeWithSDOString tns:AttributeReference=AttributeReference and writing out again gives rise to ComplexTypeAttributesTest Attribute=Attribute AttributeWithSDONameSDOName=AttributeWithSDODataType AttributeWithSDOAliasName=AttributeWithSDOAliasName AttributeWithDefaultValue=AttributeWithDefaultValueDefaultValue AttributeWithFixedValue=AttributeWithFixedValueFixedValue AttributeReference=AttributeReference AttributeWithSDOString=AttributeWithSDOString AttributeWithSDODataType=AttributeWithSDODataType / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-448) ElementWithSDOName fails on write
ElementWithSDOName fails on write - Key: TUSCANY-448 URL: http://issues.apache.org/jira/browse/TUSCANY-448 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Reading ElementWithSDONameElementWithSDOName/ElementWithSDOName against schema element name=ElementWithSDOName sdo:name=ElementWithSDONameSDOName type=string/ and writing out again gives rise to a runtime failure -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-449) Implementation ignores ElementSubstitutionGroupBase
Implementation ignores ElementSubstitutionGroupBase Key: TUSCANY-449 URL: http://issues.apache.org/jira/browse/TUSCANY-449 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Reading xml tns:ElementSubstitutionGroupExtends ElementInSubstitutionGroupBaseElementInSubstitutionGroupBase/ElementInSubstitutionGroupBase ElementInSubstitutionGroupExtendsElementInSubstitutionGroupExtends/ElementInSubstitutionGroupExtends /tns:ElementSubstitutionGroupExtends with schema complexType name=ComplexTypeSubstitutionGroupBaseType sequence element name=ElementInSubstitutionGroupBase type=string/ /sequence /complexType element name=ElementSubstitutionGroupBase type=tns:ComplexTypeSubstitutionGroupBaseType/ complexType name=ComplexTypeSubstitutionGroupExtendsType complexContent extension base=tns:ComplexTypeSubstitutionGroupBaseType sequence element name=ElementInSubstitutionGroupExtends type=string/ /sequence /extension /complexContent /complexType element name=ElementSubstitutionGroupExtends type=tns:ComplexTypeSubstitutionGroupExtendsType substitutionGroup=tns:ElementSubstitutionGroupBase/ And writing out gives rise to no output for this element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-450) ElementOfSimpleTypeWithSDOPropertyType and ElementOfSimpleTypeWithSDOOppositePropertyType not supported
ElementOfSimpleTypeWithSDOPropertyType and ElementOfSimpleTypeWithSDOOppositePropertyType not supported --- Key: TUSCANY-450 URL: http://issues.apache.org/jira/browse/TUSCANY-450 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws reading ElementOfSimpleTypeWithSDOPropertyTypeidvalue0/ElementOfSimpleTypeWithSDOPropertyType ElementOfSimpleTypeWithSDOOppositePropertyTypeidvalue0/ElementOfSimpleTypeWithSDOOppositePropertyType with schema element name=ElementOfSimpleTypeWithSDOPropertyType type=IDREF sdo:propertyType=tns:SimpleTypeWithNameType/ element name=ElementOfSimpleTypeWithSDOOppositePropertyType type=IDREF sdo:propertyType=tns:SimpleTypeWithNameType sdo:oppositeProperty=tns:ElementOfSimpleTypeWithSDOPropertyType/ and writing out again lead to these element being missing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-452) IDREF, IDREFS not supported
IDREF, IDREFS not supported --- Key: TUSCANY-452 URL: http://issues.apache.org/jira/browse/TUSCANY-452 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws Reading xml IDREFidvalue0/IDREF IDREFSidvalue0/IDREFS with schema element name=IDREF type=IDREF/ element name=IDREFS type=IDREFS/ wehn written out again these elements are missing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-453) SDO:int is not supported
SDO:int is not supported Key: TUSCANY-453 URL: http://issues.apache.org/jira/browse/TUSCANY-453 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Environment: All Reporter: Simon Laws C++ SDO currently implements SDO:int as SDO:Integer which in turn is a long. This may cause problems if the C++ implementation writes out a long and subsequently another implementation faithfully tries to interpret it as an int -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help with proxies and component context's getInstance
Hi everyone, I am experimenting with adding XSLT as an implementation type (with a WSDL interface for now). I have looked at the javascript container and found it very helpful, but I have two questions about the use of ComponentContext and proxy factories. Among other things, I have created : public class XSLTComponentContext extends AbstractContext implements AtomicContext In XSLT the components are stateless: you just run the whole stylesheet and return the result tree. I am confused about what getInstance should return if one is dealing with a non-Java implementation type. The Java container returns the actual class that implements the component's Java interface and the javascript container returns a proxy from a proxy factory... One option is to return what getTargetInstance returns (the XSLTInvoker) but that avoids the proxy chains so doesn't feel right... On the other hand, if i do something similar to what the javascript implementation does, then the result from locateService is something of class $Proxy37 that has JDKInvocationHandler .. Not sure what one would do with that (?). Am I supposed to create my own proxy factory and plug it in somehow ? Any insight appreciated into the right way to set up the proxies and the getInstance method so that a non-java implementation type that is stateless fits properly. thanks! Rania - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - 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] - 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]
[jira] Closed: (TUSCANY-416) Update helloworldws-celtix sample readme on instrumentation support
[ http://issues.apache.org/jira/browse/TUSCANY-416?page=all ] Daniel Kulp closed TUSCANY-416: --- Resolution: Fixed Patch applied. Thanks! Update helloworldws-celtix sample readme on instrumentation support --- Key: TUSCANY-416 URL: http://issues.apache.org/jira/browse/TUSCANY-416 Project: Tuscany Type: Improvement Components: Java SCA Samples Reporter: Jervis Liu Assignee: Daniel Kulp Priority: Minor Attachments: samples.patch Update helloworldws-celtix sample readme on instrumentation support -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Next week would be better for me. I'm landing home from the US on Friday and 8-10PST is 4-6pm on Friday evening which aint popular in blighty :-) Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - 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] - 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] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
By the way can someone explain what the term Recursive Core Architecture means? Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: It looks as if we have the choice of Thursday or Friday this week, or rescheduling for two weeks. I'd prefer we do it this week. Jim On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote: Next week would be better for me. I'm landing home from the US on Friday and 8-10PST is 4-6pm on Friday evening which aint popular in blighty :-) Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy and I providing an overview of changes to the SCA specifications and related recursive core architecture work going on in the sandbox, perhaps Wednesday. I'm happy to do this, however, I'm a bit concerned that since this has not been brought up on the list interested people may not be able to attend on short notice. Also, a time has not been mentioned. I propose 9PST-11PST, using a combination of Web-Ex and toll-free dial- in, which will be provided later. If interested people cannot make that time, please speak up so we can arrange an alternate (please don't hesitate to do so, even if you are the only one). Jim, I'm afraid I can't make 8 to 10 on Wed - can do before or after. -- Jeremy - 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] - 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] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.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] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com
UML diagrams and a draft PDF document for the sandbox core are uploaded to Tuscany Wiki
Hi, I uploaded a draft PDF document together with a set of UML class diagrams to Tuscany wiki @ http://wiki.apache.org/ws/Tuscany/TuscanyJava/SandboxCore. Please note these documents are work in progress and not guaranteed to be accurate and complete. They are produced based on my understanding of the new core code developed by Jim and Jeremy in the sandbox. It's subject to review and revision. I hope it will be hopeful for you to understand the code. Thanks, Raymond
[jira] Resolved: (TUSCANY-22) Errors serializing an SDO2 graph
[ http://issues.apache.org/jira/browse/TUSCANY-22?page=all ] Frank Budinsky resolved TUSCANY-22: --- Resolution: Fixed Fixed in revision 412225. Errors serializing an SDO2 graph Key: TUSCANY-22 URL: http://issues.apache.org/jira/browse/TUSCANY-22 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-Mx Environment: 2/2 EMF integration build Reporter: Brent Daniel Fix For: Java-Mx I am having a problem with serialization of an SDO2 datagraph Using java serialization (ObjectOutputStream.writeObject()), I receive the following exception: java.lang.UnsupportedOperationException at org.eclipse.emf.common.util.ECollections$EmptyUnmodifiableEList.add(ECollections.java:638) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.setTrackingModification(ResourceImpl.java:1212) at org.apache.tuscany.sdo.impl.DataGraphImpl.getWriteReplacement(DataGraphImpl.java:740) at org.apache.tuscany.sdo.impl.DataGraphImpl.getWriteReplacement(DataGraphImpl.java:766) at org.apache.tuscany.sdo.impl.DataObjectImpl.writeReplace(DataObjectImpl.java:113) 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 java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:1059) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1063) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:324) at org.apache.tuscany.das.rdb.test.SerializationTests.testReadandSerialize(SerializationTests.java:69) Note, the same test case works with SDO 1 and is currently available in SVN (org.apache.tuscany.das.rdb.test.SerializationTests) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recursive core architectural overview
Good question... In the spec group, one of the major changes we are currently undertaking is a move to a recursive model where components can either be leaf-types (atomic) or composite, in which case they may contain children. In previous versions of the spec we had a two-level model (module components and components which were leaf-types). The recursive model simplifies a great deal since it eliminates a number of unnecessary concepts. For example, components used to offer services and have references while module components offered entry points and had external services. Since there is a common type, component, we can dispense with the separate concepts of entry point and external service and just call them service (~entry point) and reference (~external service). I think this makes sense from a conceptual standpoint since a composite component may have a service bound to some protocol/transport combination such as SOAP/HTTP while a service on a POJO may be thought of as having a shared memory/by- reference binding. Besides making the implementation more concise, It also makes slideware easier since we have the same picture at different levels :-) In any event, this was one of the topics we were intending to cover on the call. I think this is a good question specifically because I believe the coordination between the spec collaboration and the Tuscany community could be a lot better. This partly arises from the fact that the people such as myself and Jeremy who wear both hats are swamped with work and things sometimes get delayed. Another reason for the less- than-ideal situation is that a collaboration model between the spec group and Tuscany has not been put in place. Regarding the latter, I believe there are some systemic improvements we can make such as not having to channel issues through Jeremy or myself as well as having more defined input mechanisms between the two groups. The spec group is aware of the issue as well so I think it would be fruitful for us to come up with some concrete proposals we could discuss with them. Ideas? Jim On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote: By the way can someone explain what the term Recursive Core Architecture means? Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: It looks as if we have the choice of Thursday or Friday this week, or rescheduling for two weeks. I'd prefer we do it this week. Jim On Jun 6, 2006, at 1:28 PM, Paul Fremantle wrote: Next week would be better for me. I'm landing home from the US on Friday and 8-10PST is 4-6pm on Friday evening which aint popular in blighty :-) Paul On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote: I'm out all next week so it sounds as if Friday is the best time for most people. Jim On Jun 6, 2006, at 10:42 AM, Rick wrote: I like to second all of what Ant wrote and also Ken Tam asked if it could not be delayed till next week. I'd like to be up to speed and just a few days more would help to digest it all to be more informed, but I'll go with Friday if that's what it is. ant elder wrote: I agree 100% with Ken, could you give just a little more information about whats going on here? That email just gives hints - there's been some SCA spec changes, there's some code in the the sandbox for recursive core architecture work and to clearly demarcate the runtime extension mechanism. What are the spec changes, are there any new spec documents people can review? Is there anything else that has changed from the M1 release code to whats in the sandbox? Whats the state of the sandbox code, does it work, are there any samples, does bigbank run? What is the intention for the future of the sandbox code? It sounds like we're being asked to just go look at some code in the sandbox and work all this out for ourselves. There's a lot of people listening who have no idea whats going on, so some more detailed background information would really help. Friday is bad for me I can't make anything much after 9am PDT, same for Mondays after 5:30BST, but i'll fit in with most times any other day. ...ant On 6/5/06, Kenneth Tam [EMAIL PROTECTED] wrote: I am very interested in this, but the short notice also concerns me. Can we push this out to at least the end of the week (say Friday?) or sometime next week so that more people on the list get a chance to find out about it and fit it into their schedules? Also, Jim Jeremy -- if you guys have anything in the way of explanatory material that you could circulate on the list/wiki before the presentation, I think that would be very useful.. certainly I could use a little more context to help with my own browsing. thanks, k On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim Marino wrote: Hi, There has been some mention offline of Jeremy
Re: UML diagrams and a draft PDF document for the sandbox core are uploaded to Tuscany Wiki
Thanks Raymond for taking this on. I have made to refactors today so could you regenerate (I hope you didn't have to do the model by hand)? The two basic changes I did are: 1. Rename ScopeContext to ScopeContainer since it contains component implementation instances 2. Internalized InstanceWrapper (tracks implementation instance lifecycle) to the scope container implementations. This means that component type extensions will be able to implement one less class. As part of this refactor, I also renamed PojoImplementationWrapper to ImplementationWrapperImpl since it is generic and not specific to POJOs. Thanks, Jim On Jun 6, 2006, at 2:46 PM, Raymond Feng wrote: Hi, I uploaded a draft PDF document together with a set of UML class diagrams to Tuscany wiki @ http://wiki.apache.org/ws/Tuscany/ TuscanyJava/SandboxCore. Please note these documents are work in progress and not guaranteed to be accurate and complete. They are produced based on my understanding of the new core code developed by Jim and Jeremy in the sandbox. It's subject to review and revision. I hope it will be hopeful for you to understand the code. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WSDL file misloading running sca demo helloworldws
Hi Guys, I am currently testing the interoperability between Tuscany and Celtix. When I changed Tuscany sca demo helloworldws's WSDL file to include in/out parameters, I found this change in WSDL is not recognized by Tuscany runtime at all. How to reproduce: 1. Change helloworld.wsdl output message getGreetingsResponse's part element from getGreetingsResponse to getGreetings wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message 2. Run helloworldws demo, send a request from a client 3. Check the response from helloworldws, it still refers to getGreetingsResponse element: helloworld:getGreetingsResponse xmlns:helloworld=http://helloworld; helloworld:getGreetingsReturnHello jervis/helloworld:getGreetingsReturn /helloworld:getGreetingsResponse Through debugging, I found the Binding object created for helloworldws demo is actually referring to helloworlde4xws demo's WSDL file other than it's own WSDL. Remove sample-helloworlde4xws and sample-helloworldjsclient directories from Tomcat, everything works. Any ideas? Cheers, Jervis Liu
[jira] Created: (TUSCANY-454) WSDL file misloading running sca demo helloworldws
WSDL file misloading running sca demo helloworldws -- Key: TUSCANY-454 URL: http://issues.apache.org/jira/browse/TUSCANY-454 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Reporter: Jervis Liu Priority: Minor When I changed Tuscany sca demo helloworldws's WSDL file to include in/out parameters, I found this change in WSDL is not recognized by Tuscany runtime at all. How to reproduce: 1. Change helloworld.wsdl output message getGreetingsResponse's part element from getGreetingsResponse to getGreetings wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message 2. Run helloworldws demo, send a request from a client 3. Check the response from helloworldws, it still refers to getGreetingsResponse element: helloworld:getGreetingsResponse xmlns:helloworld=http://helloworld; helloworld:getGreetingsReturnHello jervis/helloworld:getGreetingsReturn /helloworld:getGreetingsResponse Through debugging, I found the Binding object created for helloworldws demo is actually referring to helloworlde4xws demo's WSDL file other than it's own WSDL. Remove sample-helloworlde4xws and sample-helloworldjsclient directories from Tomcat, everything works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
