Re: Services and WSDL files
Hi Ant, I tried it as you suggested, so I deployed the service with binding.ws/ only, and tried to access the application using the : [webappSerletUrl]/componentName/serviceName but without success. I am still getting the No servlet registered for path: /HelloWorldServiceComponent/HelloWorldService/ exception. Here is the helloworldws.composite file that I use: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite and the URL that doesn't work is http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService/?wsdl Thanks, Radim On 7/26/07, ant elder [EMAIL PROTECTED] wrote: 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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke ( StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke( ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service( CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process( Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) I did some debugging on this and it seems that the servlet tries to obtain a mapping from a Map, which is empty. Is this a bug or am I just missing something in my .composite file or WSDL? Also, did you create the WSDL file manually or did you use any generation tool provided by Tuscany? Thanks, Radim On 7/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Radim. I'm not very sure if we already have the support to deploy an SCA service as a web service without WSDL. If not, that's something we want to support for sure. We have a sample to demonstrate the usage of SCA, web service and SDO. It seems to be what you are looking for. You can see the sample code at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo Thanks, Raymond - Original Message - From: Radim Kolarik [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 7:38 AM Subject: Services and WSDL files Hi, Is it necessary to supply wsdl file if I want to deploy an SCA service as a web service? Or can Tuscany generate the file on the fly? If I need to supply the file myself, what would be the best way to generate the file? Is it possible to generate the file for SDOs, if they are service parameters or if a service returns an SDO object as its result? Thanks, Radim - 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] Hi Radim Someone else is asking a similar question [1]. As part of this I made
Re: Services and WSDL files
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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke ( StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke( ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service( CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process( Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) I did some debugging on this and it seems that the servlet tries to obtain a mapping from a Map, which is empty. Is this a bug or am I just missing something in my .composite file or WSDL? Also, did you create the WSDL file manually or did you use any generation tool provided by Tuscany? Thanks, Radim On 7/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Radim. I'm not very sure if we already have the support to deploy an SCA service as a web service without WSDL. If not, that's something we want to support for sure. We have a sample to demonstrate the usage of SCA, web service and SDO. It seems to be what you are looking for. You can see the sample code at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo Thanks, Raymond - Original Message - From: Radim Kolarik [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 7:38 AM Subject: Services and WSDL files Hi, Is it necessary to supply wsdl file if I want to deploy an SCA service as a web service? Or can Tuscany generate the file on the fly? If I need to supply the file myself, what would be the best way to generate the file? Is it possible to generate the file for SDOs, if they are service parameters or if a service returns an SDO object as its result? Thanks, Radim - 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] Hi Radim Someone else is asking a similar question [1]. As part of this I made a sample [2] to experiment with exposing web services through the web app container. There are a few wrinkles in getting this to work. To make it work I hand created WSDL conatining a service URL that matched where I knew the service was going to be deployed. For example. In the sample [2] the URL that is registered with the web app relates to the single service that is described in the .composite file [3] component name=AddServiceComponent implementation.java class=calculator.AddServiceImpl/ service name=AddService interface.java interface=calculator.AddService / binding.ws wsdlElement=http://calculator#wsdl.port(AddService/AddSoapPort) http://calculator/#wsdl.port%28AddService/AddSoapPort%29/ /service /component And, in this case, takes its value from the WSDL service description [3] wsdl:service name=AddService wsdl:port binding=tns:AddSoapBinding name=AddSoapPort wsdlsoap:address location= http://localhost:8080/sample-calculator-webapp-ws/services/AddService/ /wsdl:port /wsdl:service I.e, I see the value.
Re: Services and WSDL files
On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That composite you have unfortunately wont work with Tuscany as we don't yet support web services without pre-existing wsdl. So you need to change either the binding.ws to reference a wsdl or change the service to use interface.wsdl. Thats on the current plan to fix in the next release which is targeted for August. This has come up a few times recently so i'll go start work on that now. I have a helloworld-ws-service webapp sample that I've just noticed I've never committed, i'll commit that now so there's at least something that can be used as a base to start from. Additionally on the url below, it shouldn't have a slash before ?wsdl so should be: http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl ...ant On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi Ant, I tried it as you suggested, so I deployed the service with binding.ws/ only, and tried to access the application using the : [webappSerletUrl]/componentName/serviceName but without success. I am still getting the No servlet registered for path: /HelloWorldServiceComponent/HelloWorldService/ exception. Here is the helloworldws.composite file that I use: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite and the URL that doesn't work is http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService/?wsdl Thanks, Radim On 7/26/07, ant elder [EMAIL PROTECTED] wrote: 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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke ( StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke( ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service( CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process( Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) I did some debugging on this and it seems that the servlet tries to obtain a mapping from a Map, which is empty. Is this a bug or am I just missing something in my .composite file or WSDL? Also, did you create the WSDL file manually or did you use any generation tool provided by Tuscany? Thanks, Radim On 7/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Radim. I'm not very sure if we already have the support to deploy an SCA service as a web service without WSDL. If not, that's something we want to support for sure. We have a sample to demonstrate the usage of SCA, web service and SDO. It seems to be what you are looking for. You can see the sample code at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo Thanks, Raymond
Re: Services and WSDL files
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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) I did some debugging on this and it seems that the servlet tries to obtain a mapping from a Map, which is empty. Is this a bug or am I just missing something in my .composite file or WSDL? Also, did you create the WSDL file manually or did you use any generation tool provided by Tuscany? Thanks, Radim On 7/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Radim. I'm not very sure if we already have the support to deploy an SCA service as a web service without WSDL. If not, that's something we want to support for sure. We have a sample to demonstrate the usage of SCA, web service and SDO. It seems to be what you are looking for. You can see the sample code at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo Thanks, Raymond - Original Message - From: Radim Kolarik [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 7:38 AM Subject: Services and WSDL files Hi, Is it necessary to supply wsdl file if I want to deploy an SCA service as a web service? Or can Tuscany generate the file on the fly? If I need to supply the file myself, what would be the best way to generate the file? Is it possible to generate the file for SDOs, if they are service parameters or if a service returns an SDO object as its result? Thanks, Radim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can SDO support full xpath 2.0 spec?
a quick update on my previous response, where I said any path resolves to zero or one value only, I really meant that it resolves to zero or one location in the data graph (that location may of course correspond to a multi-valued property) . Kelvin. On 26/07/07, kelvin goodson [EMAIL PROTECTED] wrote: The SDO 2.1 spec has left the way open for implementations to provide alternative, scheme based means of handling path expressions in SDO calls that operate on paths paths. From the spec perspective, each path supplied to such a call belongs to a scheme, the default scheme being sdo. To explicitly state the scheme you prefix the path with scheme:, so dataObject.get(foo) is equivalant to dataObject.get(sdo:foo);. Note that the default prefix is not xpath; The SDO spec talks of its default path syntax in terms of an augmented subset of XPath. With the primary use of this path being the getting and setting of values, it is important that any path resolves to zero or one value only. From the Tuscany perspective we only support the default scheme currently. I don't have a handle on the fine detail of the XPath 2.0spec, but I can foresee issues that would probably preclude full XPath 2.0 support via the scheme extensibility feature. It has been suggested in the spec group that new methods are added to the XSDHelper interface to handle full XPath support. This discussion is part of the ongoing SDO 3 spec effort. Kelvin. On 26/07/07, lizt [EMAIL PROTECTED] wrote: Hi: Now SDO doesn't support entire xpath 2.0 spec,I think. Can SDO support entire xpath 2.0 spec? thanks zhantao li
Re: How to add Property to an XSDHelper-defined Type
Hi Frank, The SDOUtil.createProperty() appears to do what I need with one caveat. I am currently using the EMF's Diagnostician to validate my DataObjects since Tuscany SDO does not directly offer such a capability. The Diagnostician throws an Exception when it encounters a DataObject whose type modified using SDOUtil.createProperty(). Any ideas off the top of your head why the Diagnostician might not like the DataObject with the modified type? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 9:50:26 AM Subject: Re: How to add Property to an XSDHelper-defined Type Hi Ron, I guess we would need to make TypeHelper.define support a mode where you would only give a patial definition of a Type and it would be used as a delta to modify an exisitng type. A simpler approach, which may be working already, is to use the Tuscany-specific SDOUtil.createProperty() method to modify the existing type. Have you tried that? Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/25/2007 05:16:44 PM: Yes, it would be inconvenient for me to use XSDHelper.define() to modify the existing type. Allowing TypeHelper.define() to redefine the type would be much preferred. How would TypeHelperImpl need to be changed to implement such a feature? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 4:37:46 PM Subject: Re: How to add Property to an XSDHelper-defined Type If you create your HelperContext using SDOUtil.createHelperContext(true), XSDHelper.define() will then let you add new types to an existing namespace and also to replace an existing type with a new version (Note: this is a use at your own risk feature). So, you could add a new property by calling XSDHelper.define() again passing in a new version of the XSD type that includes the new element/attribute. Maybe we should consider makingTypeHelper.define() also allow you to modify existing types if the HelperContext has extensibleNamespaces == true? Frank. Ron Gavlin [EMAIL PROTECTED] 07/25/2007 03:55 PM Please respond to tuscany-user@ws.apache.org To tuscany-user tuscany-user tuscany-user@ws.apache.org cc Subject How to add Property to an XSDHelper-defined Type Greetings, I have a Type that was created using XSDHelper.define(). Now I would like to dynamically add an add'l Property to this Type. This does not appear to be supported. Can you suggest any workarounds? - Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to add Property to an XSDHelper-defined Type
Frank,
Thanks for the detailed explanation. I'll create a JIRA for this issue.
Regards,
- Ron
- Original Message
From: Frank Budinsky [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 3:03:15 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Since the properties start at 0, the extra property number should be equal
to INTERNAL_PROPERTY_COUNT. That looks right.
The StackOverflowException problem looks to me to be caused by the fact
that the generated methods like isSet(int) are expected to find the
property and only call super in the dynamic case. In your case, the
property isn't statically handled, so it eventually calls
DataObjectBase.eIsSet():
public boolean eIsSet(int featureID)
{
if (isDynamic())
{
return super.eIsSet(internalConvertIndex(featureID));
} else
{
return isSet(internalConvertIndex(featureID));
}
}
which will recursively call isSet() again because isDynamic() returns
false. Somehow the code needs to be changed so that the dynamic property
also causes it to go down the isDynamic() path.
Actually, this eIsSet() method looks fishy to me regardless. First, the
call to internalConvertIndex(featureID) for the call to super.eIsSet()
looks wrong to me. I think it should be just featureID. The super call is
expecting the internal (EMF) number, not the converted SDO number. Second,
even in the dynamic sublass case (which this is supposed to be handling, I
think that a client call to eIsSet() won't work, because it won't ever go
down the isSet() patch which handles the static properties (in the base
class(es)).
I think the isDynamic() part of this method should be removed and instead
there should be an implementation of isSet(int) (in ExtensibleDataObject
probably?) that handles the case of a property that is either in a dynamic
sublass or was dynamically added to a static type.
Frank.
Ron Gavlin [EMAIL PROTECTED] wrote on 07/26/2007 01:09:27 PM:
Frank,
This scenario appears to trigger a property-indexing problem. The
newly added property's EMF featureID of 18 equals the value of
MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.
INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any
ideas for working around this problem?
- Ron
- Original Message
From: Ron Gavlin [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 12:53:07 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Hi Frank,
The EMF Diagnostician validate() is generating a
StackOverflowException which may be exposing a bug in the Tuscany
SDO dynamic subclassing area. Here is the stack trace. Let me know
if anything jumps out at you. BTW, I am currently using Tuscany SDO
version R548343 and EMF 2.2.2. I plan upgrade to the final 1.0
release when it is ready.
- Ron
java.lang.StackOverflowError
at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135)
at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821)
at org.apache.tuscany.sdo.impl.DataObjectBase.
eStaticClass(DataObjectBase.java:378)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eClass(ExtensibleDataObjectImpl.java:118)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:815)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
- Original Message
From: Ron Gavlin [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 12:22:49 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Hi Frank,
The SDOUtil.createProperty() appears to do what I need with one
caveat. I am currently using the EMF's Diagnostician to validate my
DataObjects since Tuscany SDO does not directly offer such a
capability. The Diagnostician throws an Exception when it encounters
a DataObject whose type modified using SDOUtil.createProperty(). Any
ideas off the top of your
Re: How to add Property to an XSDHelper-defined Type
Since the properties start at 0, the extra property number should be equal
to INTERNAL_PROPERTY_COUNT. That looks right.
The StackOverflowException problem looks to me to be caused by the fact
that the generated methods like isSet(int) are expected to find the
property and only call super in the dynamic case. In your case, the
property isn't statically handled, so it eventually calls
DataObjectBase.eIsSet():
public boolean eIsSet(int featureID)
{
if (isDynamic())
{
return super.eIsSet(internalConvertIndex(featureID));
} else
{
return isSet(internalConvertIndex(featureID));
}
}
which will recursively call isSet() again because isDynamic() returns
false. Somehow the code needs to be changed so that the dynamic property
also causes it to go down the isDynamic() path.
Actually, this eIsSet() method looks fishy to me regardless. First, the
call to internalConvertIndex(featureID) for the call to super.eIsSet()
looks wrong to me. I think it should be just featureID. The super call is
expecting the internal (EMF) number, not the converted SDO number. Second,
even in the dynamic sublass case (which this is supposed to be handling, I
think that a client call to eIsSet() won't work, because it won't ever go
down the isSet() patch which handles the static properties (in the base
class(es)).
I think the isDynamic() part of this method should be removed and instead
there should be an implementation of isSet(int) (in ExtensibleDataObject
probably?) that handles the case of a property that is either in a dynamic
sublass or was dynamically added to a static type.
Frank.
Ron Gavlin [EMAIL PROTECTED] wrote on 07/26/2007 01:09:27 PM:
Frank,
This scenario appears to trigger a property-indexing problem. The
newly added property's EMF featureID of 18 equals the value of
MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.
INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any
ideas for working around this problem?
- Ron
- Original Message
From: Ron Gavlin [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 12:53:07 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Hi Frank,
The EMF Diagnostician validate() is generating a
StackOverflowException which may be exposing a bug in the Tuscany
SDO dynamic subclassing area. Here is the stack trace. Let me know
if anything jumps out at you. BTW, I am currently using Tuscany SDO
version R548343 and EMF 2.2.2. I plan upgrade to the final 1.0
release when it is ready.
- Ron
java.lang.StackOverflowError
at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135)
at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821)
at org.apache.tuscany.sdo.impl.DataObjectBase.
eStaticClass(DataObjectBase.java:378)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eClass(ExtensibleDataObjectImpl.java:118)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:815)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
- Original Message
From: Ron Gavlin [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 12:22:49 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Hi Frank,
The SDOUtil.createProperty() appears to do what I need with one
caveat. I am currently using the EMF's Diagnostician to validate my
DataObjects since Tuscany SDO does not directly offer such a
capability. The Diagnostician throws an Exception when it encounters
a DataObject whose type modified using SDOUtil.createProperty(). Any
ideas off the top of your head why the Diagnostician might not like
the DataObject with the modified type?
- Ron
- Original Message
From: Frank Budinsky [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 9:50:26 AM
Subject: Re: How to add Property to an XSDHelper-defined Type
Re: How to add Property to an XSDHelper-defined Type
Frank, This scenario appears to trigger a property-indexing problem. The newly added property's EMF featureID of 18 equals the value of MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any ideas for working around this problem? - Ron - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 12:53:07 PM Subject: Re: How to add Property to an XSDHelper-defined Type Hi Frank, The EMF Diagnostician validate() is generating a StackOverflowException which may be exposing a bug in the Tuscany SDO dynamic subclassing area. Here is the stack trace. Let me know if anything jumps out at you. BTW, I am currently using Tuscany SDO version R548343 and EMF 2.2.2. I plan upgrade to the final 1.0 release when it is ready. - Ron java.lang.StackOverflowError at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135) at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821) at org.apache.tuscany.sdo.impl.DataObjectBase.eStaticClass(DataObjectBase.java:378) at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.eClass(ExtensibleDataObjectImpl.java:118) at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectimpl.java:815) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112) at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005) at org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectimpl.java:818) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112) ... at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005) at org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectimpl.java:818) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112) ... - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 12:22:49 PM Subject: Re: How to add Property to an XSDHelper-defined Type Hi Frank, The SDOUtil.createProperty() appears to do what I need with one caveat. I am currently using the EMF's Diagnostician to validate my DataObjects since Tuscany SDO does not directly offer such a capability. The Diagnostician throws an Exception when it encounters a DataObject whose type modified using SDOUtil.createProperty(). Any ideas off the top of your head why the Diagnostician might not like the DataObject with the modified type? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 9:50:26 AM Subject: Re: How to add Property to an XSDHelper-defined Type Hi Ron, I guess we would need to make TypeHelper.define support a mode where you would only give a patial definition of a Type and it would be used as a delta to modify an exisitng type. A simpler approach, which may be working already, is to use the Tuscany-specific SDOUtil.createProperty() method to modify the existing type. Have you tried that? Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/25/2007 05:16:44 PM: Yes, it would be inconvenient for me to use XSDHelper.define() to modify the existing type. Allowing TypeHelper.define() to redefine the type would be much preferred. How would TypeHelperImpl need to be changed to implement such a feature? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 4:37:46 PM Subject: Re: How to add Property to an XSDHelper-defined Type If you create your HelperContext using SDOUtil.createHelperContext(true), XSDHelper.define() will then let you add new types to an existing namespace and also to replace an existing type with a new version (Note: this is a use at your own risk feature). So, you could add a new property by calling XSDHelper.define() again passing in a new version of the XSD type that includes the new element/attribute. Maybe we should consider makingTypeHelper.define() also allow you to modify existing types if the HelperContext has extensibleNamespaces == true? Frank. Ron Gavlin [EMAIL PROTECTED] 07/25/2007 03:55 PM Please respond to tuscany-user@ws.apache.org To tuscany-user tuscany-user tuscany-user@ws.apache.org cc Subject How to add Property to an XSDHelper-defined Type Greetings, I have a Type that was created using XSDHelper.define(). Now I
Re: How to add Property to an XSDHelper-defined Type
Hi Frank, The EMF Diagnostician validate() is generating a StackOverflowException which may be exposing a bug in the Tuscany SDO dynamic subclassing area. Here is the stack trace. Let me know if anything jumps out at you. BTW, I am currently using Tuscany SDO version R548343 and EMF 2.2.2. I plan upgrade to the final 1.0 release when it is ready. - Ron java.lang.StackOverflowError at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135) at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821) at org.apache.tuscany.sdo.impl.DataObjectBase.eStaticClass(DataObjectBase.java:378) at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.eClass(ExtensibleDataObjectImpl.java:118) at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectimpl.java:815) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112) at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005) at org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectimpl.java:818) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112) ... at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005) at org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectimpl.java:818) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152) at org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112) ... - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 12:22:49 PM Subject: Re: How to add Property to an XSDHelper-defined Type Hi Frank, The SDOUtil.createProperty() appears to do what I need with one caveat. I am currently using the EMF's Diagnostician to validate my DataObjects since Tuscany SDO does not directly offer such a capability. The Diagnostician throws an Exception when it encounters a DataObject whose type modified using SDOUtil.createProperty(). Any ideas off the top of your head why the Diagnostician might not like the DataObject with the modified type? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 9:50:26 AM Subject: Re: How to add Property to an XSDHelper-defined Type Hi Ron, I guess we would need to make TypeHelper.define support a mode where you would only give a patial definition of a Type and it would be used as a delta to modify an exisitng type. A simpler approach, which may be working already, is to use the Tuscany-specific SDOUtil.createProperty() method to modify the existing type. Have you tried that? Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/25/2007 05:16:44 PM: Yes, it would be inconvenient for me to use XSDHelper.define() to modify the existing type. Allowing TypeHelper.define() to redefine the type would be much preferred. How would TypeHelperImpl need to be changed to implement such a feature? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 4:37:46 PM Subject: Re: How to add Property to an XSDHelper-defined Type If you create your HelperContext using SDOUtil.createHelperContext(true), XSDHelper.define() will then let you add new types to an existing namespace and also to replace an existing type with a new version (Note: this is a use at your own risk feature). So, you could add a new property by calling XSDHelper.define() again passing in a new version of the XSD type that includes the new element/attribute. Maybe we should consider makingTypeHelper.define() also allow you to modify existing types if the HelperContext has extensibleNamespaces == true? Frank. Ron Gavlin [EMAIL PROTECTED] 07/25/2007 03:55 PM Please respond to tuscany-user@ws.apache.org To tuscany-user tuscany-user tuscany-user@ws.apache.org cc Subject How to add Property to an XSDHelper-defined Type Greetings, I have a Type that was created using XSDHelper.define(). Now I would like to dynamically add an add'l Property to this Type. This does not appear to be supported. Can you suggest any workarounds? - Ron - 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: Services and WSDL files
On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That sounds a lot like the dependencies aren't quite correct. We've actually just started talking about this on the dev list to come up with a way to make this much easier for app developers. Anyway, if you take a look at the helloworld sample i just committed [1] that shows about the simplest i could come up with that shows how to do what you want. You can call that webapp service by using the tuscany helloworld-ws-reference sample by changing the wsdl port location to be: http://localhost:8080/sample-helloworld-ws-service-webapp/SCA/HelloWorldComponent/HelloWorldService I'll go try to get the calculator-webapp-ws sample working as well so there's two examples. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-webapp On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi, I made some progress with this, but it doesn't do exactly what I need it to do. In my META-INF folder, I have sca-contribution.xml file, which looks like this: contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:sample=http://helloworld; deployable composite=sample:helloworldws/ /contribution This is my .composite file: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite The important section in the WSDL file is: wsdl:service name=HelloWorldService wsdl:port binding=tns:HelloWorldSoapBinding name=HelloWorldSoapPort wsdlsoap:address location= http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService / /wsdl:port /wsdl:service Now my Tomcat is running on port 8080. As you can see, I had to specify port 8090 in WSDL, which made my service WSDL accessible via: http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl When I had the port in WSDL file set to 8080, I got an exception: java.net.BindException: Address already in use: bind That would suggest that some standalone engine is being inicialized which binds the service to port specified in WSDL. But what if I wanted the service to be handled directly by Tomcat? Would it be possible? By the way, my webapp uses the same JAR files in its WEB-INF/lib directory as were created using maven build of calculator-webapp-ws sample (I understand that I shouldn't have tuscany-sca-all-0.90-incubating.jar in web application class path). Thanks, Radim On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That composite you have unfortunately wont work with Tuscany as we don't yet support web services without pre-existing wsdl. So you need to change either the binding.ws to reference a wsdl or change the service to use interface.wsdl. Thats on the current plan to fix in the next release which is targeted for August. This has come up a few times recently so i'll go start work on that now. I have a helloworld-ws-service webapp sample that I've just noticed I've never committed, i'll commit that now so there's at least something that can be used as a base to start from. Additionally on the url below, it shouldn't have a slash before ?wsdl so should be: http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl ...ant On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi Ant, I tried it as you suggested, so I deployed the service with binding.ws/ only, and tried to access the application using the : [webappSerletUrl]/componentName/serviceName but without success. I am still getting the No servlet registered for path: /HelloWorldServiceComponent/HelloWorldService/ exception. Here is the helloworldws.composite file that I use: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface= helloworld.HelloWorldService / binding.ws/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite and the URL that doesn't work is
Re: Services and WSDL files
That sounds a lot like the dependencies aren't quite correct. We've actually just started talking about this on the dev list to come up with a way to make this much easier for app developers. Anyway, if you take a look at the helloworld sample i just committed [1] that shows about the simplest i could come up with that shows how to do what you want. You can call that webapp service by using the tuscany helloworld-ws-reference sample by changing the wsdl port location to be: http://localhost:8080/sample-helloworld-ws-service-webapp/SCA/HelloWorldComponent/HelloWorldService I'll go try to get the calculator-webapp-ws sample working as well so there's two examples. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-webapp On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi, I made some progress with this, but it doesn't do exactly what I need it to do. In my META-INF folder, I have sca-contribution.xml file, which looks like this: contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:sample=http://helloworld; deployable composite=sample:helloworldws/ /contribution This is my .composite file: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface=helloworld.HelloWorldService/ binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite The important section in the WSDL file is: wsdl:service name=HelloWorldService wsdl:port binding=tns:HelloWorldSoapBinding name=HelloWorldSoapPort wsdlsoap:address location= http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService / /wsdl:port /wsdl:service Now my Tomcat is running on port 8080. As you can see, I had to specify port 8090 in WSDL, which made my service WSDL accessible via: http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl When I had the port in WSDL file set to 8080, I got an exception: java.net.BindException: Address already in use: bind That would suggest that some standalone engine is being inicialized which binds the service to port specified in WSDL. But what if I wanted the service to be handled directly by Tomcat? Would it be possible? By the way, my webapp uses the same JAR files in its WEB-INF/lib directory as were created using maven build of calculator-webapp-ws sample (I understand that I shouldn't have tuscany-sca-all-0.90-incubating.jar in web application class path). Thanks, Radim On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That composite you have unfortunately wont work with Tuscany as we don't yet support web services without pre-existing wsdl. So you need to change either the binding.ws to reference a wsdl or change the service to use interface.wsdl. Thats on the current plan to fix in the next release which is targeted for August. This has come up a few times recently so i'll go start work on that now. I have a helloworld-ws-service webapp sample that I've just noticed I've never committed, i'll commit that now so there's at least something that can be used as a base to start from. Additionally on the url below, it shouldn't have a slash before ?wsdl so should be: http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl ...ant On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi Ant, I tried it as you suggested, so I deployed the service with binding.ws/ only, and tried to access the application using the : [webappSerletUrl]/componentName/serviceName but without success. I am still getting the No servlet registered for path: /HelloWorldServiceComponent/HelloWorldService/ exception. Here is the helloworldws.composite file that I use: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface= helloworld.HelloWorldService / binding.ws/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite and the URL that doesn't work is http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService/?wsdl Thanks, Radim On 7/26/07, ant elder [EMAIL PROTECTED] wrote: On
Static SDO generator: problem with elements named internal*
Hi, I run into a problem with the static generated SDOs, when having a xsd with the following two elements: xsd:element name=abc type=xsd:integer / xsd:element name=internalAbc type=xsd:integer / In the generated Impl class this leads twice to the same constant INTERNAL_ABC. The xsd elements might simply be renamed in order to avoid this clash, but there might be situations where this is not possible. Could the generator use a different, less probable prefix (e.g. ___INTERNAL_), or are there other parties dependent on the current prefix INTERNAL_? Thanks, Daniel. __ Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER INTERNET-GURU! www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can SDO support full xpath 2.0 spec?
The SDO 2.1 spec has left the way open for implementations to provide alternative, scheme based means of handling path expressions in SDO calls that operate on paths paths. From the spec perspective, each path supplied to such a call belongs to a scheme, the default scheme being sdo. To explicitly state the scheme you prefix the path with scheme:, so dataObject.get(foo) is equivalant to dataObject.get(sdo:foo);. Note that the default prefix is not xpath; The SDO spec talks of its default path syntax in terms of an augmented subset of XPath. With the primary use of this path being the getting and setting of values, it is important that any path resolves to zero or one value only. From the Tuscany perspective we only support the default scheme currently. I don't have a handle on the fine detail of the XPath 2.0 spec, but I can foresee issues that would probably preclude full XPath 2.0 support via the scheme extensibility feature. It has been suggested in the spec group that new methods are added to the XSDHelper interface to handle full XPath support. This discussion is part of the ongoing SDO 3 spec effort. Kelvin. On 26/07/07, lizt [EMAIL PROTECTED] wrote: Hi: Now SDO doesn't support entire xpath 2.0 spec,I think. Can SDO support entire xpath 2.0 spec? thanks zhantao li
Re: SOAP over JMS?
On 7/24/07, Mike Edwards [EMAIL PROTECTED] wrote: Simon Laws wrote: snip Ah, thanks Mike. I didn't latch onto the implication of the word intent. The choice we are talking about here seems more like a concrete decision than an intent. Does this match well with the, erm, intention of intents? Simon It is one use of intents - and, in my opinion, it is a reasonable match. It tells the binding to apply a particular policy - the policy of using a specific transport. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] So I can summarize a few things from this thread. 1/ That in this case the concensus so far is that binding-ws should have selectable transports. 2/ There are a number of ways we can describe the selection - intents - uri - child xml elements of binding.ws 3/ There are a number of ways we can describe the configuration of the selected transport - further parameters on the uri - child xml elements of binding.ws It seems to me that the uri approach is the easiest starting point (this function also needs to be added to the MS binding so I imagine the same/similar code applies). I'm not in a position to address this just now (am back working on the distributed runtime) but it answers my question about how this could be done. If there is anyone out there who fancies having a play with some binding stuff then this is another good one to look at. Simon
Re: Services and WSDL files
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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke( StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke( StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke ( StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke( ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke( StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service( CoyoteAdapter.java:261) at org.apache.coyote.http11.Http11Processor.process( Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process ( Http11Protocol.java:581) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) I did some debugging on this and it seems that the servlet tries to obtain a mapping from a Map, which is empty. Is this a bug or am I just missing something in my .composite file or WSDL? Also, did you create the WSDL file manually or did you use any generation tool provided by Tuscany? Thanks, Radim On 7/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Radim. I'm not very sure if we already have the support to deploy an SCA service as a web service without WSDL. If not, that's something we want to support for sure. We have a sample to demonstrate the usage of SCA, web service and SDO. It seems to be what you are looking for. You can see the sample code at: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo Thanks, Raymond - Original Message - From: Radim Kolarik [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, July 25, 2007 7:38 AM Subject: Services and WSDL files Hi, Is it necessary to supply wsdl file if I want to deploy an SCA service as a web service? Or can Tuscany generate the file on the fly? If I need to supply the file myself, what would be the best way to generate the file? Is it possible to generate the file for SDOs, if they are service parameters or if a service returns an SDO object as its result? Thanks, Radim - 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] Hi Radim Someone else is asking a similar question [1]. As part of this I made a sample [2] to experiment with exposing web services through the web app container. There are a few wrinkles in getting this to work. To make it work I hand created WSDL conatining a service URL that matched where I knew the service was going to be deployed. For example. In the sample [2] the URL that is registered with the web app relates to the single service that is described in the .composite file [3] component name=AddServiceComponent implementation.java class=calculator.AddServiceImpl/ service name=AddService interface.java interface=calculator.AddService / binding.ws wsdlElement=http://calculator#wsdl.port(AddService/AddSoapPort) http://calculator/#wsdl.port%28AddService/AddSoapPort%29/ /service /component And, in this case, takes its value from the WSDL service description [3] wsdl:service name=AddService wsdl:port binding=tns:AddSoapBinding name=AddSoapPort wsdlsoap:address location=http://localhost:8080/sample-calculator-webapp-ws/services/AddService/ /wsdl:port /wsdl:service I.e, I see the value. http://localhost:8080/sample-calculator-webapp-ws/services/AddServiceregistered in the WebAppServletHost The important thing here is that the URL I hand
Fwd: servlet TuscanyServlet threw exception
Forwarding as I fell for just pressing respond and googlemail only responded to the first mail address. Simon -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Jul 25, 2007 3:01 PM Subject: Re: servlet TuscanyServlet threw exception To: Nishant Joshi [EMAIL PROTECTED] On 7/25/07, Nishant Joshi [EMAIL PROTECTED] wrote: Hi Simon, I have used target servlet as Tuscany servlet which is actually get some URI path from me and get me some servlet, But if u see the complete Process of How it get URI from us and get servlet back to us it looks there is one map in WebAppServletHost called servles it is the creating problem for me, You can download source code of Tuscany from http://cwiki.apache.org/TUSCANY/sca-java-releases.html Mine problem now is How to register servlet and call one function addServletMapping() from WebAppServletHost.java file thanks Nishant Joshi This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp Ok, I think we need to take a step back and walk through what you are trying to do. From the previous posts I have imagined that you were trying to 1/ run SCA as part of a web app (and that you have got that working) 2/ add some web services to that web app Let me know if you are trying to do something else. Assuming this is the case lets talk about 1/ first. There is an example of how to do this in samples/calculator-webapp. If you look at the Calculator.composite file for this application you see composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace= http://sample; xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent/reference reference name=subtractService target=SubtractServiceComponent/reference reference name=multiplyService target=MultiplyServiceComponent/reference reference name=divideService target=DivideServiceComponent/reference /component component name=AddServiceComponent implementation.java class=calculator.AddServiceImpl/ /component component name=SubtractServiceComponent implementation.java class=calculator.SubtractServiceImpl/ /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl/ /component component name=DivideServiceComponent implementation.java class=calculator.DivideServiceImpl / /component /composite Now there is no mention here of servlets or that this application is running in a webapp. If you look at the calculator-webapp\src\main\webapp\calc.jsp file you see %@ page import=org.apache.tuscany.sca.host.embedded.SCADomain% %@ page import=calculator.CalculatorService % %@ page contentType=text/html;charset=UTF-8 language=java % % SCADomain scaDomain = (SCADomain) application.getAttribute( org.apache.tuscany.sca.SCADomain); CalculatorService calculatorService = scaDomain.getService( CalculatorService.class, CalculatorServiceComponent); % html headtitleCalculator sample/title/head body table tr thExpression/ththResult/th /tr tr td2 + 3/tdtd%= calculatorService.add(2, 3) %/td /tr tr td3 - 2/tdtd%= calculatorService.subtract(3, 2) %/td /tr tr td3 * 2/tdtd%= calculatorService.multiply(3, 2) %/td /tr tr td3 / 2/tdtd%= calculatorService.divide(3, 2) %/td /tr /table /body /html The web.xml file itself uses the TuscanyContextListener to start the SCA runtime (SCADomain) and register it in the servlet context so that the JSP can access it. web-app display-nameTuscany Calculator Web Service Sample/display-name listener listener-classorg.apache.tuscany.sca.webapp.TuscanyContextListener/listener-class /listener welcome-file-list id=WelcomeFileList welcome-filecalc.jsp/welcome-file /welcome-file-list /web-app In case 2/. If you want to expose some of the SCA components as web services then you need to describe the appropriate bindings in the composite file, for example, here, I have changed the calculator SCA application to expose the AddServiceComponent as a web service. I have to provide the WSDL for this service but the runtime should be able to work out how to register the underlying Axis servlet so that the web services run. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://sample; xmlns:sample= http://sample; name=Calculator component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl / reference name=addService interface.java interface=calculator.AddService / binding.ws wsdlElement=
RE: [SCA Native] next release content [was: Tuscany roadmap]
Hello all, I created a wiki page detailing the TuscanySCA Native Next Release Contents, which will probably be called M4. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R elease+Contents Can I get some feedback on the items listed there. Also, what's the Apache procedure to start planning and implementing the changes? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 11:00 AM To: [EMAIL PROTECTED] Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] On 12/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I forgot to mention another one in my previous post: - get the test suite up to date and working. I don't like making changes to code without running a good unit/basic test suite. We do not have ANY test suite. I run through the samples to test changes. The code under tuscany/cpp/sca/test is not maintained and should probably be discarded. I think we need to build up a unit test suite and would welcome suggestions on how to start this (use cppunit?) I can start a separate thread for the ant vs make discussion. Basically, I think it would be easier to simplify the build process using make. I've looked through some of the makefiles and they're horrendous. :) Let's discuss it here then. We need to be able to build from source on windows, linux and Mac. On Windows we settled on MSVC 8 so it can build with the free studio express. For linux we settled on automake as it seemed to be fairly standard for C/C++ open source projects. In doing this I had to learn automake and learnt to hate it ;-) ... and as you say some of the makefiles are ugly. If you believe an ant based build would be better then I'll happily go along with that. Perhaps you could start this off by showing us what the build would look like for, say, cpp/sca/runtime/core ?? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 9:53 AM To: [EMAIL PROTECTED] Subject: [SCA Native] next release content [was: Tuscany roadmap] We should definitely start planning some content for the next SCA Native release. On 12/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Is there some sort of TuscanySCA roadmap? I've looked around a bit and haven't found one. I was curious what the future plans for TuscanySCA CPP were in particular. I have a few ideas and I was curious if they had been contemplated yet. - Move from Assembly Model 0.96 to 1.0 Definitely. We also need to move the CPP extension to the 1.0 C++ CI spec version - Move to ant instead of make I need to understand this proposal a little better. Can you elaborate? Probably worth starting a separate thread to discuss this. I'm all for simplifying the build though! - Remove runtime dependancy on model data structure (slight changes to data/model shouldnt affect runtime usage) ok - Support additional WSDL bindings: RPC, DOC encoded... sounds good. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] Cheers, -- Pete - 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] -- Pete - 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]
OSCON 2007 Tuscany BOF
I was at a Tuscany BOF yesterday at OSCON 2007 (http://conferences.oreillynet.com/cs/os2007/view/e_sess/14724). I presented an overview of SCA, SDO, Tuscany, what's in our latest releases and some of the work in progress. I have uploaded the presentation there: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OSCON+2007+Tuscany+BOF I also showed the BigBank demo, available in our SVN repository there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Services and WSDL files
I was encountering a lot of the same problems trying to get a simple example (web service in a web container) with 0.91, and this thread was extremely helpful. Just to summarize what I had to do to get a sample up using 0.91: - grabbed calculator-webapp-ws from head - added latest TuscanyServlet to 0.91 jars - compiled calculator-webapp-ws sample with 0.91 jars (and new TuscanyServlet) - removed tuscany-http-jetty jar from lib - left wsdl location at port 8080 (Tomcat default) Some things discovered in getting the sample up: - with 0.91 TuscanyServlet, need the tuscany-http-jetty jar and port 8090 in wsdl - with 0.91 TuscanyServlet, does not work without tuscany-http-jetty (UndeclaredThrowableException) - with 0.91 + latest TuscanyServlet, tuscany-http-jetty jar and port 8090 in wsdl works - with 0.91 + latest TuscanyServlet, removing tuscany-http-jetty allows wsdl to use port 8080 Now on to the task of getting a sample up with web service, web container, and SDO. - Original Message From: Radim Kolarik [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 26, 2007 11:47:39 AM Subject: Re: Services and WSDL files Hi, thanks for all your support, removing tuscany-host-jetty jar from the classpath solved the problem! I can now run the service from Tomcat. I would just like to clarify with you few more things that were mentioned in this thread. Ant mentioned, that he would start working on something for next release of Tuscany, which is due to be released in August. Did you mean also the on the fly generation of WSDL, to support services without pre existing WSDL file? How can I generate WSDL file for SCA service using Tuscany at the moment? And does the generation support SDOs as parameters / results of services? Thanks, Radim On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That sounds a lot like the dependencies aren't quite correct. We've actually just started talking about this on the dev list to come up with a way to make this much easier for app developers. Anyway, if you take a look at the helloworld sample i just committed [1] that shows about the simplest i could come up with that shows how to do what you want. You can call that webapp service by using the tuscany helloworld-ws-reference sample by changing the wsdl port location to be: http://localhost:8080/sample-helloworld-ws-service-webapp/SCA/HelloWorldComponent/HelloWorldService I'll go try to get the calculator-webapp-ws sample working as well so there's two examples. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-webapp On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi, I made some progress with this, but it doesn't do exactly what I need it to do. In my META-INF folder, I have sca-contribution.xml file, which looks like this: contribution xmlns=http://www.osoa.org/xmlns/sca/1.0;; targetNamespace=http://helloworld;; xmlns:sample=http://helloworld;; deployable composite=sample:helloworldws/ /contribution This is my .composite file: composite xmlns=http://www.osoa.org/xmlns/sca/1.0;; targetNamespace=http://helloworld;; xmlns:hw=http://helloworld;; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite The important section in the WSDL file is: wsdl:service name=HelloWorldService wsdl:port binding=tns:HelloWorldSoapBinding name=HelloWorldSoapPort wsdlsoap:address location= http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService / /wsdl:port /wsdl:service Now my Tomcat is running on port 8080. As you can see, I had to specify port 8090 in WSDL, which made my service WSDL accessible via: http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl When I had the port in WSDL file set to 8080, I got an exception: java.net.BindException: Address already in use: bind That would suggest that some standalone engine is being inicialized which binds the service to port specified in WSDL. But what if I wanted the service to be handled directly by Tomcat? Would it be possible? By the way, my webapp uses the same JAR files in its WEB-INF/lib directory as were created using maven build of calculator-webapp-ws sample (I understand that I shouldn't have tuscany-sca-all-0.90-incubating.jar in web
Re: Services and WSDL files
Hi, thanks for all your support, removing tuscany-host-jetty jar from the classpath solved the problem! I can now run the service from Tomcat. I would just like to clarify with you few more things that were mentioned in this thread. Ant mentioned, that he would start working on something for next release of Tuscany, which is due to be released in August. Did you mean also the on the fly generation of WSDL, to support services without pre existing WSDL file? How can I generate WSDL file for SCA service using Tuscany at the moment? And does the generation support SDOs as parameters / results of services? Thanks, Radim On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That sounds a lot like the dependencies aren't quite correct. We've actually just started talking about this on the dev list to come up with a way to make this much easier for app developers. Anyway, if you take a look at the helloworld sample i just committed [1] that shows about the simplest i could come up with that shows how to do what you want. You can call that webapp service by using the tuscany helloworld-ws-reference sample by changing the wsdl port location to be: http://localhost:8080/sample-helloworld-ws-service-webapp/SCA/HelloWorldComponent/HelloWorldService I'll go try to get the calculator-webapp-ws sample working as well so there's two examples. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-webapp On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi, I made some progress with this, but it doesn't do exactly what I need it to do. In my META-INF folder, I have sca-contribution.xml file, which looks like this: contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:sample=http://helloworld; deployable composite=sample:helloworldws/ /contribution This is my .composite file: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /service implementation.java class=helloworld.HelloWorldImpl / /component /composite The important section in the WSDL file is: wsdl:service name=HelloWorldService wsdl:port binding=tns:HelloWorldSoapBinding name=HelloWorldSoapPort wsdlsoap:address location= http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService / /wsdl:port /wsdl:service Now my Tomcat is running on port 8080. As you can see, I had to specify port 8090 in WSDL, which made my service WSDL accessible via: http://localhost:8090/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl When I had the port in WSDL file set to 8080, I got an exception: java.net.BindException: Address already in use: bind That would suggest that some standalone engine is being inicialized which binds the service to port specified in WSDL. But what if I wanted the service to be handled directly by Tomcat? Would it be possible? By the way, my webapp uses the same JAR files in its WEB-INF/lib directory as were created using maven build of calculator-webapp-ws sample (I understand that I shouldn't have tuscany-sca-all-0.90-incubating.jar in web application class path). Thanks, Radim On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote: On 7/26/07, ant elder [EMAIL PROTECTED] wrote: That composite you have unfortunately wont work with Tuscany as we don't yet support web services without pre-existing wsdl. So you need to change either the binding.ws to reference a wsdl or change the service to use interface.wsdl. Thats on the current plan to fix in the next release which is targeted for August. This has come up a few times recently so i'll go start work on that now. I have a helloworld-ws-service webapp sample that I've just noticed I've never committed, i'll commit that now so there's at least something that can be used as a base to start from. Additionally on the url below, it shouldn't have a slash before ?wsdl so should be: http://localhost:8080/helloworldServiceWAR/HelloWorldServiceComponent/HelloWorldService?wsdl ...ant On 7/26/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi Ant, I tried it as you suggested, so I deployed the service with binding.ws/ only, and tried to access the application using the :
