Re: ClassNotFoundException in domain for application classes when registering a remote node
On Nov 30, 2007 2:18 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:50 PM, ant elder [EMAIL PROTECTED] wrote: I'm getting the exception below when i try to register a contribution in a node thats running in a separate JVM from the domain. Does this mean all contributions in nodes also need to be in the classpath used by the domain? INFO: Registered node: http://localhost:8080/tuscany/ at endpoint http://L32H83W:8080/tuscany//SCANodeManagerComponent/SCANodeManagerService 30-Nov-2007 13:46:23 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterContribution SEVERE: Exception when registering contribution C:\Tomcat\apache- tomcat-6.0.10\webapps\sample-helloworld-ws-service-webapp\org.apache.tuscany.sca.domain.DomainException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl ...ant Yes, the domain reads the contribution to build the domain model. - we don't at the moment have a mechanism of moving contributions physically between domain/node or node/domain. Only the id and location is passed. A shared filesystem is assumed. - we could relax this restriction when you add a contribution to a node but we would still need to pass the model back to the domain somehow. Would require work. In your case when you drop the contribution (war/jar?) into the web app container what do you provide as the contribution URL? Can we make sure that is an absolute URL and make sure that the domain can see it? Simon I see. I think it is using an absolute URL, (the error message above includes it), maybe the problem is the contribution URL is to the webapp root folder but the classes are inside that in the WEB-INF\classes directory so the don't get found. ...ant Doh. I should have noticed that from the error message. The war is presented to the domain as a file contribution and hence the domain doesn't know to look in WEB-INF\classes as you say. I works in the node by accident as Tomcat has already processed the war and put the classes on the classpath. I expect we need to present it as a war contribution and set the model resolver up so that it can find the classes in WEB-INF\classes. It doesn't seem that we support war contributions now. I'll have a look to see what happens in Contribution. Any Contribution experts out there that can comment? Simon
Re: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant IMHO the URI info should come from an SCA composite. Any departure from that will lead to the definition of a new configuration model for these things, stranger to SCA. Could you explain this a bit more? Would that mean composites MUST include an absolute URI as in the example at the start of this thread? How does that relate to line 2357 of the assembly spec that says An SCA domain should define a base URI for each 2358 hierarchical URI scheme on which it intends to provide services.? ...ant
Re: What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
Jean-Sebastien Delfino wrote: ant elder wrote: On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant IMHO the URI info should come from an SCA composite. Any departure from that will lead to the definition of a new configuration model for these things, stranger to SCA. Could you explain this a bit more? Would that mean composites MUST include an absolute URI as in the example at the start of this thread? How does that relate to line 2357 of the assembly spec that says An SCA domain should define a base URI for each 2358 hierarchical URI scheme on which it intends to provide services.? ...ant Line 2357 is interesting. Let me try to describe (with two use cases) how I envision that domain base URI being used. 1. Mycompany.com is a medium size
[jira] Updated: (TUSCANY-1545) Change default XML encoding to UTF-8.
[ https://issues.apache.org/jira/browse/TUSCANY-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1545: Attachment: 1545.patch I've added code to the XMLHelperImpl.java class to set the encoding on 'dynamically created' XMLDocument objects used during the save operation. Additionally, I've included an additional test in the XMLHelperTestCase to check for the validity of this behavior. The XMLSaveOptionsTestCase was modified to accomodate this change, as well. Change default XML encoding to UTF-8. Key: TUSCANY-1545 URL: https://issues.apache.org/jira/browse/TUSCANY-1545 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Reporter: Frank Budinsky Priority: Minor Fix For: Java-SDO-Next Attachments: 1545.patch XMLHelper.save() uses ASCII encoding by default, but the spec says the default encoding is UTF-8. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Raymond Feng wrote: Hi, I suggest that we not expand too quickly into other bindings such as RMI. Let's focus on getting your previous proposal (StockQuote, AccountData services) implemented first. Thanks, Raymond +1 to try to work through the actual scenario first. When I brought up the scenario I was thinking about the following steps: 1. Copy the bigbank-* modules into new bigbank-secure-* modules. 2. Split the AccountData component into two components in two different composites representing two divisions of the bank (checking and savings accounts). 3. At this point I'm not sure that the calculator component is so interesting for this scenario, as it was there to show integration of different scripting languages, not very relevant here. It's probably more interesting to invoke a CurrencyConverter Web service running on a separate node simulating an external service. 4. Discuss on this list what kind of policies (authentication, confidentiality, integrity) make sense to apply where in the bigbank solution. 5. Author the policy related application and configuration/deployment related artifacts in the bigbank modules; I'm sure that many questions will arise and help understand usage patterns and good practices for policies. 6. Go through the steps that an application developer, assembler, deployer, system administrator needs to perform to put the bigbank solution together; this is not a theoretical exercise as we'll actually have to perform these steps ourselves, and work on what can be done to our policy support to facilitate them. 7. Bring the pieces of the bigbank solution together, get it working end to end and work through any relevant technical issues. I'm guessing that questions like... - how many definitions.xml files to we need? - what do we write in them? - where do we place them? - can intent=confidentiality represent different types of confidentiality mechanisms used for different types of exchanges? - do we put policysets in the composites or definitions.xml - how do we use appliesTo? - and probably 50 more questions like that :) ... will pop up right in our face when we develop the scenario, backed by a concrete use case which will help think through them. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remotable interfaces and pass by value, was: Data transformation from/to POJO
Some answers after researching the spec docs: Raymond Feng wrote: Hi, I think this issue needs to be brought up at the spec level. Basically, the following have to be clarified: 1) What interfaces are qualified to be remotable? 2) What are the characteristics of the input/output types for remotable interfaces? Assembly spec: 697 Whether a service of a component implementation is remotable is defined by the interface of the service. In the case of Java this is defined by adding the @Remotable annotation to the Java interface (see Client and Implementation Model Specification for Java). WSDL defined interfaces are always remotable. Java SCA Annotations and APIs spec: 297 Java interfaces generated from a WSDL portType are always remotable. I think that says that JAX-WS generated interfaces should be considered remotable even in the absence of an @Remotable interface. Java SCA Annotations and APIs spec: 1531 Complex data types exchanged via remotable service interfaces must be compatible with the marshalling technology used by the service binding. For example, if the service is going to be exposed using the standard web service binding, then the parameters must be Service Data Objects (SDOs) 2.0 [2] or JAXB [3] types. Independent of whether the remotable service is called from outside of the composite that contains it or from another component in the same composite, the data exchange semantics are by-value. This leaves the door open for other data representations supported by other service bindings, e.g. a DOM or a Java Serializable object. The Java SCA Annotations and APIs spec Errata adds this: The SCA Client and Implementation Model for Java applies the WSDL to Java and Java to WSDL mapping rules as defined by the JAX-WS specification [4] for generating remotable Java interfaces from WSDL portTypes and vice versa. For the purposes of the Java-to-WSDL mapping algorithm, the interface is treated as if it had a @WebService annotation on the class, even if it doesn't, and the org.osoa.OneWay annotation should be treated as a synonym for javax.jws.OneWay. For the WSDL-to-Java, the generated @WebService annotation should imply that the interface is @Remotable. For the mapping from Java types to XML schema types SCA supports both the SDO 2.1 [2] mapping and the JAXB [3] mapping. Having a choice of binding technologies is allowed, as noted in the first paragraph of section 5 of the JSR 181 (version 2) specification, which is referenced by the JAX-WS specification. EJB binding spec: 105 When used with the EJB binding, a service or reference interface must be compatible with a session bean interface, according to the following rules: - The interface offered by a reference MUST be remotable if the remote session bean interface is being accessed, and MUST be local if the local session bean interface is being accessed. - The methods on the session bean MUST be a compatible superset of the methods in the interface used by the reference. - The interface used by a reference MAY NOT contain any methods inherited from EJBObject or EJBLocalObject. - Compatibility for an individual method is defined by the SCA Assembly Model Specification [4], and can be stated simply as compatibility of the signature. That is, the method name, input types, and output types MUST be identical. - The order of the input and output types also MUST be identical. This brings interesting points: - EJB binding does not imply remote, local interfaces are also supported (contrary to the common belief that binding implies remote). - an SCA reference can use a newly defined Java interface (compatible with the session bean interface but not dragging javax.ejb.Remote) with a @Remotable annotation. 3) What are the semantics of pass-by-value? Assembly spec: 706 Independent of whether the remotable service is called remotely from outside the process where the service runs or from another component running in the same process, the data exchange semantics are by-value. Implementations of remotable services may modify input messages (parameters) during or after an invocation and may modify return messages (results) after the invocation. If a remotable service is called locally or remotely, the SCA container is responsible for making sure that no modification of input messages or post-invocation modifications to return messages are seen by the caller. Does that help answer your questions? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 9:06 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: ant elder wrote: On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant IMHO the URI info should come from an SCA composite. Any departure from that will lead to the definition of a new configuration model for these things, stranger to SCA. Could you explain this a bit more? Would that mean composites MUST include an absolute URI as in the example at the start of this thread? How does that relate to line
Re: ClassNotFoundException in domain for application classes when registering a remote node
On Nov 30, 2007 3:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:18 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:50 PM, ant elder [EMAIL PROTECTED] wrote: I'm getting the exception below when i try to register a contribution in a node thats running in a separate JVM from the domain. Does this mean all contributions in nodes also need to be in the classpath used by the domain? INFO: Registered node: http://localhost:8080/tuscany/ at endpoint http://L32H83W:8080/tuscany//SCANodeManagerComponent/SCANodeManagerService 30-Nov-2007 13:46:23 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterContribution SEVERE: Exception when registering contribution C:\Tomcat\apache- tomcat-6.0.10\webapps\sample-helloworld-ws-service-webapp\org.apache.tuscany.sca.domain.DomainException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl ...ant Yes, the domain reads the contribution to build the domain model. - we don't at the moment have a mechanism of moving contributions physically between domain/node or node/domain. Only the id and location is passed. A shared filesystem is assumed. - we could relax this restriction when you add a contribution to a node but we would still need to pass the model back to the domain somehow. Would require work. In your case when you drop the contribution (war/jar?) into the web app container what do you provide as the contribution URL? Can we make sure that is an absolute URL and make sure that the domain can see it? Simon I see. I think it is using an absolute URL, (the error message above includes it), maybe the problem is the contribution URL is to the webapp root folder but the classes are inside that in the WEB-INF\classes directory so the don't get found. ...ant Doh. I should have noticed that from the error message. The war is presented to the domain as a file contribution and hence the domain doesn't know to look in WEB-INF\classes as you say. I works in the node by accident as Tomcat has already processed the war and put the classes on the classpath. I expect we need to present it as a war contribution and set the model resolver up so that it can find the classes in WEB-INF\classes. It doesn't seem that we support war contributions now. I'll have a look to see what happens in Contribution. Any Contribution experts out there that can comment? Simon I just chatted with Rajini and she suggested we try using the WEB\classes dir as the contribution root and treat it as a file contribution as a work around. I don't know what your contribution looks like but I'm going to try getting your web app code running in the store sample so I can move the sample distributed scenario on a bit and help you out. Any pointers to where I should start? Simon Simon
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi, I suggest that we not expand too quickly into other bindings such as RMI. Let's focus on getting your previous proposal (StockQuote, AccountData services) implemented first. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, November 30, 2007 7:41 AM Subject: Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios. Hi, Going ahead, I am starting with the calculator service. Since we have our calculator service hosted as an rmi service, I have started to look into how security could be provided in an RMI Binding. - Venkat On Nov 30, 2007 1:17 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Heres what I am intending to do for the secure-bigbank into which I have copied over the exiting calculator, stockquote and account demos into secure-bigbank... - The Calculator and StockQuote services need to exchange data that cannot be tampered with since the AccountService heavily 'relies' on their results. So interaction with these two services should have 'integrity'. I don't think there is a need for authentication or confidentiality for the interactions with these services. - The AccountData service is right now accessed only by the AccountService. I'd like to open this out and put in the following security constraints :- - just keep authentication when accessed from the AccoutService locally say over binding.sca - enforce authentication, confidentiality and integrity when accessed from outside say over binding.ws - Finally the AccountService should enforce authentication, confidentiality and integrity. Does this sound ok ? After an iteration with interaction policies, I'll start working on some implementation policies. For example having 'authorization' enforced on the AccountDataService's operations. Thanks - Venkat On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, I propose to add the following to the BigBank scenario too to cover transaction policies and JMS binding. 1) Have separate components to represent the SavingsAccountService and CheckingAccountService. The two services will be backed by two different resource managers (Database or JMS queue). Please see the code at [1] and diagrams at [2]. 2) Add a TransferService to transfer money between accounts. The operations will be executed in a global transaction. 3) The TransferService will be exposed over binding.jms. The request of money transfer from the web front will be served by the TransferService over JMS. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies Thanks, Raymond Sounds good to me. The other aspect that this scenario will allow us to explore is interaction between the JMS binding and databindings (as Bigbank flows complex types). I'd suggest to work on these two versions of Bigbank in parallel in different modules: a) secure bigbank with security policies b) reliable transfers with JMS and transactions i.e. two different copies of BigBank. And then bring the two together at some point later. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Addition for sdo java faq?
After responding to Chris' issue in Tuscany-1925, it occurred to me that this will be an ongoing problem for folks trying to use Sun 1.4 JVMs. Looking back over the dev list history, I see a couple of other times where this has been a problem. Perhaps, we might want to add this to the faq, what do you think? Here's a first stab at the FAQ entry: Why am I getting an exception when using Apache Tuscany's java SDO implementation in a Sun JDK 1.4? The Crimson DOM implementation in (some versions of) the Sun JDK 1.4 has a bug in the implementation of hasAttributeNS. This bug can be seen, when loading or importing a model from XML Schema, as either: * a null pointer exception, or * the error message Specify a valid XML Schema and try loading again. To avoid this problem use the IBM JDK 1.4 or either Sun or IBM 5.0 JDK. Another alternative is to add the Xerces or XML4J jar files to your classpath. These libraries can be found here: * XML4J: http://alphaworks.ibm.com/tech/xml4j * Xerces2-J: http://xml.apache.org/xerces2-j/download.cgi If you are experiencing this problem from within the Eclipse development environment, you will need to modify your Eclipse classpath. This can be achieved when starting Eclipse using the following command: eclipse-install-direclipse.exe -vmargs -Djava.endorsed.dirs=path-to-your-xerces-jars-folder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Selection of default service URIs based on URIs from the composite
ant elder wrote: On Nov 30, 2007 4:44 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 4:38 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:46 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:09 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri= http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t: binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc / /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t: binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom / /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t: binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc / /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant I think we can be relatively consistent using the three sources of endpoint information I put in the original mail.Now I think about it there is a number 4 that I didn't include so the list would be. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you
Re: SCADefinitions - definitions.xml file
Venkata Krishnan wrote: Hi, The Assembly and Policy Fwk specs mention that domain-wide definitions such as policy intents, policysets, binding type defns, impl type defns all defined in a 'global, domain-wide file' named. definitions.xml A single domain wide file with all definitions may not play well with extensibility. Here are some cases which seems to necessitate the existence of several definitions.xml file the contents of which could all be aggregated into a single bunch of 'domain wide definitions'. 1) For every binding / impl type in the domain there is a definition in the definitions.xml for the intents supported by the binding/impl. So whenever a new binding/impl is addeded the definitions.xml needs to be edited 2) Application Policy Administrators typically define policysets for various intents including the set of standard intents as specified by the specs such as confidentiality, integrity and authentication for the security domain. The administrator defines these policysets typically in the definitions.xmlfile. Should the administrator also be encumbered with having to add the definitions for the standard intents as well or should the administrator be actually editing the file we are going to package and making application additions there? So it seems to me that there are two options... i) Have a single definitions.xml file in our domain module and expect that it be edited for every new binding/impl type and then by application adminsitrators for application specific things ii) Allow each binding/impl type to have its own definitions.xml file and also allow contributions to have a definitions.xml file and then aggregate all of these definitions. I am convinced about about option (ii) and am looking at making the changes for this unless people have serious objections. Can folks in the specs group provide their perspective to this ? Thanks - Venkat My 2c. Let's develop the bigbank-secure scenario. We're gonna bump into this right away with the scenario. Let's see what makes sense then in the light of the concrete scenario. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 4:44 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 4:38 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:46 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:09 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri= http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t: binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc / /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t: binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom / /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t: binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc / /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the
Re: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 2:09 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant I think we can be relatively consistent using the three sources of endpoint information I put in the original mail.Now I think about it there is a number 4 that I didn't include so the list would be. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell
[SDO C++] Escaping special characters in XML
I've uploaded a proposed patch for http://issues.apache.org/jira/browse/TUSCANY-1553. Please take a look. It runs all the PHP regression tests without problems, and also makes the uploaded test run clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant
Selection of default service URIs based on URIs from the composite
We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon
[jira] Updated: (TUSCANY-1553) XML characters are not escaped by XMLHelper.
[ https://issues.apache.org/jira/browse/TUSCANY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1553: -- Attachment: tuscany-1553.patch Herewith a proposed patch for this issue. I have not delved into the issues with the previous attempt, but started out anew. This patch runs all regression tests for the PHP project without problems. XML characters are not escaped by XMLHelper. Key: TUSCANY-1553 URL: https://issues.apache.org/jira/browse/TUSCANY-1553 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: All Reporter: Albert Krzymowski Fix For: Cpp-Next Attachments: tuscany-1553.patch XML charactres are not escaped. In case of all string based data types SDOXMLWriter uses xmlTextWriterWriteRaw instead of xmlTextWriterWriteString. Is it related to this comment in SDOXMLWriter::writeXMLElement ? /* A more complex version that doesn't work! ... Shall we assume a string content at least ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1553) XML characters are not escaped by XMLHelper.
[ https://issues.apache.org/jira/browse/TUSCANY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1553: -- Component/s: C++ SDO XML characters are not escaped by XMLHelper. Key: TUSCANY-1553 URL: https://issues.apache.org/jira/browse/TUSCANY-1553 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: All Reporter: Albert Krzymowski Fix For: Cpp-Next XML charactres are not escaped. In case of all string based data types SDOXMLWriter uses xmlTextWriterWriteRaw instead of xmlTextWriterWriteString. Is it related to this comment in SDOXMLWriter::writeXMLElement ? /* A more complex version that doesn't work! ... Shall we assume a string content at least ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Convert from DB Schema to model XSDs
After discussing how further to integrate with SDO tools, I will work on those changes. Meanwhile, created a plugin with goal - generate, phase - generate-resources under - tuscany-das-plugin Also, tested same to be working by creating a test under tuscany-das-tools-test. Following this structure similar to what is there in SDO. Please see if you have any comments on this structure, else will do the check-ins. Regards, Amita On Nov 30, 2007 11:30 AM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Let me try to understand this more clearly. The tool checked in under das-tools does 2 things 1) it just wraps Apache Torque to introspect DB SChema to dump it into a simple XML file - this is entirely Torque functionality, already in use by Torque users 2) it directly uses DB Connection via Torque (to first get the XML as in and further processes it) to form SDO Model XSDs 3) It optionally can use the XML file from 1) and form SDO Model XSDs. So this tool is capable of genrating SDO Model XSDs without any dependency on SDO and with dependency on Torque. May be the appropriate place for this tool is under sdo-tools rather than das-tools as it does not as such do any Data Access, but this tool is RDB centric and SDO has nothing to do with the nature of data source, whether it is DB or XML or...so I tried to keep it under das-tools. When you say use SDO Tools to generate Static SDO, do you mean Static SDO Objects or static SDO Model XSDs? Static Model XSDs are already generated by das-tool ( and as I mentioned in last mail's exception stack trace, there are exceptions thrown in XSDHelper.generate() method when I tried the path DB-RDB DAS Code Reuse to form in-mem SDOType - XSDHelper.generate() and so tried using Torque. Thus instead of dependency on SDO and EMF both , das-tools has dependency only on Torque). TypeHelper or HelperContext from SDO provide a way to register Static Types provided through XSDs in the Context and form SDO Instance Objects from these. The tool under tuscany-das-tools can be further integrated with this SDO feature to get the Object Instance of Static SDO Types using TypeHelper / HelperContext to first register the Types stated in the Static Model XSD formed by tuscany-das-tool. Is this what you are proposing? This further integration can result into - a use generate option (XSD2JavaGen) from sdo-plugin/tool to generate interfaces and impls of Types stated in SDO Model XSDs, as we do right now in rdb-das for config.xsd, company.xsd...during mvn compile. With this during mvn compile phase, if the DB connection is available OR if the torque based schema.xml of DB is available, the user will be able to get Static SDO Types interfaces/impls code generation along with auto generation of SDO Model XSDs. b also some util methods like createDataObject(DOName) can be supported. a and b is already available using SDO Tools, so it will be just integrating it with das-tool to help in end-to-end support for- DB2JavaGenerator (on same lines as XSD2JavaGenerator) and methods like DataObject DB2XSDGenerator.createDataObject(Name) Please let me know your comments. Regards, Amita On Nov 29, 2007 8:31 PM, Luciano Resende [EMAIL PROTECTED] wrote: I guess that the main scenario for trying to create XML schema from DB schema is when one wants to create Static SDO from a DB Schema ? Am I right ? In this case, the user will have to use a DAS tool that understand the store schema, and then SDO tools to generate the Static SDO. Would it make sense to try to enhance the user experience and integrate the two, and the user could only run the SDO tools that would introspect the database schema when creating the Static SDO ? Thoughts ? What the SDO community think about this ? On Nov 29, 2007 3:54 AM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Please see the checkins under JIRA-1923, Rev 599394 In-progress- maven plugin creation and assembly file changes to include tools in distribution Regards, Amita On Nov 29, 2007 4:36 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: When trying for tool to convert from DB Schema to SDO Model xsds - tried using SDO's XSDHelper in one attempt and Apache Torque in another. 1) When using XSDHelper --- Tried using XSDHelper.generate () to take as input param the SDO created by DAS using its dynamic DO creation approach. Saw that when there is a SDO which contains child DO (like Table STATES will contain table CITIES), it was giving below exception originating from EMF - java.lang.IllegalArgumentException: The 'no duplicates' constraint is violated java.lang.IllegalArgumentException: The 'no duplicates' constraint is violated at org.eclipse.emf.common.util.BasicEList.add (BasicEList.java :642) at org.eclipse.xsd.impl.XSDNamedComponentImpl.addToSortedList(
Re: Data transformation from/to POJO
Giorgio Zoppi wrote: 2007/11/29, Simon Nash [EMAIL PROTECTED]: Giorgio Zoppi wrote: 2007/11/28, Jean-Sebastien Delfino [EMAIL PROTECTED]: Giorgio Zoppi wrote: One of the first problem that i had, when I started using Tuscany, was that I was serialize something without a mapping, because I wanted that a job was something more generics possible, i couldn't. I'm not sure I understand what you mean by serialize something without a mapping? Isn't there always a mapping like: - Java serialization - mapping between Java Objects that implement Serializable and bytes, as specified in the Java Object Serialization specification at http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html or - XML serialization - mapping between Java Objects that follow specified patterns and XML, as specified (for example) in the JAXB specification at http://java.sun.com/xml/downloads/jaxb.html or - Java support for Externalizables - mapping between Java Objects and whatever protocol the implementor of the read/writeExternal methods decides to implement, again here somebody needs to describe and publish that mapping if he wants a chance to talk to other components, or at least publish the mapping between the bytes read/written and a known type system. Can you say a little more about what you were trying to do and the specific issues that you ran into? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Java Serialization ala Serializable, for mapping I wanted to say: xml mapping ala JAXB. At that time, I thought that a simple POJO, was serialized by the SCA's runtime, over web services. In our dept. we've a java tool (muskel, see www.di.unipi.it/~marcod/Papers/Parco05.ppt) that serializes Jobs via RMI, and I wanted to do something similar, without any XML mapping. Thanks, Giorgio. Tucsany SCA Java includes an RMI binding. This should do what you want. Can you use that instead of the Web Service binding? Yes, but my requirement was doing something over ws, in order to test its scalability. And I'm planning scalability testing with Apache JMeter for end of the next week, when my workpool application will be ready. It's a workpool that sampling the load on each jvm adds or remove workers component. Cheers, Giorgio. I looked at the slides you pointed to, interesting stuff! I have a few questions. You mentioned serializing Jobs. Looking at this example from slide 25: Compute mainProgram = new Farm(new doSweep()); ParDegree parDegree = new ParDegree(Integer.parseInt(args[0])); ApplicationManager manager = new ApplicationManager(mainProgram); manager.setContract(parDegree); manager.inputStream(args[1]); manager.evalToFile(args[2]); In that example, what is the object representing the Job that's going to be serialized over the network (and I guess sent to a Worker)? Farm? DoSweep? or ParDegree? What are the main characteristics of the Job objects? Do they have a static structure defined by an application developer (like for example a Customer info, an Account info, or StockQuote info object?)? Or are they references to files containing parameter data for programs that will execute on your Grid? Or are they more like dynamic structures not formally defined by the application developer, like An instance of an anonymous class implementing java.lang.Runnable plus all the final local variables in its scope? Now a different category of questions: What are you flowing through your Web Service right now? Are you serializing Java objects into bytes and then tunneling the bytes in a Web Service call? Have you defined a WSDL portType for your Web Service? Why are you using Web Services? Is your environment just Java or are you integrating with other languages? I'm asking because slide 23 mentions WS and any OS with Java together and slide 29 mentions C, C++ etc. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is this base domain URI about? was: Selection of default service URIs based on URIs from the composite
ant elder wrote: On Nov 30, 2007 5:19 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant IMHO the URI info should come from an SCA composite. Any departure from that will lead to the definition of a new configuration model for these things, stranger to SCA. Could you explain this a bit more? Would that mean composites MUST include an absolute URI as in the example at the start of this thread? How does that relate to line 2357 of the assembly spec that says An SCA domain should define a base URI for each 2358 hierarchical URI scheme on which it intends to provide services.? ...ant Line 2357 is interesting. Let me try to describe (with two use cases) how I envision that domain base URI being used. 1. Mycompany.com is a medium size business and has defined one SCA
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Venkata Krishnan wrote: Hi, Heres what I am intending to do for the secure-bigbank into which I have copied over the exiting calculator, stockquote and account demos into secure-bigbank... Could you commit that? it doesn't have to work, I'm sure it's going to take a few weeks before it does, but that'll allow everybody to take a look. I'd suggest to have multiple modules similar to the existing module structure and in addition to that split the account module in three (account, savings-accountdata and checking-accountdata) representing different divisions in the bank. - The Calculator and StockQuote services need to exchange data that cannot be tampered with since the AccountService heavily 'relies' on their results. So interaction with these two services should have 'integrity'. I don't think there is a need for authentication or confidentiality for the interactions with these services. Yes makes sense - The AccountData service is right now accessed only by the AccountService. I'd like to open this out and put in the following security constraints :- - just keep authentication when accessed from the AccoutService locally say over binding.sca - enforce authentication, confidentiality and integrity when accessed from outside say over binding.ws OK - Finally the AccountService should enforce authentication, confidentiality and integrity. Does this sound ok ? Sounds good. More ideas will probably pop up as the scenario matures, but I can think of two other dimensions to this: - Use different confidentiality levels between divisions of the bank and communication with the external world. - Think about the security aspects of the JSP that implements the UI. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ClassNotFoundException in domain for application classes when registering a remote node
I'm getting the exception below when i try to register a contribution in a node thats running in a separate JVM from the domain. Does this mean all contributions in nodes also need to be in the classpath used by the domain? INFO: Registered node: http://localhost:8080/tuscany/ at endpoint http://L32H83W:8080/tuscany//SCANodeManagerComponent/SCANodeManagerService 30-Nov-2007 13:46:23 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterContribution SEVERE: Exception when registering contribution C:\Tomcat\apache- tomcat-6.0.10\webapps\sample-helloworld-ws-service-webapp\org.apache.tuscany.sca.domain.DomainException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl ...ant
Re: ClassNotFoundException in domain for application classes when registering a remote node
On Nov 30, 2007 1:50 PM, ant elder [EMAIL PROTECTED] wrote: I'm getting the exception below when i try to register a contribution in a node thats running in a separate JVM from the domain. Does this mean all contributions in nodes also need to be in the classpath used by the domain? INFO: Registered node: http://localhost:8080/tuscany/ at endpoint http://L32H83W:8080/tuscany//SCANodeManagerComponent/SCANodeManagerService 30-Nov-2007 13:46:23 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterContribution SEVERE: Exception when registering contribution C:\Tomcat\apache- tomcat-6.0.10\webapps\sample-helloworld-ws-service-webapp\org.apache.tuscany.sca.domain.DomainException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl ...ant Yes, the domain reads the contribution to build the domain model. - we don't at the moment have a mechanism of moving contributions physically between domain/node or node/domain. Only the id and location is passed. A shared filesystem is assumed. - we could relax this restriction when you add a contribution to a node but we would still need to pass the model back to the domain somehow. Would require work. In your case when you drop the contribution (war/jar?) into the web app container what do you provide as the contribution URL? Can we make sure that is an absolute URL and make sure that the domain can see it? Simon
Re: ClassNotFoundException in domain for application classes when registering a remote node
On Nov 30, 2007 2:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:50 PM, ant elder [EMAIL PROTECTED] wrote: I'm getting the exception below when i try to register a contribution in a node thats running in a separate JVM from the domain. Does this mean all contributions in nodes also need to be in the classpath used by the domain? INFO: Registered node: http://localhost:8080/tuscany/ at endpoint http://L32H83W:8080/tuscany//SCANodeManagerComponent/SCANodeManagerService 30-Nov-2007 13:46:23 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterContribution SEVERE: Exception when registering contribution C:\Tomcat\apache- tomcat-6.0.10\webapps\sample-helloworld-ws-service-webapp\org.apache.tuscany.sca.domain.DomainException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl ...ant Yes, the domain reads the contribution to build the domain model. - we don't at the moment have a mechanism of moving contributions physically between domain/node or node/domain. Only the id and location is passed. A shared filesystem is assumed. - we could relax this restriction when you add a contribution to a node but we would still need to pass the model back to the domain somehow. Would require work. In your case when you drop the contribution (war/jar?) into the web app container what do you provide as the contribution URL? Can we make sure that is an absolute URL and make sure that the domain can see it? Simon I see. I think it is using an absolute URL, (the error message above includes it), maybe the problem is the contribution URL is to the webapp root folder but the classes are inside that in the WEB-INF\classes directory so the don't get found. ...ant
Re: Using security policies in the Bigbank scenario, was Re: Policy Framework Scenarios.
Hi, Going ahead, I am starting with the calculator service. Since we have our calculator service hosted as an rmi service, I have started to look into how security could be provided in an RMI Binding. - Venkat On Nov 30, 2007 1:17 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Heres what I am intending to do for the secure-bigbank into which I have copied over the exiting calculator, stockquote and account demos into secure-bigbank... - The Calculator and StockQuote services need to exchange data that cannot be tampered with since the AccountService heavily 'relies' on their results. So interaction with these two services should have 'integrity'. I don't think there is a need for authentication or confidentiality for the interactions with these services. - The AccountData service is right now accessed only by the AccountService. I'd like to open this out and put in the following security constraints :- - just keep authentication when accessed from the AccoutService locally say over binding.sca - enforce authentication, confidentiality and integrity when accessed from outside say over binding.ws - Finally the AccountService should enforce authentication, confidentiality and integrity. Does this sound ok ? After an iteration with interaction policies, I'll start working on some implementation policies. For example having 'authorization' enforced on the AccountDataService's operations. Thanks - Venkat On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Hi, I propose to add the following to the BigBank scenario too to cover transaction policies and JMS binding. 1) Have separate components to represent the SavingsAccountService and CheckingAccountService. The two services will be backed by two different resource managers (Database or JMS queue). Please see the code at [1] and diagrams at [2]. 2) Add a TransferService to transfer money between accounts. The operations will be executed in a global transaction. 3) The TransferService will be exposed over binding.jms. The request of money transfer from the web front will be served by the TransferService over JMS. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies Thanks, Raymond Sounds good to me. The other aspect that this scenario will allow us to explore is interaction between the JMS binding and databindings (as Bigbank flows complex types). I'd suggest to work on these two versions of Bigbank in parallel in different modules: a) secure bigbank with security policies b) reliable transfers with JMS and transactions i.e. two different copies of BigBank. And then bring the two together at some point later. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1553) XML characters are not escaped by XMLHelper.
[ https://issues.apache.org/jira/browse/TUSCANY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1553: -- Attachment: Tuscany-1553.phpt OK, so you need php to run this test, but just viewing the test source shows the behaviour of this patch quite clearly, so it may be helpful XML characters are not escaped by XMLHelper. Key: TUSCANY-1553 URL: https://issues.apache.org/jira/browse/TUSCANY-1553 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: All Reporter: Albert Krzymowski Fix For: Cpp-Next Attachments: tuscany-1553.patch, Tuscany-1553.phpt XML charactres are not escaped. In case of all string based data types SDOXMLWriter uses xmlTextWriterWriteRaw instead of xmlTextWriterWriteString. Is it related to this comment in SDOXMLWriter::writeXMLElement ? /* A more complex version that doesn't work! ... Shall we assume a string content at least ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 2:46 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:09 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant I think we can be relatively consistent using the three sources of endpoint information I put in the original mail.Now I think about it there is a number 4 that I didn't include so the list would be. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what
Re: Selection of default service URIs based on URIs from the composite
On Nov 30, 2007 4:38 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:46 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 30, 2007 2:09 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant I think we can be relatively consistent using the three sources of endpoint information I put in the original mail.Now I think about it there is a
Re: Data transformation from/to POJO
Simon Nash wrote: Mike Edwards wrote: Folks, I have some suggestions here: Jean-Sebastien Delfino wrote: snip I prefer to have consistent rules (with respect to what the business objects can look like or must implement) between a remotable interface bound to an XML-based binding and a remotable interface used for in-VM communication. Different rules make it confusing or impossible to rewire your application without changing your business objects. +1 - I agree with consistency of rules. The SCA specs DO define two different cases, and I would accept the idea of the rules being deliberately different between those two cases: a) Local interfaces b) Remote interfaces I think the discussion so far has really been about remote interfaces. I am strongly in support of Jean-Sebastien's view that you should get the same behaviour for remote interfaces wherever the target service happens to be located. Since in-memory cloning is not possible for remote targets, it should not be ever be used for remote interfaces. For Local interfaces, the game is very different. In this case, you always know that the target is in the same VM. So, for these types of interface behaviour can be very different - as far as simply sending in the original objects. I ran into this right away in step 2 of the store tutorial (merger). The Item bean was working well over XML, but broke when I tried to pass it through an in-VM call (see the wire between Catalog and FruitsCatalog in store-merger.composite). Another alternative to using Java serialization is to write an in-memory reflective cloning function. This would probably be more efficient than serialization, would not require java.io.Serializable, and should be able to support pretty much any Java object. But what happens when the target is remote?? I think this discussion is only about the case of a remotable interface that is invoked with a local target, and therefore some kind of pass by value copying needs to be used. See my previous post today on this, which explains the compatibility issues in more detail. The pass by value copying needs to be consistent (with respect to what it can copy, what is potentially lost in the copying, the patterns and data representations that it supports) with the case when the remotable interface is mapped to WSDL/XSD and used over a networked interaction when data flows as XML compliant with that WSDL+XSD. So, we can invent 3 different algorithms to do that copy but if they give different results than what JAXB or SDO would have done, we're not helping the application developer, we're just creating confusion. With respect to RMI friendly interfaces and EJB remote interfaces, I think you've uncovered an issue in the SCA specs: EJB session bean remote interfaces are not always mappable to WSDL/XSD, they can flow data types that won't map to XSD types. So these interfaces will break with a WS binding, probably JSON as well, ATOM, and won't work with a BPEL or XQuery component for example. Basically, such interfaces do not meet the criteria for remotable interfaces defined by the assembly spec. On the other hand they need to be used as remotable interfaces on references and services configured with an EJB binding. I think that we should raise a spec issue for this and get the spec issue addressed first, instead of introducing different schemes for remotable interfaces and different mechanisms for copying data right now... and in the meantime support well a single consistent algorithm. Simon There's also the possibility of a hybrid approach, where we would use Java serialization if the object implements java.io.Serializable and some other approach (e.g., JAXB or cloning) if it doesn't. How about starting simple with one option that's consistent with the spec and really works instead of three that work differently? Yes, agree 100% Yours, Mike. - 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] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Selection of default service URIs based on URIs from the composite
ant elder wrote: On Nov 30, 2007 1:52 PM, Simon Laws [EMAIL PROTECTED] wrote: We have discussed this behaviour before and I was sort of convinced last time but now I'm playing with the store sample I'm not so sure. This features comes about because of the store composite, for example, component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component To keep the composite tidy many of the URIs are omitted and they rely on the default value. However the URI for one of the bindings is provided so that the node will detect this and use this as the default for all service bindings (where this kind of URI is applicable). All the bindings must be the same here as store.html relies on the services being accessible from the same root. There are several places that the default port for the servlet host comes from when setting up the SCA runtime. 1. The web app container. In this case no matter how you configure SCA you will get whatever the web app container gives you 2. Node URI. This is used to tell what endpoints SCA should use by default and also as a unique ID for the node. When running inside a web app this must be the host/port you expect the web app to expose your services on. Otherwise SCA can't tell what values the web app container is going to use and hence can't register services with the domain. In the case that SCA starts Tomcat/Jetty itself then the Node URI is just the default value that will be used if a URI is not provided explicitly on a binding. 3. Binding uri attribute. If SCA is running inside a web app container this value is ignored and Node URI is used (see 2). If SCA has started Tomcat/Jetty itself this value will be used to configure the endpoint of the service. If no value is provided then the default value is used (see 1 and 2). So what's the drawback of using component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And setting Node URI = http://localhost:8101 I'm uncomfortable about the current feature because I could easily include a component in front of the existing component, e.g. component nameSomeComponent implementation .../ service name=SomeService binding.ws url=http://localhost:8100/SomeService/ /service /component component name=Store t:implementation.widget location=uiservices/store.html/ service name=Widget t:binding.http uri=http://localhost:8101/ui/ /service reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart/Cart t:binding.atom/ /reference reference name=shoppingTotal target=ShoppingCart/Total t:binding.jsonrpc/ /reference /component And mess it up as now the majority services in the composite are at 8100 and not 8101 where store.html expects them to be. Regards Simon I agree. We've never come up with a very consistent story about default URLs that works well everywhere, would be great if we could as its always causing problems with getting all the runtimes and nodes and service endpoints working consistently everywhere. Can we change so that the ServletHost implementation controls the default base URL and have everything tries to use relative URLs with that? ...ant IMHO the URI info should come from an SCA composite. Any departure from that will lead to the definition of a new configuration model for these things, stranger to SCA. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition for sdo java faq?
+1. Raymond - Original Message - From: David Adcox [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, November 30, 2007 7:19 AM Subject: Addition for sdo java faq? After responding to Chris' issue in Tuscany-1925, it occurred to me that this will be an ongoing problem for folks trying to use Sun 1.4 JVMs. Looking back over the dev list history, I see a couple of other times where this has been a problem. Perhaps, we might want to add this to the faq, what do you think? Here's a first stab at the FAQ entry: Why am I getting an exception when using Apache Tuscany's java SDO implementation in a Sun JDK 1.4? The Crimson DOM implementation in (some versions of) the Sun JDK 1.4 has a bug in the implementation of hasAttributeNS. This bug can be seen, when loading or importing a model from XML Schema, as either: * a null pointer exception, or * the error message Specify a valid XML Schema and try loading again. To avoid this problem use the IBM JDK 1.4 or either Sun or IBM 5.0 JDK. Another alternative is to add the Xerces or XML4J jar files to your classpath. These libraries can be found here: * XML4J: http://alphaworks.ibm.com/tech/xml4j * Xerces2-J: http://xml.apache.org/xerces2-j/download.cgi If you are experiencing this problem from within the Eclipse development environment, you will need to modify your Eclipse classpath. This can be achieved when starting Eclipse using the following command: eclipse-install-direclipse.exe -vmargs -Djava.endorsed.dirs=path-to-your-xerces-jars-folder - 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: Ant Build Distribution System
OK, now I've added the same distribution funcionality to sdo project...an example of distribution task working on sdo project can be found here: [1]...of course it was necessary some minor changes on distribution task to fit on sdo project : ) Now, I think if everybody is ok with it, we could add this task also to sca subproject, otherwise, I will need some help with it, cause sca structure is a bit more complicated and I'm not used to...can you help me with that Brady? Adriano Crestani [1] http://people.apache.org/~adrianocrestani/sdo_distribution_example/http://people.apache.org/%7Eadrianocrestani/sdo_distribution_example/ On Nov 28, 2007 10:20 PM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, Sorry for the long time being inactive, but I'm back : ) I've got the ant build distribution generator signing correctly the packed files. I first tried out to call directly gpg using the exec task, but, unfortunately, during the gpg signing process it requires the password for the secret key to be input, otherwise, the exec task does not allow any input during its execution. So, I looked for another solution, and found the Apache Commons OpenPGP project that provides an ant task just to sign files using the gpg, then I compiled it and the generated the OpenPGP.jar that was added to das/antscripts/ folder. The OpenPGP.jar requires another 2 jars(described below) that should be download manually, I think it's ok, once OpenPGP.jar will only be used to sign the distributions and will not be included on the distributed files. Below the usage instructions, that was added to READ_ANT_INSTALL file, of the ant auto distribution system: GENERATING A PROJECT DISTRIBUTION = To create a src and bin distribution of Tuscany DAS subproject, there must be set some properties on platform.properties files: Property Required Example Description --- --- platform.public.key.path Yes E:/gnupg/trustdb.gpg The public key ring file path platform.secret.key.path Yes E:/gnupg/secring.gpg The secret key ring file path platform.key.id Yes 148CAFB2 The key id used to sign the distribution files platform.tuscanyDAS.distribution.dir NO C:\distribution\ The folder where the distribution files will be generated, default=tuscanyDAS.root.dir/distribution platform.tuscanyDAS.release.file.name NO tuscany_das_native-1.0-incubator-M4- The beginning of src and bin packed distribution file name, default=tuscany_cpp_das. TUSCANY_DASCPP_RELEASE_NAME env var may be used as an alternative Also is required the bcpg-jdklatest_version-latest_version.jar and jce-jdklatest_version-latest_version.jar files defines on classpath. Both can be found at http://www.bouncycastle.org/latest_releases.html Use the distribution target to generate the src and bin distribution file structure under platform.tuscanyDAS.distribution.dir folder. Then use the pack.distribution target to pack the bin and src distribution folders as .zip and .tar.gz and generate their .asc and .md5 files. A password must be set on the command line when using pack.distributiontarget, this password is used to sign the packed distribution files with the secret key defined on platform.secret.key.path Usage: ant distribution // do whatever you want on the generated distribution files ant pack.distribution -Dpassword=123456 The bad point in this system is that you have to type your password on command line, a bad practice once shells usually have a log file of all typed commands. I thought about a file, which contains the password, then the ant could read the password from this file...this way the password would not be typed on the command line, but I think it's a lot of work just to set a password :S...suggestions??? I have also updated the distribution example on [1]. I think next step is to create the NOTICE, LICENSE...files for das that are still missing :P [1] http://people.apache.org/ http://tr_1196323527526 ~adrianocrestani/das_distributi http://tr_1196323527526on_example/http://people.apache.org/%7Eadrianocrestani/das_distribution_example/%20 On Nov 14, 2007 1:10 AM, ant elder [EMAIL PROTECTED] wrote: On Nov 14, 2007 7:29 AM, Adriano Crestani [EMAIL PROTECTED] wrote: snip Luciano: Distribution artifact names : I'd follow the same naming of previous native releases [1] and use tuscany_das_cpp-1.0-incubator-M4-bin.zip I'm also not sure if the native project wants to start using incubating in the name, to follow the same pattern being used in the java releases. I think its currently incubating thats prefered these days,
