Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus
Ok, so can our Confluence admins tell us if we need to create a JIRA with infra to make this happen or whether they can action this? Simon
Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus
I was wanting to take Luciano's help to make my id admin. Since he is not available I've just about posted to infra to add my id as confluence admin. As mentioned on the IRC last night I'd like to check up after I get admin privelges, if this can be done by us or should have to only go thro infra. I my local confluence I can see how to get this done and remains to be seen if the same can be done on the Apache Confluence. - Venkat On 6/12/07, Simon Laws [EMAIL PROTECTED] wrote: Ok, so can our Confluence admins tell us if we need to create a JIRA with infra to make this happen or whether they can action this? Simon
Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus
Ok, thanks Venkat for looking into this. Simon
Re: 0.91 release?
Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon
Re: Reference and Service properties for SCA-OSGi implementation
Ant, We will implement this as part of implementation.osgi/ for now, so that Tuscany core doesn't have to be modified before OSGi implementation code is committed. So both service and reference properties will be specified in the implementation.osgi/ element as you described. Graham and I were discussing this today, and we are not convinced that OSGi service and reference properties really belong to implementation.osgi/. The right place for these properties is really the component type file since these properties describe the implementation rather than a configured instance of the implementation (ie. component). Once coded in an OSGi implementation, these properties are no longer configurable without modifying the OSGi bundle. When there are multiple uses of an implementation, specifying the implementation properties in the component will result in duplicating the information. Since the component type file describes an implementation, there should really be some way for additional attributes or elements specific to the type of implementation to be added to the component type file. At the moment, we have only come across properties, but there may be other implementation-specific information which belong to the component type file which come up in future. Ideally we would like to specify the OSGi service and reference properties the service/ and reference/ elements in the component type file, and have the OSGi implementation processor process this somehow: componentType service name=RetailerService property name=retailerName type=xsd:stringamazon.com /property /service /componentType componentType reference name=retailer1 property name=retailerName type=xsd:stringamazon.com /property /reference /componentType Presumably this cannot be done using the SCA specification as it stands. But I would appreciate any feedback on whether other implementations have had similar requirements in the past and whether this is a sensible approach for the future (especially if we encounter more implementation-specific information which refer to an implementation rather than its configured instance). Thank you... Regards, Rajini On 6/11/07, ant elder [EMAIL PROTECTED] wrote: On 6/11/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, I am working on an OSGi implementation type for Tuscany, and would like to figure out the best way of mapping properties of OSGi services onto SCA. This is specifically an issue in the bottom-up scenario where existing OSGi bundles are assembled using SCA (In the top-down scenario where SCA is in charge, services will be looked up using component and service names rather than OSGi properties). In OSGi, services are registered in the OSGi registry with a set of properties. BundleContext.registerService(java.lang.String clazz, java.lang.Object service, java.util.Dictionary properties); The service is looked up from the OSGi registry using a property filter. BundleContext.getServiceReferences(java.lang.String clazz, java.lang.String filter); In SCA, since properties are currently associated only with components rather than services or references, there is no easy way to specify the properties required to register or lookup OSGi services. As an example, I would like to specify a property named retailerName for the retailer service in the supplychain sample. The sample uses a customer component with a reference to a retailer component. Scenario 1: Customer is an OSGi component and the Retailer is a Java component. An existing OSGi customer bundle uses the retailer name as the filter to lookup the retailer service. A proxy service is registered for the Java component by the Tuscany OSGi implementation provider, and this service needs to be registered with the properties that the referring OSGi component uses to lookup the service. Hence we need a way to specify properties in the component reference definition. Scenario 2: Customer and Retailer are OSGi components. If there are multiple retailer services in the composite with different properties, the Tuscany OSGi implementation provider registers a proxy service (with maximum ranking) with the service properties specified to guarantee the wiring specified in the SCA composite. In this case the proxy service needs to be registered with the properties of the original OSGi service to ensure that OSGi references to the service use the proxy. Hence we need a way to specify properties in the component service definition. The possible options for adding this information to the SCA composite are: 1. Add property definitions to ComponentService and ComponentReference. These will need to be processed by the Tuscany core and made available in some format through the interfaces for ComponentService and ComponentReference. Having the service and reference properties in an identical format should simplify both the implementation and the use of
[jira] Updated: (TUSCANY-1335) Documentation for wiki
[ https://issues.apache.org/jira/browse/TUSCANY-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1335: - Attachment: ForWikiJune12.zip Note: If non-committers are getting a different space to work on wiki, the below points can wait for it. Latest zip is ForWikiJune12.zip (CHANGES.txt, modified DAS_Java_Development_Guide.txt) For DAS_Java_Development_Guide.txt - have not verified how it renders on browser. 1) on http://cwiki.apache.org/confluence/display/TUSCANY/Starting+with+DAS, please delete content from old guide - just to compare, can be deleted later onwards 2) in http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide, please give links to readmes from svn for Samples (I did not see links replaced? J2SE Sample and Web Sample still have old links and Adavanced Web Sample has no link) Required: Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm J2SE Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm Advanced Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm 3) CHANGES.txt - attaching in JIRA, so can be checked in under proper place in svn - most likely https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/beta1-incubating/distribution/src/main/release/CHANGES Let other DAS committers review this before commit to svn 4) in http://cwiki.apache.org/confluence/display/TUSCANY/DAS+RDB+Menu give links for FAQ - http://cwiki.apache.org/confluence/display/TUSCANY/DAS+Java+-+FAQ What's New? - http://cwiki.apache.org/confluence/display/TUSCANY/What%27s+New+in+DAS+JAVA - Here M3-beta1 is required in heading 5) RELEASE_NOTES.txt - can be checked in under proper place in svn - most likely https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/source/src/main/release/RELEASE NOTES Let other DAS committers review this before commit to svn. (So basically, source/src will be needed, but this can wait for other reviewers) 6) DAS_Java_Development_Guide.txt - has merged contents from http://cwiki.apache.org/confluence/display/TUSCANY/DAS+Java+Developer+Guide , so this can now replace http://cwiki.apache.org/confluence/display/TUSCANY/DAS+Java+Developer+Guide Documentation for wiki --- Key: TUSCANY-1335 URL: https://issues.apache.org/jira/browse/TUSCANY-1335 Project: Tuscany Issue Type: Task Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Amita Vadhavkar Assignee: Simon Laws Attachments: ForWiki.zip, ForWikiJune12.zip files for review and addition to wiki -- 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]
[DAS] Transaction support
Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita
Re: Contribute to SCA-OSGi integration
Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini
Re: [SDO Java DISCUSS] Contents of the next SDO release
This sounds good to me. I assume Christian's suggestion for additional SDOUtil methods, and Bert/Steffen's request for notification support, are two more candidates for 1.0. Christian and Bert/Steffen, are you planning to open JIRAs for those? I'm worried about how many things are really doable, given the target we have in mind for the release (next month). Are people going to help with these features by providing patches? If not, is delaying the release for another month or two acceptable? Personally, I'd like to stick with a July target for the release. If somebody wants a feature that we can't handle in time, they'll need to help implement it. Otherwise it slips to the next release. What do others think? By the way, that reminds me that we need someone to be release manager for this release. Any volunteers? If not, maybe Kelvin, you would be willing to do it, since you've already been doing lots of the prep work. Thanks, Frank [EMAIL PROTECTED] wrote on 06/11/2007 06:02:20 AM: Good suggestion Steffen. If you were able to open a Jira and dump into it any thoughts you may have had about the details of how you see this working that would be great. The more detail you put there, the more likely it is that someone who wants to get their hands dirty would be likely to pick it up; unless of course you have plans for doing it yourself. As an aside, it's always interesting to know the background to why a particular feature is important to someone, so if you felt like commenting on your scenarios that would benefit from this too, whether in the JIRA on or the list, that would be great. For my part here are the things that I'd like to see done ... - reorganisation of the build to create release distributions in line with the SCA release format - review and improvement of the samples and implementation of an alternative simple approach to running the samples that does not involve running a maven build - review and improvement of the website documentation In addition, some things I'd like to see being done, but I don't see as absolute prerequisites for a release are ... - creation of a further sdo sub-project that permits automated exercising of the sdo plugin and java generator - more test cases In terms of JIRA's, we currently have 3 marked for the specific release [1], rather then the generic Java-SDO-Next bucket [2] that is the placeholder for Jiras not assigned to a release. TUSCANY-1317 http://issues.apache.org/jira/browse/TUSCANY-1317, TUSCANY-1143 http://issues.apache.org/jira/browse/TUSCANY-1143 , TUSCANY-513 http://issues.apache.org/jira/browse/TUSCANY-513 The first is there because the originator marked it for the beta1, which it didn't make, but it looks well defined, so after the beta1 I changed the fix release to the 1.0 release, but I don't think I'll have the bandwidth to cover this. The second is there because I want it to be, and plan to tackle it. The third is there because the originator has provided a patch and I'm in the process of committing it. In the light of my priorities above, having taken a scan through [2] in addition to 1143, I plan to look at ... TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2 TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars TUSCANY-257recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 and there are a few others I have my eye on, e.g. 303, if all the above goes well. Regards, Kelvin. [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210status=1status=3status=4component=12311542component=12310660component=12310973component=12310802fixfor=12312521sorter/field=issuekeysorter/order=DESC [2] http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210status=1status=3status=4component=12310660component=12310973component=12310802fixfor=12312262sorter/field=issuekeysorter/order=DESC On 09/06/07, Steffen Glomb [EMAIL PROTECTED] wrote: i would like to see support for typesafe collections in the xsd2java generator. regards Steffen On 6/8/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd like to draw the communities attention to this issue again please. Thanks to David for responding with his requirements and with the fix for 1223. I have some thoughts that I'm structuring at the moment on what's important for a next release from my perspective that I'll post soon, but in general I'm just keen to get the good stuff that we have added recently out in a release that, as I said before from my perspective, warrants the title of 1.0. With the Summer holiday season coming up, I'd like to do this soon so that I can sun myself on a beach without that niggling feeling of things that
Problems with callback using WS Binding
I am trying to use callbacks with the WS Binding and receive a NPE during
composite activation. It looks like the issue is that the resolve() method
in the WebServiceBindingProcessor is not setting up a callbackInterface on
the InterfaceContract. The following snippet shows how the callInterface is
being set but there is no such code to set the callbackInterface?
PortType portType = getPortType(model);
*if* (portType != *null*) {WSDLInterfaceContract interfaceContract =
wsdlFactory.createWSDLInterfaceContract();
WSDLInterface wsdlInterface;
*try* {
wsdlInterface = introspector.introspect(portType,
wsdlDefinition.getInlinedSchemas(),
resolver);
} *catch* (InvalidInterfaceException e) {
*throw* *new* ContributionResolveException(e);
}
interfaceContract.setInterface(wsdlInterface);
model.setBindingInterfaceContract(interfaceContract);
}
Caused by: java.lang.NullPointerException
at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(
InterfaceContractMapperImpl.java:246)
at org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(
CompositeActivatorImpl.java:337)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires
(CompositeActivatorImpl.java:269)
at org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(
CompositeActivatorImpl.java:580)
at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addComposite
(EmbeddedSCADomain.java:124)
[jira] Created: (TUSCANY-1338) Add support for simple distributed runtimes to trunk
Add support for simple distributed runtimes to trunk Key: TUSCANY-1338 URL: https://issues.apache.org/jira/browse/TUSCANY-1338 Project: Tuscany Issue Type: New Feature Affects Versions: Java-SCA-Next Reporter: Simon Laws Move the sample distributed runtime support from my sandbox into truck and reorganize -- 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]
Distributed runtimes and topology
I've starting to move and reorganize some of the distributed runtime ideas from my sandbox into the trunk. So far there is not much there modules/ topology - and empty module for topology model things samples/ calculator-distributed - the current motivating use case. There have been several threads around this recently covering topology, base uris and distribution, for example. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18613.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18644.html I've be updating the page ( http://cwiki.apache.org/confluence/display/TUSCANY/Distributed+Runtime) to try and capture some of the thinking. Over the next few days I'm going to try and get the basic SCADomain topology meta data reading up and running in head. I welcome any comments or help in this area. Regards Simon
Re: SCA Binding and Disitribution was: Distributed Composites
On 6/7/07, Simon Laws [EMAIL PROTECTED] wrote: Interesting. Taking a step back I think we should agree what we are trying to represent in a model of the topology before we decide where the information comes from and the exact syntax of the configuration files. So from the previous two suggestions... When a runtime is started up we need the runtime info i.e. runtimeA: hostname ip binding.ws: scheme http://localhost:8080/acbd scheme https://localhost:442/abcd binding.sca: scheme http://localhost:1234 binding.jsonrpc: scheme http://localhost:8085/jsonxyz Does there really need to be separate schemes for each binding type (I've probably just missed this in all the many emails about this)? Section 1.7.2.1 in the Assembly spec talks about a Base System URI for a scheme, eg a base URI for http and another for https, and that covers most requirements doesn't it? ...ant
Re: An observation about the current Contribution handling code
[snip] Simon Laws wrote: Alongside the separation of loading and resolution there is a more simplistic point here I think about the current implementation to do with how a composite location is specified. As users of SCADomain I think Mike and I fell into the trap of believing that SCADomain.newInstance(my.composite) would load and resolve my.composite. When actually it means that the runtime will look for where my.composite is in the file system and load everything there. How many files are loaded and when is an internal implementation detail, newInstance(my.composite) means boot an SCA domain and include the my.composite deployable composite in that domain; my.composite is assumed to be in an SCA contribution, you can pass the location URL of the contribution or let the runtime determine it automatically if its root is on the current classloader's classpath. Luciano has explained this in detail previously in this thread (thanks Lucinao for taking the time to lay it out for us) and so is not a suprise now. In the case where contributions are coming from the file system how do you specify a specific contribution root when you only have relative paths to play with? For example, if I had somedir mydir1/ my.composite mydir2/ myother.composite Where somedir is added to the classpath. How do I configure the runtime to load only the contribution starting at the mydir1 directory? SCADomain.newInstance(my.composite) - won't find it as my.composite is not directly on the classpath SCASCADomain.newInstance(mydir1/my.composite) - will find it but deduces that the root contribution dir is still somedir SCASCADomain.newInstance(http://localhost;, file:///c:/some/abolsute/path/somedir/mydir1/, my.composite) - may find it (haven't tried) but contains absolute path information Should I be relying on jar packaging or completely independent folder structures with no common root on the classpath? Or is there a sneaky way to configure the location URL to make this work? Can you try SCADomain.newInstance(http://whatever/uri;, mydir1, my.composite)? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lazy loading and resolution of SCA composites, was: An observation about the current Contribution handling code
Simon Laws wrote: Sebastien, it looks like a good start on the lazy loading to me. On the disitributed runtime scenario point. I'd like to start putting the distributed runtime bits I have so far into head so I would like to work with you in making a start on the notion of a domain/runtime configured through incremental changes. This could, in future, facilitate an event driven runtime management function for the operations you mention. I think the first thing we could do is build an extension of the domain implementation which supports the notion of the domain composite deployed into the local runtime and make the exercise of building the domain composite an exercise in adding those artifacts for which the runtime is responsible. At the moment what I have is the domain composite being created after which the bits that the runtime is not responsible for are chopped out. Simon +1 for doing all this work in trunk This new SCA domain implementation will need to know which component runs on which runtime, so I'll start adding some model interfaces to represent that mapping and a description of the topology to the topology module you created. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An observation about the current Contribution handling code
I did try SCADomain.newInstance(http://whatever/uri;, mydir1, my.composite) and it didn't work for me. The code only seems to take any notice of location if it's and absolute URL (which the above location is not) so I would expect SCASCADomain.newInstance(http://localhost;, file:///c:/some/abolsute/path/somedir/mydir1/, my.composite) to work as I said in my previous mail. However I didn't want to specify an absolute URL as I said. So I expect I'm missing something extremely obvious here as Luciano suggested that I use this signature also (which I have tried) but he didn't give me any clues as to how I might go about it. Now the answer to all of this may be that I'm not supposed to be trying to do this. But as per the rest of the thread it's a testing convenience to be able to specify the location of a file system based contribution relatively. The lazy loading work may be a viable alternative. Simon
Re: 0.91 release?
+1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lazy loading and resolution of SCA composites, was: An observation about the current Contribution handling code
OK cool - I'm not going to do any more here today but if you do more I'll pick it up in the morning. Simon
Re: SCA Binding and Disitribution was: Distributed Composites
Looking back at this I think you are right that the specs that that a Domain will have a base URI per scheme. We may have been a bit over zelous with the base URIs in there association with bindings. I'm just wondering why we assumed it was defined on a binding basis. I imagine separate base uris could be used as a convenient diambiguation technique for bindings sharing a protocol. But it seems that the Service Binding URI is intended for this. Simon
Spring Implementation - ready for primetime....
Folks, I think that the Spring Implementation is now in reasonable shape and is capable of being added to the main trunk build. The basic function is there, supporting Services, References and Properties. Advanced stuff like scoped behaviour of components will need extra work. More test cases would be a good idea too. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring Implementation - ready for primetime....
Mike Edwards wrote: Folks, I think that the Spring Implementation is now in reasonable shape and is capable of being added to the main trunk build. The basic function is there, supporting Services, References and Properties. Advanced stuff like scoped behaviour of components will need extra work. More test cases would be a good idea too. Yours, Mike. Done under revision r546645. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1297) xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope
[ https://issues.apache.org/jira/browse/TUSCANY-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504044 ] Pete Robbins commented on TUSCANY-1297: --- I have fixed the element ordering problem. The writing of xsi:type is actually valid but unnecessary. I will look at another fix o try and prevent these being written xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope -- Key: TUSCANY-1297 URL: https://issues.apache.org/jira/browse/TUSCANY-1297 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-Next Environment: any Reporter: Matthew Peters Fix For: Cpp-Next We use SDO to build and generate WSDL. We use the standard WSDL and SOAP schemas (schemata?) to build the model then add port, operation, binding etc. elements, then serialise the lot to XML. There are occasional xsi:type attributes in the serialised XML which cause the WSDL not to validate or load in visual studio. Here is a snippet from WSDL that we have generated in this way: binding name=Labnet_API_LabnetOnline_001_ImplementationBinding type=tns2:Labnet_API_LabnetOnline_001_ImplementationPortType operation name=getRestorations input tns3:body xsi:type=tns3:tBody use=literal/ /input output tns3:body xsi:type=tns3:tBody use=literal/ /output tns3:operation xsi:type=tns3:tOperation soapAction=/ /operation tns3:binding xsi:type=tns3:tBinding transport=http://schemas.xmlsoap.org/soap/http; style=document/ /binding These xsi:type attributes cause this WSDL to fail to load. I quote one of our users: MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will not import a SCA generated WSDL. It complains that it does not validate because of the following element attributes: xsi:type=tns3:tBody of tns3:body xsi:type=tns3:tAddress of tns3:address Stripping out these attributes resolved the VS WSDL import problem. and a different bug report but the same problem: WSDL generated does not validate (ran against the oXygen editor and Mindreef SOAPscope). -- 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]
Error building distribution, was: Automated nightly builds
Venkata Krishnan wrote:
+1 from me - sounds very useful especially if distributions are going
to be
available.
- Venkat
On 6/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Luciano Resende wrote:
Wouldn't that fail if you start from a clean repo ? It expects the
other modules to be built or available as deployed snapshots no ?
On 6/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
[snip]
Luciano Resende wrote:
I'm looking for a distribution that I could use directly, as the
individual JARs are not so useful. Is there a way to get the
distribution built as part of the automated build?
For DAS, I have a distribution profile that generate javadoc,
distributions, etc
Maybe we could do same for SCA (and SDO) , and I could use this
profile on the automated builds.
Thougths ?
or maybe even simpler than a profile, is it possible to just add the
distribution Maven module to the confluence build config?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I was thinking about building adding the distribution build after the
sca build in the same confluence build config, but it doesn't look like
it's possible, so I guess a build profile, as you suggested is the best
solution.
Another thought, how about adding a link to the nightly builds to the
Tuscany SCA Java download page? What do people think?
--
Jean-Sebastien
Under revision r546709 I added a distribution profile to
tuscany/java/sca including the distribution module, but I'm running into
a weird Maven error.
I am able to build the distribution module alone.
cd tuscany/java/sca/distribution
mvn
... works.
But
cd tuscany/java/sca
mvn -Pdistribution
... gives the the following error when it reaches the distribution
build, after having successfully built all the other SCA modules:
[INFO]
[INFO] Building Apache Tuscany Distribution
[INFO]task-segment: [install]
[INFO]
[INFO] [ant:ant {execution: generate-sources}]
Wrote Ant project for tuscany-distribution to
/home/delfinoj/Tuscany/apache-repos/java/sca/distribution
[INFO] [antrun:run {execution: process-sources-xsl}]
[INFO] Executing tasks
[xslt] DEPRECATED - xalan processor is deprecated. Use trax instead.
[xslt] DEPRECATED - xslp processor is deprecated. Use trax instead.
java.lang.ClassNotFoundException:
org.apache.tools.ant.taskdefs.optional.XslpLiaison
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
at
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at
org.apache.tools.ant.taskdefs.XSLTProcess.loadClass(XSLTProcess.java:419)
at
org.apache.tools.ant.taskdefs.XSLTProcess.resolveProcessor(XSLTProcess.java:397)
at
org.apache.tools.ant.taskdefs.XSLTProcess.getLiaison(XSLTProcess.java:619)
at
org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:212)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
Re: SCA Binding and Disitribution was: Distributed Composites
Simon Laws wrote: Looking back at this I think you are right that the specs that that a Domain will have a base URI per scheme. We may have been a bit over zelous with the base URIs in there association with bindings. I'm just wondering why we assumed it was defined on a binding basis. I imagine separate base uris could be used as a convenient diambiguation technique for bindings sharing a protocol. But it seems that the Service Binding URI is intended for this. Simon Simon, Did you change your email settings recently? I've noticed that your emails do not include any of the original email anymore, making it more difficult to follow the discussion. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fixed alert-aggregator/pom.xml, was: svn commit: r546141
Jean-Sebastien Delfino wrote: The alert aggregator demo module was not compiling. I fixed it by changing a dependency scope from runtime to compile in pom.xml under revision r546698. Also removed some tabs in pom.xml and fixed the svn:ignore properties under the root of the module and src/main/webapp. One more change: Other demos name their artifact id demo-*. If there's no objection I'll change the artifact id from alert-aggregator to demo-alert-aggregator. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
