Re: Late resolution of reference targets - was:Accessing global domain information
Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, August 14, 2007 12:37 AM Subject: Late resolution of reference targets - was:Accessing global domain information Currently in CompositeWireBuilderImpl.connectComponentReference all targets are converted to bindings on a reference and the targets are removed. During this process the source and target bindings are compared until matching wireable bindings are found. This is not always possible because some of the targets are not resolvable at this point. Currently only the sca binding implements WireableBinding. I've opened https://issues.apache.org/jira/browse/TUSCANY-1534 about this. If the domain is distributed then at the build stage some of the targets will remain unresolved. For the new sca binding I have made the assumption here that unresolved targets take a copy of the bindings they may be resolved against at a later date and that the targets are maintained on the reference after the build stage. I still assume that the SCA binding is the only valid wireable binding at present. I start to look into this area too from a different perspetive. Please see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References. So I'm proposing that 1. The builder should retain the list of unresolved targets for use after the build stage 2. The list of bindings that might be used to resolve a target at a later date are associated with each target +1. What will the data structure look like? There are some cases that mixed styles are used to define the binding endpoint if the reference multiplicity is greater than 1 and promotion is used. For example, we can have the following: InnerComposite: composite name=InnerComposite .. component name=C1 ... reference name=myRef target=C2/S1 C3/S1 binding.sca/ binding.x/ /reference /component component name=C2 ... ... /component component name=C3 ... ... /component reference name=myOuterRef promote=C1/myRef binding.y /reference /composite composite name=OuterComposite ... component name=C4 implementation.composite=ns1:InnerComposite reference name=myOuterRef target=C5/S1/ /component ... component name=C5 ... ... /component /composite Then the effective wires for myRef will be: C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1 (binidng.y) Come wire creation time care must be take to create remote wires for unresolved targets. What I do at the moment is: CompositeActivatorImpl.addReferenceBindingProviders As before, create providers for all bindings that represent resolved targets For all unresolved targets If support is enabled create a cloned SCA binding and add it to the reference binding list (so that a wire will be created). This is pretty much what goes on in the CompositeWireBuilder but I've delayed it until here in the expectation that we will do remote binding matching one wireable support is fixed Create an SCA binding provider which will look up the remote endpoint at start() time. Thoughts? Regards Simon Sorry, but I'm having trouble understanding all this, it's starting to get a little complicated for me... Could somebody please give a *short* summary of the scenario that this is attempting to cover? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani resolved TUSCANY-1464. --- Resolution: Fixed Wrong query results when SELECT misses PKs -- Key: TUSCANY-1464 URL: https://issues.apache.org/jira/browse/TUSCANY-1464 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1464.patch, 1464.patch, 1464.patch, 1464.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html Fix the bug uncovered in above mail discussion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Metadata related to extension types
Venkata Krishnan wrote: Hi, The Assembly Model specs mentions the 'need' for definitions of metadata related to implementation and binding extensions types as follows: 2665 In addition to the definition for the new implementation instance element, there needs to be an 2666 associated implementationType element which provides metadata about the new implementation 2667 type. The pseudo schema for the implementationType element is shown in the following snippet: 2668 implementationType type=xs:QName 2669 alwaysProvides=list of intent xs:QName 2670 mayProvide=list of intent xs:QName/ 2749 bindingType type=xs:QName 2750 alwaysProvides=list of intent QNames? 2751 mayProvide = list of intent QNames?/ This metadata is supposed to be defined in definitions.xml file as defined on page 57, section title SCA Definitions. Since I am having to address the definitions.xml file as part of the policy framework implementation, I have included model and processors for implementationType and bindingType elements within the policy and policy-xml modules. But I guess this has to move out to a place that typically deals with 'domain' related things in general. Could people share some thoughts on this please ? Thanks - Venkat ImplementationType and BindingType are policy definitions, so what you've done - having StAX artifact processors for them in module policy-xml - makes sense to me. I'm not sure why we'd want to move them to a domain module, as that would tie unrelated aspects of an SCA domain together (and that wouldn't be good IMO). With respect to SCA definitions (contained in definitions.xml), we need: - a proper Definitions model separate from the policy module (as it can be used to define shared binding declarations which have nothing to do with policies - as described in the JMS binding spec) - a URLArtifactProcessor and StAXArtifactProcessor for definitions.xml I think we should follow the same pattern as the other models: - the Definitions model and its factory in a definition module - the URLArtifactProcessor and StAXArtifactProcessor in a definition-xml module The assembly module and the bindings that need to leverage shared definitions will need to depend on this new definition module so I'd suggest to it very minimal with just the Definitions model, unless you want to have to solve circular dependencies issues :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Learn to build your SCA app in few minutes...
Haleh, Your right it is a Java 6 problem. If I build with jre1.5.0_11 the demo starts up OK. Things are not right on the demo web page. The apple, orange and pear check boxes and labels are missing. I'm looking into this now. Cheers. On Tuesday 14 August 2007 23:01, haleh mahbod wrote: Steve, Java SCA FAQ says that Java 1.6 may not work. Can you try 1.5? Here is the link: http://incubator.apache.org/tuscany/tuscany-sca-java-faq.html#TuscanySC AJava-FAQ-BuildA Haleh On 8/14/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Steve, I am posting this to Tuscany-dev to see if there is a problem with the nightly while I am also downloading the latest to see if I run into the issue. Haleh On 8/14/07, Steve Jones [EMAIL PROTECTED] wrote: Hi, I've been working through the example. Everything builds OK. I get a null pointer exception when I try to run it (details at end). AFAIK I've built the demo exactly as outlined using the nightly build. I've linked eclipse to the latest svn source as the 0.91 source was giving me line number missmatch when I tried to do some debugging. I'm ruining eclipse Europa on Windows Vista with Java 1.6.0_02 . I'm completely new to web services so I really have no clue what to look out for. So far I've managed to get Tomcat running under IIS on a Windows Vista machine. I can stop and start Tomcat and the Tomcat jsp examples seem to work OK. I've made sure Tomcat is stopped when I launch the Tuscany demo. Could any of the above be the cause of the problem? Any suggestions would be very welcome, Thanks, Steve. Starting ... Exception in thread main org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java :264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance( SCADomain.java:69) at launch.Launch.main(Launch.java:8) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.TempServiceDeclarationUtil .getServiceClassNames( TempServiceDeclarationUtil.java:46) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtens ionPoint (DefaultExtensionPointRegistry.java:71) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder .createContributionService( ReallySmallRuntimeBuilder.java:152) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start( ReallySmallRuntime.java:109) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain .init( DefaultSCADomain.java:93) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java:230) ... 2 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Do we still need special handling of callback bindings and wires?
Now that callbacks are represented as regular services/references, are
the if (callback.) { } on lines 503 and 579 of
CompositeActivatorImpl still necessary?
If yes, then the next question is: Why? :)
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name Ok i see, thanks for the line numbers. The website page on binding.ws describes this a bit but i think I'm going to a new page on the website just about how binding uri's work and link to that from the other binding pages. Anyone feel free to help out and make it as clear as possible. ...ant
Re: Monitoring, logging and exceptions (again)
ant elder wrote: On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/8/07, ant elder [EMAIL PROTECTED] wrote: On 8/7/07, Simon Laws [EMAIL PROTECTED] wrote: We talked about this before ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16784.html) but didn't come to any conclusions. So, 1/ What is the requirement? 2/ What is the technical solution? 3/ When should we try and get it done? To get things going again here are some thoughts drawn from what was said in the referenced thread. 1/ An API in line with accepted logging/management practices to support arbitrary debugging and runtime info, warning and error logging A common approach to exception/error handling specifically around the detail recorded in the error messages Internationalization/localization Execution Tracing 2/ Keeping it simple was a popular sentiment A number of java logging solutions have been proposed Log4J, SLF4J etc. I believe DAS is using Log4J. We have dependencies that also use logging tools. We can take a look at how others approach this, e.g, quick glance at the last CxF release shows they include SLF4J jars Aspects were investigated to show how they can be used for tracing, seems like an interesting optional facility but adds extra complexity/dependencies There was also a suggestion that we could implement some higher level tracing, e.g. runtime starts, stops, application loading, component instance creation etc. We need to move error message out of the code and into resource files 3/ I think we can reasonably expect to agree what approach we are going to take fairly quickly and provide some examples, i.e. before the next release? People suggested before that we take time out to go through the code based and bring it into line. This will take a lot of time but can we get it into 1.0? Please add your thoughts to the list and we can then draw them together, try some of it out and come to some conclusions. Simon +1 for going with SLF4J. If we can decide on this soon then we can all just start adding it in to the code we're working on and debugging, and then maybe have a focused sweep before 1.0 to make sure its in everywhere useful. ...ant Cross posting to the user list also as I expect this is close to everyone heart. Can everyone reply to both lists. Thanks Simon We had a similar discussion in April [1]. Here's what I suggest for logging: - Separate the trace calls from the runtime code. Insert them automatically at build time or run time using Aspectj. Raymond on SCA and Kelvin on SDO already showed how to do it. - Use SLF4J in these generated trace calls. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] Thoughts? There were several posts on that referenced thread less keen on using aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the simplicity of the more traditional approach of explicit logging calls in Tuscany. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] OK then, I don't care much about whether or not we use aspects, but I think that calls to trace method entry/exit+parameters should be externalized and inserted automatically when we build Tuscany, as IMO writing all these repetitive calls by hand will be problematic: - it's a lot of work and will be difficult to maintain and keep consistent (when methods are renamed, parameters added etc.) - it puts a big requirement on people contributing Tuscany extensions to write all these calls in their extensions as well - it will make Tuscany difficult to integrate in an environment using a different logging framework Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error while executing the compiler - Java heap space
I always get a Java heap space error during the build while the itests are running these days. Runs fine if i build from within the itests folder but building from the top sca folder always fails. Does anyone else ever see this? Anyone know if there's something i can fiddle with in the mvn config to try to fix it? ...ant
Tuscany website down?
Hi, I can't access http://incubator.apache.org/tuscany/ website since yesterday. I am looking for Tuscany SDO binary release for Windows. Is it available from somewhere else? Yours, Ville - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany website down?
Its working fine for me when i try now. Just to confirm the URLs, the Tuscany download page is: http://incubator.apache.org/tuscany/sdo-java-releases.html You can get the actual release artifacts directly from the Apache distribution area at: http://people.apache.org/dist/incubator/tuscany/java/sdo/1.0-incubating/ ...ant On 8/15/07, Ville Kaseva [EMAIL PROTECTED] wrote: Hi, I can't access http://incubator.apache.org/tuscany/ website since yesterday. I am looking for Tuscany SDO binary release for Windows. Is it available from somewhere else? Yours, Ville - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error while executing the compiler - Java heap space
On 8/15/07, ant elder [EMAIL PROTECTED] wrote: I always get a Java heap space error during the build while the itests are running these days. Runs fine if i build from within the itests folder but building from the top sca folder always fails. Does anyone else ever see this? Anyone know if there's something i can fiddle with in the mvn config to try to fix it? ...ant Hi ant I don't know if this is exactly the same issue that Luciano was seeing in the Continuum build but I remember he was playing about with MAVEN_OPTS=-Xmx1024m -Xms512m things. I looked back at the mails and see him trying to find out how to set these on the the Continuum machine. Simon
Re: [DAS] Transaction support
Amita, Maybe I am not getting this. What is the user case scenario that you are trying to cover with your suggestion (I understand what you are suggesting to do, but not sure of use case)? In what case client needs what you are mentioning, beyond what is provided today? Thanks for the clarification. Haleh On 8/14/07, Adriano Crestani [EMAIL PROTECTED] wrote: ---if DAS exposes connection thru getConnection() ONLY when managedtx=false, it need to control cases when managedtx=true. So 2. will be needed. If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx loses its meaning and DAS can not control any transaction as client always have the control. I agree with you Amita, however the user will always have the control when it passes the a Connection to DAS on its creation no matter if the managedtx is true or not, because he will have a reference to the Connection he created. So, if the managedtx=true and the user passed the Connection to DAS, it will make no sense not to expose the Connection to the user, since he already has its reference. Regards, Adriano Crestani On 8/14/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: On 8/14/07, Adriano Crestani [EMAIL PROTECTED] wrote: Here is my opinion: 1- There are 2 ways for user to provide a Connection to DAS, create one and pass it to DAS on its creation or on ConnectionInfo. The first case is already giving the access to the Connection to the user. On the second, I think it's useful to provide access to it with getConnection(), since the user wouldn't be able to manage the transacions if he defines the managedtx=false. ---if DAS exposes connection thru getConnection() ONLY when managedtx=false, it need to control cases when managedtx=true. So 2. will be needed. If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx loses its meaning and DAS can not control any transaction as client always have the control. 2- Now, about start/endTransaction() methods, I agree with Luciano, it will look like DAS was specially designed for RDB when you define it on DAS class, maybe it could probably be added to rdb.DASImpl class and the user would have to cast it to rdb.DASImpl when creating a DAS instance using the factory. Anyway, I don't agree with adding these methods, once if being exposed the Connection with getConnection the user can commit or rollback whenever he wants, and control how many commands will be grouped as atomic change on rdb or not. 3- As we are already talking about DAS being heterogeneus and independent of implementations, as a interface should be, the classes on das package shouldn't be depedent of das.rdb package classes. But on patch from JIRA-1465 were added the methods add/remove/get/ResultDescriptor on Command class, however these methods are, as far as I know, only intended to be used with RDB DAS. So I think they are misplaced, maybe they should be placed on a Command implementation under das.rdb package. What do you 2 think? This can be a good start for DAS API-Impl separation work. We can discuss what all changes that need to happen in current DAS (Luciano already has some work in sandbox) to make a clean separation between API and Impl. e.g . DAS interface does not have an API for connecting to non-DBMS data stores, but it accepts java.sql.Connection indicating DAS from Interface level itself is tied to Database. Can we open another thread and list/discuss all the changes around this separation work? Regards, Adriano Crestani On 8/14/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just looked more at the code and found something more interesting - :) When there is no connectionInfo in DAS Config, managedtx defaults to true, so when connection is passed by user (as in TransactionTests), managedtx is true. So, with the current code case 4) can not occur (which is actually useful) 4)false from caller DAS does not issue commit/rollback, external caller manages TransactionTests - if you look closely, there is just one DAS.applyChanges(root) command which has 2 INSERT statements using same PK. So, 2nd INSERT gives JDBC Exception and DAS uses it to issue rollback. So, TransactionTests is succedding in getting exception and avoiding both INSERTs due to the fact that both INSERTs are under same applyChanges() Command. What will happen in case when there is a client code like das.applyChanges (root1); das.applyChanges(root2); and the client wants both applyChanges() to be part of the same transaction? Is it possible with current DAS? Based on the current code, there will be autocommits for each applyChanges()
Re: Learn to build your SCA app in few minutes...
Steve, Java SCA FAQ says that Java 1.6 may not work. Can you try 1.5? Here is the link: http://incubator.apache.org/tuscany/tuscany-sca-java-faq.html#TuscanySCAJava-FAQ-BuildA Haleh On 8/14/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Steve, I am posting this to Tuscany-dev to see if there is a problem with the nightly while I am also downloading the latest to see if I run into the issue. Haleh On 8/14/07, Steve Jones [EMAIL PROTECTED] wrote: Hi, I've been working through the example. Everything builds OK. I get a null pointer exception when I try to run it (details at end). AFAIK I've built the demo exactly as outlined using the nightly build. I've linked eclipse to the latest svn source as the 0.91 source was giving me line number missmatch when I tried to do some debugging. I'm ruining eclipse Europa on Windows Vista with Java 1.6.0_02 . I'm completely new to web services so I really have no clue what to look out for. So far I've managed to get Tomcat running under IIS on a Windows Vista machine. I can stop and start Tomcat and the Tomcat jsp examples seem to work OK. I've made sure Tomcat is stopped when I launch the Tuscany demo. Could any of the above be the cause of the problem? Any suggestions would be very welcome, Thanks, Steve. Starting ... Exception in thread main org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java :264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance( SCADomain.java:69) at launch.Launch.main(Launch.java:8) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.TempServiceDeclarationUtil.getServiceClassNames( TempServiceDeclarationUtil.java:46) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint (DefaultExtensionPointRegistry.java:71) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService( ReallySmallRuntimeBuilder.java:152) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start( ReallySmallRuntime.java:109) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain .init( DefaultSCADomain.java:93) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java:230) ... 2 more
Re: Error while executing the compiler - Java heap space
On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, ant elder [EMAIL PROTECTED] wrote: I always get a Java heap space error during the build while the itests are running these days. Runs fine if i build from within the itests folder but building from the top sca folder always fails. Does anyone else ever see this? Anyone know if there's something i can fiddle with in the mvn config to try to fix it? ...ant Hi ant I don't know if this is exactly the same issue that Luciano was seeing in the Continuum build but I remember he was playing about with MAVEN_OPTS=-Xmx1024m -Xms512m things. I looked back at the mails and see him trying to find out how to set these on the the Continuum machine. Simon Thanks, that does the trick. ...ant
Re: Tuscany website down?
On 8/15/07, Ville Kaseva [EMAIL PROTECTED] wrote: Hi, I can't access http://incubator.apache.org/tuscany/ website since yesterday. I am looking for Tuscany SDO binary release for Windows. Is it available from somewhere else? Yours, Ville - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Ville I can see it at the moment. The latest SDO release is at the link http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html Let us know if it still doesn't work. Regards Simon
Re: Late resolution of reference targets - was:Accessing global domain information
On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, August 14, 2007 12:37 AM Subject: Late resolution of reference targets - was:Accessing global domain information Currently in CompositeWireBuilderImpl.connectComponentReference all targets are converted to bindings on a reference and the targets are removed. During this process the source and target bindings are compared until matching wireable bindings are found. This is not always possible because some of the targets are not resolvable at this point. Currently only the sca binding implements WireableBinding. I've opened https://issues.apache.org/jira/browse/TUSCANY-1534 about this. If the domain is distributed then at the build stage some of the targets will remain unresolved. For the new sca binding I have made the assumption here that unresolved targets take a copy of the bindings they may be resolved against at a later date and that the targets are maintained on the reference after the build stage. I still assume that the SCA binding is the only valid wireable binding at present. I start to look into this area too from a different perspetive. Please see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References. So I'm proposing that 1. The builder should retain the list of unresolved targets for use after the build stage 2. The list of bindings that might be used to resolve a target at a later date are associated with each target +1. What will the data structure look like? There are some cases that mixed styles are used to define the binding endpoint if the reference multiplicity is greater than 1 and promotion is used. For example, we can have the following: InnerComposite: composite name=InnerComposite .. component name=C1 ... reference name=myRef target=C2/S1 C3/S1 binding.sca/ binding.x/ /reference /component component name=C2 ... ... /component component name=C3 ... ... /component reference name=myOuterRef promote=C1/myRef binding.y /reference /composite composite name=OuterComposite ... component name=C4 implementation.composite=ns1:InnerComposite reference name=myOuterRef target=C5/S1/ /component ... component name=C5 ... ... /component /composite Then the effective wires for myRef will be: C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1 (binidng.y) Come wire creation time care must be take to create remote wires for unresolved targets. What I do at the moment is: CompositeActivatorImpl.addReferenceBindingProviders As before, create providers for all bindings that represent resolved targets For all unresolved targets If support is enabled create a cloned SCA binding and add it to the reference binding list (so that a wire will be created). This is pretty much what goes on in the CompositeWireBuilder but I've delayed it until here in the expectation that we will do remote binding matching one wireable support is fixed Create an SCA binding provider which will look up the remote endpoint at start() time. Thoughts? Regards Simon Sorry, but I'm having trouble understanding all this, it's starting to get a little complicated for me... Could somebody please give a *short* summary of the scenario that this is attempting to cover? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Raymond is coming at the problem from a different direction to me so I'll let him give examples. For me the scenario is composite ... name=HelloWorld component name=HelloWorldClient implementation.java class=HelloWorldClient / reference name=helloWorldService target=HelloWorldService / /component /composite Where HelloWorldService does not appear in the loaded contributions. Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Your comment Binding extensions are still responsible for determining the effective URI, describes a Tuscany specific mechanism where by the URI determined using the algorithm you describe is turned into the effective URI required by each binding extension. In the code today a number of bindings hardcode default endpoint information which is used to create the effective URI in the case where this information can't be extracted from binding.getURI() I would expect, at some point, to see a mechanism by which this hardcoded default information can be changed. From previously in this thread you do seem to
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name Ok i see, thanks for the line numbers. The website page on binding.ws describes this a bit but i think I'm going to a new page on the website just about how binding uri's work and link to that from the other binding pages. Anyone feel free to help out and make it as clear as possible. ...ant I'd like to make sure this is absolutely
Re: Learn to build your SCA app in few minutes...
Hi Steve, I am posting this to Tuscany-dev to see if there is a problem with the nightly while I am also downloading the latest to see if I run into the issue. Haleh On 8/14/07, Steve Jones [EMAIL PROTECTED] wrote: Hi, I've been working through the example. Everything builds OK. I get a null pointer exception when I try to run it (details at end). AFAIK I've built the demo exactly as outlined using the nightly build. I've linked eclipse to the latest svn source as the 0.91 source was giving me line number missmatch when I tried to do some debugging. I'm ruining eclipse Europa on Windows Vista with Java 1.6.0_02. I'm completely new to web services so I really have no clue what to look out for. So far I've managed to get Tomcat running under IIS on a Windows Vista machine. I can stop and start Tomcat and the Tomcat jsp examples seem to work OK. I've made sure Tomcat is stopped when I launch the Tuscany demo. Could any of the above be the cause of the problem? Any suggestions would be very welcome, Thanks, Steve. Starting ... Exception in thread main org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java :69) at launch.Launch.main(Launch.java:8) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.TempServiceDeclarationUtil.getServiceClassNames (TempServiceDeclarationUtil.java:46) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint (DefaultExtensionPointRegistry.java:71) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeBuilder.createContributionService (ReallySmallRuntimeBuilder.java:152) at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start( ReallySmallRuntime.java:109) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init( DefaultSCADomain.java:93) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance( SCADomain.java:230) ... 2 more
Associating BindingType with Binding instances and ImplementationType with implementation instances
Hi, There is a phase in the policy fwk impl that needs to validate attachment points for the intents attached (or specified) in them. A PolicyIntent definition has a 'constrains' attribute that lists the valid attachment points (bindings / implementations) for an intent. This list is a list of QNames that point to bindingtypes or implementation types such as binding.wsor implementation.java. Having said that, presently I am doing this sort of validation during the build phase. For example I am looking into each binding instance, getting the list of intents attached to it and then for each intent I want to look up the 'constrains' attribute to see if it lists the 'bindingtype' of the binding instance in question. But then, where do I get the bindingType given the binding instance ? To support this, seems like we could had a QName field to the Binding and Implementation abstractions to represent the BindingType and ImplementationType respectively. As per the extension model section in the AssemblySpecs it does seem like every implementation and binding extension does 'need' to define implementation and bindingType elements and I have already implemented abstractions for these elements in the Policy module. References : Pg 5 of Policy Fwk specs, Pg 60 and Pg 62 of Assembly Model specs. Thoughts ? Thanks - Venkat
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name Ok i see, thanks for the line numbers. The website page on binding.ws describes this a bit but i think I'm going to a
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Your comment Binding extensions are still responsible for determining the effective URI, describes a Tuscany specific mechanism where by the URI determined using the algorithm you describe is turned into the effective URI required by each binding extension. In the code today a number of bindings hardcode default endpoint information which is used to create the effective URI in the case
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. Default values for service binding URIs are now initialized by CompositeBuilder, so binding extensions do not have to repeat that logic anymore. Service binding extensions can now call binding.getURI() and get: - binding/@uri if it the specified URI is absolute - component URI + binding/@uri if the specified URI is relative ../ ./ etc. are supported as supported by java.net.URI for a domain level composite service, component URI is empty for a service on a domain level component, component URI is the component name for a nested component, component URI is the sum of the names of the nested components separated by '/' - component URI / binding/@name if no URI is specified on the binding - component URI / service/@name if no binding name is specified Binding extensions are still responsible for determining the effective URI, choosing their specific protocol scheme, or applying any other binding-specific precedence rules (for example the Web Service binding needs to consider the URI specified in a WSDL port or WSDL endpoint). Why is component URI empty for a service on a domain level component? Is that in the spec somewhere? ...ant Not for a domain level component, but for a domain level composite service. From my original description: for a domain level composite service, component URI is empty From the assembly spec: 2380 Services deployed into the Domain (as opposed to services of components) have a URI that does 2381 not include a component name Ok i see, thanks for the line numbers. The website page on binding.ws describes this a bit but i think I'm going to a new page on the website just about how binding uri's work and link to that from the other binding pages. Anyone feel free to help out and make it as clear as possible. ...ant I'd like to make sure this is absolutely clear in my mind (if no one else's). What would you like me to do? Simon
Re: Tuscany/Geronimo Integration Demo
On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT . The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png . The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. After switching to 1.0-incubating-SNAPSHOT, I have run into a NoClassDefFoundError: org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? GERONIMO-3351 has not been integrated into 2.0 release. Part of the problem is addressed in branches\2.0 and trunk. It affects only SNAPSHOT dependencies and there is some discussion on whether the downloaded version (if it is different from SNAPSHOT) should be renamed, by the plugin installer, to SNAPSHOT or the dependency resolution is Geronimo should handle it in a different way. The problem we have run into is in conjunction with another problem that occurs when a trailing / is not present in the maven repo URL. This has been fixed in branches\2.0 and trunk (not in 2.0 release though) and the work around for this is to put that trailing / in the maven repo URLs in geronimo-plugin.xml. These two fixes will (most likely, but not guaranteed) go into 2.0.1 due to be released soon (probably this week). [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a week or so ago when I moved the majority of sca binding into the binding-sca module. I'm thinking that I was a little overzealous when I took this out and that it probably needs to go back in. In the mean time can you create a org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl instead? Regards Simon
Re: Move up to Axis2 1.3?
On 8/14/07, ant elder [EMAIL PROTECTED] wrote: Axis2 1.3 has just been released so how about moving up to that? There's a lot of improvements and bug fixes in it and as its the level we'll likely go 1.0 with i think it would be good to get it in sooner so we have time to find and fixes any problems. There's a few minor changes we need to do in Tuscany to move up but I have it almost going, just one failing testcase remaining, so what do people think, should we move up now or wait till after our next release? ...ant We will have to take your advice on whether it can be made to work this week. Assuming it can then +1 to sooner rather than later. The less we have to change just before 1.0 the better. Simon
Re: Error while executing the compiler - Java heap space
You can also increase the memory options in the sca pom, in the surefire plugin configuration section. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, ant elder [EMAIL PROTECTED] wrote: I always get a Java heap space error during the build while the itests are running these days. Runs fine if i build from within the itests folder but building from the top sca folder always fails. Does anyone else ever see this? Anyone know if there's something i can fiddle with in the mvn config to try to fix it? ...ant Hi ant I don't know if this is exactly the same issue that Luciano was seeing in the Continuum build but I remember he was playing about with MAVEN_OPTS=-Xmx1024m -Xms512m things. I looked back at the mails and see him trying to find out how to set these on the the Continuum machine. Simon Thanks, that does the trick. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1538) InitialContextCreator Patches
[ https://issues.apache.org/jira/browse/TUSCANY-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1538. -- Resolution: Fixed Patch applied InitialContextCreator Patches - Key: TUSCANY-1538 URL: https://issues.apache.org/jira/browse/TUSCANY-1538 Project: Tuscany Issue Type: Improvement Components: Java DAS LDAP Reporter: Ole Ersoy Fix For: Java-DAS-Next Attachments: InitialContextCreatorPatch.txt, InitialContextCreatorTestPatch.txt InitialContextCreator javadoc and test patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java DAS beta1 (RC4)
+1 On 8/14/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Tried tests, samples, checked documentation. Looks fine to me. +1 (non-binding) Regards, Amita On 8/14/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types
Abstract Static Base Types mixed with Dynamic Extended Types Key: TUSCANY-1540 URL: https://issues.apache.org/jira/browse/TUSCANY-1540 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Reporter: Murtaza Goga Fix For: Java-SDO-Next Setting a property on a static data object with an object of a type extended in a dynamic model results in a ClassCastException. Scenario: Static schema- xsd:complexType name=CustomerType xsd:all xsd:element name=number type=xsd:integer / xsd:element form=unqualified name=info type=InfoType / /xsd:all /xsd:complexType xsd:complexType name=InfoType abstract=true/ Dynamic Schema xsd:complexType name=InfoType xsd:complexContent xsd:extension base=staticNS:InfoType xsd:sequence xsd:element name=zipcode type=xsd:string / /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType The following will fail: DataFactory factory = scope.getDataFactory(); factory.create(CustomerType.class).setDataObject(info, factory.create(dynamicNS, InfoType)); It should be legal to assign a property to an object if they are in the same hierachy. Steps to reproduce within Tuscany: Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 'InfoType' defined in extensible/customer.xsd is marked as abstract. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can RSS Feed be enabled for Tuscany blog?
Hi, There is no RSS Feed on Tuscany blog[1]. Any one knows how to enable this? [1]: http://apache-tuscany.blogspot.com/ Haleh
Re: Can RSS Feed be enabled for Tuscany blog?
You can definetly get Atom feeds using the following URL : http://apache-tuscany.blogspot.com/feeds/posts/default As for RSS, there is some documentation here [1], but that seems not working anymore. As a tip, I also use iGoogle [2] as my homepage, and customized it to give me access to all related Tuscany blog feeds on one page, it's useful to see what's going on... and keep you updated. [1] http://help.blogger.com/bin/answer.py?answer=42662query=rss%20urltopic=type=f [2] http://www.google.com/ig On 8/15/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, There is no RSS Feed on Tuscany blog[1]. Any one knows how to enable this? [1]: http://apache-tuscany.blogspot.com/ Haleh -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Metadata related to extension types
HI Sebastien, thanks... please see my comments inline. - Venkat On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, The Assembly Model specs mentions the 'need' for definitions of metadata related to implementation and binding extensions types as follows: 2665 In addition to the definition for the new implementation instance element, there needs to be an 2666 associated implementationType element which provides metadata about the new implementation 2667 type. The pseudo schema for the implementationType element is shown in the following snippet: 2668 implementationType type=xs:QName 2669 alwaysProvides=list of intent xs:QName 2670 mayProvide=list of intent xs:QName/ 2749 bindingType type=xs:QName 2750 alwaysProvides=list of intent QNames? 2751 mayProvide = list of intent QNames?/ This metadata is supposed to be defined in definitions.xml file as defined on page 57, section title SCA Definitions. Since I am having to address the definitions.xml file as part of the policy framework implementation, I have included model and processors for implementationType and bindingType elements within the policy and policy-xml modules. But I guess this has to move out to a place that typically deals with 'domain' related things in general. Could people share some thoughts on this please ? Thanks - Venkat ImplementationType and BindingType are policy definitions, so what you've done - having StAX artifact processors for them in module policy-xml - makes sense to me. I'm not sure why we'd want to move them to a domain module, as that would tie unrelated aspects of an SCA domain together (and that wouldn't be good IMO). I am really not able to classify these two as just related to policy implementation alone. From what I understand these two are mechanisms for extensions to publish meta-data in general and not specifically metadata related to their support for policies. I just about inferred this from what the Assembly specs says. While today, we seem to find this a good place to define policy related metadata, I guess in future this is going to be accomodating more. Is this a right train of thoughts ? With respect to SCA definitions (contained in definitions.xml), we need: - a proper Definitions model separate from the policy module (as it can be used to define shared binding declarations which have nothing to do with policies - as described in the JMS binding spec) - a URLArtifactProcessor and StAXArtifactProcessor for definitions.xml I think we should follow the same pattern as the other models: - the Definitions model and its factory in a definition module - the URLArtifactProcessor and StAXArtifactProcessor in a definition-xml module The assembly module and the bindings that need to leverage shared definitions will need to depend on this new definition module so I'd suggest to it very minimal with just the Definitions model, unless you want to have to solve circular dependencies issues :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Late resolution of reference targets - was:Accessing global domain information
On 8/14/07, Raymond Feng [EMAIL PROTECTED] wrote: Comments inline. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, August 14, 2007 12:37 AM Subject: Late resolution of reference targets - was:Accessing global domain information Currently in CompositeWireBuilderImpl.connectComponentReference all targets are converted to bindings on a reference and the targets are removed. During this process the source and target bindings are compared until matching wireable bindings are found. This is not always possible because some of the targets are not resolvable at this point. Precisely:-) Currently only the sca binding implements WireableBinding. I've opened https://issues.apache.org/jira/browse/TUSCANY-1534 about this. If the domain is distributed then at the build stage some of the targets will remain unresolved. For the new sca binding I have made the assumption here that unresolved targets take a copy of the bindings they may be resolved against at a later date and that the targets are maintained on the reference after the build stage. I still assume that the SCA binding is the only valid wireable binding at present. I start to look into this area too from a different perspetive. Please see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References. Cool. Let me think about this a little and I'll add notes. I know Simon N did some work in this are recently and there have been a thread about cross JVM lookups recently specifically focusing on service references/callable references. So there are a few interested parties. So I'm proposing that 1. The builder should retain the list of unresolved targets for use after the build stage 2. The list of bindings that might be used to resolve a target at a later date are associated with each target +1. What will the data structure look like? There are some cases that mixed styles are used to define the binding endpoint if the reference multiplicity is greater than 1 and promotion is used. For example, we can have the following: InnerComposite: composite name=InnerComposite .. component name=C1 ... reference name=myRef target=C2/S1 C3/S1 binding.sca/ binding.x/ /reference /component component name=C2 ... ... /component component name=C3 ... ... /component reference name=myOuterRef promote=C1/myRef binding.y /reference /composite composite name=OuterComposite ... component name=C4 implementation.composite=ns1:InnerComposite reference name=myOuterRef target=C5/S1/ /component ... component name=C5 ... ... /component /composite Then the effective wires for myRef will be: C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1 (binidng.y) Do you know off the top of your head where the bindings for the promoted reference live in the model before build time? At build time do they get resolved back into the original reference bindings list? Come wire creation time care must be take to create remote wires for unresolved targets. What I do at the moment is: CompositeActivatorImpl.addReferenceBindingProviders As before, create providers for all bindings that represent resolved targets For all unresolved targets If support is enabled create a cloned SCA binding and add it to the reference binding list (so that a wire will be created). This is pretty much what goes on in the CompositeWireBuilder but I've delayed it until here in the expectation that we will do remote binding matching one wireable support is fixed Create an SCA binding provider which will look up the remote endpoint at start() time. Thoughts? Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Metadata related to extension types
[snip] Venkata Krishnan wrote: I am really not able to classify these two as just related to policy implementation alone. From what I understand these two are mechanisms for extensions to publish meta-data in general and not specifically metadata related to their support for policies. I just about inferred this from what the Assembly specs says. While today, we seem to find this a good place to define policy related metadata, I guess in future this is going to be accomodating more. Is this a right train of thoughts ? I still think that implementationType and bindingType are policy specific at this point (SCA 1.0 spec), and I won't try to guess if they'll accommodate more or less in the future or be replaced by something else. However, if you prefer to move them out of the policy module, then go ahead and see where it leads you :) As long as it's not tying unrelated aspects together or creating unnatural module dependencies I'm OK with it. As a suggestion, the next module that will still make sense to me then is assembly (which will then contain binding and bindingType, implementation and implementationType). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element
[ https://issues.apache.org/jira/browse/TUSCANY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1528: Attachment: 1528.patch Based on the comment from Frank B., a package should always has a document root class for containing the demand create properties at a later time. This approach simplifies the resolution for this JIRA a lot. Here is the patch with the fix and 2 test cases. I created a new private method called createDocumentRoot(). In the method getPackage() of BaseSDOXSDEcoreBuilder.java, I make sure document root class was created and associated with the newly created package. In the method, getEstructuralFeature(), of BaseSDOXSDEcoreBuild.java, I modified it to call the new createDocumentRoot() if one doesn't exist. This checking/creating should not be needed any more but I keep it to be safe. Please review and comment. Thanks. ClassCastException thrown when trying to deserializing an XML with undefined global element --- Key: TUSCANY-1528 URL: https://issues.apache.org/jira/browse/TUSCANY-1528 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Fix For: Java-SDO-Next Attachments: 1528-testcase.patch, 1528.patch Using simple.xsd, I can serialize and deserialize an XML with a undefined global element. If I removed the global element definition from the simple.xsd, a ClassCastException will be thrown. It seems without the global element definition's presence some required step was not done. Here is the stack trace and test case. junit.framework.AssertionFailedError: java.lang.ClassCastException: org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with commonj.sdo.DataObject at junit.framework.Assert.fail(Assert.java:47) at org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java DAS beta1 (RC4)
+1 ...ant On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] Next Release Design
Brady, sorry I haven't had too much time to comment on this but it all looks sensible and in the right direction to me. Regarding the schema loading, where you say sca-implementation-java.xsd (loaded but ignored) I think this means we will load this schema but as no extension is registered to handle the implementation.java / those elements will be ignored when building the model from scdl. I think we should ensure that scdl is not the only way to define model elements so that extensions can add to the model dynamically. I think this is possible today but I need to re-familiarise myself with the code ;-) Cheers, On 13/08/07, Brady Johnson [EMAIL PROTECTED] wrote: Hello all, I have written some preliminary design specifications for the TuscanySCA M4 release. This is a living document, and I will be continuously updating it. Before I get any further, I would like some opinions on the refactor of the SCA Data Model. Input/Suggestions are very welcome. Here's the WIKI page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+Nativ e+Release+M4+Design+Specifications (the mail program may cut the link into several lines, so make sure you copy all the way to +Specifications) Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
[ https://issues.apache.org/jira/browse/TUSCANY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520109 ] Jean-Sebastien Delfino commented on TUSCANY-1523: - Can you try to register your artifact processor with .xml until this is fixed? Enhance ArtifactProcessors to be registered for file names, as well as for file types - Key: TUSCANY-1523 URL: https://issues.apache.org/jira/browse/TUSCANY-1523 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Details on the following thread: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
XMLStreamException in when calling XMLHelper.load() with a large XML Key: TUSCANY-1541 URL: https://issues.apache.org/jira/browse/TUSCANY-1541 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Next Environment: Tomcat Reporter: Sunny Ip Priority: Critical When XMLHelper.load() is called with a very long XML string, OMStAXWrapper throws an XMLStreamException. I get this problem when I'm receiving a WS response with an SDO object containing a collection of records, leading to a TransformationException when databinding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1542) BPEL extension to link sca component into a business process
BPEL extension to link sca component into a business process Key: TUSCANY-1542 URL: https://issues.apache.org/jira/browse/TUSCANY-1542 Project: Tuscany Issue Type: Wish Affects Versions: Java-SCA-Next Reporter: gengshaoguang What I expect next is: extend a bpel engine, make it interact with Tuscany's sca binding. Of course any bpel engine might link wsdl naturaly. But in the latter case, we make no improvement to SOA tech. BPEL-SCA should work in a more direct way and more effect way. I think SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at section 1.4 . I open this issue to arouse collaboration from all of you. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1542) BPEL extension to link sca component into a business process
[ https://issues.apache.org/jira/browse/TUSCANY-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520141 ] Luciano Resende commented on TUSCANY-1542: -- We have started this under java/sca/modules/implementation.bpel. Any help is appreciated BPEL extension to link sca component into a business process Key: TUSCANY-1542 URL: https://issues.apache.org/jira/browse/TUSCANY-1542 Project: Tuscany Issue Type: Wish Affects Versions: Java-SCA-Next Reporter: gengshaoguang What I expect next is: extend a bpel engine, make it interact with Tuscany's sca binding. Of course any bpel engine might link wsdl naturaly. But in the latter case, we make no improvement to SOA tech. BPEL-SCA should work in a more direct way and more effect way. I think SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at section 1.4 . I open this issue to arouse collaboration from all of you. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java DAS beta1 (RC4)
It seems ok for me, everything ran fine ; ) +1 Adriano Crestani On 8/15/07, ant elder [EMAIL PROTECTED] wrote: +1 ...ant On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1542) BPEL extension to link sca component into a business process
[ https://issues.apache.org/jira/browse/TUSCANY-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520145 ] gengshaoguang commented on TUSCANY-1542: They are different! SCA has specified BPEL from to direction, one is implement a component as a BPEL. Another is to invoke SCA component from BPEL side. I metioned BPEL can invoke and WS, but it is narrowly used since it's performance is slow, so we need to extend a bpel engin to make it interact direct with SCA BINDING (from bpel's partnerlink to a sca component). BPEL extension to link sca component into a business process Key: TUSCANY-1542 URL: https://issues.apache.org/jira/browse/TUSCANY-1542 Project: Tuscany Issue Type: Wish Affects Versions: Java-SCA-Next Reporter: gengshaoguang What I expect next is: extend a bpel engine, make it interact with Tuscany's sca binding. Of course any bpel engine might link wsdl naturaly. But in the latter case, we make no improvement to SOA tech. BPEL-SCA should work in a more direct way and more effect way. I think SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at section 1.4 . I open this issue to arouse collaboration from all of you. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Home page for Tuscany standalone runtime
The runtime currently prints the servlet mappings to System.out when it starts. In order to make that kind of information easier to use, I've started to put together a home page that people can point their Web browser to, listing some basic information about the running Tuscany runtime, servlet endpoints, etc. I'm planning to start adding some of this home page support to a new home module. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML
[ https://issues.apache.org/jira/browse/TUSCANY-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520146 ] Sunny Ip commented on TUSCANY-1541: --- Here is the stacktrace. I misread it and the problem actually isn't coming from XMLHelper.load(), but XMLDocumentImpl.load(). Exception org.apache.tuscany.sca.databinding.TransformationException Exception message: org.apache.tuscany.sca.databinding.TransformationException: javax.xml.stream.XMLStreamException org.apache.tuscany.sca.databinding.TransformationException: org.apache.tuscany.sca.databinding.TransformationException: javax.xml.stream.XMLStreamException at org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:181) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:77) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.transform(DataTransformationInteceptor.java:168) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:152) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy11.DepAcctTrnInq(Unknown Source) at com.bns.soa.mci.svc.actvb.trninq.TrnInqClient.DepAcctTrnInq(TrnInqClient.java:22) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy11.DepAcctTrnInq(Unknown Source) at org.apache.jsp.DepAcctTrnInqTest_jsp._jspService(DepAcctTrnInqTest_jsp.java:222) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.tuscany.sca.databinding.TransformationException: javax.xml.stream.XMLStreamException at org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:50) at
