Re: itests: There are no tests to run
Surefire is configure to run test based on the following criteria : include**/*TestCase.java/include The test case java file must match the criteria above, and to take a concrete example (java/sca/itest/callback-api), you can see that the test case is named as CallBackApiTest.java and will not be picked up by surefire, that's why you see the message of no tests to run : --- T E S T S --- There are no tests to run. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 On 8/12/07, venu reddy [EMAIL PROTECTED] wrote: I am trying to execute itests from itest folder with mvn. Everything went fine without any errors including the sample itest that we are trying to write. However I have observed that, while trying to execute itests from each itest folder, for few folders it says There are no tests to run. What does this mean, are those tests incomplete?, or am I missing something here?. Thanks, Venu. -- 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: I think Tuscany needs a graph generator for composite layouts
Take a look at this post on Tuscany blog : http://apache-tuscany.blogspot.com/2007/07/sca-tooling.html Looks like the tooling project mentioned there has the ability to introspect components from your workspace, and give you a visual representation of your composite On 8/12/07, shaoguang geng [EMAIL PROTECTED] wrote: as the title, when composite contents comes more and more complicated, a layout graph generator would do greate help to developers. Or did some one see commercial providers of such a grapher? Good day. - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. -- 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: mvn eclipse:eclipse fails on java
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ole Here is what I tried, and all went OK 1.Removed .m2\repository\org\apache\tuscany 2.svn update to revision #565235 3.cd %tuscany_home%\java 4.mvn -U -fn clean install java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Maven version: 2.0.5 -- If you have a higher version, I'd recommend trying with 2.0.5 [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 48 minutes 3 seconds [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007 [INFO] Final Memory: 61M/63M [INFO] On 8/12/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi Simon, Simon Laws wrote: I note from your other post that you are having problems with the full build with JDK1.6. Is it possible for you to try with 1.5 as this is known to work? We can then isolate JDK issues from these more general build issues. Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it made it this far (I also disabled SELinux to make sure nothing funky was happening): --- T E S T S --- Running supplychain.SupplyChainClientTestCase In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer is [Proxy - f6438d] java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.felix.framework.Felix.loadBundleClass(Felix.java :1422) at org.apache.felix.framework.BundleImpl.loadClass( BundleImpl.java:335) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService (OSGiImplementationProvider.java:773) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle (OSGiImplementationProvider.java:873) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle (OSGiImplementationProvider.java:326) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance (OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget (OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke (OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke( RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke( AbstractInvocationHandler.java:145) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:75) at $Proxy7.purchaseGoods(Unknown Source) at supplychain.SupplyChainClientTestCase.test( SupplyChainClientTestCase.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run( OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at
Calling XSD2JavaGenerator from ANT
I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- 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: Calling XSD2JavaGenerator from ANT
Hi, The observed behaviour is the documented behavior of Ant arg value=key1/ arg value=value1 means there are two separate command-line arguments i.e. args.length=2 Is different from arg value=key1 value1/ Which means there is one command-line argument of value key1 value1. The non-recommended approach to emulate the two-argument behaviour is arg line=key1 value1/ Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 1:51 AM To: tuscany-dev Subject: Calling XSD2JavaGenerator from ANT I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- 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] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Relationship info using DBMS Metadata getCrossReference() - pros and cons?
(Prev mail thread:- http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20770.html) More on this... Looks like, single table registry approach was taken to dump all rows fetcted from database without linking DataObjects, as there is no relationship information in DAS Config. So, from the above mail thread, as join between singer and song returns 3 rows, there were 3 singer DOs and 3 song DOs and it is user's responsibility to see that out of 3 singer DOs 2 are actually identical. So question here is...can DAS use DatabaseMetadata.getCrossReference() JDBC API to form relationship information when it is missing in DAS Config. To keep matter simple, DAS can take approach of using DAS Config relationship info as first priority and DatabaseMetadata.getCrossReference() as next priority. In case queries involve tables where for some relationship is defined in DAS Config and for some it is not, DAS can just stick to DAS Config. i.e. avoid mixing DAS Config provided relationship info and DBMS provided relationship info. Whatever is the approach (we can take mixed approach too, for that matter), it just needs to be documented clearly. DAS - from the basic usage so far, promotes less config and thus uses DBMS Metadata info for tables and columns when one is not available in DAS Config. So same can be extended for Relationships too. Are there any known issues around usage of DatabaseMetadata.getCrossReference()? Checked for Derby, MySQL so far and found no issues. Also, if some vendor do not have implementation for this method, we can detect exception/null/empty ResultSet returns and continue the way we are at present using SingleTableRegistry. Comments? Regards, Amita
Re: [DAS] Transaction support
-When connection is provider by caller(say container), there is no meaning of managedtx attribute, and it is better to let the caller handle the transactionality of the operations. So, when DAS is instantiated using external connection - mandate managedtx = false. Also, expose getConnection() from DAS to give a ref. of the connection (User already owns it, DAS is just providing ref.). DAS will not issue any commit/rollback -When connection is created internally, managedtx has a meaning. 1When false, DAS.getConnection() should be exposed and user should be allowed to handle transactions. DAS should not issue any commits/rollbacks 2When true, do not expose DAS.getConnection(). If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit /rollback per command). If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to manager group of commands as a sigle transaction).Here, DAS at the simplest can use a static FLAG set/unset using methods - void DAS.startTransaction(), //mark FLAG to set - void DAS.endTransaction(commit/rollback). //mark FLAG to reset endTransaction() will issue commit/rollback based on arg passed to it. For any exception condition DAS will issue rollback() on transaction and will reset the FLAG. Client needs to call start/endTransaction() for group of Commands. Also, here for timeout impelmentation, Java Timer can be used. Regards, Amita On 8/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, I think it can be useful to bunch commands, but I didn't get how you are planning to do it : ( What would be the parameter of method getTransaction? Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: 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.
Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible
Brady Johnson (JIRA) wrote: Tuscany SDO native for windows is not msvc backwards compatible Don't I know it. In the PHP project the automated build servers for Win use VC6, so we are obliged to use that compiler in the SDO for PHP project. Since the Tuscany team decided to support only VC8, I usually find some minor problems porting the code over - you'll find a trail of these in the issues database where I've sent the fixes back as patches. It's not really a big problem, more an inconvenience. However it was a policy decision by the Tuscany committers at the time. YMMV. Again, with the localtime behaviour, this came from concerns about using non-reentrant versions of localtime(). You may not have noticed the SDOUserMacros.h file - this mechanism was introduced so that consumers of Tuscany C++ could adapt the macros to their environment. You can see the PHP version here: http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=markup It would be helpful if you would keep this mechanism in place. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] Tuscany SCA Native for Windows is not msvc backwards compatible
I've applied 1529 and 1530. Cheers, On 10/08/07, Brady Johnson [EMAIL PROTECTED] wrote: Hello all, I created a JIRA for this compilation issue and have already uploaded a patch. Can someone submit it please. https://issues.apache.org/jira/browse/TUSCANY-1530 Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDOFactory: NoClassDefFoundError.
Hi All, I am trying to read out an XML file by using your library files (tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my Websphere process server lib folder as well I set all the tuscany jar's in my class path. Still, I am experiencing the below error. YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED. [8/13/07 13:30:19:616 IST] 005a ExceptionUtil E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method transactionNotSupportedActivitySessionSupports on bean BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null). Exception data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory at org.apache.tuscany.sdo.impl.FactoryBase.clinit(FactoryBase.java:225) at org.apache.tuscany.sdo.model.ModelFactory.clinit(ModelFactory.java:41) at org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper Impl.java:63) at org.apache.tuscany.sdo.helper.TypeHelperImpl.init(TypeHelperImpl.java: 81) at org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl .java:64) at org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.init(DefaultHel perContextImpl.java:31) at org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He lperProviderImpl.java:37) at org.apache.tuscany.sdo.spi.HelperProviderBase.init(HelperProviderBase. java:81) at org.apache.tuscany.sdo.helper.HelperProviderImpl.init(HelperProviderIm pl.java:30) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA ccessorImpl.java(Compiled Code)) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons tructorAccessorImpl.java(Compiled Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at java.lang.Class.newInstance3(Class.java(Compiled Code)) at java.lang.Class.newInstance(Class.java(Compiled Code)) at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1 57) at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126) at commonj.sdo.impl.HelperProvider.clinit(HelperProvider.java:69) at commonj.sdo.helper.XMLHelper.clinit(XMLHelper.java:200) at sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav a:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe flectionAdapter.java:138) at com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe ssage(JavaImplementationHandler.java:258) at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag e(MessageDispatcherImpl.java:386) at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM essageImpl.java:476) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo duleSessionBean.java:335) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor tedActivitySessionSupports(ModuleSessionBean.java:276) at com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja va:199) at com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.transactionLocalActi vitySessionAny(UOWStrategyImpl.java:406) at com.ibm.ws.sca.internal.uow.handler.UOWAttribute.invoke(UOWAttribute.jav a:478) at com.ibm.ws.sca.internal.uow.handler.AbstractUOWHandler.processMessage(Ab stractUOWHandler.java:162) at com.ibm.ws.sca.internal.uow.handler.UOWHandler.processMessage(UOWHandler .java:81) at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag e(MessageDispatcherImpl.java:397) at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM essageImpl.java:476) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo duleSessionBean.java:335) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor tedActivitySessionNotSupported(ModuleSessionBean.java:284) at com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio nNotSupportedActivitySessionNotSupported(EJSLocalStatelessModule_4313289 2.java:131) at com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.joinTransactionFalse JoinActivitySessionFalse(UOWStrategyImpl.java:240) at
Re: Release management for next release, was: SCA 0.92 release?
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Simon Laws wrote: +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. We could probably get a stable distribution available on the 20th, and we would check that. That sounds like a good plan, i'll continue with some tidy up this week aiming to get distribution out for the 20th. ...ant
Metadata related to extension types
Hi, The Assembly Model specs mentions the 'need' for definitions of metadata related to implementation and binding extensions types as follows: 2665 In addition to the definition for the new implementation instance element, there needs to be an 2666 associated implementationType element which provides metadata about the new implementation 2667 type. The pseudo schema for the implementationType element is shown in the following snippet: 2668 implementationType type=xs:QName 2669 alwaysProvides=list of intent xs:QName 2670 mayProvide=list of intent xs:QName/ 2749 bindingType type=xs:QName 2750 alwaysProvides=list of intent QNames? 2751 mayProvide = list of intent QNames?/ This metadata is supposed to be defined in definitions.xml file as defined on page 57, section title SCA Definitions. Since I am having to address the definitions.xml file as part of the policy framework implementation, I have included model and processors for implementationType and bindingType elements within the policy and policy-xml modules. But I guess this has to move out to a place that typically deals with 'domain' related things in general. Could people share some thoughts on this please ? Thanks - Venkat
[Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]
Original Message Subject: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible Date: Mon, 13 Aug 2007 10:57:44 +0100 From: Caroline Maynard [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Newsgroups: gmane.comp.apache.webservices.tuscany.devel References: [EMAIL PROTECTED] Brady Johnson (JIRA) wrote: Tuscany SDO native for windows is not msvc backwards compatible Don't I know it. In the PHP project the automated build servers for Win use VC6, so we are obliged to use that compiler in the SDO for PHP project. Since the Tuscany team decided to support only VC8, I usually find some minor problems porting the code over - you'll find a trail of these in the issues database where I've sent the fixes back as patches. It's not really a big problem, more an inconvenience. However it was a policy decision by the Tuscany committers at the time. YMMV. Again, with the localtime behaviour, this came from concerns about using non-reentrant versions of localtime(). You may not have noticed the SDOUserMacros.h file - this mechanism was introduced so that consumers of Tuscany C++ could adapt the macros to their environment. You can see the PHP version here: http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view=markup It would be helpful if you would keep this mechanism in place. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Metadata related to extension types
On 8/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, The Assembly Model specs mentions the 'need' for definitions of metadata related to implementation and binding extensions types as follows: 2665 In addition to the definition for the new implementation instance element, there needs to be an 2666 associated implementationType element which provides metadata about the new implementation 2667 type. The pseudo schema for the implementationType element is shown in the following snippet: 2668 implementationType type=xs:QName 2669 alwaysProvides=list of intent xs:QName 2670 mayProvide=list of intent xs:QName/ 2749 bindingType type=xs:QName 2750 alwaysProvides=list of intent QNames? 2751 mayProvide = list of intent QNames?/ This metadata is supposed to be defined in definitions.xml file as defined on page 57, section title SCA Definitions. Since I am having to address the definitions.xml file as part of the policy framework implementation, I have included model and processors for implementationType and bindingType elements within the policy and policy-xml modules. But I guess this has to move out to a place that typically deals with 'domain' related things in general. Could people share some thoughts on this please ? Thanks - Venkat Hi Venkat These all seem to be policy related apart from sca:binding which, if I understand it correctly, allows binding definitions to be pre defined for a domain. I think we have three places that do domain kinds of things. host-embedded distributed (am just about to check in a new version along with a distributed-impl) topology (this might go depending on the answer to the base uri question) None of these look like particularly likely candidates. How about we have a domain module for this domain level information? Simon
RE: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]
Caroline, That's good to know the background to that include file, I didn't know about it. I'll definitely keep it in mind. I don't think the change I made should affect you, let me know if it does. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Caroline Maynard [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 6:29 AM To: [EMAIL PROTECTED] Subject: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible] Original Message Subject: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible Date: Mon, 13 Aug 2007 10:57:44 +0100 From: Caroline Maynard [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Newsgroups: gmane.comp.apache.webservices.tuscany.devel References: [EMAIL PROTECTED] Brady Johnson (JIRA) wrote: Tuscany SDO native for windows is not msvc backwards compatible Don't I know it. In the PHP project the automated build servers for Win use VC6, so we are obliged to use that compiler in the SDO for PHP project. Since the Tuscany team decided to support only VC8, I usually find some minor problems porting the code over - you'll find a trail of these in the issues database where I've sent the fixes back as patches. It's not really a big problem, more an inconvenience. However it was a policy decision by the Tuscany committers at the time. YMMV. Again, with the localtime behaviour, this came from concerns about using non-reentrant versions of localtime(). You may not have noticed the SDOUserMacros.h file - this mechanism was introduced so that consumers of Tuscany C++ could adapt the macros to their environment. You can see the PHP version here: http://cvs.php.net/viewvc.cgi/pecl/sdo/commonj/sdo/SDOUserMacros.h?view= markup It would be helpful if you would keep this mechanism in place. - 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: Metadata related to extension types
Hi Simon, You mentioned whatever was running in my mind - a module for sca-domain. I did look at the host-embeded for a fit but wasn't comfortable. I'd imagine the sca-domain to be a module on its own - having its model, processors and other things and various runtimes should strap up this domain. Though the definitions.xml has mostly about policy related things I'd expect it to accomodate more things that go just beyond policy and pertain braodly to the domain. Infact I'd guess somewhere down the line with the distributed domain scaling up, this file 'could' have a role to play. Thanks. - Venkat On 8/13/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, The Assembly Model specs mentions the 'need' for definitions of metadata related to implementation and binding extensions types as follows: 2665 In addition to the definition for the new implementation instance element, there needs to be an 2666 associated implementationType element which provides metadata about the new implementation 2667 type. The pseudo schema for the implementationType element is shown in the following snippet: 2668 implementationType type=xs:QName 2669 alwaysProvides=list of intent xs:QName 2670 mayProvide=list of intent xs:QName/ 2749 bindingType type=xs:QName 2750 alwaysProvides=list of intent QNames? 2751 mayProvide = list of intent QNames?/ This metadata is supposed to be defined in definitions.xml file as defined on page 57, section title SCA Definitions. Since I am having to address the definitions.xml file as part of the policy framework implementation, I have included model and processors for implementationType and bindingType elements within the policy and policy-xml modules. But I guess this has to move out to a place that typically deals with 'domain' related things in general. Could people share some thoughts on this please ? Thanks - Venkat Hi Venkat These all seem to be policy related apart from sca:binding which, if I understand it correctly, allows binding definitions to be pre defined for a domain. I think we have three places that do domain kinds of things. host-embedded distributed (am just about to check in a new version along with a distributed-impl) topology (this might go depending on the answer to the base uri question) None of these look like particularly likely candidates. How about we have a domain module for this domain level information? Simon
Re: [DAS] Transaction support
I think that the main goal of DAS, is to be an heterogeneous API that could be used to implement support for various backends (rdb, ldap, xml etc). Starting to add various semantics that might be specific to RDB might take us out of this direction. So, for this issue, let's take a step back and think around the scenarios where this new enhancement might be useful, could you please list a couple here ? It would be great if you could also mention the deficiencies you found from managedtx parameter on each scenario. Also, couple questions : - Could you please elaborate more on why you need to expose DAS.getConnection() ? - If you already defined the transaction demarcation flags, why you still ask the client code to handle start/endTransaction? Why is that different from passing managedtx = false ? On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: -When connection is provider by caller(say container), there is no meaning of managedtx attribute, and it is better to let the caller handle the transactionality of the operations. So, when DAS is instantiated using external connection - mandate managedtx = false. Also, expose getConnection() from DAS to give a ref. of the connection (User already owns it, DAS is just providing ref.). DAS will not issue any commit/rollback -When connection is created internally, managedtx has a meaning. 1When false, DAS.getConnection() should be exposed and user should be allowed to handle transactions. DAS should not issue any commits/rollbacks 2When true, do not expose DAS.getConnection(). If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit /rollback per command). If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to manager group of commands as a sigle transaction).Here, DAS at the simplest can use a static FLAG set/unset using methods - void DAS.startTransaction(), //mark FLAG to set - void DAS.endTransaction(commit/rollback). //mark FLAG to reset endTransaction() will issue commit/rollback based on arg passed to it. For any exception condition DAS will issue rollback() on transaction and will reset the FLAG. Client needs to call start/endTransaction() for group of Commands. Also, here for timeout impelmentation, Java Timer can be used. Regards, Amita On 8/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, I think it can be useful to bunch commands, but I didn't get how you are planning to do it : ( What would be the parameter of method getTransaction? Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: 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
Re: Calling XSD2JavaGenerator from ANT
I was expecting the non-recommended approach to work...but the SDO generator code explicitly interpret and expects the key/value as two separate command line args. The non-recommended approach to emulate the two-argument behavior is arg line=key1 value1/ If this is the expected behavior, we should at least have it documented. Thoughts ? On 8/12/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Hi, The observed behaviour is the documented behavior of Ant arg value=key1/ arg value=value1 means there are two separate command-line arguments i.e. args.length=2 Is different from arg value=key1 value1/ Which means there is one command-line argument of value key1 value1. The non-recommended approach to emulate the two-argument behaviour is arg line=key1 value1/ Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 1:51 AM To: tuscany-dev Subject: Calling XSD2JavaGenerator from ANT I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- 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] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - 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: SDOFactory: NoClassDefFoundError.
Hi Ramesh, My best guess is you have EMF version conflict between WPS and SDO 2.1. The EMF in WPS is much older than the one in Tuscany SDO. Since EMF is a runtime library in WPS, you cannot upgrade it on your own. The only way to make your env work is to refactor EMF in Tuscany SDO to avoid EMF conflict. This is probably something Tuscany SDO should do - to refactor EMF so it can hide EMF as implementation details. I am not sure whether refactoring EMF is allowed under Eclipse license. Any investigation is welcome. Fuhwei [EMAIL PROTECTED] wrote: Hi All, I am trying to read out an XML file by using your library files (tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my Websphere process server lib folder as well I set all the tuscany jar's in my class path. Still, I am experiencing the below error. YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED. [8/13/07 13:30:19:616 IST] 005a ExceptionUtil E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method transactionNotSupportedActivitySessionSupports on bean BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null). Exception data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory at org.apache.tuscany.sdo.impl.FactoryBase.(FactoryBase.java:225) at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41) at org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper Impl.java:63) at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java: 81) at org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl .java:64) at org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHel perContextImpl.java:31) at org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He lperProviderImpl.java:37) at org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase. java:81) at org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderIm pl.java:30) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA ccessorImpl.java(Compiled Code)) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons tructorAccessorImpl.java(Compiled Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at java.lang.Class.newInstance3(Class.java(Compiled Code)) at java.lang.Class.newInstance(Class.java(Compiled Code)) at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1 57) at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126) at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69) at commonj.sdo.helper.XMLHelper.(XMLHelper.java:200) at sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav a:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe flectionAdapter.java:138) at com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe ssage(JavaImplementationHandler.java:258) at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag e(MessageDispatcherImpl.java:386) at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM essageImpl.java:476) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo duleSessionBean.java:335) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor tedActivitySessionSupports(ModuleSessionBean.java:276) at com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja va:199) at com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.transactionLocalActi vitySessionAny(UOWStrategyImpl.java:406) at com.ibm.ws.sca.internal.uow.handler.UOWAttribute.invoke(UOWAttribute.jav a:478) at com.ibm.ws.sca.internal.uow.handler.AbstractUOWHandler.processMessage(Ab stractUOWHandler.java:162) at com.ibm.ws.sca.internal.uow.handler.UOWHandler.processMessage(UOWHandler .java:81) at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag e(MessageDispatcherImpl.java:397) at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM essageImpl.java:476) at
Re: SDOFactory: NoClassDefFoundError.
Hi, From the stack trace below, this doesn't really sound like an EMF/SDO version problem. It looks like it's trying to load a Tuscany class: org/apache/tuscany/sdo/SDOFactory This should be in the tuscany impl project JAR. Since it's not finding it, it sounds like the classpath is missing some JAR(s). Frank Fuhwei Lwo [EMAIL PROTECTED] wrote on 08/13/2007 12:34:05 PM: Hi Ramesh, My best guess is you have EMF version conflict between WPS and SDO 2.1. The EMF in WPS is much older than the one in Tuscany SDO. Since EMF is a runtime library in WPS, you cannot upgrade it on your own. The only way to make your env work is to refactor EMF in Tuscany SDO to avoid EMF conflict. This is probably something Tuscany SDO should do - to refactor EMF so it can hide EMF as implementation details. I am not sure whether refactoring EMF is allowed under Eclipse license. Any investigation is welcome. Fuhwei [EMAIL PROTECTED] wrote: Hi All, I am trying to read out an XML file by using your library files (tuscany-sdo-api-r2.1-1.0-incubating.jar). I placed your library in my Websphere process server lib folder as well I set all the tuscany jar's in my class path. Still, I am experiencing the below error. YOUR SUGGESTIONS WILL BE VERY MUCH APPRECIATED. [8/13/07 13:30:19:616 IST] 005a ExceptionUtil E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method transactionNotSupportedActivitySessionSupports on bean BeanId(XMLValidationApp#XMLValidationEJB.jar#Module, null). Exception data: java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/SDOFactory at org.apache.tuscany.sdo.impl.FactoryBase.(FactoryBase.java:225) at org.apache.tuscany.sdo.model.ModelFactory.(ModelFactory.java:41) at org.apache.tuscany.sdo.helper.TypeHelperImpl.getBuiltInModels(TypeHelper Impl.java:63) at org.apache.tuscany.sdo.helper.TypeHelperImpl.(TypeHelperImpl.java: 81) at org.apache.tuscany.sdo.helper.HelperContextImpl.(HelperContextImpl .java:64) at org.apache.tuscany.sdo.helper.DefaultHelperContextImpl.(DefaultHel perContextImpl.java:31) at org.apache.tuscany.sdo.helper.HelperProviderImpl.createDefaultHelpers(He lperProviderImpl.java:37) at org.apache.tuscany.sdo.spi.HelperProviderBase.(HelperProviderBase. java:81) at org.apache.tuscany.sdo.helper.HelperProviderImpl.(HelperProviderIm pl.java:30) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA ccessorImpl.java(Compiled Code)) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons tructorAccessorImpl.java(Compiled Code)) at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code)) at java.lang.Class.newInstance3(Class.java(Compiled Code)) at java.lang.Class.newInstance(Class.java(Compiled Code)) at commonj.sdo.impl.HelperProvider.loadImplementation(HelperProvider.java:1 57) at commonj.sdo.impl.HelperProvider.getInstance(HelperProvider.java:126) at commonj.sdo.impl.HelperProvider.(HelperProvider.java:69) at commonj.sdo.helper.XMLHelper.(XMLHelper.java:200) at sca.component.java.impl.XMLValidateImpl.doValidation(XMLValidateImpl.jav a:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a(Compiled Code)) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java(Compiled Code)) at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) at com.ibm.ws.sca.internal.java.handler.JavaReflectionAdapter.invoke(JavaRe flectionAdapter.java:138) at com.ibm.ws.sca.internal.java.handler.JavaImplementationHandler.processMe ssage(JavaImplementationHandler.java:258) at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessag e(MessageDispatcherImpl.java:386) at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedM essageImpl.java:476) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.processUOWMessage(Mo duleSessionBean.java:335) at com.ibm.wsspi.sca.ejb.module.impl.ModuleSessionBean.transactionNotSuppor tedActivitySessionSupports(ModuleSessionBean.java:276) at com.ibm.wsspi.sca.ejb.module.EJSLocalStatelessModule_43132892.transactio nNotSupportedActivitySessionSupports(EJSLocalStatelessModule_43132892.ja va:199) at com.ibm.ws.sca.internal.uow.handler.UOWStrategyImpl.transactionLocalActi vitySessionAny(UOWStrategyImpl.java:406) at
Re: mvn eclipse:eclipse fails on java
Hi Luciano, Simon, I ran it like this: mvn -U -fn clean install And it runs fine (Some test errors, but build completes) with maven 2.0.5 and java 1.5.12. Thanks for all the feedback, - Ole Simon Laws wrote: On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ole Here is what I tried, and all went OK 1.Removed .m2\repository\org\apache\tuscany 2.svn update to revision #565235 3.cd %tuscany_home%\java 4.mvn -U -fn clean install java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Maven version: 2.0.5 -- If you have a higher version, I'd recommend trying with 2.0.5 [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 48 minutes 3 seconds [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007 [INFO] Final Memory: 61M/63M [INFO] On 8/12/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi Simon, Simon Laws wrote: I note from your other post that you are having problems with the full build with JDK1.6. Is it possible for you to try with 1.5 as this is known to work? We can then isolate JDK issues from these more general build issues. Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it made it this far (I also disabled SELinux to make sure nothing funky was happening): --- T E S T S --- Running supplychain.SupplyChainClientTestCase In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer is [Proxy - f6438d] java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.felix.framework.Felix.loadBundleClass(Felix.java :1422) at org.apache.felix.framework.BundleImpl.loadClass( BundleImpl.java:335) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService (OSGiImplementationProvider.java:773) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle (OSGiImplementationProvider.java:873) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle (OSGiImplementationProvider.java:326) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance (OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget (OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke (OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke( RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke( AbstractInvocationHandler.java:145) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:75) at $Proxy7.purchaseGoods(Unknown Source) at supplychain.SupplyChainClientTestCase.test( SupplyChainClientTestCase.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run( OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at
Re: [Fwd: Re: [jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible]
Brady Johnson wrote: That's good to know the background to that include file, I didn't know about it. I'll definitely keep it in mind. I don't think the change I made should affect you, let me know if it does. Thanks. As discussed previously, we're sticking with the branch for now, and will move up to the trunk when it is more stable - it's clear there will be a lot of changes to make, though the majority should be fairly mindless refactoring. Just wanted to make sure that you knew how some of the Tuscany code ended up like it is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
On 8/13/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi Luciano, Simon, I ran it like this: mvn -U -fn clean install And it runs fine (Some test errors, but build completes) with maven 2.0.5and java 1.5.12. Thanks for all the feedback, - Ole Simon Laws wrote: On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ole Here is what I tried, and all went OK 1.Removed .m2\repository\org\apache\tuscany 2.svn update to revision #565235 3.cd %tuscany_home%\java 4.mvn -U -fn clean install java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Maven version: 2.0.5 -- If you have a higher version, I'd recommend trying with 2.0.5 [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 48 minutes 3 seconds [INFO] Finished at: Sun Aug 12 22:28:52 PDT 2007 [INFO] Final Memory: 61M/63M [INFO] On 8/12/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi Simon, Simon Laws wrote: I note from your other post that you are having problems with the full build with JDK1.6. Is it possible for you to try with 1.5 as this is known to work? We can then isolate JDK issues from these more general build issues. Oh Man - It almost made it - I gave 1.5.12 a go for the whole build and it made it this far (I also disabled SELinux to make sure nothing funky was happening): --- T E S T S --- Running supplychain.SupplyChainClientTestCase In SupplyChainClientTestCase.test: Calling customer.purchaseGoods, customer is [Proxy - f6438d] java.lang.ClassNotFoundException: supplychain.retailer.Retailer at org.apache.felix.framework.Felix.loadBundleClass(Felix.java :1422) at org.apache.felix.framework.BundleImpl.loadClass( BundleImpl.java:335) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveWireRegisterProxyService (OSGiImplementationProvider.java:773) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.resolveBundle (OSGiImplementationProvider.java:873) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.startBundle (OSGiImplementationProvider.java:326) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiInstanceWrapper.getInstance (OSGiInstanceWrapper.java:70) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invokeTarget (OSGiTargetInvoker.java:121) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invoke (OSGiTargetInvoker.java:172) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingInvoker.invoke ( RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke ( AbstractInvocationHandler.java:145) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:75) at $Proxy7.purchaseGoods(Unknown Source) at supplychain.SupplyChainClientTestCase.test( SupplyChainClientTestCase.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java :128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run( OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet( AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( AbstractDirectoryTestSuite.java:125) at
[SCA Native] Next Release Design
Hello all, I have written some preliminary design specifications for the TuscanySCA M4 release. This is a living document, and I will be continuously updating it. Before I get any further, I would like some opinions on the refactor of the SCA Data Model. Input/Suggestions are very welcome. Here's the WIKI page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+Nativ e+Release+M4+Design+Specifications (the mail program may cut the link into several lines, so make sure you copy all the way to +Specifications) Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
Re: SCA distribution is really big now
It would be good to get user 's view on this as well. I am re-posting to tuscany-user list since I am not sure if everyone monitors both lists. On 8/11/07, ant elder [EMAIL PROTECTED] wrote: Our SCA binary distribution is over 100Meg now and there's still extensions and dependencies I've not added yet. This seems a little big considering we're trying to sell Tuscany as all svelte and light weight. So what to do? The reason its so big is that every webapp sample and demo we have ends up including a copy of most of the runtime and dependencies. One solution could be to just ship fewer prebuilt webapp samples and demos. Another could be to change the way we do those samples so that each sample/demo is just a simple SCA contribution jar and you have to deploy that to some Tuscany runtime. We've already the webapp runtime that would work for that, and the Geronimo Tuscany support, and we could create another standalone runtime if you don't want to use Tomcat or Geronimo. What do people think, does the size matter, are there some other things we could do? ...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/6/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/3/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI ). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. After more reading of the various SCA specs, I think we should defer supporting a domain URI (or a set of domain URIs) until the specs clarify the use cases for it. Here are the issues I'm seeing: - Component URI is not clearly defined in the spec (there's an errata for this), the name of the component cannot be used alone for nested components, and concatenating names of nested components with a domain URI is likely to cause ambiguities and collisions. - Having a domain URI per node in a domain (proposed earlier in this thread) is not in line with the spec. - Also doing that will burn the node topology in the SCA domain logical assembly, as you'll see the addresses of your nodes in the URIs on your reference bindings, so the logical assembly won't be so logical anymore :) - We could say that the domain URI is just a logical URI, but then I don't understand why we would need it at all, as specifying domainURI/someURI in the URI of a reference binding would only compete with the target attribute of a reference or wire. - And if it was just a logical URI then I'm not sure why we'd need a different URI per protocol. So at this point I don't understand how this domain URI was intended to be used and I think we should keep things simple. I'd suggest to not try to use a domain URI to calculate any binding URIs for now, and ask application developers and assemblers to specify the URIs they want explicitly. If anyone out there has a requirement for domain URIs and can articulate the use case and how it should work, please shout :) Finally, the SCA assembly model is already able to store a single URI in the domain's Composite model object (see Composite.get/setURI()), so if people find a real use case and are OK to start with a single domain URI, they can just use that. Thoughts? So what is the proposal
Re: I think Tuscany needs a graph generator for composite layouts
Shaoguang, The Eclipse SOA Tools Project is building a graphical editor for SCA composites. You can find the project here: http://www.eclipse.org/stp/ In addition to the graphical composition editor, there is a range of SCA and SOA related tooling available in this tools project. Of course, there are also commercial tools produced by some vendors, of which the IBM WebSphere Integration Developer (WID) tool is an example: http://www-306.ibm.com/software/integration/wid/ ...the commercial tools are big on graphical editors, but as you might expect for such productive tools, they come at a significant price! Yours, Mike. shaoguang geng wrote: as the title, when composite contents comes more and more complicated, a layout graph generator would do greate help to developers. Or did some one see commercial providers of such a grapher? Good day. - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sample news page....
Hi, Here is a sample of SCA news page that I had proposed last week[1]. This news page includes information about both Java SCA and Native SCA. It is a live page that reflects what's going on in the project (no old news). This page is created on TuscanyWiki so that everyone can add information to it. It currently has two main sections. Project news and user news. Please feel free to add more if you can think of other news categories to add. Please help keep this page interesting! Share what you think is useful. If your news script consists of long text, please provide a link to a page to keep this page easy to read. I'll go ahead and link it to the website for now at [2]. Let's give this a few weeks to see how it evolves. Do you think we should have one Tuscany news page or separate ones for SCA, SDO and DAS? [1]: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+News+Page [2]: http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html Haleh
RE: [SCA Native] java implementation and interface schema files loaded but not used
-Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 8:33 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] java implementation and interface schema files loaded but not used Brady Johnson wrote: Does anyone have any insight into why these files are loaded but never used in TuscanySCA Native: TuscanySCA Root dir/xsd/ sca-implementation-java.xsd sca-interface-java.xsd I created a JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1513 Their existence in the project is misleading and implies that TuscanySCA Native supports Java services. Perhaps these should be removed in M4. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Will you be able to load (and ignore without breaking) a composite containing implementation.java and interface.java elements? I'm thinking about scenarios where people share a composite between the two runtimes, with part of it running on the Native runtime and part running on the Java runtime. I guess I'll have the same question for the Java project, we should be able to ignore (or just handle with a warning) implementation.cpp and interface.cpp in the Java runtime. -- Jean-Sebastien Won't this still be a problem for other extensions that are provided by Tuscany Java? For example, implementation.script? Does this imply that we should copy all of the extension xsd files from Tuscany Java into Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)? Is it possible we could have the composite loader ignore (or warn about) extension types that it doesn't recognize? This would allow it to parse the composite files, but wouldn't require that our runtime explicitly recognize every extension type that isn't supported. -- David Haney -- Chief Architect, Hydra Products -- Rogue Wave Software -- http://www.roguewave.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sample news page....
Looks nice! I meant to reply last week saying that I thought it was a good idea, but time just got away from me again... The Native part looks a bit sparse. Imp trying to think of something to beef it up a bit. :) Brady -Original Message- From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 3:33 PM To: tuscany-dev; Tuscany Users Subject: sample news page Hi, Here is a sample of SCA news page that I had proposed last week[1]. This news page includes information about both Java SCA and Native SCA. It is a live page that reflects what's going on in the project (no old news). This page is created on TuscanyWiki so that everyone can add information to it. It currently has two main sections. Project news and user news. Please feel free to add more if you can think of other news categories to add. Please help keep this page interesting! Share what you think is useful. If your news script consists of long text, please provide a link to a page to keep this page easy to read. I'll go ahead and link it to the website for now at [2]. Let's give this a few weeks to see how it evolves. Do you think we should have one Tuscany news page or separate ones for SCA, SDO and DAS? [1]: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+News+ Page [2]: http://incubator.apache.org/tuscany/tuscany-downloads-documentations.htm l Haleh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
[ https://issues.apache.org/jira/browse/TUSCANY-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1524: - Description: See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html was: See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1533) TuscanySCA Native test suite is stale and hasnt been maintained for ages
TuscanySCA Native test suite is stale and hasnt been maintained for ages Key: TUSCANY-1533 URL: https://issues.apache.org/jira/browse/TUSCANY-1533 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: All platforms Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next The TuscanySCA Native test suite is stale and hasn't been maintained for ages. It could be very confusing for anyone who downloads the source code and tries to run the tests since they don't even compile. (like I once did and then spent a few hours searching/wondering what I did wrong) Why don't we just delete it? We'll be creating a new one with the M4 release. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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]
[SCA Native] Test suite is stale and hasn't been maintained for ages
I wrote a JIRA about this: https://issues.apache.org/jira/browse/TUSCANY-1533 Why don't we just delete it to avoid people wasting time wondering why it doesn't even compile for them (like I did). We'll be making a new one for the M4 release anyways. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
[VOTE] Release Tuscany Java DAS beta1 (RC4)
Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
[ https://issues.apache.org/jira/browse/TUSCANY-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1524. -- Resolution: Fixed Fixed under revision #565488 Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
[ https://issues.apache.org/jira/browse/TUSCANY-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519545 ] Luciano Resende commented on TUSCANY-1524: -- This was also fixed in trunk under revision #565487 Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 See details here : http://www.mail-archive.com/general%40incubator.apache.org/msg14905.html and http://www.mail-archive.com/general%40incubator.apache.org/msg14853.html -- 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: sample news page....
Thanks Brady. As I mentioned below I am hoping that everyone who has something to share about the project will participate and share information. Thanks for making the effort to update Native SCA section on News page. One piece of news might be interesting is OSCON demo that goes across Java and Native if it is ready. Haleh On 8/13/07, Brady Johnson [EMAIL PROTECTED] wrote: Looks nice! I meant to reply last week saying that I thought it was a good idea, but time just got away from me again... The Native part looks a bit sparse. Imp trying to think of something to beef it up a bit. :) Brady -Original Message- From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 3:33 PM To: tuscany-dev; Tuscany Users Subject: sample news page Hi, Here is a sample of SCA news page that I had proposed last week[1]. This news page includes information about both Java SCA and Native SCA. It is a live page that reflects what's going on in the project (no old news). This page is created on TuscanyWiki so that everyone can add information to it. It currently has two main sections. Project news and user news. Please feel free to add more if you can think of other news categories to add. Please help keep this page interesting! Share what you think is useful. If your news script consists of long text, please provide a link to a page to keep this page easy to read. I'll go ahead and link it to the website for now at [2]. Let's give this a few weeks to see how it evolves. Do you think we should have one Tuscany news page or separate ones for SCA, SDO and DAS? [1]: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+News+ Page [2]: http://incubator.apache.org/tuscany/tuscany-downloads-documentations.htm l Haleh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] java implementation and interface schema files loaded but not used
Hi, The SCA Java runtime doesn't use the XSD for the assembly or extensions at runtime to parse the composite file. A StAX-based artifact processor is plugged into the runtime to handle the extensions such as implementation.java, implementation.script and binidng.rmi. Does SCA Native use the generated SDO from the XSDs to load the composite file? Thanks, Raymond - Original Message - From: David Haney [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, August 13, 2007 2:35 PM Subject: RE: [SCA Native] java implementation and interface schema files loaded but not used -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 8:33 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] java implementation and interface schema files loaded but not used Brady Johnson wrote: Does anyone have any insight into why these files are loaded but never used in TuscanySCA Native: TuscanySCA Root dir/xsd/ sca-implementation-java.xsd sca-interface-java.xsd I created a JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1513 Their existence in the project is misleading and implies that TuscanySCA Native supports Java services. Perhaps these should be removed in M4. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Will you be able to load (and ignore without breaking) a composite containing implementation.java and interface.java elements? I'm thinking about scenarios where people share a composite between the two runtimes, with part of it running on the Native runtime and part running on the Java runtime. I guess I'll have the same question for the Java project, we should be able to ignore (or just handle with a warning) implementation.cpp and interface.cpp in the Java runtime. -- Jean-Sebastien Won't this still be a problem for other extensions that are provided by Tuscany Java? For example, implementation.script? Does this imply that we should copy all of the extension xsd files from Tuscany Java into Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)? Is it possible we could have the composite loader ignore (or warn about) extension types that it doesn't recognize? This would allow it to parse the composite files, but wouldn't require that our runtime explicitly recognize every extension type that isn't supported. -- David Haney -- Chief Architect, Hydra Products -- Rogue Wave Software -- http://www.roguewave.com/ - 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: [SCA Native] java implementation and interface schema files loaded but not used
David Haney wrote: -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 8:33 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] java implementation and interface schema files loaded but not used Brady Johnson wrote: Does anyone have any insight into why these files are loaded but never used in TuscanySCA Native: TuscanySCA Root dir/xsd/ sca-implementation-java.xsd sca-interface-java.xsd I created a JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1513 Their existence in the project is misleading and implies that TuscanySCA Native supports Java services. Perhaps these should be removed in M4. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Will you be able to load (and ignore without breaking) a composite containing implementation.java and interface.java elements? I'm thinking about scenarios where people share a composite between the two runtimes, with part of it running on the Native runtime and part running on the Java runtime. I guess I'll have the same question for the Java project, we should be able to ignore (or just handle with a warning) implementation.cpp and interface.cpp in the Java runtime. -- Jean-Sebastien Won't this still be a problem for other extensions that are provided by Tuscany Java? For example, implementation.script? Does this imply that we should copy all of the extension xsd files from Tuscany Java into Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)? I'm not implying anything or advocating for any solution. It's just that the discussion about the schemas made me think about scenarios mixing implementation and binding types and I'm just asking if there will be an issue at all with these scenarios. Is it possible we could have the composite loader ignore (or warn about) extension types that it doesn't recognize? This would allow it to parse the composite files, but wouldn't require that our runtime explicitly recognize every extension type that isn't supported. That would be a good idea. -- David Haney -- Chief Architect, Hydra Products -- Rogue Wave Software -- http://www.roguewave.com/ - 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: Policy intents and policySets on bindings and implementations
[snip] Venkata Krishnan wrote: Hi Sebastien, Yes, this was what I intended to do initially. But got a bit concerned about losing the original state of the model after build time. I was thinking of a Admin or Mgmt function that might display the original configurations before thing got built i.e. computed or aggregated. For this I thought its best to have information that was originially loaded preserved. The 'ComputedIntents' and 'ComputedPolicies' will only emerge during the build time. I could not figure out a better place to hold this information than the model itself. Well, that's just for explaining the thoughts behind that implementation. I am open to cutting this out :). Independent of this change, could you please help me get some clarity on how we could retrieve the original configurations. Thanks. - Venkat If you want to implement an administration tool that shows the original composites, components, services, references, implementations, bindings... and policies then just don't call CompositeBuilder.build() :) Administration tools, wizards, and editors should use the original models loaded from the development artifacts. CompositeBuilder.build() refactors and transforms the original assembly model so much (to make it easier to process at runtime) than preserving only the original policies wouldn't help anyway. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
Below is what is happening 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
So what is lacking is
a ability to issue commit/rollback on group of commands where connection is
managed by DAS (managedtx=true).(case 3)). this will be essential to handle
any business unit work. otherwise DAS is ending up today in mimicking
autocommit behavior of Database which is not so useful when business
transactions need to handle a group of operations as one atomic unit
b what is the reason behind providing case 1)? when client/container
provides connection, it can be controlled by client/container. and even if
DAS tries to controll it, as user has handle to connection,
commits/rollbacks can be issued by client async with what DAS is trying to
control. So there will be no meaning in DAS controlling the connection
supplied by client. And so there is no meaning to managedtx either.
c case 2), as of today there is no way to expose connection to client when
it is created by DAS. so neither DAS nor client manages transaction. For
this case exposing connection thru getConnection() will be useful (for other
cases, it can be banned)
d as DAS is heterogeneous API, is the DAS config going to be
heterogeneous too? If yes, then it will be advantageousto support the
transactional nature of RDB using such semantics. If the backend (non RDB)
does not support transaction, this semantics will be of no use, but
in this case the DAS config can be different (more tuned to that particular
backend)
So, it all depends on whether we are following the path to support DAS with
heterogeneous APIs or not. Will you please elaborate meaning of
heterogeneous API in context of different flavors of DAS?
e {If you already defined the transaction demarcation flags...}Where are we
doing that at present? What is there is only issue commit/rollback at the
end of each DAS Command. Am I missing some other transaction demarcation
mechanism already available in DAS?
Regards,
Amita
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote:
I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.
So, for this issue, let's take a step back and think around the
scenarios where this new enhancement might be useful, could you please
list a couple here ? It would be great if you could also mention the
deficiencies you found from managedtx parameter on each scenario.
Also, couple questions :
- Could you please elaborate more on why you need to expose
DAS.getConnection() ?
- If you already defined the transaction demarcation flags, why you
still ask the client code to handle start/endTransaction? Why is that
different from passing managedtx = false ?
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection() from DAS to give a ref. of the connection (User already
owns
it, DAS is just providing ref.). DAS will not issue any commit/rollback
-When connection is created internally, managedtx has a meaning.
1When false, DAS.getConnection() should be exposed and user should be
allowed to handle transactions. DAS should not issue any
commits/rollbacks
2When true, do not expose DAS.getConnection().
If TRANSACTION_DEMARCATION_PER_COMMAND is true, work like today (commit
/rollback per command).
If TRANSACTION_DEMARCATION_PER_COMMAND is false (now is time for DAS to
manager group of commands as a sigle transaction).Here, DAS at the
simplest
can use a static FLAG set/unset using methods
- void DAS.startTransaction(), //mark FLAG to set
- void DAS.endTransaction(commit/rollback). //mark FLAG to reset
endTransaction() will issue commit/rollback based on arg passed to it.
For any exception condition DAS will issue rollback() on transaction and
will reset the FLAG.
Client needs to call start/endTransaction() for group of Commands.
Also, here for timeout impelmentation, Java Timer can be used.
Regards,
Amita
On 8/10/07, Adriano Crestani [EMAIL PROTECTED]
Re: [DAS] Transaction support
Comments inline
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is what is happening 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
So what is lacking is
a ability to issue commit/rollback on group of commands where connection is
managed by DAS (managedtx=true).(case 3)). this will be essential to handle
any business unit work. otherwise DAS is ending up today in mimicking
autocommit behavior of Database which is not so useful when business
transactions need to handle a group of operations as one atomic unit
So, the test case below is an example of multiple commands under one
transaction. On this scenario, connection is supplied by client, and I
think this gives you the same results as if the connection was created
by DAS and exposed to client code, and also gives more flexibility to
how the client will aquire the connection, or re-use some other
connection to be part of the same transaction.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java
b what is the reason behind providing case 1)? when client/container
provides connection, it can be controlled by client/container. and even if
DAS tries to controll it, as user has handle to connection,
commits/rollbacks can be issued by client async with what DAS is trying to
control. So there will be no meaning in DAS controlling the connection
supplied by client. And so there is no meaning to managedtx either.
c case 2), as of today there is no way to expose connection to client when
it is created by DAS. so neither DAS nor client manages transaction. For
this case exposing connection thru getConnection() will be useful (for other
cases, it can be banned)
In the case where client code requires access to the connection, is
there any issue with supplying it to DAS ?
d as DAS is heterogeneous API, is the DAS config going to be
heterogeneous too? If yes, then it will be advantageousto support the
transactional nature of RDB using such semantics. If the backend (non RDB)
does not support transaction, this semantics will be of no use, but
in this case the DAS config can be different (more tuned to that particular
backend)
So, it all depends on whether we are following the path to support DAS with
heterogeneous APIs or not. Will you please elaborate meaning of
heterogeneous API in context of different flavors of DAS?
Yes, the idea is that each impl would define it's own model,
inheriting from a common root class (xsd element)
e {If you already defined the transaction demarcation flags...}Where are we
doing that at present? What is there is only issue commit/rollback at the
end of each DAS Command. Am I missing some other transaction demarcation
mechanism already available in DAS?
Regards,
Amita
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote:
I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.
So, for this issue, let's take a step back and think around the
scenarios where this new enhancement might be useful, could you please
list a couple here ? It would be great if you could also mention the
deficiencies you found from managedtx parameter on each scenario.
Also, couple questions :
- Could you please elaborate more on why you need to expose
DAS.getConnection() ?
- If you already defined the transaction demarcation flags, why you
still ask the client code to handle start/endTransaction? Why is that
different from passing managedtx = false ?
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection() from DAS to give a ref. of the connection (User already
owns
it, DAS is just providing ref.). DAS will not issue any commit/rollback
-When connection is created internally, managedtx has a meaning.
1When false, DAS.getConnection() should be exposed and user should be
allowed to handle
