RE: DataObjectUtil.getProperty
Thanks. I guess the same applies to org.apache.tuscany.sdo.util.SDOUtil. We should be using org.apache.tuscany.sdo.api.SDOUtil? -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 3:06 PM To: tuscany-user@ws.apache.org Subject: Re: DataObjectUtil.getProperty DataObjectUtil.getProperty() has been renamed DataObjectUtil.getInstanceProperty(), but you should never be calling either of these internal implementation methods. The proper SDO API is in commonj.sdo.DataObject: /** * Returns the named Property from the current instance properties, * or null if not found. The instance properties are getInstanceProperties(). * @param propertyName the name of the Property * @return the named Property from the DataObject's current instance properties, or null. */ Property getInstanceProperty(String propertyName); Frank. "Murtaza Goga" <[EMAIL PROTECTED]> wrote on 08/14/2007 02:46:52 PM: > What would be the equivalent operation(s) to replace the following > method which we have been using since the M2 release: > > > > public static Property getProperty(DataObject dataObject, String > propertyName) > > > > Thanks, > > Murtaza > > > > > - 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: [DAS] Transaction support
Amita, Maybe I am not getting this. What is the user case scenario that you are trying to cover with your suggestion (I understand what you are suggesting to do, but not sure of use case)? In what case client needs what you are mentioning, beyond what is provided today? Thanks for the clarification. Haleh On 8/14/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > --->if DAS exposes connection thru getConnection() ONLY when > managedtx=false, it need to control cases when managedtx=true. So 2. will > be > needed. > If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx > loses its meaning and DAS can not control any transaction as client always > have the control. > > I agree with you Amita, however the user will always have the control when > it passes the a Connection to DAS on its creation no matter if the > managedtx > is true or not, because he will have a reference to the Connection he > created. > > So, if the managedtx=true and the user passed the Connection to DAS, it > will > make no sense not to expose the Connection to the user, since he already > has > its reference. > > Regards, > Adriano Crestani > > On 8/14/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > On 8/14/07, Adriano Crestani <[EMAIL PROTECTED]> wrote: > > > > > > Here is my opinion: > > > > > > 1- There are 2 ways for user to provide a Connection to DAS, create > one > > > and > > > pass it to DAS on its creation or on ConnectionInfo. The first case is > > > already giving the access to the Connection to the user. On the > second, > > I > > > think it's useful to provide access to it with getConnection(), since > > the > > > user wouldn't be able to manage the transacions if he defines the > > > managedtx=false. > > > > > > --->if DAS exposes connection thru getConnection() ONLY when > > managedtx=false, it need to control cases when managedtx=true. So 2. > will > > be > > needed. > > If it exposes getConnection() ALWAYS (ignoring managetx), then managedtx > > loses its meaning and DAS can not control any transaction as client > always > > have the control. > > > > 2- Now, about start/endTransaction() methods, I agree with Luciano, it > > will > > > look like DAS was specially designed for RDB when you define it on DAS > > > class, maybe it could probably be added to rdb.DASImpl class and the > > user > > > would have to cast it to rdb.DASImpl when creating a DAS instance > using > > > the > > > factory. > > > > > > Anyway, I don't agree with adding these methods, once if being exposed > > the > > > > > > Connection with getConnection the user can commit or rollback whenever > > he > > > wants, and control how many commands will be grouped as atomic change > on > > > rdb > > > or not. > > > > > > 3- As we are already talking about DAS being heterogeneus and > > independent > > > of > > > implementations, as a interface should be, the classes on das package > > > shouldn't be depedent of das.rdb package classes. But on patch from > > > JIRA-1465 were added the methods add/remove/get/ResultDescriptor on > > > Command > > > class, however these methods are, as far as I know, only intended to > be > > > used > > > with RDB DAS. So I think they are misplaced, maybe they should be > placed > > > on > > > a Command implementation under das.rdb package. What do you 2 think? > > > > > > --->-This can be a good start for DAS API-Impl separation work. > We > > can discuss > > what all changes that need to happen in current DAS (Luciano already has > > some work in sandbox) to make a clean separation between API and Impl. > e.g > > . > > DAS interface does not have an API for connecting to non-DBMS data > stores, > > but it accepts java.sql.Connection indicating DAS from Interface level > > itself is tied to Database. Can we open another thread and list/discuss > > all > > the changes around this separation work? > > > > Regards, > > > Adriano Crestani > > > > > > On 8/14/07, Amita Vadhavkar < [EMAIL PROTECTED]> wrote: > > > > > > > > Just looked more at the code and found something more interesting - > :) > > > > > > > > When there is no connectionInfo in DAS Config, managedtx defaults to > > > true, > > > > so when > > > > connection is passed by user (as in TransactionTests), managedtx is > > > true. > > > > > > > > So, with the current code case 4) can not occur (which is actually > > > useful) > > > > 4)false from caller DAS does not issue > > commit/rollback, > > > > external caller manages > > > > > > > > TransactionTests - if you look closely, there is just "one" > > > > DAS.applyChanges(root) > > > > command > > > > which has 2 INSERT statements using same PK. So, 2nd INSERT gives > JDBC > > > > Exception > > > > and DAS uses it to issue rollback. So, TransactionTests is > succedding > > in > > > > getting exception > > > > and avoiding "both" INSERTs due to the fact that "both INSERTs are > > under > > > > > > > same applyChanges() Command." > > > > > > > > What will happe
RE: DataObjectUtil.getProperty
"Murtaza Goga" <[EMAIL PROTECTED]> wrote on 08/15/2007 08:45:47 AM: > Thanks. > I guess the same applies to org.apache.tuscany.sdo.util.SDOUtil. We > should be using org.apache.tuscany.sdo.api.SDOUtil? > Right. We've now clearly separated the client APIs from the implementation classes. It was hard to tell in the past what clients should and shouldn't use. From now on, clients should only call standard SDO (commonj.sdo) APIs or the Tuscany extension APIs in org.apache.tuscany.sdo.api. Everything else is internal and subject to change. Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Static and Dynamic Mixed
We are running into an issue where setting a property on a static data object with an object of a type extended in a dynamic schema results in a ClassCastException. I looked at the following issue http://issues.apache.org/jira/browse/TUSCANY-513 and our scenario is very similar. It turns out that the base type cannot be abstract. The following test case org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 'InfoType' defined in customer.xsd (test case artifact) is marked as abstract. Is this something which can be fixed? Thanks, Murtaza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Static and Dynamic Mixed
Hi Murtaza, Indeed, this is a bug in the current Tuscany SDO implementation. Would you mind opening a JIRA to track this problem? Thanks, - Ron - Original Message From: Murtaza Goga <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Sent: Wednesday, August 15, 2007 11:12:52 AM Subject: Static and Dynamic Mixed We are running into an issue where setting a property on a static data object with an object of a type extended in a dynamic schema results in a ClassCastException. I looked at the following issue http://issues.apache.org/jira/browse/TUSCANY-513 and our scenario is very similar. It turns out that the base type cannot be abstract. The following test case org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 'InfoType' defined in customer.xsd (test case artifact) is marked as abstract. Is this something which can be fixed? Thanks, Murtaza. - 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: Monitoring, logging and exceptions (again)
absolutely , I will forward this to our lead developer, so that he may input into the jira, as she is more aware of the exact limitations we are running into with the current spring binding. Regards Jeff From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Wed 2007-08-15 01:19 To: tuscany-user@ws.apache.org Subject: Re: Monitoring, logging and exceptions (again) Anderson, Jeff T (CA - Toronto) wrote: > Shore, > I am currently leading a team working for a large Canadian financial services > institution to develop what is going to be there standardized SOA platform > going forward. Currently we are supporting a number of international banking > initiatives, with domestic and other channels coming aboard within this in > the next fiscal year. We plan to go in production with Tuscany within the > next couple of months. We have done fairly rigorous performance testing > > When shopping around for the right technology to help support this > initiative, we were careful to look at anything that would help us to support > a "business centric/POJO" programming model. In other words, we didn't want > infrastructure/plumbing code intermingled with our business logic, even on > the inheritance level. > > The two technologies that seem to best serve our purposes was > 1) Tuscany/SCA with its ability to inject services as well as various binding > technologies, > 2) Spring for its IOC/AOP support. > > We've done some fairly rigorous performance testing on the Tuscany/Spring > mix, and are getting very good results. (Tomcat/Windows and > websphere/Solaris) > Once finished we would be happy to publish. > > One of the major things currently impacting our ability to deliver a truly > integrated service assembly model is that we are running into limitations in > terms of spring binding support from Tuscany. We are currently just using a > pogo binding that calls a spring adapter, simply just a Java class that > implements the service interface, invokes the application context and then > delegates to the actual service implementation which is a Spring bean. > > Once the spring binding improves, we will probably be the first to jump on > it, we are also considering contributing to the current spring binding > implementation, but our development cycles are fairly packed with > implementing service platform features which we have mostly done using Spring > aspects. These features include service caching, service logging, service > validation , and service error handling. We use Spring AOP to declaratively > inject these lifecycle features, and use Spring introductions to dynamically > introduce common interfaces to service requests and service response objects > currently being generated by Tuscany SDO. > > In the coming months we will try to put a bit of a case study together, and > submit it up to the Tuscany wiki. > Regards > Jeff > > Hi Jeff, Good input. Thanks! Would you mind opening JIRAs to report the technical limitations you've run into with the current Spring implementation extension? We are about to put the next release together and if you do this soon we may be able to address some of them before we release. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - ** Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Example to define the ResultSet shape Definition for a join in DAS
Would like an example if my query is a join between two tables? For example, Select a.dept_name, b.employee_name from dept a, emp b where a.id = b.dept_id (+) How do I define an Explicit ResultSet shape definition for the resultset from a join I'm working in Oracle. Thanks, Wing *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Example to define the ResultSet shape Definition for a join in DAS
You can find some information on the DAS User Guide [1]. There are couple test cases that also show this working, here is one test case [2] and it's config file [3]. Amita is also working on getting support for passing ResultDescriptor for dynamic Commands [4], if that would be useful for you. [1] http://incubator.apache.org/tuscany/explicit-resultset-shape-definition.html [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/RelationshipTests.java [3] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/resources/companyMappingWithResultDescriptor.xml [4] http://www.mail-archive.com/[EMAIL PROTECTED]/msg19886.html On 8/15/07, Chu, Wing (Exchange) <[EMAIL PROTECTED]> wrote: > > > > > Would like an example if my query is a join between two tables? > > > > For example, > > > > Select a.dept_name, b.employee_name > > from dept a, emp b > > where a.id = b.dept_id (+) > > > > How do I define an Explicit ResultSet shape definition for the resultset > from a join > > > > I'm working in Oracle. > > > > Thanks, > > Wing > > > *** > Bear Stearns is not responsible for any recommendation, solicitation, > offer or agreement or any information about any transaction, customer > account or account activity contained in this communication. > *** > > > > - > 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: Static and Dynamic Mixed
Thanks. I created a JIRA for this problem http://issues.apache.org/jira/browse/TUSCANY-1540 Murtaza. -Original Message- From: Ron Gavlin [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 11:56 AM To: tuscany-user@ws.apache.org Subject: Re: Static and Dynamic Mixed Hi Murtaza, Indeed, this is a bug in the current Tuscany SDO implementation. Would you mind opening a JIRA to track this problem? Thanks, - Ron - Original Message From: Murtaza Goga <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Sent: Wednesday, August 15, 2007 11:12:52 AM Subject: Static and Dynamic Mixed We are running into an issue where setting a property on a static data object with an object of a type extended in a dynamic schema results in a ClassCastException. I looked at the following issue http://issues.apache.org/jira/browse/TUSCANY-513 and our scenario is very similar. It turns out that the base type cannot be abstract. The following test case org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 'InfoType' defined in customer.xsd (test case artifact) is marked as abstract. Is this something which can be fixed? Thanks, Murtaza. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly download server performance issues
DAS and SDO nightly builds now available from vmbuild1 also: DAS Source distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/source/target&file=tuscany-das-1.0-incubating-SNAPSHOT-src.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/source/target&file=tuscany-das-1.0-incubating-SNAPSHOT-src.tar.gz DAS Binary distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/binary/target&file=tuscany-das-1.0-incubating-SNAPSHOT-bin.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/binary/target&file=tuscany-das-1.0-incubating-SNAPSHOT-bin.tar.gz SDO Source distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT-src.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT-src.tar.gz SDO Binary distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT.tar.gz Please, let me know if this works better for you... I'm still working with infra to get this published to another place. On 8/13/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > Luciano, > > Thanks for the update. Your plan sounds good to me. Any status updates you > can provide as this effort moves forward is much appreciated. > > Regards, > > - Ron > > - Original Message > From: Luciano Resende <[EMAIL PROTECTED]> > To: tuscany-user@ws.apache.org > Sent: Sunday, August 12, 2007 2:29:34 AM > Subject: Re: Nightly download server performance issues > > Hi Ron > >I'm working with Apache Infra to migrate the builds to vmbuild1, > and also checking the possibility to copy the distributions to > people.apache.org. This should solve the performance issues, as well > as allow us to still have the latest sucessful nightly build stored, > in case of any build failure. I'll send more updates on the next > couple days, when more progress is done on this. > > > On 8/10/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Greetings, > > > > I have had minimal success attempting to download a nightly Tuscany SCA, > > SDO, or DAS build using the links provided on the Tuscany web site. I > > presume the Apache vmbuild.apache.org server just cannot handle the load. I > > noticed that the Apache vmbuild1.apache.org server is now available that > > includes a Tuscany placeholder. Please either: 1. remove the downloads page > > 2. improve the performance of the current vmbuild server or 3. migrate the > > builds to the new vmbuild1.apache.org server. The current arrangement for > > downloading nightly builds is quite frustrating. > > > > > > Regards, > > > > - Ron > > > > > > > > - > > 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] > > > > > > - > 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: Nightly download server performance issues
Yes, the vmbuild1 server is a significant improvement over the old vmbuild server. Thanks, - Ron - Original Message From: Luciano Resende <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Sent: Wednesday, August 15, 2007 3:08:51 PM Subject: Re: Nightly download server performance issues DAS and SDO nightly builds now available from vmbuild1 also: DAS Source distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/source/target&file=tuscany-das-1.0-incubating-SNAPSHOT-src.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/source/target&file=tuscany-das-1.0-incubating-SNAPSHOT-src.tar.gz DAS Binary distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/binary/target&file=tuscany-das-1.0-incubating-SNAPSHOT-bin.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/binary/target&file=tuscany-das-1.0-incubating-SNAPSHOT-bin.tar.gz SDO Source distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT-src.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT-src.tar.gz SDO Binary distros http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT.zip http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT.tar.gz Please, let me know if this works better for you... I'm still working with infra to get this published to another place. On 8/13/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > Luciano, > > Thanks for the update. Your plan sounds good to me. Any status updates you > can provide as this effort moves forward is much appreciated. > > Regards, > > - Ron > > - Original Message > From: Luciano Resende <[EMAIL PROTECTED]> > To: tuscany-user@ws.apache.org > Sent: Sunday, August 12, 2007 2:29:34 AM > Subject: Re: Nightly download server performance issues > > Hi Ron > >I'm working with Apache Infra to migrate the builds to vmbuild1, > and also checking the possibility to copy the distributions to > people.apache.org. This should solve the performance issues, as well > as allow us to still have the latest sucessful nightly build stored, > in case of any build failure. I'll send more updates on the next > couple days, when more progress is done on this. > > > On 8/10/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Greetings, > > > > I have had minimal success attempting to download a nightly Tuscany SCA, > > SDO, or DAS build using the links provided on the Tuscany web site. I > > presume the Apache vmbuild.apache.org server just cannot handle the load. I > > noticed that the Apache vmbuild1.apache.org server is now available that > > includes a Tuscany placeholder. Please either: 1. remove the downloads page > > 2. improve the performance of the current vmbuild server or 3. migrate the > > builds to the new vmbuild1.apache.org server. The current arrangement for > > downloading nightly builds is quite frustrating. > > > > > > Regards, > > > > - Ron > > > > > > > > - > > 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] > > > > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly download server performance issues
Great to hear that, I'll add these links as alternative links to the download page. On 8/15/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > Yes, the vmbuild1 server is a significant improvement over the old vmbuild > server. > > Thanks, > > - Ron > > - Original Message > From: Luciano Resende <[EMAIL PROTECTED]> > To: tuscany-user@ws.apache.org > Sent: Wednesday, August 15, 2007 3:08:51 PM > Subject: Re: Nightly download server performance issues > > DAS and SDO nightly builds now available from vmbuild1 also: > > DAS Source distros > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/source/target&file=tuscany-das-1.0-incubating-SNAPSHOT-src.zip > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/source/target&file=tuscany-das-1.0-incubating-SNAPSHOT-src.tar.gz > > DAS Binary distros > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/binary/target&file=tuscany-das-1.0-incubating-SNAPSHOT-bin.zip > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=36&projectName=Apache+Tuscany+DAS+Implementation+project&userDirectory=distribution/binary/target&file=tuscany-das-1.0-incubating-SNAPSHOT-bin.tar.gz > > > SDO Source distros > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT-src.zip > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT-src.tar.gz > > SDO Binary distros > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT.zip > > http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=37&projectName=Apache+Tuscany+SDO+Implementation+Project&userDirectory=distribution/target&file=apache-tuscany-sdo-1.0-incubating-SNAPSHOT.tar.gz > > > Please, let me know if this works better for you... I'm still working > with infra to get this published to another place. > > > > On 8/13/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Luciano, > > > > Thanks for the update. Your plan sounds good to me. Any status updates you > > can provide as this effort moves forward is much appreciated. > > > > Regards, > > > > - Ron > > > > - Original Message > > From: Luciano Resende <[EMAIL PROTECTED]> > > To: tuscany-user@ws.apache.org > > Sent: Sunday, August 12, 2007 2:29:34 AM > > Subject: Re: Nightly download server performance issues > > > > Hi Ron > > > >I'm working with Apache Infra to migrate the builds to vmbuild1, > > and also checking the possibility to copy the distributions to > > people.apache.org. This should solve the performance issues, as well > > as allow us to still have the latest sucessful nightly build stored, > > in case of any build failure. I'll send more updates on the next > > couple days, when more progress is done on this. > > > > > > On 8/10/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > > Greetings, > > > > > > I have had minimal success attempting to download a nightly Tuscany SCA, > > > SDO, or DAS build using the links provided on the Tuscany web site. I > > > presume the Apache vmbuild.apache.org server just cannot handle the load. > > > I noticed that the Apache vmbuild1.apache.org server is now available > > > that includes a Tuscany placeholder. Please either: 1. remove the > > > downloads page 2. improve the performance of the current vmbuild server > > > or 3. migrate the builds to the new vmbuild1.apache.org server. The > > > current arrangement for downloading nightly builds is quite frustrating. > > > > > > > > > Regards, > > > > > > - Ron > > > > > > > > > > > > - > > > 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] > > > > > > > > > > > > - > > 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/ > > -
Re: Monitoring, logging and exceptions (again)
Me too, read this as a very valuable. Something else, I want to say here: Tuscany is doing things no more than Spring infact, It's nothing but standard. To boost Tuscany, we have a lot of works to do, one of the most is TRANSACTION support. Bind Tuscnay with Spring together is not something smart to me, if Tuscany has transaction support, I think Anderson would not need Spring any more. Nice day. Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Anderson, Jeff T (CA - Toronto) wrote: > Shore, > I am currently leading a team working for a large Canadian financial services > institution to develop what is going to be there standardized SOA platform > going forward. Currently we are supporting a number of international banking > initiatives, with domestic and other channels coming aboard within this in > the next fiscal year. We plan to go in production with Tuscany within the > next couple of months. We have done fairly rigorous performance testing > > When shopping around for the right technology to help support this > initiative, we were careful to look at anything that would help us to support > a "business centric/POJO" programming model. In other words, we didn't want > infrastructure/plumbing code intermingled with our business logic, even on > the inheritance level. > > The two technologies that seem to best serve our purposes was > 1) Tuscany/SCA with its ability to inject services as well as various binding > technologies, > 2) Spring for its IOC/AOP support. > > We've done some fairly rigorous performance testing on the Tuscany/Spring > mix, and are getting very good results. (Tomcat/Windows and > websphere/Solaris) > Once finished we would be happy to publish. > > One of the major things currently impacting our ability to deliver a truly > integrated service assembly model is that we are running into limitations in > terms of spring binding support from Tuscany. We are currently just using a > pogo binding that calls a spring adapter, simply just a Java class that > implements the service interface, invokes the application context and then > delegates to the actual service implementation which is a Spring bean. > > Once the spring binding improves, we will probably be the first to jump on > it, we are also considering contributing to the current spring binding > implementation, but our development cycles are fairly packed with > implementing service platform features which we have mostly done using Spring > aspects. These features include service caching, service logging, service > validation , and service error handling. We use Spring AOP to declaratively > inject these lifecycle features, and use Spring introductions to dynamically > introduce common interfaces to service requests and service response objects > currently being generated by Tuscany SDO. > > In the coming months we will try to put a bit of a case study together, and > submit it up to the Tuscany wiki. > Regards > Jeff > > Hi Jeff, Good input. Thanks! Would you mind opening JIRAs to report the technical limitations you've run into with the current Spring implementation extension? We are about to put the next release together and if you do this soon we may be able to address some of them before we release. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
Re: jax-ws instead of axis2
Hi, here is some of my vision: Performance: It seems jaxws is faster than axis2, at this point, I agree jaxws should be part of Tuscany. Another hand, we use axiom for axis2's databinding model, in fact this model is slower than ADB, so change axiom into ADB might be another thing we should do. Jean-Marc Taillant <[EMAIL PROTECTED]> wrote: Hello, Do you know if there is a way to use jax-ws instead of Axis2 for web services. If not is there a plan to integrate jax-ws into Tuscany? Thanks in Advance, Jean-Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
