Re: [C++] Creating an SDO DataObject for the properties of a component
Sebastien, I'm fixing this. It shouldn't take long. Cheers, On 22/08/06, Pete Robbins [EMAIL PROTECTED] wrote: ah! On 22/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It doesn't work at all now. With SCDL 0.9 a component declaration looked like that: component properties v:Fredabc/v:Fred v:Joexyz/v:Joe v:Joetuv/v:Joe /properties /component The DataObject loaded from that looked exactly like what the client Cpp code expected, allowing you to code ComponentContext.getProperties()-getCString(Fred)... SCDL 0.95 now looks pretty different: component property name=Fredabc/property property name=Joexyz/property property name=Joetuv/property /component ... missing the convenient properties parent element and in a very different form now. I'm guessing that we don't want the client code to change, so we need to massage the DataObject loaded from SCDL to look like what the client code wants to see. The other thing is that we should use the property types specified in the component type instead of guessing the types from the instance properties in the component declaration. So I'm basically trying to fix ModelLoader to created the expected DataObject from what we get from SCDL. In the SupplyChain scenario I have multiple Manufacturer and Warehouse components, same implementation but configured with different properties so I need to get this property stuff working... Ok I understand the problem. I wasn't up to date with the latest definition of properties. If the current interface to properties is not workable then we can always feed that back to the spec group. Anyho... I think what we need to do is 1)create a DataFactory for the properties and populate it with the types required for the properties (basic xml types will be there by default but any user defined complex types will have to be defined in a schema somewhere so lets stick to simple types for now). 2) When loading the definitions of the properties from the componentType we need to create a new SDO Type for properties associated with this component and add it to the DataFactory. So we would do something like: dataFactory-addType(someNamespace, componentProperties, ) dataFactory-addPropertyToType((propertyName, propType for each of the properties defined) 3) create a DO of someNamespace, componentProperties type and save the DOPtr in the Component defintion in the model 4) For each property set propertyDO-set(propertyName, value) 5) ComponentContext::GetProperties will return the propertyDO from the Component voila! So we need to create a datafactory per componentType I think. -- Pete -- Pete
Re: svn commit: r432722 [1/2] - in /incubator/tuscany/java/sca/containers/container.spring/src: main/java/org/apache/tuscany/container/spring/config/ main/java/org/apache/tuscany/container/spring/i
I spoke to Rod today, he seems happy to do the appropriate software grant to Apache as per the apache licensing conventions. NOTICES.txt would then need to contain an appropriate attribution. I think this would probably only need to be a temporary measure, but who knows. Thanks andy At 12:05 PM 8/21/2006, ant elder wrote: The bit I was specifically asking about was in the license header having Copyright 2002-2006 the original author or authors., with the authors being Adrian and Rod. I'm not sure if we can have that copyright in our ASF source files, but as we're not the copyright holders I don't think we can delete that line either. ..ant PS, I'm also not sure we can have source packages called org.springframeworkin our codebase. Doesn't all our code have to be org.apache.? On 8/21/06, Andy Piper [EMAIL PROTECTED] wrote: At 17:23 19/08/2006, Jim Marino wrote: Andy was an author as well. All code is licensed under an ASF license and we preserved the license in the files so I believe we are o.k. If not, then I would be happy to just get Rod and Adrian to submit them as well. Andy, could you elaborate? I, of course, checked with Adrian and Rod before submitting this. The code is all ASL licensed and they are delighted for it to be included in Tuscany. Ultimately the generic Spring code should be included in a spring disto so that Tuscanny can simply specify it as a dependency - however, we are a ways from that as yet. I plan on integrating back into the I21 codebase (at their request) changes that come out of the Tuscany integration (just the generic Spring pieces) so that the two will be kept in sync. Thanks andy ___ 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] ___ 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]
Re: [C++] Creating an SDO DataObject for the properties of a component
Pete Robbins wrote: Sebastien, I'm fixing this. It shouldn't take long. Cheers, On 22/08/06, Pete Robbins [EMAIL PROTECTED] wrote: ah! On 22/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It doesn't work at all now. With SCDL 0.9 a component declaration looked like that: component properties v:Fredabc/v:Fred v:Joexyz/v:Joe v:Joetuv/v:Joe /properties /component The DataObject loaded from that looked exactly like what the client Cpp code expected, allowing you to code ComponentContext.getProperties()-getCString(Fred)... SCDL 0.95 now looks pretty different: component property name=Fredabc/property property name=Joexyz/property property name=Joetuv/property /component ... missing the convenient properties parent element and in a very different form now. I'm guessing that we don't want the client code to change, so we need to massage the DataObject loaded from SCDL to look like what the client code wants to see. The other thing is that we should use the property types specified in the component type instead of guessing the types from the instance properties in the component declaration. So I'm basically trying to fix ModelLoader to created the expected DataObject from what we get from SCDL. In the SupplyChain scenario I have multiple Manufacturer and Warehouse components, same implementation but configured with different properties so I need to get this property stuff working... Ok I understand the problem. I wasn't up to date with the latest definition of properties. If the current interface to properties is not workable then we can always feed that back to the spec group. Anyho... I think what we need to do is 1)create a DataFactory for the properties and populate it with the types required for the properties (basic xml types will be there by default but any user defined complex types will have to be defined in a schema somewhere so lets stick to simple types for now). 2) When loading the definitions of the properties from the componentType we need to create a new SDO Type for properties associated with this component and add it to the DataFactory. So we would do something like: dataFactory-addType(someNamespace, componentProperties, ) dataFactory-addPropertyToType((propertyName, propType for each of the properties defined) 3) create a DO of someNamespace, componentProperties type and save the DOPtr in the Component defintion in the model 4) For each property set propertyDO-set(propertyName, value) 5) ComponentContext::GetProperties will return the propertyDO from the Component voila! So we need to create a datafactory per componentType I think. -- Pete Cool, Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-660) Should not have to repeat a service definition to publish it out of a composite
Should not have to repeat a service definition to publish it out of a composite - Key: TUSCANY-660 URL: http://issues.apache.org/jira/browse/TUSCANY-660 Project: Tuscany Issue Type: Bug Components: Specification Affects Versions: Cpp-current Reporter: Jean-Sebastien Delfino Assigned To: Jean-Sebastien Delfino I'm trying to build a reasonably complex scenario with SCA (0.95), and wondering why I have to repeat myself so many times when I define services. Let's imagine that I want to build a simple Quoting service application. Here's what I'll want to do: Step 1. define a Quote component type, in the component type define a service, give it a name, specify its interface. Step 2. create a component of that type in a composite, indicate that I want my service visible outside the composite Step 3. take my composite to a system, configure an instance of it, bind my service to a SOAP endpoint Here's what it looks like with SCA 0.95: Step 1: Quote.componentType componentType ... service name=QuoteService interface.wsdl interface=http://www.whatever.org/QuoteService/#wsdl.portType(Quote)/ /service ... /componentType Step 2: QuotingEngine.composite composite... service name=QuoteService interface.wsdl interface=http://www.whatever.org/QuoteService/#wsdl.portType(Quote)/ referenceQuotingEngineGorpImpl/QuoteService/reference /service ... /composite Step 2: MyDeployedAndConfiguredQuotingSystem.composite composite... service name=QuoteService interface.wsdl interface=http://www.whatever.org/QuoteService/#wsdl.portType(Quote)/ binding.ws port=http://www.whatever.org/QuoteService/#wsdl.endpoint(QuoteService/QuoteSOAPPort)/ referenceMyDeployedQuotingEngine/QuoteService/reference /service ... /composite Why do I need to repeat the definition of QuoteService three times in this example? The SCA specification should not force me to repeat service definitions just to publish/promote them out of a composite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] SCDL and WSDL files for the WS-I SupplyChain scenario
Hi, I just checked in a first cut of the SCDL files composing the WS-I SupplyChain sample application, as well as the WSDL files describing the ports for all the Web services under tuscany/cpp/sca/samples/SupplyChain. I tried to follow the structure described in the WS-I supplychain architecture document at http://www.ws-i.org/SampleApplications/SupplyChainManagement/2003-12/SCMArchitecture1.01.pdf, including: - a demo sub-system, including a client reference and a logging service - a retailer sub-system, composed of a retailer service component and three Warehouses - manufacturer sub-systems serving the Warehouses - composites describing the implementation of the logging, retailer, warehouse and manufacturer components. Note that I'm still using the sub-system terminology here... My intention is not go back to the 0.9 spec :) but I am influenced by the WS-I spec which uses the term system to refer to these things, and I'm looking for good terms to distinguish between system-configuration-composites and composites-describing-pieces-of-implementations. After this first pass trying to define all the SCDL artifacts, I have a few comments, and requests for comments: - I had to repeat service definitions many times just to publish/promote services out of composites. IMO this needs to be simplified. I opened issue JIRA 660 for this and also raised it to the OSOA specification workgroup. - In my composite definitions I just needed to declare SOAP bindings for my services and references, but since binding.ws requires a port I had to create dummy ports with dummy SOAP addresses for all the services and references, knowing that these would be different once deployed to my system. I'll raise this issue to the spec group as well. - I was not sure when to use wires and when to use URIs on bindings. I tended to use binding URIs instead of wires in all the cases where I had to specify the binding anyway, resulting in very few wires. It would be great if some SCA spec experts on this list could look at what I've done and help me get the wiring right... - The callback pattern described in the WS-I document didn't seem to fit with SCA conversational callbacks as I understood them. The supplychain callback does not seem conversational to me, or if it is then the correlation between the various exchanges is done through business data and URLs manually added to SOAP headers, and I'm not sure how that fits with SCA callbacks. So for now I have modeled this contract with two independent reference + service in both directions. This seems consistent with what the other existing implementations of the WS-I supplychain sample have done as well. - I was not sure how to publish a reference with multiplicity out of a composite. See supplychain.retailer.composite to see what I did to define the warehouses references (which needs to point to three warehouses). The warehouses reference is first defined in the Retailer component type, then promoted out of the supplychain.retailer.composite and bound to SOAP by a composite reference. In doubt I specified multiplicity 0..n on both the component reference and the composite reference, but I'm not sure that this makes any sense at all :) - Finally I organized the artifacts like we recently discussed on this list, the composites configuring and assembling sub-systems under a configuration/ folder, and the composites describing installed implementations under packages/. Thoughts? Is anybody interested in helping with the design and implementation of this scenario? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Creating an SDO DataObject for the properties of a component
Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Geoff. On 23/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Sebastien, I'm fixing this. It shouldn't take long. Cheers, On 22/08/06, Pete Robbins [EMAIL PROTECTED] wrote: ah! On 22/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It doesn't work at all now. With SCDL 0.9 a component declaration looked like that: component properties v:Fredabc/v:Fred v:Joexyz/v:Joe v:Joetuv/v:Joe /properties /component The DataObject loaded from that looked exactly like what the client Cpp code expected, allowing you to code ComponentContext.getProperties()-getCString(Fred)... SCDL 0.95 now looks pretty different: component property name=Fredabc/property property name=Joexyz/property property name=Joetuv/property /component ... missing the convenient properties parent element and in a very different form now. I'm guessing that we don't want the client code to change, so we need to massage the DataObject loaded from SCDL to look like what the client code wants to see. The other thing is that we should use the property types specified in the component type instead of guessing the types from the instance properties in the component declaration. So I'm basically trying to fix ModelLoader to created the expected DataObject from what we get from SCDL. In the SupplyChain scenario I have multiple Manufacturer and Warehouse components, same implementation but configured with different properties so I need to get this property stuff working... Ok I understand the problem. I wasn't up to date with the latest definition of properties. If the current interface to properties is not workable then we can always feed that back to the spec group. Anyho... I think what we need to do is 1)create a DataFactory for the properties and populate it with the types required for the properties (basic xml types will be there by default but any user defined complex types will have to be defined in a schema somewhere so lets stick to simple types for now). 2) When loading the definitions of the properties from the componentType we need to create a new SDO Type for properties associated with this component and add it to the DataFactory. So we would do something like: dataFactory-addType(someNamespace, componentProperties, ) dataFactory-addPropertyToType((propertyName, propType for each of the properties defined) 3) create a DO of someNamespace, componentProperties type and save the DOPtr in the Component defintion in the model 4) For each property set propertyDO-set(propertyName, value) 5) ComponentContext::GetProperties will return the propertyDO from the Component voila! So we need to create a datafactory per componentType I think. -- Pete Cool, Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Creating an SDO DataObject for the properties of a component
On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Exactly! However my brain let me down as when I went to check the code I had already coded it this way ;-) What we do need is a way of setting the default value for a type. Maybe you can enlighten me on what I have to do. Is there code to handle default values in SDO? Cheers, -- Pete
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
I've had some offline chats with Venkat about this. I'd not ported any of
the E4X code over from M1 so Venkat is looking at that. The XML instance
utility being talked about is for JIRA TUSCANY-419. Here's a bit more detail
on TUSCANY-419 and how it would work.
Today an E4X helloworld function looks like this:
function getGreeting(xmlIn) {
var greeting = e4xHello + xmlIn..*::in0;
var xmlOut =
helloworld:getGreetingsResponse xmlns:helloworld=
http://integration.rhino.container.tuscany.apache.org;
helloworld:getGreetingsReturn { greeting }
/helloworld:getGreetingsReturn
/helloworld:getGreetingsResponse;
return xmlOut;
}
There's a lot of boilerplate XML in there which could be determined
automatically from the WSDL, so ideally the function could rewritten
something like:
function getGreeting(xmlIn) {
var xmlOut = _getXML(getGreetingResponse);
xmlOut.getGreetingsReturn = e4xHello + xmlIn..*::in0;
return xmlOut;
}
The _getResponseXML function is a system supplied function that the
JavaScript container injects into the script environment. It returns an E4X
XML object that is an representation of the WSDL schema with all the values
defaulting. Thats worked out based on the interface of the component, there
could be similar ones for references, eg, if there is a reference named foo
you could do foo._getXML(fooType).
...ant
On 8/20/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Ant,
Is this something that works in M2 now? I remember doing a util for
creating xml instances for this.
When I see the current trunk's javascript container I don't see the e4x
samples. Shall I try moving them over and intergrating with the xml
instance creation utility. Please let me know.
Thanks.
- Venkat
On 6/7/06, ant elder [EMAIL PROTECTED] wrote:
No reply to this yet...after a little playing around it seems to work so
I'm
going to go ahead unless anyone raises any objections now. Sebastien,
you
did the async work using PolicyBuilders and Interceptors so have you any
comments to what I suggested in the email below?
...ant
On 6/6/06, ant elder [EMAIL PROTECTED] wrote:
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
Re: [jira] Created: (TUSCANY-651) Port WSDL2Java and Java2WSDL from M1
Thanks Chris ! I will try doing that. On 8/22/06, Chris Wall [EMAIL PROTECTED] wrote: Hey Jojo. I ran into this last week. I added stax-1.2.0.jar to the classpath/classloader. On 8/22/06, Jojo [EMAIL PROTECTED] wrote: Hi, I was trying to get some java2wsdl test case running, but got stuck with the following error : javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java :72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance( XMLInputFactory.java:136) I remember seeing this problem previously discussed in the thread [Axiom and classloaders, was: svn commit: r429905] and was fixed subsequently. But the fix was not discussed in the tread. I understand this is a classloader/classpath issue. Can someone tell me what was the fix ? The same fix need to be applied to the sca-tools project. Thanks! jojo. On 8/22/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Rick, I can with this. Please let me know what else needs to be done to the existing code in M1 in the context of M2 after you have moved the code over to the current trunk. Thanks - Venkat On 8/22/06, Rick Rineholt (JIRA) tuscany-dev@ws.apache.org wrote: Port WSDL2Java and Java2WSDL from M1 Key: TUSCANY-651 URL: http://issues.apache.org/jira/browse/TUSCANY-651 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Rick Rineholt Java2WSDL and WSDL2Java tooling needs to be ported from M1 to facilitate the creation of webservices applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Celtix binding
There's a long thread going on about this right now: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html ...ant On 8/23/06, Liu, Jervis [EMAIL PROTECTED] wrote: One thing you can try is same as what is done by axis2's WebServiceBindingLoader, i.e., using wsdlLocation to parse wsdl Definition by yourself. This way wsdl Definition is not cached but it works. I can not remember if we had a discussion on this before. Do we still need a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like we did in M1? As far as I can see, once WebServiceBinding is created, components that use web service binding should be able to access all wsdl related info from WebServiceBinding, thus there is no need to access a wsdl cache any more. Cheers, Jervis -Original Message- From: Liu, Jervis Sent: Wednesday, August 23, 2006 10:52 AM To: Jim Marino; tuscany-dev@ws.apache.org Cc: Chris Wall Subject: RE: Celtix binding Hi Jim, Celtix binding currently is not working yet. I got the helloworldwsclient working with the Celtix binding with some hacks and without using SDO. At the same time, for the helloworldws-celtix sample, I am able to get the reference part working, and still struggling on the service part. the creation of WebServiceBinding is one issue among many, the main problem is that the wsdl info is not properly cached in WSDLDefinitionRegistry. As soon as helloworldwsclient and helloworldws-celtix are both working, your sample should work as well. I will let you know once I make any further progress on these two samples. Thanks, Jervis -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 4:02 PM To: tuscany-dev@ws.apache.org Cc: Chris Wall; Liu, Jervis Subject: Celtix binding Hi Jervis, Chris and I have been trying to get the Celtix binding bootstrapped into a sample where it wires to Spring. I noticed WebServiceBindingLoader line 134 originally returned a null instead of a WebServiceBinding, which caused another issue related to composite wiring (I or Ignacio will need to fix). So, to get around this, I changed the loader to return a WebServiceBinding that doesn't work as I pass mostly nulls in. Ideally, we'd like to get the Celtix part fully working. Both of us are willing to help out if you can provide some direction. The same SCDL and WSDL are attached. Thanks, Jim - 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: [jira] Created: (TUSCANY-651) Port WSDL2Java and Java2WSDL from M1
Jojo, it should be picking up the Woodstox jar (eg, wstx-asl-2.9.3.jar), this error is saying it can't find that jar. Is that jar in your classpath? Could you describe a bit more how you're try to run this - in eclipse or mvn, is the code in SVN so I can try? ...ant On 8/22/06, Jojo [EMAIL PROTECTED] wrote: Hi, I was trying to get some java2wsdl test case running, but got stuck with the following error : javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java :72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance( XMLInputFactory.java:136) I remember seeing this problem previously discussed in the thread [Axiom and classloaders, was: svn commit: r429905] and was fixed subsequently. But the fix was not discussed in the tread. I understand this is a classloader/classpath issue. Can someone tell me what was the fix ? The same fix need to be applied to the sca-tools project. Thanks! jojo. On 8/22/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Rick, I can with this. Please let me know what else needs to be done to the existing code in M1 in the context of M2 after you have moved the code over to the current trunk. Thanks - Venkat On 8/22/06, Rick Rineholt (JIRA) tuscany-dev@ws.apache.org wrote: Port WSDL2Java and Java2WSDL from M1 Key: TUSCANY-651 URL: http://issues.apache.org/jira/browse/TUSCANY-651 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Rick Rineholt Java2WSDL and WSDL2Java tooling needs to be ported from M1 to facilitate the creation of webservices applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Creating an SDO DataObject for the properties of a component
Oh I give up! I meant DataFactoryImpl not DataObjectImpl in the previous post. Regards, Geoff. On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Pete, The DataObjectImpl class has a variety of public setDefault methods that will set a default value for a property of a type. Is that what you a looking for? Also, I fumbled the JIRA reference earlier. The JIRA to add a flexible type system is TUSCANY-546 Regards, Geoff. On 23/08/06, Pete Robbins [EMAIL PROTECTED] wrote: On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Exactly! However my brain let me down as when I went to check the code I had already coded it this way ;-) What we do need is a way of setting the default value for a type. Maybe you can enlighten me on what I have to do. Is there code to handle default values in SDO? Cheers, -- Pete
Re: [SDO for C++} Review of JIRA status
Pete, Thanks for that, all the ones with applied patches have been closed. That leaves four with patches waiting to be applied 490: patch submitted but not yet applied 496: patch submitted but not yet applied 539: patch submitted but not yet applied 553: patch submitted but not yet applied Could you look at those too? Thanks in advance. Geoff. On 04/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, I'll go through, verify, then close the Jiras that are fixed. I'll take a look at the patches that have not been applied as well. Cheers,
Re: Composite Reference Example
Hi, Could it be that the scdl contains references and then within that reference. Is there an element as references. Anyways, here is an scdl I used for the RMI Binding. To me it seems similar in structure to what Joel is using. This works there. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:rmi= http://tuscany.apache.org/xmlns/binding/rmi/1.0-SNAPSHOT; name=HelloWorldRmiComposite service name=HelloWorldRmiService target=HelloWorldServiceComponent interface.java interface=helloworld.HelloWorldService/ rmi:binding.rmi host=localhost port=1099 serviceName=HelloWorldRemoteService / referenceHelloWorldServiceComponent/reference /service component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl/ /component component name=HelloWorldRmiServiceComponent implementation.java class=helloworld.HelloWorldRmiImpl/ reference name=extService target=HelloWorldRmiReferenceHelloWorldRmiReference/reference /component reference name=HelloWorldRmiReference target=Nothing interface.java interface=helloworld.HelloWorldService/ rmi:binding.rmi host=localhost port=1099 serviceName=HelloWorldRemoteService / /reference /composite Thanks Venkat On 8/23/06, Hawkins, Joel [EMAIL PROTECTED] wrote: Jim, TUSCANY-657. Thanks for looking at this. Cheers, Joel -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 11:04 AM To: tuscany-dev@ws.apache.org Subject: Composite Reference Example Can anyone point me to an example that uses a Composite Reference? I noticed that the one in BigBank is commented out. I'm having trouble testing OSGi support against the latest code. I've got a sample that looks like this: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:osgi=http://tuscany.apache.org/xmlns/osgi/1.0; name=Retailer_Warehouse service name=RetailerService target=RetailerComponent interface.java interface=mypackage.Retailer/ osgi:binding.osgi service=mypackage.Retailer/ referenceRetailerComponent/reference /service reference name=ShipperReference override=may multiplicity=0..n interface.java interface=mypackage.Shipper/ osgi:binding.osgi service=mypackage.Shipper filter=(objectclass=mypackage.Shipper) immediate=false/ /reference component name=RetailerComponent implementation.java class=mypackage.RetailerComponentImpl/ references reference name=warehouse target=WarehouseComponent/ /references /component component name=WarehouseComponent implementation.java class=mypackage.WarehouseComponentImpl/ references reference name=shipperShipperReference/reference /references /component /composite According to the spec, it should be legal for the target of the shipper reference to be a Composite Reference (in this case, ShipperReference): A composite reference is a valid target of a wire. In this case, the name of the reference is the value set on the wire targeting the reference. (pg 24 of the v.95 spec). However, the composite above fails when ConnectorImpl attempts to locate the target (the parent's children map contains only components and services, no composite references). Is the problem with my Composite definition, or is the problem with Tuscany? Thanks, Joel The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany Wiki - DataMediation content
Hi Raymond, I have renamed the DataMediation page on the wiki in an attempt to flow to it from the SCA Java page. The new page name is http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java/DataMediation?action=show. In doing this I slipped a couple of attachments (a zip file and a jpg file). Could you please upload them whenever possible? I apologize for this inconvenience. Thanks. - Venkat
Re: Tuscany feature wish list
Jim, Hi. If you're interested in doing some piece of work the best practice IMO is let people know about it. Communicate it to the mailing list, open Jira's or both. The web site would probably not have a lot in new ideas but the mailing list, wiki and even the Jira's may have something you could be interested in. Even getting your hands in fixing some bugs lets the community know you. The website has a lot of information to help in getting started too. I don't think priorities are particularly important, mostly find something you're interested in. As per dependencies, once again, state on the mailing list what you're looking at, give as much details as you can once you think you have an idea. People will start communicating with you if they think there are dependencies on what they're doing. Jim Lynch wrote: I think this would be great. I'm new (a couple weeks) to Tuscany and at some point would like to contribute (once the deer in headlights syndrome passes). The problem is, it's tough to know who's working on what and at the same time which features are at a priority and which have dependencies. I believe I need to earn my way to be a contributor, but it's tough to find a place to start (especially without breaking anything). jim On 8/22/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 22, 2006, at 7:50 AM, ant elder wrote: I'm regularly asked be people new to Tuscany about what is something they could look at or help to develop, we don't give any help with this on the website or wiki so to help I've created a Wish list category in JIRA: http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truemode=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=12310210fixfor=12312038 JIRA makes it easier to manage than keeping a list on the wiki or website, and we could add a link to the wish list from the website. Is easy to move things around or add separate wish lists for C++ or SDO or DAS etc, although if you put a prefix in the summary you can sort the JIRA list. There's only one thing in there right now, I'm sure we could all thing of things to add. Is this useful? I think it is very useful, especially for people outside the project. ...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]
Re: Auto discovering WSDL. WAS: RE: Celtix binding
Thanks, ant. I did see this discussion after I sent out my email. However, my point was that no matter what kind of locating and loading mechanism we adopt, it does not appear to be an absolute requirement that we need to cache loaded wsdls. As once the wsdl is loaded and parsed, we store all info in the instance of WebServiceBinding, there is no need to access wsdl anymore for following processes. Of course I have to admit, without a cache or registry, it is a bit hard to implement refreshings We do need a system service for example a resolve to lookup and load wsdls. It can be a chained resolvers, so that if resolver A can not load a resource successfully then the responsibility passes to resolver b, then c...This way Tuscany runtime can config a default resolving logic by registering resolovers in order, applications can extend this by register their own resolvers. Cheers, Jervis -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 6:18 PM To: tuscany-dev@ws.apache.org Subject: Re: Celtix binding There's a long thread going on about this right now: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html ...ant On 8/23/06, Liu, Jervis [EMAIL PROTECTED] wrote: One thing you can try is same as what is done by axis2's WebServiceBindingLoader, i.e., using wsdlLocation to parse wsdl Definition by yourself. This way wsdl Definition is not cached but it works. I can not remember if we had a discussion on this before. Do we still need a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like we did in M1? As far as I can see, once WebServiceBinding is created, components that use web service binding should be able to access all wsdl related info from WebServiceBinding, thus there is no need to access a wsdl cache any more. Cheers, Jervis -Original Message- From: Liu, Jervis Sent: Wednesday, August 23, 2006 10:52 AM To: Jim Marino; tuscany-dev@ws.apache.org Cc: Chris Wall Subject: RE: Celtix binding Hi Jim, Celtix binding currently is not working yet. I got the helloworldwsclient working with the Celtix binding with some hacks and without using SDO. At the same time, for the helloworldws-celtix sample, I am able to get the reference part working, and still struggling on the service part. the creation of WebServiceBinding is one issue among many, the main problem is that the wsdl info is not properly cached in WSDLDefinitionRegistry. As soon as helloworldwsclient and helloworldws-celtix are both working, your sample should work as well. I will let you know once I make any further progress on these two samples. Thanks, Jervis -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 4:02 PM To: tuscany-dev@ws.apache.org Cc: Chris Wall; Liu, Jervis Subject: Celtix binding Hi Jervis, Chris and I have been trying to get the Celtix binding bootstrapped into a sample where it wires to Spring. I noticed WebServiceBindingLoader line 134 originally returned a null instead of a WebServiceBinding, which caused another issue related to composite wiring (I or Ignacio will need to fix). So, to get around this, I changed the loader to return a WebServiceBinding that doesn't work as I pass mostly nulls in. Ideally, we'd like to get the Celtix part fully working. Both of us are willing to help out if you can provide some direction. The same SCDL and WSDL are attached. Thanks, Jim - 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]
Re: [jira] Created: (TUSCANY-651) Port WSDL2Java and Java2WSDL from M1
Hi Ant, Thanks for looking into this. Unfortuately I had a machine crash sometime back and trying to recover. So I won't be able to give you a patch. And the code is not yet in SVN. I am trying to run it usig Maven. I will try to give you a zip file with the code. Thanks and regards, jojo. On 8/23/06, ant elder [EMAIL PROTECTED] wrote: Jojo, it should be picking up the Woodstox jar (eg, wstx-asl-2.9.3.jar), this error is saying it can't find that jar. Is that jar in your classpath? Could you describe a bit more how you're try to run this - in eclipse or mvn, is the code in SVN so I can try? ...ant On 8/22/06, Jojo [EMAIL PROTECTED] wrote: Hi, I was trying to get some java2wsdl test case running, but got stuck with the following error : javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java :72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance( XMLInputFactory.java:136) I remember seeing this problem previously discussed in the thread [Axiom and classloaders, was: svn commit: r429905] and was fixed subsequently. But the fix was not discussed in the tread. I understand this is a classloader/classpath issue. Can someone tell me what was the fix ? The same fix need to be applied to the sca-tools project. Thanks! jojo. On 8/22/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Rick, I can with this. Please let me know what else needs to be done to the existing code in M1 in the context of M2 after you have moved the code over to the current trunk. Thanks - Venkat On 8/22/06, Rick Rineholt (JIRA) tuscany-dev@ws.apache.org wrote: Port WSDL2Java and Java2WSDL from M1 Key: TUSCANY-651 URL: http://issues.apache.org/jira/browse/TUSCANY-651 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Rick Rineholt Java2WSDL and WSDL2Java tooling needs to be ported from M1 to facilitate the creation of webservices applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OSGi host
Hi Andy, I'm pretty new to it, too, hence the questions. :-) For me, SCA seems like wiring technology that's very useful for things with a bit of an impedance mismatch, whereas Spring is more focused on IOC. Spring is very good at wiring things together that are meant to be wired, and functionality like the OSGi binding for Spring is a means of bringing more wiring targets into the fold. I guess my question is, could SCA be the standard way for Spring and EJB3 to deal with these impedance mismatches, so that all Spring would need to implement is an SCA bean type, and all SCA would need to implement is an OSGi binding? Then anything bind-able by SCA could be consumed by Spring - BPEL components, Javascript, whatever. This seems like what the OSOA Client and Implementation spec for Spring implies. I just wonder how it's viewed from the Spring side of the fence. Oh well, it looks like we need those OSGi services and bindings in Tuscany regardless, so I'll get back to working on them. For the OSGi crowd, size matters - and smaller is better. They won't want to include the Spring jars if they don't have to. Thanks again for the link - it helps to level-set what the SCA binding should be capable of! Cheers, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 6:07 PM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Hi Joel, I'm new to SCA, so don't believe everything I say :) OSGi is IMO an infrastructure technology suitable for building container technologies such as SCA. Spring is a Java component wiring technology, so inevitably overlaps with some of what SCA is trying to achieve (and EJB3 for example). That's ok - customers will decide what is appropriate for them. For me the sweet spot of SCA is SOA which has no overlap at all with either Spring or OSGI. andy At 02:50 PM 8/21/2006, Hawkins, Joel wrote: Hi Andy, Thanks for the link. You bring up a question that's been troubling me about some of this. What is the role of OSGi in SCA? How does it differ from the role of something like Spring? Or, asked in the larger sense, where does SCA fit into the world of Containers? My assumption has been that OSGi is analogous to Tomcat - it is the outer container for hosting SCA runtime instances (the Hosting Platform). I saw Spring as something contained by an SCA runtime. In my simple world view, that would mean that the SCA runtime should mediate between the OSGi and Spring worlds. I'm assuming that we would want an SCA wire between Spring beans accessing OSGi services, etc. so that SCA would have a place to inject code (for whatever reason), and so that the SCDLs would more closely reflect the actual application's interrelationships (a really nice side-effect that enhances manageability). All of this argues for a separate OSGi binding for SCA (and a single SCA bean-type in Spring for 'outside' beans). On the other hand, there is quite a bit of overlap between what Spring and SCA do, and I am getting the feeling that this code could rapidly become wheel-shaped. :-) Do you have any suggestions for how to proceed? What are your thoughts on the big-picture relationship between SCA and these fully-featured containers like Spring and J2EE? Thanks, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 6:40 AM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Note that you will get a lot of this stuff for free if you use Spring. http://opensource.atlassian.com/projects/spring/secure/attachment/11891 / spring_and_osgi.html andy At 14:44 18/08/2006, Hawkins, Joel wrote: Jim, I've done an intial checkin of your patch for OSGi host support. I did some mods and didn't check in the samples as we have a discussion ongoing on how best to structure the samples and didn't want to create more issues for now related to the restructuring. Yes, how to deal with samples is always and issue. I'm sure dealing with test cases will be as well. 1. I didn't check in support for OSGi services as component implementation types. For SCA, our model has typically been that implementation types are created for artifacts that are deployed and evolved as part of a composite. Services that are not deployed with the composite are treated as external and modeled as References. I think this fits with OSGi as well, whose services are more dynamic in nature. Given that, I think we should be providing an OSGi binding that accesses those services as References and publishes SCA components as OSGi Services. I agree. I think where I went for Implementation rather than Reference is when the core wanted me to specify a target declared in the component. In the spec, you can declare a reference without a target, but that didn't appear to be the case in the code I had. My thought process (such as it is..) was that at a certain
Re: Auto discovering WSDL. WAS: RE: Celtix binding
I agree its not an absolute requirement, but it makes things simpler (in some respects). Take a simple example of a service using both interface.wsdland binding.ws without any caching: service name=HelloWorldWebService interface.wsdl wsdlLocation=wsdl/helloworld.wsdl.../ binding.ws wsdlLocation=wsdl/helloworld.wsdl.../ referenceHelloWorldServiceComponent/reference /service That requires the same wsdl be defined twice which seems a bit unnecessary. More complex examples which also include components using interface.wsdl and composites including other composites and wanting wsdl shared between both composites and you end up having to specify the same wsdl lots of times. Compare that to say interface.java class=sample.Helloworld, you don't have to tell that where to find the class as it just comes from the application class loader. Some sort of WSDL registry could be similar to the application class loader. ...ant On 8/23/06, Liu, Jervis [EMAIL PROTECTED] wrote: Thanks, ant. I did see this discussion after I sent out my email. However, my point was that no matter what kind of locating and loading mechanism we adopt, it does not appear to be an absolute requirement that we need to cache loaded wsdls. As once the wsdl is loaded and parsed, we store all info in the instance of WebServiceBinding, there is no need to access wsdl anymore for following processes. Of course I have to admit, without a cache or registry, it is a bit hard to implement refreshings We do need a system service for example a resolve to lookup and load wsdls. It can be a chained resolvers, so that if resolver A can not load a resource successfully then the responsibility passes to resolver b, then c...This way Tuscany runtime can config a default resolving logic by registering resolovers in order, applications can extend this by register their own resolvers. Cheers, Jervis -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 6:18 PM To: tuscany-dev@ws.apache.org Subject: Re: Celtix binding There's a long thread going on about this right now: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html ...ant On 8/23/06, Liu, Jervis [EMAIL PROTECTED] wrote: One thing you can try is same as what is done by axis2's WebServiceBindingLoader, i.e., using wsdlLocation to parse wsdl Definition by yourself. This way wsdl Definition is not cached but it works. I can not remember if we had a discussion on this before. Do we still need a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like we did in M1? As far as I can see, once WebServiceBinding is created, components that use web service binding should be able to access all wsdl related info from WebServiceBinding, thus there is no need to access a wsdl cache any more. Cheers, Jervis -Original Message- From: Liu, Jervis Sent: Wednesday, August 23, 2006 10:52 AM To: Jim Marino; tuscany-dev@ws.apache.org Cc: Chris Wall Subject: RE: Celtix binding Hi Jim, Celtix binding currently is not working yet. I got the helloworldwsclient working with the Celtix binding with some hacks and without using SDO. At the same time, for the helloworldws-celtix sample, I am able to get the reference part working, and still struggling on the service part. the creation of WebServiceBinding is one issue among many, the main problem is that the wsdl info is not properly cached in WSDLDefinitionRegistry. As soon as helloworldwsclient and helloworldws-celtix are both working, your sample should work as well. I will let you know once I make any further progress on these two samples. Thanks, Jervis -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 4:02 PM To: tuscany-dev@ws.apache.org Cc: Chris Wall; Liu, Jervis Subject: Celtix binding Hi Jervis, Chris and I have been trying to get the Celtix binding bootstrapped into a sample where it wires to Spring. I noticed WebServiceBindingLoader line 134 originally returned a null instead of a WebServiceBinding, which caused another issue related to composite wiring (I or Ignacio will need to fix). So, to get around this, I changed the loader to return a WebServiceBinding that doesn't work as I pass mostly nulls in. Ideally, we'd like to get the Celtix part fully working. Both of us are willing to help out if you can provide some direction. The same SCDL and WSDL are attached. Thanks, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
RE: Composite Reference Example
Venkaat, Thanks! Found the problem. As it turns out, the Launcher code has drifted quite a bit. I'd created an OSGiLauncher based on code that was a couple of weeks old (whenever I checked in the initial support). This code was loading the application into a SystemCompositeImpl rather than a plain CompositeImpl. The CompositeBuilder builds bound references, the SystemCompositeBuilder only builds bound services. Not sure if this is intentional. Anyway, seeing your working RMI example helped me see where the real problem had to be. Thanks again, Joel -Original Message- From: Venkata Krishnan [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 6:58 AM To: tuscany-dev@ws.apache.org Subject: Re: Composite Reference Example Hi, Could it be that the scdl contains references and then within that reference. Is there an element as references. Anyways, here is an scdl I used for the RMI Binding. To me it seems similar in structure to what Joel is using. This works there. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:rmi= http://tuscany.apache.org/xmlns/binding/rmi/1.0-SNAPSHOT; name=HelloWorldRmiComposite service name=HelloWorldRmiService target=HelloWorldServiceComponent interface.java interface=helloworld.HelloWorldService/ rmi:binding.rmi host=localhost port=1099 serviceName=HelloWorldRemoteService / referenceHelloWorldServiceComponent/reference /service component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl/ /component component name=HelloWorldRmiServiceComponent implementation.java class=helloworld.HelloWorldRmiImpl/ reference name=extService target=HelloWorldRmiReferenceHelloWorldRmiReference/reference /component reference name=HelloWorldRmiReference target=Nothing interface.java interface=helloworld.HelloWorldService/ rmi:binding.rmi host=localhost port=1099 serviceName=HelloWorldRemoteService / /reference /composite Thanks Venkat On 8/23/06, Hawkins, Joel [EMAIL PROTECTED] wrote: Jim, TUSCANY-657. Thanks for looking at this. Cheers, Joel -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 11:04 AM To: tuscany-dev@ws.apache.org Subject: Composite Reference Example Can anyone point me to an example that uses a Composite Reference? I noticed that the one in BigBank is commented out. I'm having trouble testing OSGi support against the latest code. I've got a sample that looks like this: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:osgi=http://tuscany.apache.org/xmlns/osgi/1.0; name=Retailer_Warehouse service name=RetailerService target=RetailerComponent interface.java interface=mypackage.Retailer/ osgi:binding.osgi service=mypackage.Retailer/ referenceRetailerComponent/reference /service reference name=ShipperReference override=may multiplicity=0..n interface.java interface=mypackage.Shipper/ osgi:binding.osgi service=mypackage.Shipper filter=(objectclass=mypackage.Shipper) immediate=false/ /reference component name=RetailerComponent implementation.java class=mypackage.RetailerComponentImpl/ references reference name=warehouse target=WarehouseComponent/ /references /component component name=WarehouseComponent implementation.java class=mypackage.WarehouseComponentImpl/ references reference name=shipperShipperReference/reference /references /component /composite According to the spec, it should be legal for the target of the shipper reference to be a Composite Reference (in this case, ShipperReference): A composite reference is a valid target of a wire. In this case, the name of the reference is the value set on the wire targeting the reference. (pg 24 of the v.95 spec). However, the composite above fails when ConnectorImpl attempts to locate the target (the parent's children map contains only components and services, no composite references). Is the problem with my Composite definition, or is the problem with Tuscany? Thanks, Joel The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be
Re: Auto discovering WSDL
Something else that just occurred to me with regard to this --- error reporting. If wsdl is cached and could be located in different locations and that may even be changed by replacing some pluggable system component, when errors arise will there be a means to specifically state which WSDL participated in that error? I could see an very large deployment this could be a real pain point if wsdl not being referenced where the use *thinks* it is. Rick wrote: I can see in having a default location or via searching for wsdl in resources, but I'm still in favor of have the ability to give specific location control in the scdl. Does it seem reasonable the actual location can/should be specified by url? Not on the local machine itself? Could it be generated? change in time to change an endpoint address ? If yes will a caching scheme take that into account? I'm assuming caching will be hierarchical with each classloader on each composite having its own cache and delegating if not found to the containing composite to finally a global one. If I'm understanding correctly the aspects of this I think this is where we went wrong in M1 (global across all webapps). If this is the case I think at each level it would be nice to have a scdl parameter to block the delegating to the next level. Generally I like the idea of making it simple by having less to specify, but not if it's at the expense of not having control when it's needed. Jim Marino wrote: On Aug 22, 2006, at 4:31 PM, ant elder wrote: On 8/22/06, Jim Marino [EMAIL PROTECTED] wrote: snip/ I really like the suggestion that WSDL be automatically discovered anywhere within the application directory structure. I pretty much have the same concerns as mentioned by Raymond on this. I'm confused by this thread, you're concerns are the same as Raymonds, Raymond says Sebastien points out the problems, but AFAICT Sebastien likes Yea actually I thought Sebastien liked it some I'm a bit confused too. Outside of that, I don't like when things are magically picked up on a classpath. For example, fragments caused all sorts of problems. the auto discovery approach and I think this is how the C++ guys are going to implemented it. What alternative approaches do you like - must use wsdlLocation on every interface.wsdl and binding.ws? I think this was Jeremy's preference. I'm not the hard line Only auto discover in a specific folder such as META-INF/wsdl? I prefer a specific folder as well as potentially reinstating import.wsdl since that may be more portable. Re-instate import.wsdl? Something else ? I'd just like to get something going, especially while Yang is sounding so keen to help out. ...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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto discovering WSDL
As you mentioned WeakReferences work as long as values do not contain pointers back to the classloader, which I have found is difficult to avoid and error prone. I'd prefer to see if we could avoid keying on classloader. I also think having to flush a system service may be more complicated than just treating it within the context of a composite. Jim On Aug 22, 2006, at 4:58 PM, Yang ZHONG wrote: Keying can be done by WeakReference or SoftReference, as long as no strong reference from value to key (value sure can have weak/soft reference to key). The registry I worked on, Eclipse Modeling Framework, and many other Java caches, use Java Reference. On 8/22/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 22, 2006, at 2:46 PM, Yang ZHONG wrote: Ant has just mentioned two important aspects of a decent registry: multi-dimension scoping and NameSpace aggregation. I forgot to mention the registry I previously worked on supports them too, thank Ant. Specifically, keyed by application and the WSDL location mentions scoping by application/ClassLoaders *and* scoping by (WSDL) location. application/ClassLoaders scoping and location scoping are *not* in parallel, e.g. one WSDL/XSD file could be shared by both WAR and EJB, or both app1 and app2. By multi-dimension, I mean the loaded symbol may need to be only one instance, e.g. Quote type/message from WSDL file, it's especially important to types due to instanceof and isSuperType checking (we know how painful that one .class file ends up more than one copies in memory) NameSpace aggregation is also important. e.g. WSDL file 1 may have defined NameSpace tns in location 1 scope, and WSDL 2 defines the same tns in location 2 scope, and both WSDL 1 and 2 are accessible from application scope, then a NameSpace aggregation *view* is necessary for queries from the application scope. I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. Yea it sure sounds like it. I'm wondering that this should not be a system component by something scoped within the application composite as you mentioned classloaders are referenced. We could potentially do something with the property extension mechanism. I'm a little behind so if you can figure out how the keying could work, I could offer some suggestions on how to plug the registry into the runtime. On 8/22/06, ant elder [EMAIL PROTECTED] wrote: I agree a registry would be good, we need some sort of cache or registry otherwise you need to specify the wsdlLocation on every interface.wsdl and binding.ws which is quite ugly. But we had a simple registry in M1 and that caused problems with namespace reuse. We definitely need to handle the reuse of namespaces across applications, and also maybe the reuse of namespaces within an application. To handle namespace reuse within an application you need the option to specify a wsdlLocation everywhere interface.wsdl or binding.ws is used, to handle reuse across applications the registry needs to have some sort of application scope. I really like the suggestion that WSDL be automatically discovered anywhere within the application directory structure. So for now, to get the current code working without requiring wsdlLocation be used everywhere and until the spec group do something, could we have a simple registry that finds WSDL anywhere within applications and its keyed by application and the WSDL location. Then extensions could locate WSDL objects based on the name, eg portType name, DeploymentContext and an optional wsdlLocation? ...ant On 8/22/06, Jim Marino [EMAIL PROTECTED] wrote: I like Raymond's and Yang's approach and perhaps someone is willing to propose the standardized way to the spec group? Sebastien, since you had a bunch of other issues raised against the spec group, do you want to do that? Jim On Aug 22, 2006, at 10:36 AM, Raymond Feng wrote: I'm leaning the following: 1) Have a well-defined default scheme. I agree with Sebastien that the SCA spec should spell it out. 2) Allow extensibility to plug in new schemes (for example, my:path) if the host platform desires. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, August 22, 2006 10:21 AM Subject: Re: Auto discovering WSDL Raymond Feng wrote: Hi, I would suggest that we define a system service to provide the artifact resolving strategy. Then we can supply a default implementation, for example, resolve the wsdlLocation based on classpath. The embedded can choose to replace it with its own more sophisticated resolver (for exmaple, using META-INF/ wsdl, scanning directory, or querying a WSDL repository). Thanks, Raymond Making things pluggable to support all
Re: Auto discovering WSDL. WAS: RE: Celtix binding
On Aug 23, 2006, at 4:57 AM, Liu, Jervis wrote: Thanks, ant. I did see this discussion after I sent out my email. However, my point was that no matter what kind of locating and loading mechanism we adopt, it does not appear to be an absolute requirement that we need to cache loaded wsdls. As once the wsdl is loaded and parsed, we store all info in the instance of WebServiceBinding, there is no need to access wsdl anymore for following processes. Why don't we start with something simple and then add in functionality as we need it? Of course I have to admit, without a cache or registry, it is a bit hard to implement refreshings We do need a system service for example a resolve to lookup and load wsdls. It can be a chained resolvers, so that if resolver A can not load a resource successfully then the responsibility passes to resolver b, then c...This way Tuscany runtime can config a default resolving logic by registering resolovers in order, applications can extend this by register their own resolvers. Yea the resolver has come up too. I think we were going to have a swappable system service that implemented different resolution strategies. Do the resolvers need to do more than just handle resolution? Cheers, Jervis -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 6:18 PM To: tuscany-dev@ws.apache.org Subject: Re: Celtix binding There's a long thread going on about this right now: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06781.html ...ant On 8/23/06, Liu, Jervis [EMAIL PROTECTED] wrote: One thing you can try is same as what is done by axis2's WebServiceBindingLoader, i.e., using wsdlLocation to parse wsdl Definition by yourself. This way wsdl Definition is not cached but it works. I can not remember if we had a discussion on this before. Do we still need a wsdl cache ( e.g. WSDLDefinitionRegistry) somewhere like we did in M1? As far as I can see, once WebServiceBinding is created, components that use web service binding should be able to access all wsdl related info from WebServiceBinding, thus there is no need to access a wsdl cache any more. Cheers, Jervis -Original Message- From: Liu, Jervis Sent: Wednesday, August 23, 2006 10:52 AM To: Jim Marino; tuscany-dev@ws.apache.org Cc: Chris Wall Subject: RE: Celtix binding Hi Jim, Celtix binding currently is not working yet. I got the helloworldwsclient working with the Celtix binding with some hacks and without using SDO. At the same time, for the helloworldws-celtix sample, I am able to get the reference part working, and still struggling on the service part. the creation of WebServiceBinding is one issue among many, the main problem is that the wsdl info is not properly cached in WSDLDefinitionRegistry. As soon as helloworldwsclient and helloworldws-celtix are both working, your sample should work as well. I will let you know once I make any further progress on these two samples. Thanks, Jervis -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 4:02 PM To: tuscany-dev@ws.apache.org Cc: Chris Wall; Liu, Jervis Subject: Celtix binding Hi Jervis, Chris and I have been trying to get the Celtix binding bootstrapped into a sample where it wires to Spring. I noticed WebServiceBindingLoader line 134 originally returned a null instead of a WebServiceBinding, which caused another issue related to composite wiring (I or Ignacio will need to fix). So, to get around this, I changed the loader to return a WebServiceBinding that doesn't work as I pass mostly nulls in. Ideally, we'd like to get the Celtix part fully working. Both of us are willing to help out if you can provide some direction. The same SCDL and WSDL are attached. Thanks, Jim - 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]
Re: Auto discovering WSDL
On 8/22/06, Yang ZHONG [EMAIL PROTECTED] wrote: snip/ I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. How about we take Yang up on this offer. We could have a WSDL registry as an optional system service, and define the wsdlLocation attribute on both the interface.wsdl and binding.ws elements. If you don't configure your system with a WSDL registry then it will be null and the wsdlLocation attribute must be specified, if you do configure a WSDL registry in your system then the wsdlLocation attribute becomes optional and if you leave it out the registry is used to locate the wsdl. The registry could have configurable wsdl locating strategies such as looking in a specific folder or scanning all folders or something completely different. This seems like it gives everyone what they want. Yang could have a go at coming up with a registry impl that works and doesn't cause memory leaks and works across applications etc. I'd be happy to help, and I'd change the Axis2 binding and JavaScript container to use the registry if we can get it to work. Yang sounds like he has lots of experience with this type of thing, and has volunteered, so it would be good to encourage a new contributor. ...ant
Re: Auto discovering WSDL
I personally like Ant's optional wsdlLocation attribute idea, it's flexible enough to address many requirements, and just like what XSD/WSDL specification has done - optional schemaLocation attribute: if present, option to use the specified location; if not present, to be resolved by loader (registry, repository, whatever) On 8/23/06, ant elder [EMAIL PROTECTED] wrote: On 8/22/06, Yang ZHONG [EMAIL PROTECTED] wrote: snip/ I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. How about we take Yang up on this offer. We could have a WSDL registry as an optional system service, and define the wsdlLocation attribute on both the interface.wsdl and binding.ws elements. If you don't configure your system with a WSDL registry then it will be null and the wsdlLocation attribute must be specified, if you do configure a WSDL registry in your system then the wsdlLocation attribute becomes optional and if you leave it out the registry is used to locate the wsdl. The registry could have configurable wsdl locating strategies such as looking in a specific folder or scanning all folders or something completely different. This seems like it gives everyone what they want. Yang could have a go at coming up with a registry impl that works and doesn't cause memory leaks and works across applications etc. I'd be happy to help, and I'd change the Axis2 binding and JavaScript container to use the registry if we can get it to work. Yang sounds like he has lots of experience with this type of thing, and has volunteered, so it would be good to encourage a new contributor. ...ant -- Yang ZHONG
Re: Auto discovering WSDL
On Aug 23, 2006, at 8:41 AM, ant elder wrote: On 8/22/06, Yang ZHONG [EMAIL PROTECTED] wrote: snip/ I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. How about we take Yang up on this offer. We could have a WSDL registry as an optional system service, and define the wsdlLocation attribute on both the interface.wsdl and binding.ws elements. If you don't configure your system with a WSDL registry then it will be null and the wsdlLocation attribute must be specified, if you do configure a WSDL registry in your system then the wsdlLocation attribute becomes optional and if you leave it out the registry is used to locate the wsdl. The registry could have configurable wsdl locating strategies such as looking in a specific folder or scanning all folders or something completely different. This sounds like a a good idea. We just need to be careful about back references to keys. If you need help with the system service part, let me know. This seems like it gives everyone what they want. Yang could have a go at coming up with a registry impl that works and doesn't cause memory leaks and works across applications etc. I'd be happy to help, and I'd change the Axis2 binding and JavaScript container to use the registry if we can get it to work. Yang sounds like he has lots of experience with this type of thing, and has volunteered, so it would be good to encourage a new contributor. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi host
On Aug 23, 2006, at 5:00 AM, Hawkins, Joel wrote: Hi Andy, I'm pretty new to it, too, hence the questions. :-) For me, SCA seems like wiring technology that's very useful for things with a bit of an impedance mismatch, whereas Spring is more focused on IOC. Spring is very good at wiring things together that are meant to be wired, and functionality like the OSGi binding for Spring is a means of bringing more wiring targets into the fold. I guess my question is, could SCA be the standard way for Spring and EJB3 to deal with these impedance mismatches, so that all Spring would need to implement is an SCA bean type, and all SCA would need to implement is an OSGi binding? Then anything bind-able by SCA could be consumed by Spring - BPEL components, Javascript, whatever. I view things similarly as well I generally characterize Java SCA Tuscany as wiring infrastructure which involves connecting services both remotely and locally. Tuscany handles remote or coarse grained connections through bindings which may involve delegation to some transport. Tuscany handles local wiring (i.e. from source to target in a shared memory space) either directly through a proxying strategy or through delegation to a container extension (e.g. Spring). While Java SCA Tuscany may use web services technology for interop, it is just one option among many and it does not mandate them. Tuscany supports (or should support since it is a work in progress) multiple programming models to author services with. For Java, there's an SCA POJO model, Spring and (hopefully at some point others such as EJB, JAX-WS, etc.). The SCA programming model supported by Tuscany is principally focused on exposing assembly concepts to the service developer, so things like non-blocking invocations, conversations, statefull interactions, etc. Spring, in addition to having a programming model, is also an application framework so it has a broader range of functionality including UI, persistence abstraction, AOP, etc. From a Spring perspective, I'd say the value in SCA is (as you stated) that it allows remote wiring to and from Spring beans. Spring has a basic remoting technology but SCA provides more thorough capabilities in this regard. I'd probably characterize it more as remote/coarse-grained wiring as opposed to mediated wiring since Spring's AOP infrastructure supports mediation on a local scale. Similar to Spring, there is some overlap with SCA with OSGi, specifically around the OSGI r4 service model. However, I also see a lot of complimentary function and actually view OSGi services as fitting into an SCA environment. In this case OSGi provides a host environment for Tuscany and OSGi services may be wired to from Tuscany (as well as the latter publishing services into OSGi). Jim This seems like what the OSOA Client and Implementation spec for Spring implies. I just wonder how it's viewed from the Spring side of the fence. Rod and Adrian are one the spec group. Most of where they have concentrated has been on the Spring Client and Implementation model so my assumption would be the value they see is in integration of Spring with SCA's remote wiring capabilities. Oh well, it looks like we need those OSGi services and bindings in Tuscany regardless, so I'll get back to working on them. For the OSGi crowd, size matters - and smaller is better. :-) One of the things we should talk about is embedding the Tuscany runtime in somewhat small devices. I think it would be interesting to have my Tivo wired with SCA. Seriously, I think this is a really interesting scenario as there is no reason Tuscany should not be able to scale down as well as up. Jim They won't want to include the Spring jars if they don't have to. Thanks again for the link - it helps to level-set what the SCA binding should be capable of! Cheers, Joel -Original Message- From: Andy Piper [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 6:07 PM To: tuscany-dev@ws.apache.org Cc: tuscany-dev@ws.apache.org Subject: RE: OSGi host Hi Joel, I'm new to SCA, so don't believe everything I say :) OSGi is IMO an infrastructure technology suitable for building container technologies such as SCA. Spring is a Java component wiring technology, so inevitably overlaps with some of what SCA is trying to achieve (and EJB3 for example). That's ok - customers will decide what is appropriate for them. For me the sweet spot of SCA is SOA which has no overlap at all with either Spring or OSGI. andy At 02:50 PM 8/21/2006, Hawkins, Joel wrote: Hi Andy, Thanks for the link. You bring up a question that's been troubling me about some of this. What is the role of OSGi in SCA? How does it differ from the role of something like Spring? Or, asked in the larger sense, where does SCA fit into the world of Containers? My assumption has been that OSGi is analogous to Tomcat - it is the outer container for
[jira] Created: (TUSCANY-661) Make celtix biding working for helloworldwsclient and helloworldws-celtix
Make celtix biding working for helloworldwsclient and helloworldws-celtix - Key: TUSCANY-661 URL: http://issues.apache.org/jira/browse/TUSCANY-661 Project: Tuscany Issue Type: Improvement Affects Versions: Java-Mx Reporter: Jervis Liu -- 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: [C++] Creating an SDO DataObject for the properties of a component
Pete Robbins wrote: On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Exactly! However my brain let me down as when I went to check the code I had already coded it this way ;-) What we do need is a way of setting the default value for a type. Maybe you can enlighten me on what I have to do. Is there code to handle default values in SDO? Cheers, Pete, With your last check-in, simple type properties now work. The BigBank Account service gets its property correctly set up to EURO. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-661) Make celtix biding working for helloworldwsclient and helloworldws-celtix
[ http://issues.apache.org/jira/browse/TUSCANY-661?page=all ] Jervis Liu updated TUSCANY-661: --- Attachment: jira661.patch Make celtix biding working for helloworldwsclient and helloworldws-celtix - Key: TUSCANY-661 URL: http://issues.apache.org/jira/browse/TUSCANY-661 Project: Tuscany Issue Type: Improvement Affects Versions: Java-Mx Reporter: Jervis Liu Attachments: jira661.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-661) Make celtix biding working for helloworldwsclient and helloworldws-celtix
[ http://issues.apache.org/jira/browse/TUSCANY-661?page=comments#action_12430048 ] Jervis Liu commented on TUSCANY-661: I've got the helloworldwsclient sample working with celtix binding with some hacks: 1. A hack in NodeDataWriter.java to not use SDO. At the moment, we just make it returns a mocked data node. 2. A hack in WebServiceBindingLoader.java to load wsdl direclty using wsdlLocation. the wsdl is not cached. In order to initialize Celtix WSDLManager, we have to create a WSDLDefinitionRegistry inside WebServiceBindingLoader, which obviously is not the right place to do so. In this patch, I also added a distrubtion target for axis2 and cletix bindings. This may not be the way we want to distribute extensions at the end of day, but this makes current work a little bit easier. Make celtix biding working for helloworldwsclient and helloworldws-celtix - Key: TUSCANY-661 URL: http://issues.apache.org/jira/browse/TUSCANY-661 Project: Tuscany Issue Type: Improvement Affects Versions: Java-Mx Reporter: Jervis Liu Attachments: jira661.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding an interceptor
Are you proposing the use of databinding. the package name for the
annotations or does that have some significance? If it is just a
package name, I'd assume we would want a fully qualified one. If this
is the case, then an interesting question comes up - which one to
use. Since these are extensions, I don't think we should allow the
use of Tuscany for data binding extensions not provided by the
project. Also, if we go this route, we'll need annotation processors
for each annotation.
Another option may be to define a generic databinding annotation
such as:
@Target({METHOD})
@Retention(RUNTIME)
public @interface Databinding {
String type() default ;
}
Individual extensions would supply a value for type (its too bad
enums can't be extended). There would be one annotation processor
which would handle the decoration of the model. What do you think?
Also, some quick questions inline:
On Aug 21, 2006, at 10:45 AM, Raymond Feng wrote:
Hi,
For the data transformation to be handled by a databinding
interceptor, let's assume we have the following case:
* The source side uses SDO.
import.sdo location=xsd/customer.xsd/
int getCreditScore(@databinding.sdo(namespace=http://customer;
name=Customer)Customer customer);
Is data binding definable per param, with the possibility to mix or
do we want to just say for the entire method (mixing seems kind of
strange). Also, what about the return value? Maybe it would be better
to place the param only on the method?
* The target side uses JAXB.
int getCreditScore(@databinding.jaxb Customer customer);
Then the interceptor will require the following information:
1) DataType on the source side (SDO Customer)
2) A commonj.sdo.TypeHelper associated with the current composite
that will provide the SDO type system
3) DataType on the target side (JAXB Customer)
4) (some JAXB context for the JAXB Customer?)
Thanks,
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, August 19, 2006 5:24 PM
Subject: Re: adding an interceptor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Jira661: Make celtix biding working for helloworldwsclient and helloworldws-celtix
Hi, can someone kindly review and apply patch for jira 661 please. In this patch I got the helloworldwsclient sample working with celtix binding with some hacks: 1. A hack in NodeDataWriter.java to not use SDO. At the moment, I just make it returns a mocked data node. 2. A hack in WebServiceBindingLoader.java to load wsdl direclty using wsdlLocation. the wsdl is not cached. In order to initialize Celtix WSDLManager, I have to create a WSDLDefinitionRegistry inside WebServiceBindingLoader, which obviously is not the right place to do so. In this patch, I also added a distrubtion target in axis2 and cletix 's poms. This may not be the way we want to distribute extensions at the end of day, but this at least makes current work a little bit easier. See samples\sca\helloworldwsclient\run_celtix.bat for how to use binding distributions to run the sample. Thanks, Jervis
Re: [PATCH] Jira661: Make celtix biding working for helloworldwsclient and helloworldws-celtix
I'll take a look and apply. On Aug 23, 2006, at 10:19 AM, Liu, Jervis wrote: Hi, can someone kindly review and apply patch for jira 661 please. In this patch I got the helloworldwsclient sample working with celtix binding with some hacks: 1. A hack in NodeDataWriter.java to not use SDO. At the moment, I just make it returns a mocked data node. 2. A hack in WebServiceBindingLoader.java to load wsdl direclty using wsdlLocation. the wsdl is not cached. In order to initialize Celtix WSDLManager, I have to create a WSDLDefinitionRegistry inside WebServiceBindingLoader, which obviously is not the right place to do so. I think that is fine for now. In this patch, I also added a distrubtion target in axis2 and cletix 's poms. This may not be the way we want to distribute extensions at the end of day, but this at least makes current work a little bit easier. See samples\sca\helloworldwsclient \run_celtix.bat for how to use binding distributions to run the sample. Yea ultimately probably not but we can deal with that later Thanks for the patch! Jim Thanks, Jervis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding an interceptor
Hi,
Please my comments in line.
Thanks,
Raymond
- Original Message -
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 10:16 AM
Subject: Re: adding an interceptor
Are you proposing the use of databinding. the package name for the
annotations or does that have some significance? If it is just a package
name, I'd assume we would want a fully qualified one. If this is the
case, then an interesting question comes up - which one to use. Since
these are extensions, I don't think we should allow the use of Tuscany
for data binding extensions not provided by the project. Also, if we go
this route, we'll need annotation processors for each annotation.
Sorry, it was a mistake in the sample. I meant two different annotations
such as DataBindingSDO and DataBindingJAXB.
Another option may be to define a generic databinding annotation such
as:
@Target({METHOD})
@Retention(RUNTIME)
public @interface Databinding {
String type() default ;
}
Individual extensions would supply a value for type (its too bad enums
can't be extended). There would be one annotation processor which would
handle the decoration of the model. What do you think?
I already have such an annotation defined in the databinding-framework
module. We probably want to rename it as DataType to be consistent with the
DataType model.
As for the two different annotation styles, I had some discussions with
Jeremy. Here're some issues we touched:
1) The annotation can be used to create/decorate a DataType
2) The generic annotation should be able to catch all the related metadata
for a given DataType (maybe some name/value pair for extra info)
3) We should allow databinding providers to add their own annotation if they
choose to do so (I assume it's low proirity for now)
Also, some quick questions inline:
On Aug 21, 2006, at 10:45 AM, Raymond Feng wrote:
Hi,
For the data transformation to be handled by a databinding interceptor,
let's assume we have the following case:
* The source side uses SDO.
import.sdo location=xsd/customer.xsd/
int getCreditScore(@databinding.sdo(namespace=http://customer;
name=Customer)Customer customer);
Is data binding definable per param, with the possibility to mix or do we
want to just say for the entire method (mixing seems kind of strange).
Also, what about the return value? Maybe it would be better to place the
param only on the method?
This concern was brought up by Ant as well. We have three levels here:
Interface, Method and Parameter. Jeremy's DataType model seems to promote
Parameter level. I think it's reasonable to set some defaults at Interface
or Method level.
* The target side uses JAXB.
int getCreditScore(@databinding.jaxb Customer customer);
Then the interceptor will require the following information:
1) DataType on the source side (SDO Customer)
2) A commonj.sdo.TypeHelper associated with the current composite that
will provide the SDO type system
3) DataType on the target side (JAXB Customer)
4) (some JAXB context for the JAXB Customer?)
Thanks,
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, August 19, 2006 5:24 PM
Subject: Re: adding an interceptor
-
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]
Can't load implementation.composite
I am trying to run a more complete sample version of the inner composite test
case and I am getting the following exception:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.482 sec FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.452 sec ERROR!
org.apache.tuscany.spi.loader.UnrecognizedElementException: {http://www.osoa.org
/xmlns/sca/1.0}implementation.composite [{http://www.osoa.org/xmlns/sca/1.0}impl
ementation.composite]
Context stack trace: [application][SourceComponent]
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:90)
at org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com
ponentLoader.java:130)
at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:84)
at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:57)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:52)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:109)
at org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:38)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L
oaderRegistryImpl.java:159)
at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:
118)
at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:93)
at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(Launche
rImpl.java:190)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:65)
at innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja
va:30)
I am not sure if I need to something extra to get the appropriate loader added
to the loader registry, assuming such a loader exists. I tried looking in
commands/launcher/.../META-INF/tuscany/*.scdl but I don't see anything quick
that I can try.
In case it helps, here's the default.scdl of the sample:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=OuterComposite
component name=SourceComponent
implementation.composite name=InnerComposite/
reference name=TargetComponentRefTargetComponent/reference
/component
component name=TargetComponent
implementation.java class=innerComposite.TargetImpl/
/component
/composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=InnerComposite
service name=InnerSourceService target=InnerSourceComponent
interface.java interface=innerComposite.Source/
reference name=innerSourceInnerSourceComponent/reference
/service
component name=InnerSourceComponent
implementation.java class=innerComposite.SourceImpl/
reference name=targetReferenceTargetComponentRef/reference
/component
reference name=TargetComponentRef
interface.java interface=innerComposite.Target/
/reference
/composite
Re: Can't load implementation.composite
Hi,
This is a bug. The corresponding loader
org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader
is not registered in the system SCDLs. Would you like to contribute a patch?
You will have to define a component in the META-INF/tuscany/composite.scdl
for test, launcher and webapp-host modules (unfortunately we don't
have a good packaging story for the system SCDLs).
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: Tuscany Dev tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 10:44 AM
Subject: Can't load implementation.composite
I am trying to run a more complete sample version of the inner composite
test case and I am getting the following exception:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.482 sec
FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.452 sec
ERROR!
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org
/xmlns/sca/1.0}implementation.composite
[{http://www.osoa.org/xmlns/sca/1.0}impl
ementation.composite]
Context stack trace: [application][SourceComponent]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:90)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com
ponentLoader.java:130)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L
oaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:
118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(Launche
rImpl.java:190)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:65)
at
innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja
va:30)
I am not sure if I need to something extra to get the appropriate loader
added to the loader registry, assuming such a loader exists. I tried looking
in commands/launcher/.../META-INF/tuscany/*.scdl but I don't see anything
quick that I can try.
In case it helps, here's the default.scdl of the sample:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=OuterComposite
component name=SourceComponent
implementation.composite name=InnerComposite/
reference name=TargetComponentRefTargetComponent/reference
/component
component name=TargetComponent
implementation.java class=innerComposite.TargetImpl/
/component
/composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=InnerComposite
service name=InnerSourceService target=InnerSourceComponent
interface.java interface=innerComposite.Source/
reference name=innerSourceInnerSourceComponent/reference
/service
component name=InnerSourceComponent
implementation.java class=innerComposite.SourceImpl/
reference name=targetReferenceTargetComponentRef/reference
/component
reference name=TargetComponentRef
interface.java interface=innerComposite.Target/
/reference
/composite
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't load implementation.composite
On Aug 23, 2006, at 10:51 AM, Raymond Feng wrote: Hi, This is a bug. The corresponding loader org.apache.tuscany.core.implementation.composite.ImplementationCompos iteLoader is not registered in the system SCDLs. Would you like to contribute a patch? You will have to define a component in the META-INF/tuscany/composite.scdl for test, launcher and webapp-host modules (unfortunately we don't have a good packaging story for the system SCDLs). We should look for a way to reuse some of the SCDLs (this may involve some file reshuffling). I'd also like to get integration tests in which verify the SCDLs since the NPE the other day was the result of not having any checks in place. Such integration tests would load the SCDLs into a minimal bootstrap and run through a couple deployment scenarios. I'm so far behind on things I won't be able to get to that but perhaps someone else is interested? Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't load implementation.composite
Ok, I see the loader class. IIUC, I need to add:
component name=composite.implementationLoader
system:implementation.system
class=org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader/
/component
to composite.scdl. Anything else? I still get the exception. But for some
reason I am not able to do a full build from the top, so I build sca/core
and samples/sca after mvn clean and mvn -e go as far as they can from the
top.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:51 PM
Subject: Re: Can't load implementation.composite
Hi,
This is a bug. The corresponding loader
org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader
is not registered in the system SCDLs. Would you like to contribute a
patch? You will have to define a component in the
META-INF/tuscany/composite.scdl for test, launcher and webapp-host
modules (unfortunately we don't have a good packaging story for the system
SCDLs).
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: Tuscany Dev tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 10:44 AM
Subject: Can't load implementation.composite
I am trying to run a more complete sample version of the inner composite
test case and I am getting the following exception:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.482 sec
FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.452 sec
ERROR!
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org
/xmlns/sca/1.0}implementation.composite
[{http://www.osoa.org/xmlns/sca/1.0}impl
ementation.composite]
Context stack trace: [application][SourceComponent]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:90)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com
ponentLoader.java:130)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L
oaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:
118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(Launche
rImpl.java:190)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:65)
at
innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja
va:30)
I am not sure if I need to something extra to get the appropriate loader
added to the loader registry, assuming such a loader exists. I tried
looking in commands/launcher/.../META-INF/tuscany/*.scdl but I don't see
anything quick that I can try.
In case it helps, here's the default.scdl of the sample:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=OuterComposite
component name=SourceComponent
implementation.composite name=InnerComposite/
reference name=TargetComponentRefTargetComponent/reference
/component
component name=TargetComponent
implementation.java class=innerComposite.TargetImpl/
/component
/composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=InnerComposite
service name=InnerSourceService target=InnerSourceComponent
interface.java interface=innerComposite.Source/
reference name=innerSourceInnerSourceComponent/reference
/service
component name=InnerSourceComponent
implementation.java class=innerComposite.SourceImpl/
reference name=targetReferenceTargetComponentRef/reference
/component
reference name=TargetComponentRef
interface.java interface=innerComposite.Target/
/reference
/composite
Re: Tuscany feature wish list
hi Rick..thanks for the feedback...great ideas..once I have a better understanding of things, i'll send a note to the dev list and we can go from there... thanks again..jim On 8/23/06, Rick [EMAIL PROTECTED] wrote: Jim, Hi. If you're interested in doing some piece of work the best practice IMO is let people know about it. Communicate it to the mailing list, open Jira's or both. The web site would probably not have a lot in new ideas but the mailing list, wiki and even the Jira's may have something you could be interested in. Even getting your hands in fixing some bugs lets the community know you. The website has a lot of information to help in getting started too. I don't think priorities are particularly important, mostly find something you're interested in. As per dependencies, once again, state on the mailing list what you're looking at, give as much details as you can once you think you have an idea. People will start communicating with you if they think there are dependencies on what they're doing. Jim Lynch wrote: I think this would be great. I'm new (a couple weeks) to Tuscany and at some point would like to contribute (once the deer in headlights syndrome passes). The problem is, it's tough to know who's working on what and at the same time which features are at a priority and which have dependencies. I believe I need to earn my way to be a contributor, but it's tough to find a place to start (especially without breaking anything). jim On 8/22/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 22, 2006, at 7:50 AM, ant elder wrote: I'm regularly asked be people new to Tuscany about what is something they could look at or help to develop, we don't give any help with this on the website or wiki so to help I've created a Wish list category in JIRA: http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truemode=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=12310210fixfor=12312038 JIRA makes it easier to manage than keeping a list on the wiki or website, and we could add a link to the wish list from the website. Is easy to move things around or add separate wish lists for C++ or SDO or DAS etc, although if you put a prefix in the summary you can sort the JIRA list. There's only one thing in there right now, I'm sure we could all thing of things to add. Is this useful? I think it is very useful, especially for people outside the project. ...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]
RE: Auto discovering WSDL
As Yang has pointed out, there are probably four things we can do in this area: locating, loading, caching and refreshing. We should not mix the responsibilities of locating/loading with caching. To satisfy your use case described below (wsdlLocation attribute becomes optional), we actually only need some kind of resolver chain to resolve wsdl, a cache is not needed here. The first resolver in the chain should resolve wsdl using wsdlLocation specified in scdl, if the first resolved failed (e.g., because the wsdllocation is null), then the second resolver should try to resolve wsdl from a default location, and so on. The implementation Yang proposed might be different, but the principle should be same. The WSDL registry should only responsible for caching wsdls and provide query APIs to query against cache. How WSDL registry loads a wsdl if that wsdl is not in cache yet should be a call delegated to the resource resolver service. The benefit of this separation is that we can start with sth simple and small, i.e., in the component loader, initially we can only use the resource resolver service without cache. Cheers, Jervis -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: 2006?8?23? 23:42 To: tuscany-dev@ws.apache.org Subject: Re: Auto discovering WSDL On 8/22/06, Yang ZHONG [EMAIL PROTECTED] wrote: snip/ I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. How about we take Yang up on this offer. We could have a WSDL registry as an optional system service, and define the wsdlLocation attribute on both the interface.wsdl and binding.ws elements. If you don't configure your system with a WSDL registry then it will be null and the wsdlLocation attribute must be specified, if you do configure a WSDL registry in your system then the wsdlLocation attribute becomes optional and if you leave it out the registry is used to locate the wsdl. The registry could have configurable wsdl locating strategies such as looking in a specific folder or scanning all folders or something completely different. This seems like it gives everyone what they want. Yang could have a go at coming up with a registry impl that works and doesn't cause memory leaks and works across applications etc. I'd be happy to help, and I'd change the Axis2 binding and JavaScript container to use the registry if we can get it to work. Yang sounds like he has lots of experience with this type of thing, and has volunteered, so it would be good to encourage a new contributor. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't load implementation.composite
Did you make sure that you added it to all of the three projects (launcher,
test and webapp-host)?
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 11:07 AM
Subject: Re: Can't load implementation.composite
Ok, I see the loader class. IIUC, I need to add:
component name=composite.implementationLoader
system:implementation.system
class=org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader/
/component
to composite.scdl. Anything else? I still get the exception. But for some
reason I am not able to do a full build from the top, so I build sca/core
and samples/sca after mvn clean and mvn -e go as far as they can from the
top.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:51 PM
Subject: Re: Can't load implementation.composite
Hi,
This is a bug. The corresponding loader
org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader
is not registered in the system SCDLs. Would you like to contribute a
patch? You will have to define a component in the
META-INF/tuscany/composite.scdl for test, launcher and
webapp-host modules (unfortunately we don't have a good packaging story
for the system SCDLs).
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: Tuscany Dev tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 10:44 AM
Subject: Can't load implementation.composite
I am trying to run a more complete sample version of the inner composite
test case and I am getting the following exception:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.482 sec
FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.452 sec
ERROR!
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org
/xmlns/sca/1.0}implementation.composite
[{http://www.osoa.org/xmlns/sca/1.0}impl
ementation.composite]
Context stack trace: [application][SourceComponent]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:90)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com
ponentLoader.java:130)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L
oaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:
118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(Launche
rImpl.java:190)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:65)
at
innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja
va:30)
I am not sure if I need to something extra to get the appropriate loader
added to the loader registry, assuming such a loader exists. I tried
looking in commands/launcher/.../META-INF/tuscany/*.scdl but I don't see
anything quick that I can try.
In case it helps, here's the default.scdl of the sample:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=OuterComposite
component name=SourceComponent
implementation.composite name=InnerComposite/
reference name=TargetComponentRefTargetComponent/reference
/component
component name=TargetComponent
implementation.java class=innerComposite.TargetImpl/
/component
/composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=InnerComposite
service name=InnerSourceService target=InnerSourceComponent
interface.java interface=innerComposite.Source/
reference name=innerSourceInnerSourceComponent/reference
/service
component
Re: Auto discovering WSDL
Exactly, locating, loading, caching and refreshing will all be loosely coupled *and* extensible. On 8/23/06, Liu, Jervis [EMAIL PROTECTED] wrote: As Yang has pointed out, there are probably four things we can do in this area: locating, loading, caching and refreshing. We should not mix the responsibilities of locating/loading with caching. To satisfy your use case described below (wsdlLocation attribute becomes optional), we actually only need some kind of resolver chain to resolve wsdl, a cache is not needed here. The first resolver in the chain should resolve wsdl using wsdlLocation specified in scdl, if the first resolved failed (e.g., because the wsdllocation is null), then the second resolver should try to resolve wsdl from a default location, and so on. The implementation Yang proposed might be different, but the principle should be same. The WSDL registry should only responsible for caching wsdls and provide query APIs to query against cache. How WSDL registry loads a wsdl if that wsdl is not in cache yet should be a call delegated to the resource resolver service. The benefit of this separation is that we can start with sth simple and small, i.e., in the component loader, initially we can only use the resource resolver service without cache. Cheers, Jervis -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: 2006?8?23? 23:42 To: tuscany-dev@ws.apache.org Subject: Re: Auto discovering WSDL On 8/22/06, Yang ZHONG [EMAIL PROTECTED] wrote: snip/ I have quite some experience working on such registry, I'd like to contribute if it's the way Tuscany wants to go. How about we take Yang up on this offer. We could have a WSDL registry as an optional system service, and define the wsdlLocation attribute on both the interface.wsdl and binding.ws elements. If you don't configure your system with a WSDL registry then it will be null and the wsdlLocation attribute must be specified, if you do configure a WSDL registry in your system then the wsdlLocation attribute becomes optional and if you leave it out the registry is used to locate the wsdl. The registry could have configurable wsdl locating strategies such as looking in a specific folder or scanning all folders or something completely different. This seems like it gives everyone what they want. Yang could have a go at coming up with a registry impl that works and doesn't cause memory leaks and works across applications etc. I'd be happy to help, and I'd change the Axis2 binding and JavaScript container to use the registry if we can get it to work. Yang sounds like he has lots of experience with this type of thing, and has volunteered, so it would be good to encourage a new contributor. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: Can't load implementation.composite
Yeah, as in sca\test, sca\commands\launcher and sca\runtime\webapp-host,
right? Still getting the exception.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 2:12 PM
Subject: Re: Can't load implementation.composite
Did you make sure that you added it to all of the three projects
(launcher, test and webapp-host)?
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 11:07 AM
Subject: Re: Can't load implementation.composite
Ok, I see the loader class. IIUC, I need to add:
component name=composite.implementationLoader
system:implementation.system
class=org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader/
/component
to composite.scdl. Anything else? I still get the exception. But for some
reason I am not able to do a full build from the top, so I build sca/core
and samples/sca after mvn clean and mvn -e go as far as they can from the
top.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:51 PM
Subject: Re: Can't load implementation.composite
Hi,
This is a bug. The corresponding loader
org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader
is not registered in the system SCDLs. Would you like to contribute a
patch? You will have to define a component in the
META-INF/tuscany/composite.scdl for test, launcher and
webapp-host modules (unfortunately we don't have a good packaging
story for the system SCDLs).
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: Tuscany Dev tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 10:44 AM
Subject: Can't load implementation.composite
I am trying to run a more complete sample version of the inner composite
test case and I am getting the following exception:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.482
sec FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.452 sec
ERROR!
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org
/xmlns/sca/1.0}implementation.composite
[{http://www.osoa.org/xmlns/sca/1.0}impl
ementation.composite]
Context stack trace: [application][SourceComponent]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:90)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com
ponentLoader.java:130)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j
ava:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L
oaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:
118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(Launche
rImpl.java:190)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:65)
at
innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja
va:30)
I am not sure if I need to something extra to get the appropriate loader
added to the loader registry, assuming such a loader exists. I tried
looking in commands/launcher/.../META-INF/tuscany/*.scdl but I don't see
anything quick that I can try.
In case it helps, here's the default.scdl of the sample:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=OuterComposite
component name=SourceComponent
implementation.composite name=InnerComposite/
reference name=TargetComponentRefTargetComponent/reference
/component
component name=TargetComponent
implementation.java class=innerComposite.TargetImpl/
/component
Re: [C++] Creating an SDO DataObject for the properties of a component
Yay! On 23/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Sebastien, Pete, I may have misunderstood the base note, however, it looks to me that you are trying to make changes to the metadata - by adding types - after creating a data object. so we already have in hand a DataObject representing the component, containing a list of property DataObjects. Now I need to dynamically create a new SDO type containing If I'm right then this is a known restricion. We have a JIRA (TUSCANY-474) that explains it. Bascally, as soon as you create a data object the type system is frozen. Pete, is that why you are suggesting creating a DataFactory for each componenType? Exactly! However my brain let me down as when I went to check the code I had already coded it this way ;-) What we do need is a way of setting the default value for a type. Maybe you can enlighten me on what I have to do. Is there code to handle default values in SDO? Cheers, Pete, With your last check-in, simple type properties now work. The BigBank Account service gets its property correctly set up to EURO. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: Can't load implementation.composite
Actually, my mistake, I am now getting a NPE: Running innercomposite.InnerCompositeTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491 sec FA ILURE! test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:102) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.load(CompositeComponentTypeLoader.java:56) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L oaderRegistryImpl.java:159) at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j ava:85) at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j ava:57) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:92) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:77) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load (CompositeLoader.java:52) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:92) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:109) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.load(CompositeComponentTypeLoader.java:56) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L oaderRegistryImpl.java:159) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java: 118) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav a:93) at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(Launche rImpl.java:190) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:65) at innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja va:30) Trying to track it down, but just in case it rings a bell. - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 2:39 PM Subject: Re: Can't load implementation.composite Yeah, as in sca\test, sca\commands\launcher and sca\runtime\webapp-host, right? Still getting the exception. - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 2:12 PM Subject: Re: Can't load implementation.composite Did you make sure that you added it to all of the three projects (launcher, test and webapp-host)? Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 11:07 AM Subject: Re: Can't load implementation.composite Ok, I see the loader class. IIUC, I need to add: component name=composite.implementationLoader system:implementation.system class=org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader/ /component to composite.scdl. Anything else? I still get the exception. But for some reason I am not able to do a full build from the top, so I build sca/core and samples/sca after mvn clean and mvn -e go as far as they can from the top. - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 1:51 PM Subject: Re: Can't load implementation.composite Hi, This is a bug. The corresponding loader org.apache.tuscany.core.implementation.composite.ImplementationCompositeLoader is not registered in the system SCDLs. Would you like to contribute a patch? You will have to define a component in the META-INF/tuscany/composite.scdl for test, launcher and webapp-host modules (unfortunately we don't have a good packaging story for the system SCDLs). Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: Tuscany Dev tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 10:44 AM Subject: Can't load implementation.composite I am trying to run a more complete sample version of the inner composite test case and I am getting the following exception: Running innercomposite.InnerCompositeTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.482 sec FA ILURE!
Re: Can't load implementation.composite
On closer inspection, it looks like it may be trying to load the inner composite from a separate file. Since the implementation.composite element uses name=InnerComposite, I tried putting the inner composite scdl in InnerComposite.scdl in the same dir as default.scdl (META-INF/sca) but I still get the NPE. Of course, this was just a guess. Any ideas? - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 3:30 PM Subject: Re: Can't load implementation.composite Actually, my mistake, I am now getting a NPE: Running innercomposite.InnerCompositeTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491 sec FA ILURE! test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:102) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.load(CompositeComponentTypeLoader.java:56) at - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding an interceptor
On Aug 23, 2006, at 10:38 AM, Raymond Feng wrote: Hi, I already have such an annotation defined in the databinding- framework module. We probably want to rename it as DataType to be consistent with the DataType model. O.K. I'll add this into API. Looking at the API package, I'm not sure why @Monitor is defined there as I think that should be in SPI. I believe Jeremy moved it there, so I'll have to ask him. As for the two different annotation styles, I had some discussions with Jeremy. Here're some issues we touched: 1) The annotation can be used to create/decorate a DataType 2) The generic annotation should be able to catch all the related metadata for a given DataType (maybe some name/value pair for extra info) 3) We should allow databinding providers to add their own annotation if they choose to do so (I assume it's low proirity for now) Also, some quick questions inline: On Aug 21, 2006, at 10:45 AM, Raymond Feng wrote: Hi, For the data transformation to be handled by a databinding interceptor, let's assume we have the following case: * The source side uses SDO. import.sdo location=xsd/customer.xsd/ int getCreditScore(@databinding.sdo(namespace=http:// customer name=Customer)Customer customer); Is data binding definable per param, with the possibility to mix or do we want to just say for the entire method (mixing seems kind of strange). Also, what about the return value? Maybe it would be better to place the param only on the method? This concern was brought up by Ant as well. We have three levels here: Interface, Method and Parameter. Jeremy's DataType model seems to promote Parameter level. I think it's reasonable to set some defaults at Interface or Method level. Is there a realistic case where people mix data types within an operation? That seems kind of weird. Perhaps we just start with interface and method level? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't load implementation.composite
Hi, The ImplementationCompositeLoader needs to be fixed to take a scdlLocation attribute and set it to CompositeImplemention. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 12:42 PM Subject: Re: Can't load implementation.composite On closer inspection, it looks like it may be trying to load the inner composite from a separate file. Since the implementation.composite element uses name=InnerComposite, I tried putting the inner composite scdl in InnerComposite.scdl in the same dir as default.scdl (META-INF/sca) but I still get the NPE. Of course, this was just a guess. Any ideas? - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 3:30 PM Subject: Re: Can't load implementation.composite Actually, my mistake, I am now getting a NPE: Running innercomposite.InnerCompositeTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491 sec FA ILURE! test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry Impl.java:102) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64) at org.apache.tuscany.core.implementation.composite.CompositeComponentTy peLoader.load(CompositeComponentTypeLoader.java:56) at - 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: Can't load implementation.composite
Ok. I hacked CompositeComponentTypeLoader to do:
if (scdlLocation == null) {
try { scdlLocation =
getClass().getClassLoader().getResource(META-INF/sca/ +
implementation.getName() + .scdl); }
catch(Exception e) { e.printStackTrace(); }
}
but I can move that to ImplementationCompositeLoader. However, how would
that attribute be set? Other than the name in implementation.composite/ I
don't see any other way of naming the file where the referred composite is
defined.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 4:16 PM
Subject: Re: Can't load implementation.composite
Hi,
The ImplementationCompositeLoader needs to be fixed to take a
scdlLocation attribute and set it to CompositeImplemention.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 12:42 PM
Subject: Re: Can't load implementation.composite
On closer inspection, it looks like it may be trying to load the inner
composite from a separate file. Since the implementation.composite
element uses name=InnerComposite, I tried putting the inner composite
scdl in InnerComposite.scdl in the same dir as default.scdl
(META-INF/sca) but I still get the NPE. Of course, this was just a guess.
Any ideas?
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 3:30 PM
Subject: Re: Can't load implementation.composite
Actually, my mistake, I am now getting a NPE:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491
sec FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec
ERROR!
java.lang.NullPointerException
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:102)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
-
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]
Re: Can't load implementation.composite
Hi,
I meant to have the following:
implementation.composite name=InnerComposiste
scdlLocation=InnerComposite.scdl/
And then in ImplementationCompositeLoader, get the scdlLocation attr from
the XML stream reader and set its value to the CompositeImplementation.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:39 PM
Subject: Re: Can't load implementation.composite
Ok. I hacked CompositeComponentTypeLoader to do:
if (scdlLocation == null) {
try { scdlLocation =
getClass().getClassLoader().getResource(META-INF/sca/ +
implementation.getName() + .scdl); }
catch(Exception e) { e.printStackTrace(); }
}
but I can move that to ImplementationCompositeLoader. However, how would
that attribute be set? Other than the name in implementation.composite/
I don't see any other way of naming the file where the referred composite
is defined.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 4:16 PM
Subject: Re: Can't load implementation.composite
Hi,
The ImplementationCompositeLoader needs to be fixed to take a
scdlLocation attribute and set it to CompositeImplemention.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 12:42 PM
Subject: Re: Can't load implementation.composite
On closer inspection, it looks like it may be trying to load the inner
composite from a separate file. Since the implementation.composite
element uses name=InnerComposite, I tried putting the inner composite
scdl in InnerComposite.scdl in the same dir as default.scdl
(META-INF/sca) but I still get the NPE. Of course, this was just a
guess. Any ideas?
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 3:30 PM
Subject: Re: Can't load implementation.composite
Actually, my mistake, I am now getting a NPE:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491
sec FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec
ERROR!
java.lang.NullPointerException
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:102)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
-
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]
Re: Can't load implementation.composite
Right, but I don't see scdlLocation as an attribute of
implementation.composite in the spec, maybe I don't have the right doc.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 4:45 PM
Subject: Re: Can't load implementation.composite
Hi,
I meant to have the following:
implementation.composite name=InnerComposiste
scdlLocation=InnerComposite.scdl/
And then in ImplementationCompositeLoader, get the scdlLocation attr
from the XML stream reader and set its value to the
CompositeImplementation.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:39 PM
Subject: Re: Can't load implementation.composite
Ok. I hacked CompositeComponentTypeLoader to do:
if (scdlLocation == null) {
try { scdlLocation =
getClass().getClassLoader().getResource(META-INF/sca/ +
implementation.getName() + .scdl); }
catch(Exception e) { e.printStackTrace(); }
}
but I can move that to ImplementationCompositeLoader. However, how would
that attribute be set? Other than the name in implementation.composite/
I don't see any other way of naming the file where the referred composite
is defined.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 4:16 PM
Subject: Re: Can't load implementation.composite
Hi,
The ImplementationCompositeLoader needs to be fixed to take a
scdlLocation attribute and set it to CompositeImplemention.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 12:42 PM
Subject: Re: Can't load implementation.composite
On closer inspection, it looks like it may be trying to load the inner
composite from a separate file. Since the implementation.composite
element uses name=InnerComposite, I tried putting the inner composite
scdl in InnerComposite.scdl in the same dir as default.scdl
(META-INF/sca) but I still get the NPE. Of course, this was just a
guess. Any ideas?
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 3:30 PM
Subject: Re: Can't load implementation.composite
Actually, my mistake, I am now getting a NPE:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491
sec FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec
ERROR!
java.lang.NullPointerException
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:102)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
So, trying to catchup with many replies to the REST thread...
+1 on DAS supporting all data access on the REST service side...
Also, trying to get a summary of points here, we are saying
1.We need to provide a REST binding for SCA
2.We would provide a REST service using DAS/SDO and the SCA REST binding
would consume this REST service
3.We would probably create a sample app that would show the usage and
binding of all these (and we need a scenario here)
I could definitely help with 2 and 3... also, I'm finishing up a DAS sample
that, with little change could be transformed as the REST service similar to
what was mentioned by Kevin... (should be in the trunk in the next day or
so)
- Luciano
On 8/23/06, Kevin Williams [EMAIL PROTECTED] wrote:
snip
In the client:
customers.get(http://my.customer.database.com/customers/1234;);
returns an instance of the Customer XSD complex type
customers.put(http://my.customer.database.com/customers/1234;,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get(http://my.customer.database.com/customers/;) returns a
list of URIs to the customers.
On the server, the CustomerResource component implements the Customer
resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
liststring list(string uris);
}
Also, I was thinking that somehow our REST work should tie in with the
DAS work that we're doing in Tuscany.
Thoughts?
snip
I have spent a little time thinking about DAS and REST ... no epiphany
so far. Some RDB vendors offer URL access to relational data with an
option to return results as xml with something like this:
http://localhost/myDatabase?sql=SELECT+firstname,lastname+FROM+employees+FOR+XML+AUTO
So, this seems quasi-restful although what is returned is really the
results of a query rather than a resource. I suppose this would be more
restful and similar to Sebastien's example if the get returned a list of
urls of Employees that satisfied the query.
I am not sure we would want to embed SQL in the URL but it also does not
seem to make much sense to invent a new query language. Without a
fairly sophisticated query language, how could a client retrieve a graph
of results like: Customers-Orders-LineItems? I am starting to ramble.
I need to think about this a bit more.
--Kevin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-
Luciano Resende
SOA Opensource - Apache Tuscany
-
Re: Can't load implementation.composite
Hi,
The attr is not in the spec. There are some discussions on this list on how
to locate/resolve SCDL. For now, it's probably the simplest way to get your
case working as I suggested.
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:51 PM
Subject: Re: Can't load implementation.composite
Right, but I don't see scdlLocation as an attribute of
implementation.composite in the spec, maybe I don't have the right doc.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 4:45 PM
Subject: Re: Can't load implementation.composite
Hi,
I meant to have the following:
implementation.composite name=InnerComposiste
scdlLocation=InnerComposite.scdl/
And then in ImplementationCompositeLoader, get the scdlLocation attr
from the XML stream reader and set its value to the
CompositeImplementation.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 1:39 PM
Subject: Re: Can't load implementation.composite
Ok. I hacked CompositeComponentTypeLoader to do:
if (scdlLocation == null) {
try { scdlLocation =
getClass().getClassLoader().getResource(META-INF/sca/ +
implementation.getName() + .scdl); }
catch(Exception e) { e.printStackTrace(); }
}
but I can move that to ImplementationCompositeLoader. However, how would
that attribute be set? Other than the name in
implementation.composite/ I don't see any other way of naming the file
where the referred composite is defined.
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 4:16 PM
Subject: Re: Can't load implementation.composite
Hi,
The ImplementationCompositeLoader needs to be fixed to take a
scdlLocation attribute and set it to CompositeImplemention.
Thanks,
Raymond
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 12:42 PM
Subject: Re: Can't load implementation.composite
On closer inspection, it looks like it may be trying to load the inner
composite from a separate file. Since the implementation.composite
element uses name=InnerComposite, I tried putting the inner
composite scdl in InnerComposite.scdl in the same dir as default.scdl
(META-INF/sca) but I still get the NPE. Of course, this was just a
guess. Any ideas?
- Original Message -
From: Ignacio Silva-Lepe [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 23, 2006 3:30 PM
Subject: Re: Can't load implementation.composite
Actually, my mistake, I am now getting a NPE:
Running innercomposite.InnerCompositeTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.491
sec FA
ILURE!
test(innercomposite.InnerCompositeTestCase) Time elapsed: 0.471 sec
ERROR!
java.lang.NullPointerException
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry
Impl.java:102)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.loadFromSidefile(CompositeComponentTypeLoader.java:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTy
peLoader.load(CompositeComponentTypeLoader.java:56)
at
-
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]
-
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: Can't load implementation.composite
Raymond Feng wrote: Hi, I meant to have the following: implementation.composite name=InnerComposiste scdlLocation=InnerComposite.scdl/ And then in ImplementationCompositeLoader, get the scdlLocation attr from the XML stream reader and set its value to the CompositeImplementation. Thanks, Raymond This thread just caught my eye as changes to the SCDL programming model will have impacts on all runtimes including C++. Is scdlLocation new in the spec or is this a Tuscany/Java extension? Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't load implementation.composite
My reply to Ignacio has probably answered your question. To recap, 1) It's not in the SCA spec (scdlLocation attr) 2) It's a Tuscany/Java extension for now 3) It might be changed when we have an artifact resolving story. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 23, 2006 2:07 PM Subject: Re: Can't load implementation.composite Raymond Feng wrote: Hi, I meant to have the following: implementation.composite name=InnerComposiste scdlLocation=InnerComposite.scdl/ And then in ImplementationCompositeLoader, get the scdlLocation attr from the XML stream reader and set its value to the CompositeImplementation. Thanks, Raymond This thread just caught my eye as changes to the SCDL programming model will have impacts on all runtimes including C++. Is scdlLocation new in the spec or is this a Tuscany/Java extension? Thanks, -- 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]
[C++] Coding convention for #ifndef in our includes
I see two different coding conventions for the usual #ifndef/#define/#endif in our include files: #ifndef tuscany_sca_model_binding_h in tuscany::sca::model::Binding.h #ifndef _CHANGEDDATAOBJECTLIST_H_ in commonj::sdo::ChangedDataObjectList.h Can we decide on a common convention? I have used both conventions in the past, so I'm OK with either but think it'd be nicer if we could pick one and stick to it. Until we make a decision I'll follow my old code maintainer habit to stick to the scheme I see in the code around what I'm adding/changing. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New site sample
I've updated the site sandbox at http://zerovec.com/tuscany/ On the front I've put a revised verion of the block diagram as well as a version of the triangle relationship diagram for side by side comparison. On the top I've implemented some drop down menus for navigating to specific pages related to SCA/SDO/DAS. Some of these pages do not exist yet. I've also inserted a Getting started category in the nav bar for links similiar to those in the menus. Let me know what you guys think works, and where you want the site to be. -David Wheeler. On 8/21/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Haleh, David... I am trying to rephrase what I tried to convey over the IRC about the diagram at http://www.zerovec.com/tuscany/AssemblyDiagram.png If this is the diagram of our websites front page, In my opinion the diagram seems to put more emphasis on the SCA project detailing it more than the SDO and DAS. If I visited the website I would think that SCA is the main thing and SDO and DAS are supporting stuff. If this is what it is actually then it is me who has got it all wrong :) On the other hand if all three of them are key initiatives / projects that we are doing under Tuscany, we have to project them in a equivalent footage. .i.e. either detail all of them or show all as just blocks (with no details within each block) Also, we must convey what is the binding theme for us to do these three technologies under the Tuscany Umbrella - what is the motivation? This also hints on what other projects we might include under Tuscany in the future. Thanks. - Venkat On 8/17/06, David Wheeler [EMAIL PROTECTED] wrote: Hello again, I worked some more on the site and here is what I have come up with. http://www.zerovec.com/tuscany/ I created a php script to parse the xml docs in site-author and display them. This make it pretty easy to migrate over all the content that was previously there. The only change was making links that pointed to pageName.html point to index.php?page=pageName . Does this work for everyone? On 8/14/06, David Wheeler [EMAIL PROTECTED] wrote: Hi, I've got the site layout to the point where some things are now functional. Content pages need only contain what is relevant to the themselves, with no formatting information Currently it uses javascript to take a local page and inject it into the main page. (This causes the page to feel more responsive, but breaks the back button.) An easy alternative would be to use PHP if javascript isn't ok. I've attached the source as well as posted it here: http://66.160.135.98/tuscany/ -David W
Re: Das Logging Framework
snip Luciano Resende wrote: Not sure if I'm just repeating what Robbie just said, but what about also having a common log/trace infrastructure/abstraction between SCA, SDO and DAS, and we could provide a default implementation using a standard log framework (e.g log4J or java native log support) and allow user to customize it by implementing a specific interface and registering/loading it somehow ? snip The current DAS logging implementation was put in place to facilitate early development and debug. Now we need to take a step back and think about logging from within a client's application perspective. I think there are two issues we must resolve before we can go forward and change the current DAS logging code: 1. What logging framework should the DAS use? 2. What is our logging policy? It seems that the discussion, so far, has been about #1. My first thought was that the DAS should use one of the popular logging frameworks directly. I think the approach SCA has taken is too heavy for our lightweight RDB DAS and I doubt our time would be well spent inventing a new framework. But, Jim and Jeremy make an important point about the need to work well with the logging implementation chosen by our client applications. Given this, Commons Logging seems the best choice for the DAS. But, Jim mentioned problems he has experienced with Clogging and Jeremy even threatened a trout-slapping over the issue. I would like to know if these issues were specific to the SCA runtime and perhaps not an issue with a potential DAS usage. There are several successful OS projects using Commons Logging. The second issue has to do with what we should log and what logging patterns to use. There was some initial discussion on this list quite awhile back and TUSCANY-292 was created and remains open. Here are Ricks initial comments to the JIRA: ... I've looked for logging guidelines in various projects but couldn't find anything really relevant. My only specific advise is to log exceptions, major interfaces between components, and user settings/ configurations. Any thoughts? Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Coding convention for #ifndef in our includes
Can you please update C++ development website to include conventions that are agreed to? On 8/23/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I see two different coding conventions for the usual #ifndef/#define/#endif in our include files: #ifndef tuscany_sca_model_binding_h in tuscany::sca::model::Binding.h #ifndef _CHANGEDDATAOBJECTLIST_H_ in commonj::sdo::ChangedDataObjectList.h Can we decide on a common convention? I have used both conventions in the past, so I'm OK with either but think it'd be nicer if we could pick one and stick to it. Until we make a decision I'll follow my old code maintainer habit to stick to the scheme I see in the code around what I'm adding/changing. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Das Logging Framework
On Aug 23, 2006, at 3:13 PM, Kevin Williams wrote: snip Luciano Resende wrote: Not sure if I'm just repeating what Robbie just said, but what about also having a common log/trace infrastructure/abstraction between SCA, SDO and DAS, and we could provide a default implementation using a standard log framework (e.g log4J or java native log support) and allow user to customize it by implementing a specific interface and registering/loading it somehow ? snip The current DAS logging implementation was put in place to facilitate early development and debug. Now we need to take a step back and think about logging from within a client's application perspective. I think there are two issues we must resolve before we can go forward and change the current DAS logging code: 1. What logging framework should the DAS use? 2. What is our logging policy? It seems that the discussion, so far, has been about #1. My first thought was that the DAS should use one of the popular logging frameworks directly. I think the approach SCA has taken is too heavy for our lightweight RDB DAS and I doubt our time would be well spent inventing a new framework. But, Jim and Jeremy make an important point about the need to work well with the logging implementation chosen by our client applications. Given this, Commons Logging seems the best choice for the DAS. But, Jim mentioned problems he has experienced with Clogging and Jeremy even threatened a trout-slapping over the issue. I would like to know if these issues were specific to the SCA runtime and perhaps not an issue with a potential DAS usage. Please, please, please don't use clogging ;-) I used it in a previous implementation of SCA and really came to regret it due to memory leaks from not properly flushing its caches as well as collisions with other libraries, particularly when deployed to JBoss. These problems are not specific to SCA and I imagine they would be exacerbated in DAS as it is not a container technology. Various projects have encountered problems with clogging, including Jetty, Spring, Hibernate, JBoss, and I believe Geronimo (Jeremy knows the details of the latter). Basically, they revolve around failure to call LogFactory.release(). The lead log4j developer has written a detailed analysis of common problems here: http://www.qos.ch/logging/classloader.jsp The solution to some memory leak issues is suggested by clogging here: http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak? action=print http://jakarta.apache.org/commons/logging/guide.html#Classloader%20and %20Memory%20Management Requiring a container hook for release to be called seems very intrusive for a library. For a more colorful analysis, see: http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging Jim There are several successful OS projects using Commons Logging. The second issue has to do with what we should log and what logging patterns to use. There was some initial discussion on this list quite awhile back and TUSCANY-292 was created and remains open. Here are Ricks initial comments to the JIRA: ... I've looked for logging guidelines in various projects but couldn't find anything really relevant. My only specific advise is to log exceptions, major interfaces between components, and user settings/ configurations. Any thoughts? Thanks, --Kevin - 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: REST bindings for Tuscany SCA runtime
More ideas and questions below.
Oisin Hurley wrote:
Apologies for addressing the emails in this thread out of order :)
I was on a similar track, thinking about implementing a REST binding
for Tuscany C++. I agree with you that the REST pattern is about
resources, so we need to go further than just sending XML service
requests over HTTP, and understand what it means to work with
resources in an SCA application.
I was thinking about starting with something very simple like this:
In an SCDL component reference:
reference name=customers
interface.resource type=http://my.business.objects/#Customer/
/reference
and later in a composite reference:
reference name=customers
binding.rest/
/reference
QName http://my.business.objects/#Customer; specifies an XSD complex
type describing my Customer business object.
binding.rest loads my new REST binding extension that knows how to
send Customer resource requests over HTTP.
interface.resource indicates a fixed interface pattern with the
resource management / HTTP verbs.
In the client:
customers.get(http://my.customer.database.com/customers/1234;);
returns an instance of the Customer XSD complex type
customers.put(http://my.customer.database.com/customers/1234;,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get(http://my.customer.database.com/customers/;) returns a
list of URIs to the customers.
On the server, the CustomerResource component implements the Customer
resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
liststring list(string uris);
}
Yes I do like it, but I still have a fond attachment to the annotation
driven state-change - method mapping :)
What do you think about the following approach:
a) If you put no annotations in your code then you have to stick to the
fixed pattern with fixed method names, and you write the side SCDL file
that turns your code into a component and publishes the REST endpoint.
b) If you want more flexibility to map state changes to nicer method
names then you use annotations as your were proposing earlier in this
thread. The annotations also allow you to completely avoid writing SCDL
and specify the details of the binding like the base URI for the
resources...
Thoughts?
You have .put and .get in the client example, maybe the .post should be
something like
customers.post(uri, state-diff)
Ah! interesting, I never thought about that before, looks like there
could be a pretty good fit with SDO with the following:
customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ...
This would be an interesting usage of SDO change summaries IMO,
obviously just as an option as you should be able to format your state
diff in any format you want as long as it's understood by your application.
What do you think?
where state-diff is a state format dependent serialization.
Also, I was thinking that somehow our REST work should tie in with
the DAS work that we're doing in Tuscany.
+1 - I know little about the DAS stuff as yet, but the REST/CRUD/BREAD
approach has a strong affinity for data sources. IMHO this would be
a great first step!
--oh
-
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]
Re: possible bug: IllegalArgumentException, XSDHelperImpl.define : 204 ?
i just grabbed the latest source from svn, and i'm still getting the same issue. seems that there's a classcast exception within the define method on the XSDHelper. the difficult part is that the src.zip files don't match w/ the jars they're released w/ so stepping thru the EMF code is nearly impossible. has anyone had this issue before or seen anything odd within the define method in xsdhelperimpl? thanks --- Yang ZHONG [EMAIL PROTECTED] wrote: Some bugs have been fixed since M1, do you want to try the latest build(s)? Some build instructions can be found at http://incubator.apache.org/tuscany/java_sdo_overview.html If any steps are unclear to you, welcome to raise question(s) even contribute to improve the documentation :-) On 8/22/06, Paul Tomsic [EMAIL PROTECTED] wrote: does anyone know what causes this: 14:11:19,784 ERROR [STDERR] java.lang.IllegalArgumentException: org.eclipse.emf.ecore.impl.EDataTypeImpl 14:11:19,786 ERROR [STDERR] at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:204) 14:11:19,786 ERROR [STDERR] at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:163) i'm using incubating-M1 version of the sdo-impl for tuscany. The XSD isn't null, and it validates just fine against the XML. Just not sure what the issue is, since it appears that the method define is wrapping all the functionality in a illegal argument try/catch/throw thoughts? thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible bug: IllegalArgumentException, XSDHelperImpl.define : 204 ?
Do you want to open a JIRA at http://issues.apache.org/jira/browse/TUSCANY and attach all your test case(s)? On 8/23/06, Paul Tomsic [EMAIL PROTECTED] wrote: i just grabbed the latest source from svn, and i'm still getting the same issue. seems that there's a classcast exception within the define method on the XSDHelper. the difficult part is that the src.zip files don't match w/ the jars they're released w/ so stepping thru the EMF code is nearly impossible. has anyone had this issue before or seen anything odd within the define method in xsdhelperimpl? thanks --- Yang ZHONG [EMAIL PROTECTED] wrote: Some bugs have been fixed since M1, do you want to try the latest build(s)? Some build instructions can be found at http://incubator.apache.org/tuscany/java_sdo_overview.html If any steps are unclear to you, welcome to raise question(s) even contribute to improve the documentation :-) On 8/22/06, Paul Tomsic [EMAIL PROTECTED] wrote: does anyone know what causes this: 14:11:19,784 ERROR [STDERR] java.lang.IllegalArgumentException: org.eclipse.emf.ecore.impl.EDataTypeImpl 14:11:19,786 ERROR [STDERR] at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:204) 14:11:19,786 ERROR [STDERR] at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:163) i'm using incubating-M1 version of the sdo-impl for tuscany. The XSD isn't null, and it validates just fine against the XML. Just not sure what the issue is, since it appears that the method define is wrapping all the functionality in a illegal argument try/catch/throw thoughts? thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: Das Logging Framework
Thanks for your input. I enjoyed the evils of common logging link. So, if we avoid JCL then my next suggestion would be to use either Java logging or log4j directly and our users will need to deal with the -- possibly -- separate logging system. Are there any objections to this route? Thanks, --Kevin Jim Marino wrote: On Aug 23, 2006, at 3:13 PM, Kevin Williams wrote: snip Luciano Resende wrote: Not sure if I'm just repeating what Robbie just said, but what about also having a common log/trace infrastructure/abstraction between SCA, SDO and DAS, and we could provide a default implementation using a standard log framework (e.g log4J or java native log support) and allow user to customize it by implementing a specific interface and registering/loading it somehow ? snip The current DAS logging implementation was put in place to facilitate early development and debug. Now we need to take a step back and think about logging from within a client's application perspective. I think there are two issues we must resolve before we can go forward and change the current DAS logging code: 1. What logging framework should the DAS use? 2. What is our logging policy? It seems that the discussion, so far, has been about #1. My first thought was that the DAS should use one of the popular logging frameworks directly. I think the approach SCA has taken is too heavy for our lightweight RDB DAS and I doubt our time would be well spent inventing a new framework. But, Jim and Jeremy make an important point about the need to work well with the logging implementation chosen by our client applications. Given this, Commons Logging seems the best choice for the DAS. But, Jim mentioned problems he has experienced with Clogging and Jeremy even threatened a trout-slapping over the issue. I would like to know if these issues were specific to the SCA runtime and perhaps not an issue with a potential DAS usage. Please, please, please don't use clogging ;-) I used it in a previous implementation of SCA and really came to regret it due to memory leaks from not properly flushing its caches as well as collisions with other libraries, particularly when deployed to JBoss. These problems are not specific to SCA and I imagine they would be exacerbated in DAS as it is not a container technology. Various projects have encountered problems with clogging, including Jetty, Spring, Hibernate, JBoss, and I believe Geronimo (Jeremy knows the details of the latter). Basically, they revolve around failure to call LogFactory.release(). The lead log4j developer has written a detailed analysis of common problems here: http://www.qos.ch/logging/classloader.jsp The solution to some memory leak issues is suggested by clogging here: http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak? action=print http://jakarta.apache.org/commons/logging/guide.html#Classloader%20and %20Memory%20Management Requiring a container hook for release to be called seems very intrusive for a library. For a more colorful analysis, see: http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging Jim There are several successful OS projects using Commons Logging. The second issue has to do with what we should log and what logging patterns to use. There was some initial discussion on this list quite awhile back and TUSCANY-292 was created and remains open. Here are Ricks initial comments to the JIRA: ... I've looked for logging guidelines in various projects but couldn't find anything really relevant. My only specific advise is to log exceptions, major interfaces between components, and user settings/ configurations. Any thoughts? Thanks, --Kevin - 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]
