Re: [DAS] Transaction support
Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita
[RDB DAS] Consistent use of Parameters in Config
Hi, A few days ago there was a user question about passing name in Parameter:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg19339.html When checking how Parameters are used in Config, came across the following points. There is a difference in Config (SDO) generated Parameter and org.apache.tuscany.das.rdb.impl.ParameterImpl. The one from Config has only ColumnType, Direction and Index whereas in impl, it has in addition Name and some other attributes. Not having Name in Config generated version does not cause any problems anywhere as JDBC PreparedStatement setParameter() requires Index and not Name. But to give a consistent user experience, it can be good to add Name (Optional). Also, when supporting Create, Update, Delete in RDB DAS Config, the attribute parameters is String, which is internally interpreted in Index and Name. This misses the ColumnType and Direction.Direction can be safely assumed as IN for these statements. Also, not supplying ColumnType again causes no issues, as DAS tries to get it from database metadata or using SDO standards. Still here again, if user can specify ColumnType (optional), it will give a consistent user experiece. So, question here, for the sake of consistency and uniform user experience, is it a good idea to replace [1] with [2]? (Same for Update and Delete) [1]xsd:complexType name=Create xsd:attribute name=sql type=xsd:string/ xsd:attribute name=parameters type=xsd:string/ /xsd:complexType [2]xsd:complexType name=Create xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Parameter type=config:Parameter/ /xsd:sequence xsd:attribute name=sql type=xsd:string/ /xsd:complexType Regards, Amita
Re: Getting service manually through servlet
So, two questions : 1- Are you registering the tuscany servlet context listener to your web.xml file ? 2 - How are you contributing your contributions ? You might be having problems finding the root of the contribution or the deployables, please take a look at this [1] as a reference. [1] - http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Web+Application+Integration+Story On 7/12/07, Robert Young [EMAIL PROTECTED] wrote: I'm trying to find my way around with Tuscany being run inside Tomcat. I can successfully load my service using SCADomain.newInstance(search.composite); but I am coming across difficulties when I try to manually load it through org.apache.tuscany.sca.webapp.SCADomainHelper In my servlet context listener I call SCADomainHelper.initSCADomain(context); as the Tuscany context listener does, which successfully sets an instance of SCADomain as an attribute of my servlet context. However, when I come to load my service I get an org.osoa.sca.ServiceRuntimeException thrown with the message Component not found: ConfigurationServiceComponent. I am guessing that for some reason SCADomainHelper isn't finding my .composite file. I have this file in the root of my class directory as I believe it should be. Does anyone know why it is not being picked up or what the problem is? If I should be conforming to a particular naming convention for the .composite filename does anyone know that that is? Thanks Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting service manually through servlet
I think right now you have to use a META-INF/sca-contribution.xml file to point to your .composite files, you can see an example in one of the Tuscany samples, eg: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp/src/main/webapp/META-INF/. An alternative may be to place your .composite files in a META-INF/deployables folder, but I've had problems getting that to work. I think it would could be useful if when neither of those two things were done then any .composite files found got deployed, any one know why we can't do that? ...ant On 7/12/07, Robert Young [EMAIL PROTECTED] wrote: I'm trying to find my way around with Tuscany being run inside Tomcat. I can successfully load my service using SCADomain.newInstance(search.composite); but I am coming across difficulties when I try to manually load it through org.apache.tuscany.sca.webapp.SCADomainHelper In my servlet context listener I call SCADomainHelper.initSCADomain(context); as the Tuscany context listener does, which successfully sets an instance of SCADomain as an attribute of my servlet context. However, when I come to load my service I get an org.osoa.sca.ServiceRuntimeException thrown with the message Component not found: ConfigurationServiceComponent. I am guessing that for some reason SCADomainHelper isn't finding my .composite file. I have this file in the root of my class directory as I believe it should be. Does anyone know why it is not being picked up or what the problem is? If I should be conforming to a particular naming convention for the .composite filename does anyone know that that is? Thanks Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting service manually through servlet
I remember having similar discussions when we discussed web-app story. One issue I see here, when adding all composites as deployable, is that, in some phases of the development life-cycle you might have bad composites, and that would not cause any issues to your app, as these bad composites are not referenced or used. Using your suggestion, these composites would be promoted as deployables and would probably cause problems when deployed to the SCA Domain, right ? On 7/12/07, ant elder [EMAIL PROTECTED] wrote: I think right now you have to use a META-INF/sca-contribution.xml file to point to your .composite files, you can see an example in one of the Tuscany samples, eg: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp/src/main/webapp/META-INF/. An alternative may be to place your .composite files in a META-INF/deployables folder, but I've had problems getting that to work. I think it would could be useful if when neither of those two things were done then any .composite files found got deployed, any one know why we can't do that? ...ant On 7/12/07, Robert Young [EMAIL PROTECTED] wrote: I'm trying to find my way around with Tuscany being run inside Tomcat. I can successfully load my service using SCADomain.newInstance(search.composite); but I am coming across difficulties when I try to manually load it through org.apache.tuscany.sca.webapp.SCADomainHelper In my servlet context listener I call SCADomainHelper.initSCADomain(context); as the Tuscany context listener does, which successfully sets an instance of SCADomain as an attribute of my servlet context. However, when I come to load my service I get an org.osoa.sca.ServiceRuntimeException thrown with the message Component not found: ConfigurationServiceComponent. I am guessing that for some reason SCADomainHelper isn't finding my .composite file. I have this file in the root of my class directory as I believe it should be. Does anyone know why it is not being picked up or what the problem is? If I should be conforming to a particular naming convention for the .composite filename does anyone know that that is? Thanks Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RDB DAS] Consistent use of Parameters in Config
The named parameter support was removed from earlier versions of DAS, here is some previous discussion around the subject [1] See also tuscany-658. We might need to do further cleanup on the impl, if I understood correctly. As for your second suggestion (parameter column types), could you expose some use cases scenarios where this would be helpful ? Also, have you thought about multiple queries retrieving the same column, you would have to configure the parameter in multiple places. [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg04672.html [2] http://issues.apache.org/jira/browse/TUSCANY-658 On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, A few days ago there was a user question about passing name in Parameter:- http://www.mail-archive.com/[EMAIL PROTECTED]/msg19339.html When checking how Parameters are used in Config, came across the following points. There is a difference in Config (SDO) generated Parameter and org.apache.tuscany.das.rdb.impl.ParameterImpl. The one from Config has only ColumnType, Direction and Index whereas in impl, it has in addition Name and some other attributes. Not having Name in Config generated version does not cause any problems anywhere as JDBC PreparedStatement setParameter() requires Index and not Name. But to give a consistent user experience, it can be good to add Name (Optional). Also, when supporting Create, Update, Delete in RDB DAS Config, the attribute parameters is String, which is internally interpreted in Index and Name. This misses the ColumnType and Direction.Direction can be safely assumed as IN for these statements. Also, not supplying ColumnType again causes no issues, as DAS tries to get it from database metadata or using SDO standards. Still here again, if user can specify ColumnType (optional), it will give a consistent user experiece. So, question here, for the sake of consistency and uniform user experience, is it a good idea to replace [1] with [2]? (Same for Update and Delete) [1]xsd:complexType name=Create xsd:attribute name=sql type=xsd:string/ xsd:attribute name=parameters type=xsd:string/ /xsd:complexType [2]xsd:complexType name=Create xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Parameter type=config:Parameter/ /xsd:sequence xsd:attribute name=sql type=xsd:string/ /xsd:complexType Regards, Amita -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Java] Using complex types in the helloworld-ws-reference example
Hi, David.
It seems that you're doing the right steps. If you can attach your test case
into a JIRA, we can look into it.
Thanks,
Raymond
- Original Message -
From: David Haney [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 12, 2007 5:56 PM
Subject: [SCA Java] Using complex types in the helloworld-ws-reference
example
Hi all,
I'm attempting to modify the helloworld-ws-reference example so that it
is sending a complexType instead of simple types, and am having trouble
with an exception that I can't explain. I wasn't able to find an
example of this sort of thing in one of the other samples, so I've been
trying to piece together the necessary changes, and I'm guessing I've
just missed a step along the way.
Here's what I've done so far (all file references are relative to
installdir/samples/helloworld-ws-reference):
- Modified the src/main/resources/wsdl/helloworld.wsdl So that the
getGreetings operation contains a complexType:
...
element name=getGreetings
complexType
sequence
element name=name type=tns:Name/
/sequence
/complexType
/element
...
complexType name=Name
sequence
element name=first type=xsd:string/
element name=last type=xsd:string/
/sequence
/complexType
...
- Next, I code-generated the static SDO types based on the updated WSDL
file. I added the following to the root build.xml in order to generate
the types (I wasn't able to find the necessary code-generator tools in
the SCA distribution, so the following depends on an external SDO
distribution specified by the environment variable TUSCANY_SDO. I used
the tuscany-sdo-1.0-incubating-beta1 binary distribution for this test):
...
property environment=env/
target name=codegen depends=init
java classname=org.apache.tuscany.sdo.generate.XSD2JavaGenerator
fork=true
classpath
pathelement
path=${env.TUSCANY_SDO}/lib/tuscany-sdo-tools-1.0-incubating-beta1.jar
/
pathelement path=${env.TUSCANY_SDO}/lib/common-2.2.2.jar/
pathelement path=${env.TUSCANY_SDO}/lib/ecore-2.2.2.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/sdo-api-r2.1-1.0-incubating-beta1.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/tuscany-sdo-impl-1.0-incubating-beta1.jar/
pathelement path=${env.TUSCANY_SDO}/lib/ecore-xmi-2.2.2.jar/
pathelement path=${env.TUSCANY_SDO}/lib/xsd-2.2.2.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/ecore-change-2.2.2.jar/
pathelement path=${env.TUSCANY_SDO}/lib/codegen-2.2.2.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/codegen-ecore-2.2.2.jar/
/classpath
arg value=-targetDirectory/
arg value=src/main/java/
arg value=-javapackage/
arg value=helloworld/
arg value=src/main/resources/wsdl/helloworld.wsdl/
/java
/target
...
- This produced the following files in src/main/java/helloworld:
getGreetings.java
getGreetingsResponse.java
HelloworldFactory.java
Name.java
impl/getGreetingsImpl.java
impl/getGreetingsResponseImpl.java
impl/HelloworldFactoryImpl.java
impl/NameImpl.java
- Once these were in place, I modified HelloWorldService::getGreetings()
to take the new Name type:
...
public interface HelloWorldService {
public String getGreetings(Name name);
}
- and modified HelloWorldServiceComponent::getGreeting() to match:
...
public String getGreetings(Name name) {
System.out.println(Called getGreetings);
return helloWorldService.getGreetings(name);
}
- Finally, I modified HelloWorldServiceClient::main() to create a Name
instance, and pass it into the getGreetings() call.
...
Name name = HelloworldFactory.INSTANCE.createName();
name.setFirst(David);
name.setLast(Haney);
String value = helloWorldService.getGreetings(name);
...
- Once all of the code changes were in place, I went back to the
src/main/resources/helloworldws.composite file, and attempted to update
it so that it would recognize that it should be using the SDO binding:
dbsdo:import.sdo
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
factory=helloworld.HelloworldFactory/
- That seemed like it should be sufficient based on the
documentation/tests/demos/examples that I was able to find, however when
I attempt to run the application, I'm seeing the following output:
Buildfile: build.xml
run:
[java] log4j:WARN No appenders could be found for logger
(org.apache.axiom.om.util.StAXUtils).
[java] log4j:WARN Please initialize the log4j system properly.
[java] Injected helloWorldService
[java] Called getGreetings
[java] Exception in thread main org.apache.axiom.om.OMException:
java.util.NoSuchElementException: End of stream has reached.
[java] at
org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:2
11)
[java] at
org.apache.axiom.om.impl.llom.OMElementImpl.buildNext(OMElementImpl.java
:546)
[java] at
org.apache.axiom.om.impl.llom.OMSourcedElementImpl.buildNext(OMSourcedEl
ementImpl.java:744)
[java] at
Can anyone show me example of a simple scenario?
Hi, I want to achieve the following tasks in Tuscany. However, not quite sure which sample I really should look into. Can anyone point me to the right direction? I want to write implementation for two components where each component take one input and generate one output. Imagine that these components are generic function, therefore, composition of these components is done by writing the composite file, which wires component's service(as output) and reference(as input) together. is there any simple example for this scenario? In the Tuscany samples, such as bigbank, it seems to me that composite service needs to have knowledge about the component service they are going to reference. but in my case, I want all component to be generic, and be able to dynamically compose by defining the composite file of what components to use. not sure whether the SCA is a better way to do this? any idea or comment? -- regards; Peizhao - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can anyone show me example of a simple scenario?
Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: Peizhao Hu [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 12, 2007 7:44 PM Subject: Can anyone show me example of a simple scenario? Hi, I want to achieve the following tasks in Tuscany. However, not quite sure which sample I really should look into. Can anyone point me to the right direction? I want to write implementation for two components where each component take one input and generate one output. Imagine that these components are generic function, therefore, composition of these components is done by writing the composite file, which wires component's service(as output) and reference(as input) together. It seems that you want implement some mediation logic, am I right? You could define a generic interface or take advantage of the any interface (org.apache.tuscany.sca.interfacedef.Interface, if isDynamic() returns true). is there any simple example for this scenario? In the Tuscany samples, such as bigbank, it seems to me that composite service needs to have knowledge about the component service they are going to reference. but in my case, I want all component to be generic, and be able to dynamically compose by defining the composite file of what components to use. What are the criteria for your composition? SCA spec defines the wiring between a component reference and component service by the interface compatibility. Components can also be autowired by the runtime. Do you just want to programatically wire the components together or do you expect the Tuscany runtime to wire things based on the metadata (such as business semantics, service-level agreement)? not sure whether the SCA is a better way to do this? any idea or comment? -- regards; Peizhao - 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]
