Re: Binding endpoints (was Fwd: Services and WSDL files
On 7/26/07, ant elder [EMAIL PROTECTED] wrote: snip Another problem is the runtime base uri is changing for our different environments, for example the standalone Jetty runtime has an empty base uri, where as the sample webapp ones have things like /services/ or other samples /SCA/. That is user configurable in the web.xml, but how about at least in all our samples we change that to be consistent? I've just hit this issue again with the new helloworld sdo webapp sample which has a testcase that uses our Jetty host and the sample creates a deployable war. That results in the WS endpoint being different depending on where its running, i.e. in the webapp case it includes the webapp name in the url but the testcase using the jetty host doesn't include the name. I guess this is related to the discussions on the runtime base URL but could we somehow make that configurable so that from within a testcase its possible to set the base url used by the Jetty host so that its the same as used by the webapp host? ...ant
Re: Binding endpoints (was Fwd: Services and WSDL files
Thats pretty interesting. Though there's so little detail about definitions.xml I find it hard to work out what its for, could any spec people give a be more detail about this? One thing it talks about is using bindingType and implementationType elements to add new extensions, should we really be using these as part of the extension SPI? ...ant On 7/29/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good place to define the domain uri for various schemes for an SCA Domain. - Venkat On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. [snip] Ok I'll get started on that. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? If we're talking about a domain URI, this is typically model information that can be hosted in a Top level Composite or Domain Composite or Domain model object, whatever we want to call it. If I understand the spec correctly, the cardinality is: 1 Domain - 1 base URI per protocol used in the domain. The ExtensionPointRegistry is associated with a Runtime instance, not tied to a Domain. I'll propose a new model object to host that domain-wide configuration. Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is not at the moment and that it is just good architecture practice to separate these clearly distinct parts of the solution. [snip] I guess it should be sufficient to report if we run in Jetty or Tomcat, right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? Right, we have multiple options for HTTP hosts so it's interesting to report which one is used. It looks like we have only one implementation for RMI or JMS at this point. So I was not thinking about spending time reporting which one is used right now... I'll be happy to spend time sorting out which one is used when we get to a point where we have multiple implementations for these. All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Yes, I've bumped into this one several times too... so I'd like to volunteer to fix it. It looks like adding prints is under way too. In addition I'd like to do the following. When Tuscany starts, make a Web Page available with its status, http://localhost:9090 for example, and on that page say Hello Tuscany has started or something like that, plus: 1. display the top level
Re: Binding endpoints (was Fwd: Services and WSDL files
Hi Ant, Working with the policy framework, the definitions.xml is the file that lists all the intents and policysets that are applicable for an SCA Domain. The Policy Fwk specs talks quite a bit about the contents of this file - such as things like the BindingType, ImplementationType etc. As for having these in the SPI, I have started off with some abstractions for these in https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy/src/main/java/org/apache/tuscany/sca/policy as part of the PolicyFramework things which is still work in progress. Once I have some thing substantial we could work on moving some things as SPI. Having looked at definitions.xml before, it just about rung a bell in the context of this discussion. Not sure if the specs folks are going to like this proposition ;-) - Venkat On 7/30/07, ant elder [EMAIL PROTECTED] wrote: Thats pretty interesting. Though there's so little detail about definitions.xml I find it hard to work out what its for, could any spec people give a be more detail about this? One thing it talks about is using bindingType and implementationType elements to add new extensions, should we really be using these as part of the extension SPI? ...ant On 7/29/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good place to define the domain uri for various schemes for an SCA Domain. - Venkat On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. [snip] Ok I'll get started on that. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? If we're talking about a domain URI, this is typically model information that can be hosted in a Top level Composite or Domain Composite or Domain model object, whatever we want to call it. If I understand the spec correctly, the cardinality is: 1 Domain - 1 base URI per protocol used in the domain. The ExtensionPointRegistry is associated with a Runtime instance, not tied to a Domain. I'll propose a new model object to host that domain-wide configuration. Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is not at the moment and that it is just good architecture practice to separate these clearly distinct parts of the solution. [snip] I guess it should be sufficient to report if we run in Jetty or Tomcat, right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? Right, we have multiple options for HTTP hosts so it's interesting to report which one is used. It looks like we have only one implementation for RMI or JMS at this point. So I was not thinking about spending time reporting which one is used right now... I'll be happy to spend time sorting out which one
Re: Binding endpoints (was Fwd: Services and WSDL files
[snip] Simon Laws wrote: If we're talking about a domain URI, this is typically model information that can be hosted in a Top level Composite or Domain Composite or Domain model object, whatever we want to call it. If I understand the spec correctly, the cardinality is: 1 Domain - 1 base URI per protocol used in the domain. The ExtensionPointRegistry is associated with a Runtime instance, not tied to a Domain. I'll propose a new model object to host that domain-wide configuration. Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is not at the moment and that it is just good architecture practice to separate these clearly distinct parts of the solution. One example: an administrator creates / edits / updates domain configuration, without having started any runtime at all :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding endpoints (was Fwd: Services and WSDL files
Hi, Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good place to define the domain uri for various schemes for an SCA Domain. - Venkat On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. [snip] Ok I'll get started on that. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? If we're talking about a domain URI, this is typically model information that can be hosted in a Top level Composite or Domain Composite or Domain model object, whatever we want to call it. If I understand the spec correctly, the cardinality is: 1 Domain - 1 base URI per protocol used in the domain. The ExtensionPointRegistry is associated with a Runtime instance, not tied to a Domain. I'll propose a new model object to host that domain-wide configuration. Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is not at the moment and that it is just good architecture practice to separate these clearly distinct parts of the solution. [snip] I guess it should be sufficient to report if we run in Jetty or Tomcat, right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? Right, we have multiple options for HTTP hosts so it's interesting to report which one is used. It looks like we have only one implementation for RMI or JMS at this point. So I was not thinking about spending time reporting which one is used right now... I'll be happy to spend time sorting out which one is used when we get to a point where we have multiple implementations for these. All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Yes, I've bumped into this one several times too... so I'd like to volunteer to fix it. It looks like adding prints is under way too. In addition I'd like to do the following. When Tuscany starts, make a Web Page available with its status, http://localhost:9090 for example, and on that page say Hello Tuscany has started or something like that, plus: 1. display the top level components started 2. display the services available and their endpoints 3. display the extensions loaded in the runtime I'll probably do 1 and 2 first, leaving 3 for later, depending on how useful people think it is. If there's no objection, I'd like to add this sometime before the end of the week. There's already a start of exactly this distribution/webapp which i'd planned to develop further, would you help? Sure! Where is it? The scenario I'm most interested in is running Tuscany
Re: Binding endpoints (was Fwd: Services and WSDL files
On 7/28/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. [snip] Ok I'll get started on that. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? If we're talking about a domain URI, this is typically model information that can be hosted in a Top level Composite or Domain Composite or Domain model object, whatever we want to call it. If I understand the spec correctly, the cardinality is: 1 Domain - 1 base URI per protocol used in the domain. The ExtensionPointRegistry is associated with a Runtime instance, not tied to a Domain. I'll propose a new model object to host that domain-wide configuration. Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is not at the moment and that it is just good architecture practice to separate these clearly distinct parts of the solution. [snip] I guess it should be sufficient to report if we run in Jetty or Tomcat, right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? Right, we have multiple options for HTTP hosts so it's interesting to report which one is used. It looks like we have only one implementation for RMI or JMS at this point. So I was not thinking about spending time reporting which one is used right now... I'll be happy to spend time sorting out which one is used when we get to a point where we have multiple implementations for these. All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Yes, I've bumped into this one several times too... so I'd like to volunteer to fix it. It looks like adding prints is under way too. In addition I'd like to do the following. When Tuscany starts, make a Web Page available with its status, http://localhost:9090 for example, and on that page say Hello Tuscany has started or something like that, plus: 1. display the top level components started 2. display the services available and their endpoints 3. display the extensions loaded in the runtime I'll probably do 1 and 2 first, leaving 3 for later, depending on how useful people think it is. If there's no objection, I'd like to add this sometime before the end of the week. There's already a start of exactly this distribution/webapp which i'd planned to develop further, would you help? Sure! Where is it? The scenario I'm most interested in is running Tuscany outside of a Web container, so I'd like to see if I can use and add to what you have started in that environment. distribution/webapp/src/main/webapp/scaDomainInfo.jsp -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: Binding endpoints (was Fwd: Services and WSDL files
On 7/26/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: This is becoming one of the most often asked about and (i think) one of the most confusing parts of using Tuscany, so how about we try to fix things up a bit? One problem is its just really hard to see where servlets get registered. These days I often run with a local mod to servlet host that just does a System.out.println of each servlet registration. Maybe I should just commit that for now and we can delete it when we have some logging strategy in place? +1 - I use a registry inspector component that I shove into the SCDL I'm testing but it's more complicated to use that just having the printout in place +1 to print the URIs of the endpoints of the services activated by Tuscany. Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? We should try and catch the case where an absolute URL is specified that doesn't match the result of the URI Calculator. +1 We should report is what extension is hosting each protocol. As we have multiple options in some cases this can be confusing if you have your classpath wrong. I guess it should be sufficient to report if we run in Jetty or Tomcat, right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Yes, I've bumped into this one several times too... so I'd like to volunteer to fix it. It looks like adding prints is under way too. In addition I'd like to do the following. When Tuscany starts, make a Web Page available with its status, http://localhost:9090 for example, and on that page say Hello Tuscany has started or something like that, plus: 1. display the top level components started 2. display the services available and their endpoints 3. display the extensions loaded in the runtime I'll probably do 1 and 2 first, leaving 3 for later, depending on how useful people think it is. If there's no objection, I'd like to add this sometime before the end of the week. There's already a start of exactly this distribution/webapp which i'd planned to develop further, would you help? ...ant
Re: Binding endpoints (was Fwd: Services and WSDL files
On 7/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] ant elder wrote: I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. [snip] Ok I'll get started on that. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? If we're talking about a domain URI, this is typically model information that can be hosted in a Top level Composite or Domain Composite or Domain model object, whatever we want to call it. If I understand the spec correctly, the cardinality is: 1 Domain - 1 base URI per protocol used in the domain. The ExtensionPointRegistry is associated with a Runtime instance, not tied to a Domain. I'll propose a new model object to host that domain-wide configuration. Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is not at the moment and that it is just good architecture practice to separate these clearly distinct parts of the solution. [snip] I guess it should be sufficient to report if we run in Jetty or Tomcat, right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? Right, we have multiple options for HTTP hosts so it's interesting to report which one is used. It looks like we have only one implementation for RMI or JMS at this point. So I was not thinking about spending time reporting which one is used right now... I'll be happy to spend time sorting out which one is used when we get to a point where we have multiple implementations for these. All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Yes, I've bumped into this one several times too... so I'd like to volunteer to fix it. It looks like adding prints is under way too. In addition I'd like to do the following. When Tuscany starts, make a Web Page available with its status, http://localhost:9090 for example, and on that page say Hello Tuscany has started or something like that, plus: 1. display the top level components started 2. display the services available and their endpoints 3. display the extensions loaded in the runtime I'll probably do 1 and 2 first, leaving 3 for later, depending on how useful people think it is. If there's no objection, I'd like to add this sometime before the end of the week. There's already a start of exactly this distribution/webapp which i'd planned to develop further, would you help? Sure! Where is it? The scenario I'm most interested in is running Tuscany outside of a Web container, so I'd like to see if I can use and add to what you have started in that environment. distribution/webapp/src/main/webapp/scaDomainInfo.jsp -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding endpoints (was Fwd: Services and WSDL files
[snip] ant elder wrote: On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: This is becoming one of the most often asked about and (i think) one of the most confusing parts of using Tuscany, so how about we try to fix things up a bit? One problem is its just really hard to see where servlets get registered. These days I often run with a local mod to servlet host that just does a System.out.println of each servlet registration. Maybe I should just commit that for now and we can delete it when we have some logging strategy in place? +1 - I use a registry inspector component that I shove into the SCDL I'm testing but it's more complicated to use that just having the printout in place +1 to print the URIs of the endpoints of the services activated by Tuscany. Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. I'm not quite getting this part... the extension point registry is well... a registry for extension points, an extension point contains extensions (multiple extensions), I can't quite see how a URI calculator utility is an extension point. We should try and catch the case where an absolute URL is specified that doesn't match the result of the URI Calculator. +1 We should report is what extension is hosting each protocol. As we have multiple options in some cases this can be confusing if you have your classpath wrong. I guess it should be sufficient to report if we run in Jetty or Tomcat, right? All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Yes, I've bumped into this one several times too... so I'd like to volunteer to fix it. It looks like adding prints is under way too. In addition I'd like to do the following. When Tuscany starts, make a Web Page available with its status, http://localhost:9090 for example, and on that page say Hello Tuscany has started or something like that, plus: 1. display the top level components started 2. display the services available and their endpoints 3. display the extensions loaded in the runtime I'll probably do 1 and 2 first, leaving 3 for later, depending on how useful people think it is. If there's no objection, I'd like to add this sometime before the end of the week. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding endpoints (was Fwd: Services and WSDL files
Ant, you beat me too it;-) Having spent time yesterday trying to figure out how URLs are handled with the web app host I feel the pain. Some comments inline Simon On 7/26/07, ant elder [EMAIL PROTECTED] wrote: This is becoming one of the most often asked about and (i think) one of the most confusing parts of using Tuscany, so how about we try to fix things up a bit? One problem is its just really hard to see where servlets get registered. These days I often run with a local mod to servlet host that just does a System.out.println of each servlet registration. Maybe I should just commit that for now and we can delete it when we have some logging strategy in place? +1 - I use a registry inspector component that I shove into the SCDL I'm testing but it's more complicated to use that just having the printout in place Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. We should try and catch the case where an absolute URL is specified that doesn't match the result of the URI Calculator. We should report is what extension is hosting each protocol. As we have multiple options in some cases this can be confusing if you have your classpath wrong. Another problem is the runtime base uri is changing for our different environments, for example the standalone Jetty runtime has an empty base uri, where as the sample webapp ones have things like /services/ or other samples /SCA/. That is user configurable in the web.xml, but how about at least in all our samples we change that to be consistent? +1 to sample consistency. Re. the base uri. The least we can do is report which base uris are in operation for each binding/environment. A confusion for me is knowing which of the many pieces of information that can be specified wins. Again if we trap the case where what is specified doesn't match what the runtime calculates the uri should be then that would be a great help. Another kind of related problem is the way we require sca application developers to know the intimate details of the structure of the Tuscany build - you want to use web services you must add a dependency for tuscany-binding-ws-axis2, if using Java components then you need to add tuscany-implementation-java-runtime, etc for all the other things you may want to use. We got the J2SE samples so you don't need to know any of that, i think we could do the same for webapps. For example one way would be like the distribution/webapp module strawman we have. That enables sca applications to require no dependencies at all on any tuscany modules, you just build your application jar using only things related to your application and drop it into the webapp sca-contributions folder and it just works. Would that be a better approach than what we do today for webapps? Not sure yet. What's the mode of operation with the distribution/webapp module? You deploy a distribution/webapp war and then deploy application jars to the sca-contributions folder? ...ant -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Jul 26, 2007 9:59 AM Subject: Re: Services and WSDL files To: [EMAIL PROTECTED] On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi Reymond, Thank you for your reply. How do I run the example if it is deployed to a web server, such as Tomcat? I found an information about TuscanyServlet, which needs to be in web.xml file, which I have now. Let's say that my server's root context and web app context URL is http://localhost:8080/myWebApp . What do I have to add after this URL to be able to access the application? According to SCA spec, the web service WSDL should be available if the URL ends with ?wsdl. But if I type http://localhost:8080/myWebApp/?wsdl in the browser, I get an exception: SEVERE: Servlet.service() for servlet TuscanyServlet threw exception java.lang.IllegalStateException: No servlet registered for path: / at org.apache.tuscany.sca.webapp.TuscanyServlet.service( TuscanyServlet.java:57) at
Re: Binding endpoints (was Fwd: Services and WSDL files
On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: Ant, you beat me too it;-) Having spent time yesterday trying to figure out how URLs are handled with the web app host I feel the pain. Some comments inline Simon On 7/26/07, ant elder [EMAIL PROTECTED] wrote: This is becoming one of the most often asked about and (i think) one of the most confusing parts of using Tuscany, so how about we try to fix things up a bit? One problem is its just really hard to see where servlets get registered. These days I often run with a local mod to servlet host that just does a System.out.println of each servlet registration. Maybe I should just commit that for now and we can delete it when we have some logging strategy in place? +1 - I use a registry inspector component that I shove into the SCDL I'm testing but it's more complicated to use that just having the printout in place Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the URI calculator which could be in the extension registry so that all bindings can get at it. We should try and catch the case where an absolute URL is specified that doesn't match the result of the URI Calculator. We should report is what extension is hosting each protocol. As we have multiple options in some cases this can be confusing if you have your classpath wrong. All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. Another problem is the runtime base uri is changing for our different environments, for example the standalone Jetty runtime has an empty base uri, where as the sample webapp ones have things like /services/ or other samples /SCA/. That is user configurable in the web.xml, but how about at least in all our samples we change that to be consistent? +1 to sample consistency. Re. the base uri. The least we can do is report which base uris are in operation for each binding/environment. A confusion for me is knowing which of the many pieces of information that can be specified wins. Again if we trap the case where what is specified doesn't match what the runtime calculates the uri should be then that would be a great help. Another kind of related problem is the way we require sca application developers to know the intimate details of the structure of the Tuscany build - you want to use web services you must add a dependency for tuscany-binding-ws-axis2, if using Java components then you need to add tuscany-implementation-java-runtime, etc for all the other things you may want to use. We got the J2SE samples so you don't need to know any of that, i think we could do the same for webapps. For example one way would be like the distribution/webapp module strawman we have. That enables sca applications to require no dependencies at all on any tuscany modules, you just build your application jar using only things related to your application and drop it into the webapp sca-contributions folder and it just works. Would that be a better approach than what we do today for webapps? Not sure yet. What's the mode of operation with the distribution/webapp module? You deploy a distribution/webapp war and then deploy application jars to the sca-contributions folder? Thats the way it works right now yes. Its like for example Axis2 or DWR which have ready to run WAR distributions that you just download and deploy and they have some sample applications in the repository (sca-contributions folder) and users just add their own to that. Or we could do something else, maybe have a maven archetype so its easy to create an application maven project for sca webapps. ...ant
