Re: DAS C++ Status
DAS is no longer needing the config.xsd to read xml configuration files since revision 544749. Adriano Crestani On 5/30/07, Adriano Crestani [EMAIL PROTECTED] wrote: Since revision 542742, DAS C++ is only working with SDO on trunk, and not with SDO C++ M3. Adriano Crestani On 5/29/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added support to one to many relationship under revision 542742 Adriano Crestani On 5/28/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added support to set up the framework via config xml under revision 542124. Adriano Crestani On 5/22/07, haleh mahbod [EMAIL PROTECTED] wrote: Thank you for the explanation. On 5/21/07, Adriano Crestani [EMAIL PROTECTED] wrote: Yes, it's intergrated with Tuscany SDO C++. Next step is to implement a sample for it. I intend to add some info on wiki before the first release. Regards, Adriano Crestani On 5/21/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Adriano, Is this integrated with SDO C++? Is there a sample for it? Can more information be added to the home page and user guide[1]? [1] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=46512 Haleh On 5/20/07, Adriano Crestani [EMAIL PROTECTED] wrote: Actually is being developed the Tuscany DAS C++. So far, the framework can perform the following: - Convetion Over Configuration(COC): - DAS assumes that a column named xxx_id is a FK to the column named id on table xxx. - If no PK column is found on the ResultSet, it sets the column named id as PK, if exists. - The COCs defined above are, actually, case sensitive and, for example, a column named ID will not be set as PK - The das is using the ResultSet metadata(column name, column data type and column table) to generate the sdo graph and popule it. The DAS guarantees the table object uniqueness on graph basing on the table PK, so the first table retrieved by the ResultSet will be taken, and any other table containing the same PK ignored: - A table may contain a simple PK or a composite one. - If no PK is defined for the table, the DAS tries to find one using COC. - If the table has a composite PK and not all the columns that compound the PK are contained on the ResultSet, the DAS ignores the defined composite PK and tries to find another PK using COC as defined above. - If no PK is found using COC, the DAS sets all columns on ResultSet as PK. - Setting the references on graph objects basing on table relationships. - Actually, there may be up to 1 relationship between 2 tables. - The columns data that compound the FK are not created on the graph. - The DAS accepts simple or composite relationships. - If not all the columns, PK or FK, that compound the relationship are on the ResultSet, the relationship is ignored and the remaining FK are loaded onto graph. - Actually, the DAS config can only be set from code. - There are also implemented some testcases. - DAS is only supporting the following SQL types: INTEGER, REAL, CHAR, VARCHAR, FLOAT, DOUBLE. Next steps: - Read the config from a xml file. - To implement a sample that reads some data from a database and print on console. - Implement support for more SQL types. Comments and suggestions will be appreciated : ) Any volunteer would be helpful ; ) Regards, Adriano Crestani
[jira] Updated: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly
[ https://issues.apache.org/jira/browse/TUSCANY-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1325: Patch Info: [Patch Available] Property value with xsd:QName type is not deserialized and serialized correctly --- Key: TUSCANY-1325 URL: https://issues.apache.org/jira/browse/TUSCANY-1325 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Attachments: 1325.patch, XSDQNameTestCase.java, XSDQNameTestCase.java Current SDO implementation doesn't convert property value with xsd:QName type at all. The value is treated as a plain string without any conversion. The conversion should take place based on SDO 2.1 spec section 9.4.1. -- 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: Website - Consistent navigation menus
I would be disappointed to lose the ability to contribute directly to the Web site pages. When the move to a wiki-based approach was first discussed, one of the benefits was that it would not be necessary to limit updates to committers as was the case with the previous web site. Would it be possible to have some level of access control for edits that is somewhat broader than the list of code committers, but not opened up to everyone in the world? Regarding Ant's comment, I think the alternative proposed wording currently in the page is good...Since the wiki content forms the backbone for the public website content, its structure is documented here to help keep it maintainable. Simon Hernan Cunico wrote: You will have to restrict edit to just committers if you want to make this Confluence space your official web site. I strongly recommend you folks discuss this with Infra@ as you will also need Confluence admin auth to control your own user groups. Cheers! Hernan ant elder wrote: I don't like this bit: Since the Wiki content forms the backbone for the public website content, it is important that the community adheres to some community accepted common guidelines when authoring content on the Wiki, to help in consistency and maintainability of the content. If we're worried about what happens on the website we should just restrict access so only committers can update it, then, just as with the code, we work CTR. The website is looking good now, much better than before, but IMHO that doesn't mean its perfect or that we should try to restrict or control any future changes to it. ...ant On 6/5/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I've added more to this guidelines page. Please take a look and see if it all makes sense. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build break, was: svn commit: r544528 - in /incubator/tuscany/java/sca: modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ samples/helloworld-ws-reference/src/main/java/hellow
+1 for reverting implementation-crud back to the official SPIs and adding another sample for the simplified extension layer. Simon Jean-Sebastien Delfino wrote: Ant, This commit introduced breaking changes to the helloworld-ws-reference and helloworld-ws-service samples, using some kind of binding.console. Probably an oversight :) More important, I think we should revert to the official Tuscany SPIs in the implementation-crud sample, as it is our main sample to show people how to develop extensions using these SPIs. I'll be happy to have another new sample showing how to use the new simplified extension layer, as I think that this new layer will be very useful. This will avoid confusion, and will also allow people to compare and choose between the two layers and ways to develop extensions. Thanks... [EMAIL PROTECTED] wrote: Author: antelder Date: Tue Jun 5 09:00:23 2007 New Revision: 544528 URL: http://svn.apache.org/viewvc?view=revrev=544528 Log: Change implementation-crud sample to use extension-helper instead of core spi (hoping that may prompt some review comments on if the extension-helper needs changes) (cut) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website - Consistent navigation menus
The rules, as documented [1], don't restrict editorship of a wiki used as a project website to just committers but ask that only those who have a signed CLA on file be allowed to edit the pages destined for the project website. It doesn't say we can't restrict it to just committers of course. I think we should allow this wider level of access. I have added the asf-cla group into our space permission list and given it the same rights as committers (apart from admin rights). I admit that I don't know though how/when people are added to asf-cla but assume that it is done when a CLA is received. I believe that in keeping with [1] we do need to turn off create rights for confluence-users whichever way we go. If people agree to this I (or any other committer for that matter) can make the change. We also had a discussion previously about creating a new space which is not used for the web site and supports more ad-hoc editing of content. Is there still and appetite for this? If so we should request one now as we turn off general edit rights. Regards Simon [1] http://cwiki.apache.org/confluence/display/CWIKI/Index
Re: Website - Consistent navigation menus
Everybody knows what to expect from a wiki (due to wikis very nature) and what to expect from an official website. AFAIK, if a content is not developed and/or entirely controlled by the committers then it can not be called official. There have been endless discussions on this topic on infra@ Making it official means the backing not just from the project but from Apache Software Foundation; that means it's an official Apache site. Last time I checked, websites should be served from mino and confluence based wikis from brutus and whenever possible access the autoexported HTML content instead of native confluence. As I said before, pls check with infra because some of these things may have changed. The problem with Confluence is that it is so cool to use and you can do so much than sometimes you forget it's main purpose, to be a wiki. For Geronimo we have multiple spaces, most of them are aligned with the wiki philosophy and we use them for documentation. Then we have a private (view restricted) space for TCK and one for the website where only Geronimo committers have edit access. So, we have a website and a separate wiki. Hope this clarifies the things a bit. Check with infra for the latest guidelines. Cheers! Hernan Simon Nash wrote: I would be disappointed to lose the ability to contribute directly to the Web site pages. When the move to a wiki-based approach was first discussed, one of the benefits was that it would not be necessary to limit updates to committers as was the case with the previous web site. Would it be possible to have some level of access control for edits that is somewhat broader than the list of code committers, but not opened up to everyone in the world? Regarding Ant's comment, I think the alternative proposed wording currently in the page is good...Since the wiki content forms the backbone for the public website content, its structure is documented here to help keep it maintainable. Simon Hernan Cunico wrote: You will have to restrict edit to just committers if you want to make this Confluence space your official web site. I strongly recommend you folks discuss this with Infra@ as you will also need Confluence admin auth to control your own user groups. Cheers! Hernan ant elder wrote: I don't like this bit: Since the Wiki content forms the backbone for the public website content, it is important that the community adheres to some community accepted common guidelines when authoring content on the Wiki, to help in consistency and maintainability of the content. If we're worried about what happens on the website we should just restrict access so only committers can update it, then, just as with the code, we work CTR. The website is looking good now, much better than before, but IMHO that doesn't mean its perfect or that we should try to restrict or control any future changes to it. ...ant On 6/5/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I've added more to this guidelines page. Please take a look and see if it all makes sense. Thanks. - Venkat - 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: Servlet path change?
Thanks for the pointers/info. I assume the intention is to add in the ability to specify the binding specific base system uri on a binding by binding bases (as well as implementing all the other rules of course). I don't see this configuration in the code now. sca domain sca runtime runtime.a.name runtime.a.address binding.a config Scheme.a baseURI=HTTP://runtime.a.address:80/ Scheme.a baseURI=HTTPS://runtime.a.address:442/ I'm interested in this bit particularly as this is where it touches the distributed runtime. Simon
Re: Website - Consistent navigation menus
+1, it would be unfortunate to have the home paged covered in unsavory links by some spammer just as 0.90 has been announced. ...ant On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon
Re: Do we want the simpler spi? was: svn commit: r544528 - in /incubator/tuscany/java/sca: modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/impl/ samples/helloworld-ws-reference/src/m
ant elder wrote: I'm not sure i agree about the sample, wont it be even more confusing having it use the old way? Maybe if there was something the sample was doing that required the complex SPI but while there isn't wont it just seem odd to do it an unnecessarily complicated way. Do we even want this simpler SPI? If we do i think we should use it, if we don't we should scrap it now, which I'm fine with doing. Maybe it would be better to just move some of the simplifications to the existing SPI? ...ant I'm still on the path that we were discussing earlier in [1], and I thought we were pursuing: - a simplified extension SPI layer, for simplified bindings and implementations that don't need the power of the complete/advanced SPI - on top of the more advanced SPI, not replacing or altering it - clearly identified in separate packages I don't think that having 2 samples for the 2 separate SPI layers is confusing. We just released a 0.90 release with stable SPIs that we want people to use, we should continue to have a sample illustrating how to use these SPIs. If implementation-crud does not make good use of some of the interesting SPI methods (like some of the start/stop methods) we should just improve the sample and add a few print statements for example indicating what could be done in these methods... And we can have a different sample showing how you can use the simplified extension SPI layer for a simpler implementation extension. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website - Consistent navigation menus
I think it was Ted Husted who created your space first, you could start there. Either way, you need to send the request to infra@ and open a JIRA with the request so those folks can keep track Cheers! Hernan Simon Laws wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet path change?
On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Thanks for the pointers/info. I assume the intention is to add in the ability to specify the binding specific base system uri on a binding by binding bases (as well as implementing all the other rules of course). I don't see this configuration in the code now. sca domain sca runtime runtime.a.name runtime.a.address binding.a config Scheme.a baseURI=HTTP://runtime.a.address:80/ Scheme.a baseURI=HTTPS://runtime.a.address:442/ I'm interested in this bit particularly as this is where it touches the distributed runtime. Go for it, I've not yet been able to work out how that should properly be done. Right now there's a hard coded BASE_URI used in Axis2ServiceBindingProvider. The host name is ignored but the port is used when using the Tuscany Jetty or Tomcat host (though i think maybe the port is actually only used for the 1st service registered which is a bug), but the whole thing is ignored for webapps. In Axis2ServiceBindingProvider there's also a method computeActualURI which works out a URI based on section 1.7.2 of the Assembly spec. Most of that is not WS specific and its what we need to do for all bindings using hierarchical URI schemes so it would be nice to generalize it for use by all those bindings - Axis, json-rpc, rmi etc. And so all the info is here, there's also a problem in computeActualURI related TUSCANY-1291 and this thread: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/[EMAIL PROTECTED] ...ant
Re: SCA Binding and Disitribution was: Distributed Composites
[snip] Simon Laws wrote: Ok, I've taken the next step here and have a distributed runtime example running in my sandbox. A sample calculator application [1] showing the disitributed runtime in action and a module containing the changes I had to make to the runtime to get this to work [2]. The changes are actually trivial but getting them in the appropriate place was a bit of a challenge. Looking at the sample first I have, for the purposes of this example, chosen to extend the SCDL model with extra attributes to indicate which runtime a component will run in. component name=CalculatorServiceComponent runtimeId=sca://mydomain/A This information could have been conveyed in many other ways so alternative suggestions are welcome. This is a pretty nice starting point. I would suggest to try to separate the topology description information from the logical SCA domain composition: - what runtimes are available - for each runtime: - the (logical) addresses at which it can be reached for each SCA binding type - the components allocated to that runtime Here are two suggestions for doing this: A topology.config file, something like that: runtimeA: binding.ws: http://localhost:8080/acbd binding.sca: http://localhost:1234 binding.jsonrpc: http://localhost:8085/jsonxyz components: CalculatorServiceComponent, AddServiceComponent runtimeB: binding.ws: http:myotherhost:6060/tuvw binding.sca: http://myotherhost:5678 components: MultiplyServiceComponent, SubtractServiceComponent, DivideServiceComponent or a topology.xml file, where we would actually describe the SCA runtimes, their configuration and how they are assembled on a network using an SCA assembly: topology.xml composite component name=runtimeA service binding.ws uri=http://localhost:8080/acbd/ binding.jsonrpc uri=http://localhost:8085/jsonxyz/ binding.sca uri=http://localhost:1234/ /service implementation.container component name=CalculatorServiceComponent/ component name=AddServiceComponent/ /implementation.container /component component name=runtimeB service binding.ws uri=http://myotherhost:6060/tuvw/ binding.sca uri=http://myotherhost:5678/ /service implementation.container component name=MultiplyServiceComponent/ component name=SubtractServiceComponent/ component name=DivideServiceComponent/ /implementation.container /component /composite What I find interesting with that second form - apart from the fact that the user won't have to learn another configuration language if he already knows SCA - is that we could use the binding.* configurations in that topology file to host default configuration for the bindings described in the SCA domain. Then the notation that you're proposing with the runtime ID inlined in the SCA domain logical assembly could be supported as well, but as a progressive/shortcut option for want to inline the runtime allocation in their SCA domain composite. However, we would have the capability, in our underlying configuration model and runtime implementation to completely separate the logical SCA domain composition and the topology description, which are really two different dimensions of the configuration of a service network. Thoughts? [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/calculator-distributed/ [2] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/disitributed-changes/ [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18242.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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: Servlet path change?
OK, I need to take a closer look. Assuming we don't hard code the info we can potentially determine the IP info (although that might not even be the case when there are multiple NICs) but we need to get the port selection from somewhere. Is there currently a natural place where this config info lives or are we looking at a new config file or similar. Regards Simon
[jira] Resolved: (TUSCANY-1325) Property value with xsd:QName type is not deserialized and serialized correctly
[ https://issues.apache.org/jira/browse/TUSCANY-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1325. - Resolution: Fixed Fixed at revision 544858 Property value with xsd:QName type is not deserialized and serialized correctly --- Key: TUSCANY-1325 URL: https://issues.apache.org/jira/browse/TUSCANY-1325 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Attachments: 1325.patch, XSDQNameTestCase.java, XSDQNameTestCase.java Current SDO implementation doesn't convert property value with xsd:QName type at all. The value is treated as a plain string without any conversion. The conversion should take place based on SDO 2.1 spec section 9.4.1. -- 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-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
[ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501951 ] Frank Budinsky commented on TUSCANY-1327: - If I remember correctly, types defined in wsdl files cannot be imported or included in anther schema (they are effectively private local types). The XSD spec says that the schemaLocation for an import must have a schema element at the root, which says that it can't be a wsdl file). Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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: Website - Consistent navigation menus
When we do this, we should also be asking for 'administrator' access for a couple of us atleast so that we could give Hernan a break on somethings such as a manual autoexport. Thanks. - Venkat On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon
Re: Website - Consistent navigation menus
With this new approach, how can a non-committer make a change? Will there be a mirror of the web site in the separate space with committer+CLA access where I can do this? Or will I need to create diff patches and attach them to a JIRA? Simon ant elder wrote: +1, it would be unfortunate to have the home paged covered in unsavory links by some spammer just as 0.90 has been announced. ...ant On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Binding and Disitribution was: Distributed Composites
Hi, I like the topology.xml approach. For the topology composite, I suggest that we use a syntax something like the following: composite component name=runtimeA implementation.runtime host=hostname or ip-address mappings binding name=binding.ws scheme name=http baseURI=http://$host:8080/acbd; !-- $host points to the host attr of the implementation.runtime -- scheme name=https baseURI=https://$host:8090/acbd; /binding binding name=binding.jsonrpc scheme name=http baseURI=http://$host:8085/jsonxyz; /binding binding name=binding.sca scheme name=http baseURI=http://$host:1234/ /binding component name=CalculatorServiceComponent/ component name=AddServiceComponent/ /mappings /component ... /composite - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 7:20 AM Subject: Re: SCA Binding and Disitribution was: Distributed Composites [snip] Simon Laws wrote: Ok, I've taken the next step here and have a distributed runtime example running in my sandbox. A sample calculator application [1] showing the disitributed runtime in action and a module containing the changes I had to make to the runtime to get this to work [2]. The changes are actually trivial but getting them in the appropriate place was a bit of a challenge. Looking at the sample first I have, for the purposes of this example, chosen to extend the SCDL model with extra attributes to indicate which runtime a component will run in. component name=CalculatorServiceComponent runtimeId=sca://mydomain/A This information could have been conveyed in many other ways so alternative suggestions are welcome. This is a pretty nice starting point. I would suggest to try to separate the topology description information from the logical SCA domain composition: - what runtimes are available - for each runtime: - the (logical) addresses at which it can be reached for each SCA binding type - the components allocated to that runtime Here are two suggestions for doing this: A topology.config file, something like that: runtimeA: binding.ws: http://localhost:8080/acbd binding.sca: http://localhost:1234 binding.jsonrpc: http://localhost:8085/jsonxyz components: CalculatorServiceComponent, AddServiceComponent runtimeB: binding.ws: http:myotherhost:6060/tuvw binding.sca: http://myotherhost:5678 components: MultiplyServiceComponent, SubtractServiceComponent, DivideServiceComponent or a topology.xml file, where we would actually describe the SCA runtimes, their configuration and how they are assembled on a network using an SCA assembly: topology.xml composite component name=runtimeA service binding.ws uri=http://localhost:8080/acbd/ binding.jsonrpc uri=http://localhost:8085/jsonxyz/ binding.sca uri=http://localhost:1234/ /service implementation.container component name=CalculatorServiceComponent/ component name=AddServiceComponent/ /implementation.container /component component name=runtimeB service binding.ws uri=http://myotherhost:6060/tuvw/ binding.sca uri=http://myotherhost:5678/ /service implementation.container component name=MultiplyServiceComponent/ component name=SubtractServiceComponent/ component name=DivideServiceComponent/ /implementation.container /component /composite What I find interesting with that second form - apart from the fact that the user won't have to learn another configuration language if he already knows SCA - is that we could use the binding.* configurations in that topology file to host default configuration for the bindings described in the SCA domain. Then the notation that you're proposing with the runtime ID inlined in the SCA domain logical assembly could be supported as well, but as a progressive/shortcut option for want to inline the runtime allocation in their SCA domain composite. However, we would have the capability, in our underlying configuration model and runtime implementation to completely separate the logical SCA domain composition and the topology description, which are really two different dimensions of the configuration of a service network. Thoughts? [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/calculator-distributed/ [2] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/disitributed-changes/ [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18242.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website - Consistent navigation menus
Simon, I think that the idea is to split the material between official Website pages and general Wiki pages. The official website pages would be restricted to editing by committers. The rest of the Wiki can be open to editing by all. The simplest way for a non-committer to create something that is intended for the main website is to create the page in the Wiki area and then submit an email to the list with a URL to the page. Any committer can simply copy the page into the Confluence space for the offical website... At least, that's my interpretation ;-) Mike. Simon Nash wrote: With this new approach, how can a non-committer make a change? Will there be a mirror of the web site in the separate space with committer+CLA access where I can do this? Or will I need to create diff patches and attach them to a JIRA? Simon ant elder wrote: +1, it would be unfortunate to have the home paged covered in unsavory links by some spammer just as 0.90 has been announced. ...ant On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon - 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: Website - Consistent navigation menus
diff for patches wont work as the confluence native content (the source) is not on svn. That is unless those patches are for any other static content that is not served directly by confluence but still is being referenced by it, something like the css or some images like logos, templates, etc. I think you need to ask yourself this question, why would I want a everybody to have edit access to my project website? For the wiki this goes well, you want as many people contributing as possible but for the website the situation is totally different. Having just captcha on new accounts sign up wont protect your website from any malicious editing. Cheers! Hernan Simon Nash wrote: With this new approach, how can a non-committer make a change? Will there be a mirror of the web site in the separate space with committer+CLA access where I can do this? Or will I need to create diff patches and attach them to a JIRA? Simon ant elder wrote: +1, it would be unfortunate to have the home paged covered in unsavory links by some spammer just as 0.90 has been announced. ...ant On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon - 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: Servlet path change?
Hi, Ant. I agree with you that we should generalize the service binding URI. I think I have a proposal here. When the CompositeBuidler builds the composite, we should calculate the service binding URI based on various pieces of the information as defined by the spec and save the effective URI in the service binding so that Binding.getURI() will return the good URI. This way, the binding providers doesn't have to deal with the calculation. If you guys think it's the right way to go, I can try to add the function to the CompositeBuilder. This is also related to how a binding is mapped to a protocol (scheme) and baseURI. The topic is being discussed on the ML under SCA Binding and Distribution. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 7:02 AM Subject: Re: Servlet path change? On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Thanks for the pointers/info. I assume the intention is to add in the ability to specify the binding specific base system uri on a binding by binding bases (as well as implementing all the other rules of course). I don't see this configuration in the code now. sca domain sca runtime runtime.a.name runtime.a.address binding.a config Scheme.a baseURI=HTTP://runtime.a.address:80/ Scheme.a baseURI=HTTPS://runtime.a.address:442/ I'm interested in this bit particularly as this is where it touches the distributed runtime. Go for it, I've not yet been able to work out how that should properly be done. Right now there's a hard coded BASE_URI used in Axis2ServiceBindingProvider. The host name is ignored but the port is used when using the Tuscany Jetty or Tomcat host (though i think maybe the port is actually only used for the 1st service registered which is a bug), but the whole thing is ignored for webapps. In Axis2ServiceBindingProvider there's also a method computeActualURI which works out a URI based on section 1.7.2 of the Assembly spec. Most of that is not WS specific and its what we need to do for all bindings using hierarchical URI schemes so it would be nice to generalize it for use by all those bindings - Axis, json-rpc, rmi etc. And so all the info is here, there's also a problem in computeActualURI related TUSCANY-1291 and this thread: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/[EMAIL PROTECTED] ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website - Consistent navigation menus
OK so, I'll raise a JIRA against infrastructure asking for a new space to act as our wiki: Name: Apache Tuscany Wiki Key: TUSCANYWIKI Is everyone happy with this name? Venkat, when you say administrator privileges I assume you mean confluence admin privileges? Wouldn't this be a separate request? If so can you go ahead with this also. Regards Simon
Re: Website - Consistent navigation menus
So, the idea is to have the current wiki as the official Tuscany website, and the new one, would be used as general purpose wiki ? On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: OK so, I'll raise a JIRA against infrastructure asking for a new space to act as our wiki: Name: Apache Tuscany Wiki Key: TUSCANYWIKI Is everyone happy with this name? Venkat, when you say administrator privileges I assume you mean confluence admin privileges? Wouldn't this be a separate request? If so can you go ahead with this also. Regards Simon -- 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: Website - Consistent navigation menus
Yes. Make sense? Simon
Re: Website - Consistent navigation menus
Yes - confluence admin. Ok for now shall I go ahead and raise requests for Admin previleges for me and Luciano ? - Venkat On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: OK so, I'll raise a JIRA against infrastructure asking for a new space to act as our wiki: Name: Apache Tuscany Wiki Key: TUSCANYWIKI Is everyone happy with this name? Venkat, when you say administrator privileges I assume you mean confluence admin privileges? Wouldn't this be a separate request? If so can you go ahead with this also. Regards Simon
Re: Website - Consistent navigation menus
I would suggest you guys use lower case for the space names, at least for the one with the highest hierarchy. Remember the URL is case sensitive and it is based on the space ID. Ideally http://cwiki.apache.org/tuscany should take you to a page consolidating pointers to all the other Tuscany spaces. This would be the tuscany space. Then you could have shorter names to identify project name and space. Long time ago when all the Confluence thingy was just starting we came out with the following convention, AAAxBBB. That is 3 cap letters for identify the project and 2 or more to identify the specific space, all separated by a lower case x. Hence the names used in the Geronimo spaces (http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html) However not all the projects are following this convention so, ultimately, it's up to you guys. The idea is to make your like easier when you get to the point when you need to start spanning to more and more spaces. HTH Cheers! Hernan Simon Laws wrote: OK so, I'll raise a JIRA against infrastructure asking for a new space to act as our wiki: Name: Apache Tuscany Wiki Key: TUSCANYWIKI Is everyone happy with this name? Venkat, when you say administrator privileges I assume you mean confluence admin privileges? Wouldn't this be a separate request? If so can you go ahead with this also. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany wiki strategy, was :Re: Website - Consistent navigation menus
Should we have a discussion around our wiki strategy and make sure we do the right thing? We could use the Geronimo wiki strategy [1] as an example and start point. I think we should consider the following things: - Naming Convention - Access Control List for the wiki spaces - Scope for contents - What goes where.. - What is going to be available on the website space - What is going to be available on the other wiki spaces - Navigation on defined scopes - Maintainability If we come up with a scheme that would have multiple spaces, that is going to be transparent for the end user, we may have couple advantages : - Easy content administration - We could apply the Left Navigation Template, similar to the one used at OSOA.org and then we would maintain sub-space look and feel more consistent without having to use page templates that will be hard to maintain in the future. - Small spaces are easier to maintain and organize - Separate spaces can make it easy to track web traffic to specific sub projects - etc Well, I'm not convinced we need the same amount of spaces Geronimo have, but we might take advantages of having multiple spaces, and I wanted to throw the idea and would like to hear back your thoughts and feedback. Herman, could also share little more about your experience with Confluence in the Geronimo project, and how multiple spaces made life easier for you guys ? [1] http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html On 6/6/07, Hernan Cunico [EMAIL PROTECTED] wrote: I would suggest you guys use lower case for the space names, at least for the one with the highest hierarchy. Remember the URL is case sensitive and it is based on the space ID. Ideally http://cwiki.apache.org/tuscany should take you to a page consolidating pointers to all the other Tuscany spaces. This would be the tuscany space. Then you could have shorter names to identify project name and space. Long time ago when all the Confluence thingy was just starting we came out with the following convention, AAAxBBB. That is 3 cap letters for identify the project and 2 or more to identify the specific space, all separated by a lower case x. Hence the names used in the Geronimo spaces (http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html) However not all the projects are following this convention so, ultimately, it's up to you guys. The idea is to make your like easier when you get to the point when you need to start spanning to more and more spaces. HTH Cheers! Hernan Simon Laws wrote: OK so, I'll raise a JIRA against infrastructure asking for a new space to act as our wiki: Name: Apache Tuscany Wiki Key: TUSCANYWIKI Is everyone happy with this name? Venkat, when you say administrator privileges I assume you mean confluence admin privileges? Wouldn't this be a separate request? If so can you go ahead with this also. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
[ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502022 ] Scott Kurz commented on TUSCANY-1327: - What authority (if any) does the Basic Profile 1.1 have here? BP 1.1 disallows this: http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#WSDL_and_Schema_Import Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Matthew Sykes wrote: I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. I'm trying to understand the problem that you're running into, and I'm not sure why the URI would change. A new self reference created in CompositeBuilderImpl.createSelfReferences actually points to the original bindings of the service that the reference is created for. So as far as I can tell, the URI used by the reference is the same (meaning exactly the same object) as the URI declared on the service's binding. So if the URI changes there's a bigger problem, as it's probably going to break the service itself... Are you actually seeing the URI change? do you have a test case that I could use to debug that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Hi, Let's look at a use case: Assuming we have a deployable composite as follows. composite ... component name=MyComponent service name=MyService binding.ws .../ /service /component /composite When this composite is deployed to the SCA domain, then MyService should be available over the Web Service binding. Let's assume that the deployed URI is http://localhost:8080/MyComponent/MyService. Now it becomes interesting: Is MyService available for SCADomain.getService(MyService.class, MyComponent/MyService)? If so, which binding should be used? If the answer is yes, I think by the SCA spec, only Web Service binding is available to access MyService. Then the service proxy returned from SCADomain.getService(...) will be a self reference with a Web Service binding and the binding URI should be the SAME as the calculated service binding URI, i.e., http://localhost:8080/MyComponent/MyService. (I think the binding URI for the self reference is not correctly filled today and that's why the $self$ comes into the binding providers' faces). The other option is that if the service doesn't have a SCA binding, SCADomain.getService(...) will throw ServiceUnavailableException. Thanks, Raymond - Original Message - From: Matthew Sykes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 12:31 PM Subject: Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - 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: Servlet path change?
[snip] Raymond Feng wrote: Hi, Ant. I agree with you that we should generalize the service binding URI. I think I have a proposal here. When the CompositeBuidler builds the composite, we should calculate the service binding URI based on various pieces of the information as defined by the spec and save the effective URI in the service binding so that Binding.getURI() will return the good URI. This way, the binding providers doesn't have to deal with the calculation. If you guys think it's the right way to go, I can try to add the function to the CompositeBuilder. This is also related to how a binding is mapped to a protocol (scheme) and baseURI. The topic is being discussed on the ML under SCA Binding and Distribution. Thanks, Raymond This initially sounds reasonable to me, but how are you going to handle protocol/binding specific URIs in CompositeBuilder? not all binding URIs start with http://... Would it be possible to let the Binding extension decide what form the URI should take? Maybe we could have have another field on the base Binding named computedURI (computed by CompositeBuilder), which the binding extension could use to compose the value of the actual URI field? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus
You pretty much summarized the advantages of having multiple spaces
From Admin point of view, there are all benefits from having multiple spaces, you have
more control on everything, it is more granular and the maintenance is
lighter-weight.
From the user perspective it is transparent, however they get improved HTML
render speed.
From development perspective it's just matter of getting used to the architecture. Have a good understanding
what goes where and why. You can also have multiple templates for
exporting the spaces (well, still limited to one per space), this give you some additional flexibility. You
could manage all the menus directly at template level so there would not be the need for the {include} on
every single page anymore.
As for planning I would start doing a breakdown planning for the current
content trying to maximize reusability within those spaces; come up with some
grouping criteria. Then work on what would be the relation between those
spaces. You'll also need to outline a hierarchy and naming convention. Separate
wiki content from website content. Define user groups and roles.
Using themes as you pointed out from OSOA.org did not work for us. It
required lot of template customization at Confluence level plus we would still have to
use the AE plugin template to export to HTML. We rather used the later that in addition
supported css and we were more independent from infra to make these changes. Changes made
to the AE plugin template do not affect Confluence.
HTH
Cheers!
Hernan
Luciano Resende wrote:
Should we have a discussion around our wiki strategy and make sure we
do the right thing?
We could use the Geronimo wiki strategy [1] as an example and start point.
I think we should consider the following things:
- Naming Convention
- Access Control List for the wiki spaces
- Scope for contents
- What goes where..
- What is going to be available on the website space
- What is going to be available on the other wiki spaces
- Navigation on defined scopes
- Maintainability
If we come up with a scheme that would have multiple spaces, that is
going to be transparent for the end user, we may have couple
advantages :
- Easy content administration
- We could apply the Left Navigation Template, similar to the
one used at OSOA.org and then we would maintain sub-space look and
feel more consistent without having to use page templates that will be
hard to maintain in the future.
- Small spaces are easier to maintain and organize
- Separate spaces can make it easy to track web traffic to specific
sub projects
- etc
Well, I'm not convinced we need the same amount of spaces Geronimo
have, but we might take advantages of having multiple spaces, and I
wanted to throw the idea and would like to hear back your thoughts and
feedback.
Herman, could also share little more about your experience with
Confluence in the Geronimo project, and how multiple spaces made life
easier for you guys ?
[1]
http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html
On 6/6/07, Hernan Cunico [EMAIL PROTECTED] wrote:
I would suggest you guys use lower case for the space names, at least
for the one with the highest hierarchy. Remember the URL is case
sensitive and it is based on the space ID.
Ideally http://cwiki.apache.org/tuscany should take you to a page
consolidating pointers to all the other Tuscany spaces. This would be
the tuscany space.
Then you could have shorter names to identify project name and space.
Long time ago when all the Confluence thingy was just starting we came
out with the following convention, AAAxBBB. That is 3 cap letters for
identify the project and 2 or more to identify the specific space, all
separated by a lower case x. Hence the names used in the Geronimo
spaces
(http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html)
However not all the projects are following this convention so,
ultimately, it's up to you guys. The idea is to make your like easier
when you get to the point when you need to start spanning to more and
more spaces.
HTH
Cheers!
Hernan
Simon Laws wrote:
OK so,
I'll raise a JIRA against infrastructure asking for a new space to
act as
our wiki:
Name: Apache Tuscany Wiki
Key: TUSCANYWIKI
Is everyone happy with this name?
Venkat, when you say administrator privileges I assume you mean
confluence
admin privileges? Wouldn't this be a separate request? If so can you go
ahead with this also.
Regards
Simon
-
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] Commented: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
[ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502077 ] Fuhwei Lwo commented on TUSCANY-1327: - wsdl:include was introduced in WSDL 1.2 so for now, let's not worry about it. According to WS-I Basic Profile 1.0 WSDL 1.1, the users can use the following to import their schemas. In fact, it's one of the best pratices in the web services industry. Bindings.wsdl --- wsdl:import --- Messages.wsdl --- xsd:import --- Types.xsd Currently, if I did codegen on Bindings.wsdl, nothing happens. If I codegened on Messages.wsdl, it's working fine which will generate codes from namespaces from Messages.wsdl and Types.xsd. I will attach all 3 wsdl/xsd files soon. Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Attachments: Bindings.wsdl, Messages.wsdl, Types.xsd Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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] Updated: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
[ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1327: Attachment: Types.xsd Messages.wsdl Bindings.wsdl Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Attachments: Bindings.wsdl, Messages.wsdl, Types.xsd Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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: Servlet path change?
Hi, Please see my comments inline below. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 1:09 PM Subject: Re: Servlet path change? [snip] Raymond Feng wrote: Hi, Ant. I agree with you that we should generalize the service binding URI. I think I have a proposal here. When the CompositeBuidler builds the composite, we should calculate the service binding URI based on various pieces of the information as defined by the spec and save the effective URI in the service binding so that Binding.getURI() will return the good URI. This way, the binding providers doesn't have to deal with the calculation. If you guys think it's the right way to go, I can try to add the function to the CompositeBuilder. This is also related to how a binding is mapped to a protocol (scheme) and baseURI. The topic is being discussed on the ML under SCA Binding and Distribution. Thanks, Raymond This initially sounds reasonable to me, but how are you going to handle protocol/binding specific URIs in CompositeBuilder? not all binding URIs start with http://... That's where the SCA domain configuration of base URIs for hierarchical URI scheme comes to play. The SCA spec says: An SCA domain should define a base URI for each hierarchical URI scheme on which it intends to provide services. Let's assume we have two bindings: binding.x and binding.y. The scheme (protocol) is ftp for binding.x and http for binding.y. component name=C1 service name=FTPService binding.x .../ /service service name=HTTPService binding.y .../ /service /component If the SCA domain defines the mapping: binding.x -- ftp://ftp.example.com/public binding.y -- http://www.example.com Then the computedURI for binding.x and binding.y would be: binding.x: ftp://ftp.example.com/public/C1/FTPService binding.y http://www.example.com/C1/HTTPService The CompositeBuilder should compute and keep them in the binding. We can add computedURI as you proposed. Would it be possible to let the Binding extension decide what form the URI should take? Maybe we could have have another field on the base Binding named computedURI (computed by CompositeBuilder), which the binding extension could use to compose the value of the actual URI field? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What's an SCA domain base URI? was: Servlet path change?
[snip] That's where the SCA domain configuration of base URIs for hierarchical URI scheme comes to play. The SCA spec says: An SCA domain should define a base URI for each hierarchical URI scheme on which it intends to provide services. Let's assume we have two bindings: binding.x and binding.y. The scheme (protocol) is ftp for binding.x and http for binding.y. component name=C1 service name=FTPService binding.x .../ /service service name=HTTPService binding.y .../ /service /component If the SCA domain defines the mapping: binding.x -- ftp://ftp.example.com/public binding.y -- http://www.example.com Then the computedURI for binding.x and binding.y would be: binding.x: ftp://ftp.example.com/public/C1/FTPService binding.y http://www.example.com/C1/HTTPService I took another look at the spec, and you're correct this is what it says, but now I am not sure I understand anymore how this can really work... Well, maybe I do understand some of it, but I'd like to explore and challenge it a bit here :) I have a simple use case in mind: - my SCA domain includes components running on two servers (an SCA domain is a administrative domain so I'm going to assume that I have at least 2 servers in that domain) - the host names of my two servers are servera and serverb - my components provide web services, over the HTTP protocol - what should my SCA domain URI look like? http:// and then what? just http://? how is this domain URI useful here? Possible answers: - configure my domain URI to www.mydomain.com and have my two servers appear as one... under www.mydomain.com/x and www.mydomain.com/y? - conclude that domain URI is not so useful after all? - another idea? Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1328) can not locate service from a component whose implementation is composite
can not locate service from a component whose implementation is composite
-
Key: TUSCANY-1328
URL: https://issues.apache.org/jira/browse/TUSCANY-1328
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Yang Lei
Fix For: Java-SCA-0.90
default.composite:
composite autowire=false
local=true
name=Iteration3Composite
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
component name=MySimpleServiceInRecursive
implementation.composite
name=foo:MySimpleService/
/component
/composite
MySimpleService.composite:
composite autowire=false
local=true
name=MySimpleService
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
service name=MyServiceOrig1
promote=MyServiceComponentOrig/MyService
interface.java
interface=mysca.test.myservice.MyService/
/service
component name=MyServiceComponentOrig
implementation.java
class=mysca.test.myservice.impl.MyServiceImpl/
/component
/composite
MyServiceImpl
@Service(interfaces={MyService.class, MyServiceByDate.class,
MyListService.class, MyListServiceByYear.class})
public class MyServiceImpl implements MyService, MyServiceByDate,
MyListService, MyListServiceByYear{
...
}
When I try to locateService of MySimpleServiceInRecursive/MyServiceOrig1,
got the following exception
org.osoa.sca.ServiceRuntimeException: Service not found:
MySimpleServiceInRecursive/MyServiceOrig1 at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
at
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke
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: What's an SCA domain base URI? was: Servlet path change?
Hi, I think the base URI for a scheme cannot be global to a SCA domain. As you said, that would be useless. The spec needs some clarifications here. We might have two options here: 1) The SCA domain defines the base URI pattern such as http://$host:8080/. And $host will be replaced by the running server name or address. 2) The baseURI is defined per runtime/server (http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18613.html). Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 1:51 PM Subject: What's an SCA domain base URI? was: Servlet path change? [snip] That's where the SCA domain configuration of base URIs for hierarchical URI scheme comes to play. The SCA spec says: An SCA domain should define a base URI for each hierarchical URI scheme on which it intends to provide services. Let's assume we have two bindings: binding.x and binding.y. The scheme (protocol) is ftp for binding.x and http for binding.y. component name=C1 service name=FTPService binding.x .../ /service service name=HTTPService binding.y .../ /service /component If the SCA domain defines the mapping: binding.x -- ftp://ftp.example.com/public binding.y -- http://www.example.com Then the computedURI for binding.x and binding.y would be: binding.x: ftp://ftp.example.com/public/C1/FTPService binding.y http://www.example.com/C1/HTTPService I took another look at the spec, and you're correct this is what it says, but now I am not sure I understand anymore how this can really work... Well, maybe I do understand some of it, but I'd like to explore and challenge it a bit here :) I have a simple use case in mind: - my SCA domain includes components running on two servers (an SCA domain is a administrative domain so I'm going to assume that I have at least 2 servers in that domain) - the host names of my two servers are servera and serverb - my components provide web services, over the HTTP protocol - what should my SCA domain URI look like? http:// and then what? just http://? how is this domain URI useful here? Possible answers: - configure my domain URI to www.mydomain.com and have my two servers appear as one... under www.mydomain.com/x and www.mydomain.com/y? - conclude that domain URI is not so useful after all? - another idea? Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's an SCA domain base URI? was: Servlet path change?
I also think the assembly spec is a little deficient in this area. I don't think it's description of the Base Domain URI at line 2357 chimes well with the notion that an SCA Domain may be represented across a number of runtime nodes at line 2765. While we might assume from how it stands that there is only one URL for the domain, we can create completely different URLs for each binding/scheme. What I would expect it be saying is that the base URI depends on the potentially distributed nodes that make up the domain. Regardless of DNS settings (which I wouldn't expect people to be forced to fiddle with just to get SCA working) there is nothing stopping people missing out DNS and going straight for IP addresses in the URLs in which case we have to deal with different binding URLs for different nodes. Simon
[jira] Created: (TUSCANY-1329) Contribution metada initializer is using classloader wrongly
Contribution metada initializer is using classloader wrongly Key: TUSCANY-1329 URL: https://issues.apache.org/jira/browse/TUSCANY-1329 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.90 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Patrick identified a problem with the class loader being used to discover the sca-contribution file inside a contribution http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg01059.html We should really just try to simplify this discover and perform two changes to the code - Move the code that initializes the contribution metadata to after the contribution package was scaned - only initialize the contribution if one of the sca-contribution metadata side files are available - While initializing the contribution metadata, ask the package processor to normalize the url for the contribution metadata. -- 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: RMI binding SCDL
Ant, I was trying to add the link to this document from the website and was not sure where you intended to sit? It seems like user doc is the right place for it? On 6/4/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Ant, I was trying to avoid the uri scheme and thought this to be a sure way to keep out errors - getting explicit inputs for each. But then, this just about manages only the defaults for host and port. So, I am open to implementing your suggestion and understand it could be more consistent with the other bindings. Thanks - Venkat On 6/4/07, ant elder [EMAIL PROTECTED] wrote: As I started documenting the RMI binding SCDL at http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.rmi I wondered if it could use a URI format instead of or as well as the separate host, port, and servicename attributes? There may be some reason its doesn't, has it ever been considered? Along the lines of whats described at http://java.sun.com/j2se/1.5.0/docs/guide/jndi/jndi-rmi.html#RMI, so: binding.rmi uri=rmi://localhost:1099/myservice/ and all those could have defaults so you could just have binding.rmi/ on a service and it would make it available using the component and service name as described in 1.7.2 of the assembly spec. ...ant
Re: Servlet path change?
Raymond, if you think CompositeBuilder is the right place to do this then I have to bow to your better judgement. The binding base URLs should be stored in a topology model (as in the SCA Binding and Distribution thread). So if you are going to make this change it would be good to instigate enough of the topology model to to support your change. Happy to help with this as I want to start moving the beginnings of the distributed implementation into the trunck. Regardless of the format this actually arrives in I guess we need at least the following to get your change to work. domain runtime name binding name scheme name baseuri Regards Simon
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Sebastien, I should say that I'm working on a default binding that replaces the Tuscany implementation. The URI isn't changed but new references are created with target URIs that are unknown to the binding implementation on the service side. CompositeBuilderImpl.createSelfReferences creates new references for each service and sets the name to $self$.servicename. Later wireComposite iterates over each of the references and finds the new $self$ references and associates it with the default binding. On paths where SCARuntime.getService is called, createSelfReference eventually follows and the Reference passed back to the caller is one that holds generated uri. As the reference's target URI doesn't point to a service exposed at that URI, invocations through the reference are failing. I can see how I might work around this in the binding but I'm not sure that I should have to. ;) Thanks. Jean-Sebastien Delfino wrote: Matthew Sykes wrote: I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. I'm trying to understand the problem that you're running into, and I'm not sure why the URI would change. A new self reference created in CompositeBuilderImpl.createSelfReferences actually points to the original bindings of the service that the reference is created for. So as far as I can tell, the URI used by the reference is the same (meaning exactly the same object) as the URI declared on the service's binding. So if the URI changes there's a bigger problem, as it's probably going to break the service itself... Are you actually seeing the URI change? do you have a test case that I could use to debug that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet path change?
Hi, I agree with you that the base URIs are from the topology model. What I meant before is that the CompositeBuilder will be aware of the topology model and use it to compute the effective URI for the service bindings. Are we on the same page? Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 3:11 PM Subject: Re: Servlet path change? Raymond, if you think CompositeBuilder is the right place to do this then I have to bow to your better judgement. The binding base URLs should be stored in a topology model (as in the SCA Binding and Distribution thread). So if you are going to make this change it would be good to instigate enough of the topology model to to support your change. Happy to help with this as I want to start moving the beginnings of the distributed implementation into the trunck. Regardless of the format this actually arrives in I guess we need at least the following to get your change to work. domain runtime name binding name scheme name baseuri Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet path change?
Raymond Feng wrote: Hi, I agree with you that the base URIs are from the topology model. What I meant before is that the CompositeBuilder will be aware of the topology model and use it to compute the effective URI for the service bindings. Are we on the same page? Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 3:11 PM Subject: Re: Servlet path change? Raymond, if you think CompositeBuilder is the right place to do this then I have to bow to your better judgement. The binding base URLs should be stored in a topology model (as in the SCA Binding and Distribution thread). So if you are going to make this change it would be good to instigate enough of the topology model to to support your change. Happy to help with this as I want to start moving the beginnings of the distributed implementation into the trunck. Regardless of the format this actually arrives in I guess we need at least the following to get your change to work. domain runtime name binding name scheme name baseuri Regards Simon I'd like to keep this modular and continue to have a clear separation of concerns between assembly, interfaces, databindings, and now... the topology aspects. So I suggest to put the model describing the topology of an SCA domain and the builders/processors/etc that handle it in a new module, separate from the assembly module, which is really specialized in the domain logical composition. In that modular architecture, CompositeBuilder will continue to know only about logical composition, and we can have a new WhateverBuilder in that new topology module to handle the building of the topology model and the determination of the base binding URIs. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet path change?
Good points. +1 to have separate modules handle the physical topology aspect. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 3:46 PM Subject: Re: Servlet path change? Raymond Feng wrote: Hi, I agree with you that the base URIs are from the topology model. What I meant before is that the CompositeBuilder will be aware of the topology model and use it to compute the effective URI for the service bindings. Are we on the same page? Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, June 06, 2007 3:11 PM Subject: Re: Servlet path change? Raymond, if you think CompositeBuilder is the right place to do this then I have to bow to your better judgement. The binding base URLs should be stored in a topology model (as in the SCA Binding and Distribution thread). So if you are going to make this change it would be good to instigate enough of the topology model to to support your change. Happy to help with this as I want to start moving the beginnings of the distributed implementation into the trunck. Regardless of the format this actually arrives in I guess we need at least the following to get your change to work. domain runtime name binding name scheme name baseuri Regards Simon I'd like to keep this modular and continue to have a clear separation of concerns between assembly, interfaces, databindings, and now... the topology aspects. So I suggest to put the model describing the topology of an SCA domain and the builders/processors/etc that handle it in a new module, separate from the assembly module, which is really specialized in the domain logical composition. In that modular architecture, CompositeBuilder will continue to know only about logical composition, and we can have a new WhateverBuilder in that new topology module to handle the building of the topology model and the determination of the base binding URIs. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
Fuhwei, you're right.. the BP's just saying not to use WSDL import to import schemas directly. Sorry for the confusion. Scott On 6/6/07, Fuhwei Lwo (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502077] Fuhwei Lwo commented on TUSCANY-1327: - wsdl:include was introduced in WSDL 1.2 so for now, let's not worry about it. According to WS-I Basic Profile 1.0 WSDL 1.1, the users can use the following to import their schemas. In fact, it's one of the best pratices in the web services industry. Bindings.wsdl --- wsdl:import --- Messages.wsdl --- xsd:import --- Types.xsd Currently, if I did codegen on Bindings.wsdl, nothing happens. If I codegened on Messages.wsdl, it's working fine which will generate codes from namespaces from Messages.wsdl and Types.xsd. I will attach all 3 wsdl/xsd files soon. Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Attachments: Bindings.wsdl, Messages.wsdl, Types.xsd Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- 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-1330) Calculator webapp composite file and sca contribution metadata file are missing targetNamespace attribute
Calculator webapp composite file and sca contribution metadata file are missing targetNamespace attribute - Key: TUSCANY-1330 URL: https://issues.apache.org/jira/browse/TUSCANY-1330 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Bug found by Raymond during review of RC http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18194.html composite element is missing required targetNamespace attribute, for example, the Calculator.composite has the following: composite xmlns=http://www.osoa.org/xmlns/sca/1.0 name=Calculator ... /composite By the SCA spec, the composite should have the targetNamespace attr: attribute name=targetNamespace type=anyURI use=required/ A similar issue applies to sca-contribution.xml: deployable composite=xs:QName/. We need to reference the composite by QName. -- 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: Website - Consistent navigation menus
[snip] haleh mahbod wrote: How about we change the name of the document to 'Tuscany cwiki Website Structure' And remove the paragraphs marked with the pink comments? http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 This document is purely sharing the wiki stucture and explains how to move cwiki to the website. Two more things: - would it be possible to add a link to this doc to the get involved section of our web site? - and add a link to the part of the Tuscany Wiki open to everybody to the web site navigation bar and the get involved section as well? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website - Consistent navigation menus
Jean-Sebastien Delfino wrote: [snip] haleh mahbod wrote: How about we change the name of the document to 'Tuscany cwiki Website Structure' And remove the paragraphs marked with the pink comments? http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 This document is purely sharing the wiki stucture and explains how to move cwiki to the website. Two more things: - would it be possible to add a link to this doc to the get involved section of our web site? - and add a link to the part of the Tuscany Wiki open to everybody to the web site navigation bar and the get involved section as well? Thanks. One more comment, how about making the Source Code link point to a page describing how to check out the Tuscany source code from Subversion and build it? If I remember correctly the was a page describing how to check out the source code before the move to Wiki, but I can't find it anymore. The build steps are described there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/distribution/src/main/release/src/BUILDING so I guess it's just a matter of copying the steps or linking to that document. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Steps to update the Web site, was: Website - Consistent navigation menus
[snip] haleh mahbod wrote: http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 This document is purely sharing the wiki stucture and explains how to move cwiki to the website. According to this doc a change to the Wiki representing the Tuscany Web site is: 1. Exported to Html based on change activity Does that mean exported on each change to a Wiki page? I think this is what I've observed but could you please confirm? If it's the case then I'd suggest to make it more clear in the doc. 2. Copied to the web site using an SVN update every 5, 25, 40 and 55 after the hour? I made a change to the Wiki (added a news entry about the 0.90 release to http://cwiki.apache.org/confluence/display/TUSCANY/Home) at 5:26pm PDT. It is 9:17pm PDT and I can't see my change at http://incubator.apache.org/tuscany/. So I must have missed a step... What do I need to do to get a Wiki change propagated to the Web site? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Steps to update the Web site, was: Website - Consistent navigation menus
Comments inline On 6/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] haleh mahbod wrote: http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 This document is purely sharing the wiki stucture and explains how to move cwiki to the website. According to this doc a change to the Wiki representing the Tuscany Web site is: 1. Exported to Html based on change activity Does that mean exported on each change to a Wiki page? I think this is what I've observed but could you please confirm? If it's the case then I'd suggest to make it more clear in the doc. Yes, it's every page... I'll update the doc. 2. Copied to the web site using an SVN update every 5, 25, 40 and 55 after the hour? I made a change to the Wiki (added a news entry about the 0.90 release to http://cwiki.apache.org/confluence/display/TUSCANY/Home) at 5:26pm PDT. It is 9:17pm PDT and I can't see my change at http://incubator.apache.org/tuscany/. So I must have missed a step... What do I need to do to get a Wiki change propagated to the Web site? You might be having the same issue as described on the following post http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18528.html Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Automated nightly builds
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1316) WriteAllTestCase: java.lang.IllegalStateException: writeNamespace() can only be called following writeStartElement() or writeEmptyElement
[ https://issues.apache.org/jira/browse/TUSCANY-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-1316: --- Assignee: Jean-Sebastien Delfino WriteAllTestCase: java.lang.IllegalStateException: writeNamespace() can only be called following writeStartElement() or writeEmptyElement - Key: TUSCANY-1316 URL: https://issues.apache.org/jira/browse/TUSCANY-1316 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Yang Lei Assignee: Jean-Sebastien Delfino on r540027 java.lang.IllegalStateException: writeNamespace() can only be called following writeStartElement() or writeEmptyElement(). at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwIllegalStateException(StAXMessageProvider.java:45) at com.ibm.xml.xlxp.api.stax.XMLStreamWriterBase.writeNamespace(XMLStreamWriterBase.java:512) at com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl$XMLStreamWriterProxy.writeNamespace(XMLOutputFactoryImpl.java:149) at org.apache.tuscany.sca.assembly.xml.XAttr.writeQNameValue(XAttr.java:98) at org.apache.tuscany.sca.assembly.xml.XAttr.write(XAttr.java:110) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.writeAttributes(BaseArtifactProcessor.java:498) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.writeStart(BaseArtifactProcessor.java:456) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.writeStartDocument(BaseArtifactProcessor.java:476) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.write(CompositeProcessor.java:320) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.write(CompositeProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.write(ExtensibleStAXArtifactProcessor.java:87) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.write(ExtensibleStAXArtifactProcessor.java:163) at org.apache.tuscany.sca.assembly.xml.WriteAllTestCase.testReadWriteComposite(WriteAllTestCase.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) 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.RemoteTestRunner.runTests(RemoteTestRunner.java:481) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:347) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) -- 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] Resolved: (TUSCANY-1318) can not get include Composite's services, components...
[ https://issues.apache.org/jira/browse/TUSCANY-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1318. - Resolution: Invalid This works as designed. SCA composites are processed in multiple phases. 1. load composite files, as part of the loading for each include we create an empty composite placeholder representing a proxy for the included composite, with it's unresolved flag set to true 2. after all composites of a contribution have been loaded, we resolve references to various model objects, like included composites, at this point we'll replace the composite placeholders with the actual loaded composites. 3. normalize composites, as part of this normalization phase we'll clone included composites (in addition to many other things like merging configuration at different composition levels and resolving wires) The ReadAllTestCase test case only tests phase one, so seeing empty composites in the includes list is expected. Other test cases running the 3 phases, for example test cases exercizing the SCADomain, will show populated composites instead of these empty placeholders. can not get include Composite's services, components... --- Key: TUSCANY-1318 URL: https://issues.apache.org/jira/browse/TUSCANY-1318 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Yang Lei Fix For: Java-SCA-Next Add two lines to ReadAllTestCase.testReadComposite() Composite include = composite.getIncludes().get(0); assertEquals(include.getName(), new QName(http://calc;, TestAllDivide)); // the following is the added lines assertEquals(1,include.getComponents().size()); assertEquals(1,include.getServices().size(), 1); And got 0 components and 0 services. Tried to get other attribute on the include as PolicySet and Intents, are are also empty. -- 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: Steps to update the Web site, was: Website - Consistent navigation menus
Luciano Resende wrote: Comments inline On 6/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] haleh mahbod wrote: http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 This document is purely sharing the wiki stucture and explains how to move cwiki to the website. According to this doc a change to the Wiki representing the Tuscany Web site is: 1. Exported to Html based on change activity Does that mean exported on each change to a Wiki page? I think this is what I've observed but could you please confirm? If it's the case then I'd suggest to make it more clear in the doc. Yes, it's every page... I'll update the doc. 2. Copied to the web site using an SVN update every 5, 25, 40 and 55 after the hour? I made a change to the Wiki (added a news entry about the 0.90 release to http://cwiki.apache.org/confluence/display/TUSCANY/Home) at 5:26pm PDT. It is 9:17pm PDT and I can't see my change at http://incubator.apache.org/tuscany/. So I must have missed a step... What do I need to do to get a Wiki change propagated to the Web site? You might be having the same issue as described on the following post http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18528.html How do I manually run an autoexport as suggested in that thread? I looked at all the options I have in the admin category and couldn't find it. If others are likely to run into this, maybe the best answer to my question would be to add these steps to that cwiki structure doc :) Thanks -- Jean-Sebastien -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Steps to update the Web site, was: Website - Consistent navigation menus
Do you have Confluence Admin rights ? We are trying to get couple of people with Admin rights in order to be able to resolve this infra issues. Otherwise we are dependent on the existent confluence admins, and Herman is one of the guys that are helping us. On 6/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Comments inline On 6/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] haleh mahbod wrote: http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=56590 This document is purely sharing the wiki stucture and explains how to move cwiki to the website. According to this doc a change to the Wiki representing the Tuscany Web site is: 1. Exported to Html based on change activity Does that mean exported on each change to a Wiki page? I think this is what I've observed but could you please confirm? If it's the case then I'd suggest to make it more clear in the doc. Yes, it's every page... I'll update the doc. 2. Copied to the web site using an SVN update every 5, 25, 40 and 55 after the hour? I made a change to the Wiki (added a news entry about the 0.90 release to http://cwiki.apache.org/confluence/display/TUSCANY/Home) at 5:26pm PDT. It is 9:17pm PDT and I can't see my change at http://incubator.apache.org/tuscany/. So I must have missed a step... What do I need to do to get a Wiki change propagated to the Web site? You might be having the same issue as described on the following post http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18528.html How do I manually run an autoexport as suggested in that thread? I looked at all the options I have in the admin category and couldn't find it. If others are likely to run into this, maybe the best answer to my question would be to add these steps to that cwiki structure doc :) Thanks -- Jean-Sebastien -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
