SCA Continuum build failure (resource issue)
Our continuum build is failing with some resource utilization issues : INFO: ActiveMQ Message Broker (localhost, ID:vmbuild.apache.org-53376-1181958568786-1:0) is shutting down Jun 15, 2007 6:49:45 PM org.apache.activemq.ActiveMQConnection onAsyncException WARNING: Async exception with no exception listener: java.io.EOFException java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:358) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:267) at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:156) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) at java.lang.Thread.run(Thread.java:595) Jun 15, 2007 6:49:45 PM org.apache.activemq.broker.TransportConnector stop INFO: Connector tcp://vmbuild.apache.org:61616 Stopped This is probably a similar issue as the default http port, or a access control issue. Could someone with more experience with ActiveMQ help on this issue ? -- 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] Commented: (TUSCANY-1344) Tuscany does not provide a loader for the elements in scdl
[ https://issues.apache.org/jira/browse/TUSCANY-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505380 ] Matthew Sykes commented on TUSCANY-1344: When the artifact processor is created, createSCABindings in CompositeBuilderImpl will need to be a little bit smarter about how and when it overwrites the uri attributes on the bindings. In particular, on the reference side, the uri could point to the target but the current implementation will set it to the URI of the reference. > Tuscany does not provide a loader for the elements in scdl > -- > > Key: TUSCANY-1344 > URL: https://issues.apache.org/jira/browse/TUSCANY-1344 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Assembly Model >Affects Versions: Java-SCA-0.90, Java-SCA-0.91 > Environment: sca-java-0.90 >Reporter: Matthew Sykes >Priority: Trivial > > There doesn't appear to be a StAXArtifactProcessor capable of reading and > serializing elements in the scdl. -- 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]
Fwd: Call for Papers Opens for OS Summit Asia 2007
-- Forwarded message -- From: J Aaron Farr <[EMAIL PROTECTED]> Date: Jun 15, 2007 10:36 AM Subject: Call for Papers Opens for OS Summit Asia 2007 To: [EMAIL PROTECTED] PMCs, please send this announcement to your various users@ and devs@ mailing lists, as appropriate for your particular community. Remember, your project can only be represented at OS Summit Asia if your community submits talks proposals: Call for Papers Opens for OS Summit Asia 2007 The call for papers is now open for OS Summit Asia, to be held November 26-30 at the Cyberport in Hong Kong. This joint conference between the Apache Software Foundation and the Eclipse Foundation will be consist of two days of tutorials (Nov 26-27) and three days of regular conference sessions (Nov 28-30). The paper submission deadline is Friday, 13 July, 2007, Midnight PDT. You may log in to the ApacheCon submission site to submit your proposals. Further details about the conference, submissions, and fees can be found at: http://www.ossummit.com/cfp.html Topics appropriate for submission include, but are not restricted to, the following: * ASF-wide projects such as Apache HTTP server, Tomcat, Struts, Geronimo, mod_perl and XML Web Services * Eclipse-wide projects such as BI and Reporting Tools (BIRT), Web Tools Platform (WTP), Eclipse Modeling Framework (EMF), Data Tools Platform (DTP), Equinox and the Rich Client Platform (RCP) * Programming languages such as Java, Perl, Python, Ruby and PHP * Web development technologies and techniques including security, performance tuning, e-commerce and J2EE * New technologies and trends such as Web Services and Web 2.0 * Open source community and business models, legal and marketing issues * Open source projects and activities in Asia, local efforts and case studies Thanks and we hope to hear from you, and see you in Hong Kong! -- The OSSummit Planners [EMAIL PROTECTED]
Re: Cleaning up some of the new sample modules
ant elder wrote: On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: ant elder wrote: > On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > > Testing that our sample client doesn't fail with an exception is >> >> >>> useful to us and may deserve a test in our integration test suite (if >> >>> we think that having a proper unit test case testing the bits and >> >>> pieces in that module is not good enough), but I don't thing that >> >>> it's interesting to keep it in the sample itself, as it's not going >> >>> to teach anything to an application developer looking at the sample, >> >>> and doesn't look like a "normal" unit test case. >> >>> >> >> Yes, agreed that this does not really belong in the samples. I >> would be >> >> inclined to put this test code in itest/samples, just to have the >> build >> >> confirm automatically that all the sample clients actually do run. >> It's >> >> good to have equivalent unit tests as well, but the samples are so >> >> visible >> >> that I think it's worth testing them explicitly. >> >> >> > [snip] >> > >> > This is still open. +1 to that suggestion, we do not pollute the >> samples >> > themselves with this kind of testing, we need to add new tests under >> > sca/itest/samples that verify that the samples' main methods do not >> fail. >> > >> I volunteer to produce a patch for this. I'd like to get this into 0.91. > > > > If all this is going to do is check a sample main method runs without an > exception does it really matter if it gets in 0.91 or not? > The main benefit of getting it into 0.91 is to remove this test code from the sample itself, as it is making the sample slightly confusing. Maybe I've misunderstood whats being proposed, which testcases are being changed? Someone has already replaced the client test code that previously called main() with a copy of the JUnit test code from the extension samples. So in the implementation-crud sample (using the new naming convention) we have CRUDClient.java (correct) and CRUDTestCase.java (incorrect, a copy of the same test from implementation-crud-extension, and not testing any client code). This test does use the crud.composite file from src/main/resources. If we had a non-sample itest to exercise CRUDClient.java and crud.composite from this sample, we could eliminate the duplicate copy of CRUDTestCase.java here. We could also eliminate the dusplicate crud.composite file in implementation-crud-extension by having the JUnit test in implementation-crud-extension use the crud.composite file from implementation-crud. Similarly, in the binding-echo-extension sample, under src/test we have duplicates of the implementation code, composite file, and JUnit test code from binding-echo. I'd like to remove this duplicate code from binding-echo-extension, have the JUnit tests in binding-echo-extension use this code from binding-echo, and have a separate itest that excercises EchoBindingClient.java. With this approach, all duplicate code is eliminated from the samples, all sample code is tested either by sample JUnit tests or separate itests, and the distinction between the extension and client/application samples is much clearer. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] XQuery-DAS
Hi All, After a while on RDB DAS beta1 , I am trying to do more on XQuery DAS. Tried to check different XQuery implementations available, below is summary: http://www.axyana.com///products.html Quizx/open - open source Quizx/db(XQuest) - not open source http://www.gnu.org/software/qexo/ - license? - kawa it compiles XQuery expressions and programs to Java bytecodes , this does not have API to be used, so not of much use http://www.oracle.com/technology/sample_code/tech/xml/xmldb/jxqi.html - license will be a problem ***http://dsd.lbl.gov/nux/api/index.html - http://dsd.lbl.gov/nux/license.html has good set of APIs. I am not sure if the license poses some restrictions on use. Looks like this will be a good choice to give first attempt for XQuery DAS. Any advise? http://saxon.sourceforge.net/ - only SAXON-B is fee and SAXON-SA is commercial,So may not be a good choice I am trying to start based on https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/ This uses Service Provider API to separate different DAS implementations. There is http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.htmlthread to discuss the high level approach to provide this. Please add your comments there for refactoring approach. We can use the current mail thread for XQuery DAS specific comments. Also, I will use a new page on http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home to track detailed status for XQuery DAS. I will make sure not to link this page to any other page, so as not to mess up with ongoing release. Regards, Amita On 4/4/07, Luciano Resende <[EMAIL PROTECTED]> wrote: Hi Amita Related to the features, I think it's fine to start simple and get improvements gradatively as we progress... Some issues that you have identified: - Config model more flexible to accommodate differences between multiple implementation - Factory issues, and the ability to get different implementations Are already available in my sandbox [1] as part of the work I did to accommodate multiple DAS implementations [2] It's probably good idea to keep a XQuery DAS page on the Wiki and keep updating it with requirements, discussions and design we are taking... [1] - https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/ [2] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html On 3/26/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > Hi All, > I am trying to create a prototype for supporting XQuery-DAS. Below are > some points I have gathered so far. > Please give your comments, add to the points. > > 1) Basic Features that can be supported:- > >>Need to support associating path expression to xml data source. > > >>Parameter passing in path expression > > >>Support for FLWOR expressions - use of parameters, data source name > > >>JOIN operation will involve multiple data sources and multiple > expressions > - need to support association > for same. > > >>Support for XQuery update facility > > 2) Places where current das config/code needs to be modified:- > >>Provide flexibility in config to support RDB/XQUery/xyz...Can have > expansion to > current config.xsd to support multiple connections of multiple types? like > RDB/XQuery... > > >>Command - needs to take care of associating multiple data sources with > multiple expressions > say, in RDB - its select from t1, t2... > in XQuery - the FLWOR - we can say books.xml <-> expr1, stores.xml <-> > expr2 > and have a JOIN. > > >>Getting connection to data store - should be in Interface-Impl , not > directly in impl- like > it is currently there in DASImpl not in DAS, to keep it generic. > > >>graph building related classes should also have separation of interface > and implementation. > > > 3) What can be kept for in-future and what is MUST for the first cut:- > Need comments from you all. > > 4) Questions:- > >>In RDB-DAS we do not support connection to multiple databases. Even > JIRA-952 talks > only about multiple schemas. Is there any requirement for this/ constraint > due to which > we need to stick to single database? > > >>Also, in future, there can be mix of data stores, RDB, XQuery, What > are the pros/cons > for supporting connection to multiple different types of datastores > (like one RDB compliant, one XQuery compliant) > > 5) Link from ML - [DAS] Refactoring DAS to allow multiple implementatons > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html > During the attempt to separate APIs from Impl, we can now decide on the > approach and structure the design. > > Regards, > Amita > -- Luciano Resende http://people.apache.org/~lresende
[jira] Created: (TUSCANY-1350) Reorganise SDO build / distribution layout
Reorganise SDO build / distribution layout -- Key: TUSCANY-1350 URL: https://issues.apache.org/jira/browse/TUSCANY-1350 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Reporter: Kelvin Goodson Fix For: Java-SDO-1.0 There has been discussion on the list about moving the SDO API project under the SDO root folder and making the SDO distribution look more like the SCA one. -- 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-1152) Support Spring beans as eager-init singletons with references to SCA composite references
[ https://issues.apache.org/jira/browse/TUSCANY-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505192 ] Mike Edwards commented on TUSCANY-1152: --- The only information about this issue is the title, which is a bit thin! Having implemented the Spring Implementation support for the new core runtime, I'm having trouble understanding why this is required: 1) Why Spring beans need to be eager-init. In fact, in the current implementation, lazy initialization is almost forced due to timing issues relating to the instantiation of Spring Beans vs the existence of the wire configuration for references that they make. 2) Why singletons? This I really don't understand. Seems counter-intuitive to me. 3) References to SCA Composite references. Already supported as standard in the current implementation. So, unless someone can come up with a detailed explanation of the requirements behind this Issue, I propose to close it as "won't fix" since none of the items seem to make sense to me. Have I missed something here? > Support Spring beans as eager-init singletons with references to SCA > composite references > - > > Key: TUSCANY-1152 > URL: https://issues.apache.org/jira/browse/TUSCANY-1152 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Spring Implementation Extension >Affects Versions: Java-SCA-Next >Reporter: Jim Marino >Assignee: Mike Edwards > Fix For: Java-SCA-Next > > -- 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] Assigned: (TUSCANY-1152) Support Spring beans as eager-init singletons with references to SCA composite references
[ https://issues.apache.org/jira/browse/TUSCANY-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael John Edwards reassigned TUSCANY-1152: - Assignee: Michael John Edwards > Support Spring beans as eager-init singletons with references to SCA > composite references > - > > Key: TUSCANY-1152 > URL: https://issues.apache.org/jira/browse/TUSCANY-1152 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Spring Implementation Extension >Affects Versions: Java-SCA-Next >Reporter: Jim Marino >Assignee: Michael John Edwards > Fix For: Java-SCA-Next > > -- 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: Cleaning up some of the new sample modules
On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: ant elder wrote: > On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > > Testing that our sample client doesn't fail with an exception is >> >> >>> useful to us and may deserve a test in our integration test suite (if >> >>> we think that having a proper unit test case testing the bits and >> >>> pieces in that module is not good enough), but I don't thing that >> >>> it's interesting to keep it in the sample itself, as it's not going >> >>> to teach anything to an application developer looking at the sample, >> >>> and doesn't look like a "normal" unit test case. >> >>> >> >> Yes, agreed that this does not really belong in the samples. I >> would be >> >> inclined to put this test code in itest/samples, just to have the >> build >> >> confirm automatically that all the sample clients actually do run. >> It's >> >> good to have equivalent unit tests as well, but the samples are so >> >> visible >> >> that I think it's worth testing them explicitly. >> >> >> > [snip] >> > >> > This is still open. +1 to that suggestion, we do not pollute the >> samples >> > themselves with this kind of testing, we need to add new tests under >> > sca/itest/samples that verify that the samples' main methods do not >> fail. >> > >> I volunteer to produce a patch for this. I'd like to get this into 0.91. > > > > If all this is going to do is check a sample main method runs without an > exception does it really matter if it gets in 0.91 or not? > The main benefit of getting it into 0.91 is to remove this test code from the sample itself, as it is making the sample slightly confusing. Maybe I've misunderstood whats being proposed, which testcases are being changed? ...ant
Re: How to add contribution to an existing domain
On 6/15/07, Huang Kai <[EMAIL PROTECTED]> wrote: Hi all: How do I add a contribution to an existing domain, without creating a new domain? And I have no way to get a ContributionService instance in current domain before I can call its contribute() or remove() method (IMHO, it should has a update() method). I think it's neccesary to have a API to get current ContributionService in a domain. Hi, welcome to Tuscany Someone else got stuck on this recently. Luciano has been working on it with Patrick. There is a thread [1] that describes where they got to. I believe the net result is that DefaultSCADomain doesn't support it, as you have found, but there is a new domain implementation, EmbeddedSCADomain, that provides a more comprehensive interface for doing this kind of thing. As you see from the mail thread it's still evolving. If you have ideas about how it should work and want to help make it do what you need then that would be great. Regards Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18695.html
Re: Cleaning up some of the new sample modules
ant elder wrote: On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: Testing that our sample client doesn't fail with an exception is >>> useful to us and may deserve a test in our integration test suite (if >>> we think that having a proper unit test case testing the bits and >>> pieces in that module is not good enough), but I don't thing that >>> it's interesting to keep it in the sample itself, as it's not going >>> to teach anything to an application developer looking at the sample, >>> and doesn't look like a "normal" unit test case. >>> >> Yes, agreed that this does not really belong in the samples. I would be >> inclined to put this test code in itest/samples, just to have the build >> confirm automatically that all the sample clients actually do run. It's >> good to have equivalent unit tests as well, but the samples are so >> visible >> that I think it's worth testing them explicitly. >> > [snip] > > This is still open. +1 to that suggestion, we do not pollute the samples > themselves with this kind of testing, we need to add new tests under > sca/itest/samples that verify that the samples' main methods do not fail. > I volunteer to produce a patch for this. I'd like to get this into 0.91. If all this is going to do is check a sample main method runs without an exception does it really matter if it gets in 0.91 or not? The main benefit of getting it into 0.91 is to remove this test code from the sample itself, as it is making the sample slightly confusing. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to add contribution to an existing domain
Hi all: How do I add a contribution to an existing domain, without creating a new domain? And I have no way to get a ContributionService instance in current domain before I can call its contribute() or remove() method (IMHO, it should has a update() method). I think it's neccesary to have a API to get current ContributionService in a domain.
Re: Cleaning up some of the new sample modules
On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: Testing that our sample client doesn't fail with an exception is >>> useful to us and may deserve a test in our integration test suite (if >>> we think that having a proper unit test case testing the bits and >>> pieces in that module is not good enough), but I don't thing that >>> it's interesting to keep it in the sample itself, as it's not going >>> to teach anything to an application developer looking at the sample, >>> and doesn't look like a "normal" unit test case. >>> >> Yes, agreed that this does not really belong in the samples. I would be >> inclined to put this test code in itest/samples, just to have the build >> confirm automatically that all the sample clients actually do run. It's >> good to have equivalent unit tests as well, but the samples are so >> visible >> that I think it's worth testing them explicitly. >> > [snip] > > This is still open. +1 to that suggestion, we do not pollute the samples > themselves with this kind of testing, we need to add new tests under > sca/itest/samples that verify that the samples' main methods do not fail. > I volunteer to produce a patch for this. I'd like to get this into 0.91. If all this is going to do is check a sample main method runs without an exception does it really matter if it gets in 0.91 or not? ...ant
[jira] Commented: (TUSCANY-1112) Incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505150
]
Pete Robbins commented on TUSCANY-1112:
---
I think you may have 2 separate problems here. Let's start with your original
report comments inline:
You say:
There are three (!) things wrong with this.
1. XERCES will not accept the xsi:type="add". I do not really know why.
I assume this is because there is no type called "add", it's only an
element. So I do not think this should be coming out.
The xsi:type is valid and is written because you are writing the root as
an unknown element: "BOGUS". If you
saved this with the correct root element name, "add"m, then the xsi:type would
not be needed and would be supressed
2. name should not be in tns2=http://www.test.com/info, neither should
"first" and "last" be in the default namespace of http://Component. The
person.xsd has no elementFormDefault, so the elements below
should all ne in the no name namespace.
Fromm the schema name SHOULD be in tns2 and is written correctly. "first"
and "last" should also be in tns2. This is a bug in writing primitive elements
and I will check in a fix.
elementFormDefault=unqualified means that a prefix is not REQUIRED not that it
can not be written
With the fix I will apply the output looks like:
http://Component"; xsi:type="add" xmlns:tns="http://Component";
xmlns:tns2="http://www.test.com/info";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
Will
Shakespeare
... which I believe is correct.
I will look at the second problem you have with the catalog example. (If you
could attach the full schema rather than sniippets it would make my life a lot
easier ;-) )
3.You have to change the person.xsd to see the third thing: put
ElementNameDefault="qualified" in
the person schema, then "name", "first" and "last" should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML.
elementFormDefault="qualified" is not currently supported. I am looking
into this
> Incorrect namespaces in generated XML
> -
>
> Key: TUSCANY-1112
> URL: https://issues.apache.org/jira/browse/TUSCANY-1112
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: WinXP
>Reporter: Matthew Peters
> Fix For: Cpp-Next
>
>
> Please excuse the fact that I have only a PHP testcase for this. The PHP is
> however pretty trivial and it seems a simple thing to make in C. Also, I know
> that the PHP layer is doing very little to interfere, so this is genuine
> Tuscany behaviour.
> Here is the bug report from the PHP bug tracking system:
> Description:
>
> I have been quite sceptical about the XML that SDO is producing when it
> builds a SOAP request, especially w.r.t. the namespaces. So I tried
> loading the XML that SDO is producing into Java XERCES with validation
> on. There are several problems with the XML generated, I think.
> Using the two xsds that are in the reproduce section below, and the
> short PHP script also there, SDO generates:
>
> http://Component"; xmlns:tns="http://Component";
> xmlns:tns2="http://www.test.com/info";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:type="add">
>
>
> Will
> Shakespeare
>
>
>
> There are three (!) things wrong with this.
> 1. XERCES will not accept the xsi:type="add". I do not really know why.
> I assume this is because there is no type called "add", it's only an
> element. So I do not think this should be coming out.
> 2. name should not be in tns2=http://www.test.com/info, neither should
> "first" and "last" be in the default namespace of http://Component. The
> person.xsd has no elementFormDefault, so the elements below
> should all ne in the no name namespace.
> 3.You have to change the person.xsd to see the third thing: put
> ElementNameDefault="qualified" in
> the person schema, then "name", "first" and "last" should all now be
> coming out in the http://www.test.com/info namespace, but it makes no
> difference to the generated XML.
> Reproduce code:
> ---
> $xmldas = SDO_DAS_XML::create('types.xsd');
> $person =
> $xmldas->createDataObject('http://www.test.com/info','personType');
> $name = $person->createDataObject('name');
> $name->first = "Will";
> $name->last = "Shakespeare";
> $add = $xmldas->createDataObject('http://Component','add');
> $add->person = $person;
> $xdoc = $xmldas->createDocument('', 'BOGUS', $add);
> $xmlstr = $xmldas->saveString($xdoc, 2);
> echo $xmlstr;
> ?>
> types.xsd:
> http://www.w3.org/2001/XMLSchema";
> xmlns:ns0="http://www.test.com/info";
> targetNamespace="http://Component";
> elementNameDefault="qual
Re: Cleaning up some of the new sample modules
Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: I would like to keep the "split" structure as it currently is rather than make a last minute change just before the 0.90 RC without opportunity for discussion. (I'm on a plane tomorrow so I won't have any email access all day.) I am fine with the proposed renaming of the samples as suggested: - echo-binding to echo-binding-extension - echo-binding-appl to echo-binding - implementation-crud to implementation-crud-extension - implementation-crud-client to implementation-crud Adding the "extension" suffix to the extension samples makes the purpose of these samples clearer and solves the awkwardness over how to describe the non-extension code. Done under revision r547139. Thanks. [snip] Testing that our sample client doesn't fail with an exception is useful to us and may deserve a test in our integration test suite (if we think that having a proper unit test case testing the bits and pieces in that module is not good enough), but I don't thing that it's interesting to keep it in the sample itself, as it's not going to teach anything to an application developer looking at the sample, and doesn't look like a "normal" unit test case. Yes, agreed that this does not really belong in the samples. I would be inclined to put this test code in itest/samples, just to have the build confirm automatically that all the sample clients actually do run. It's good to have equivalent unit tests as well, but the samples are so visible that I think it's worth testing them explicitly. [snip] This is still open. +1 to that suggestion, we do not pollute the samples themselves with this kind of testing, we need to add new tests under sca/itest/samples that verify that the samples' main methods do not fail. I volunteer to produce a patch for this. I'd like to get this into 0.91. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How are we going to use the Tuscany Wiki space?
I'd like to retain the copied pages from the Tuscany web site. As Venkat said, this makes it easy for non-committers to develop and preview proposed updates to the Web site. I agree that it would be good to create a new front page for the Wiki, with the copied Web site home page http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home linked from the TUSCANYWIKI front page. Simon Simon Laws wrote: I agree. Looking at it now it is confusing with the complete copy of the web site material presented on the front page. It's not clear where the definitive source of this material is. +1 to the proposal for changing the front page of TUSCANYWIKI. I would have thought we can just start with a subpage of TUSCANYWIKI for "main site pages in preparation". Everthing else is wiki content with an organization of our choosing. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Declarative DAS - Exposing data as Services
On 6/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote: I have added a first cut of this under revision #547551 . The implementation.das right now only supports static services interfaces. My plans is to expand the implementation to handle all crud operations and also dynamic interfaces. As an example of how easy it can be to do dynamic interfaces I've refactored this in a sandbox to use the implementation spi so that the CompanyServiceTestCase now works: https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/implementation-das/ ...ant
Re: How are we going to use the Tuscany Wiki space?
I agree. Looking at it now it is confusing with the complete copy of the web site material presented on the front page. It's not clear where the definitive source of this material is. +1 to the proposal for changing the front page of TUSCANYWIKI. I would have thought we can just start with a subpage of TUSCANYWIKI for "main site pages in preparation". Everthing else is wiki content with an organization of our choosing. Regards Simon
Re: How are we going to use the Tuscany Wiki space?
Hi Mike, I agree we need to put some information on the Home page of the TUSCANYWIKI, related to how the wiki is to be used - alteast earmark some place in the page hierarchy under which discussion pages should go and how content for website should be contributed. As far as the copying of pages over to TUSCANYWIKI from TUSCANY is concerned, I thought it would be easy for folks wanting to contribute to website to be able to position their contributions better with respect to the site structure. This would get easier if contributions are coming as corrections or additions to existing pages. Am I missing a better way of doing this? - Venkat On 6/15/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Folks, I'm a bit confused (nothing out of the ordinary there then!) about how we intend to use the new Tuscany Wiki space. So, the Apache Tuscany space is the material which makes up the external Tuscany website. I understand our desire to control the update of material there - hence there is a restricted list of people who can edit pages there. So, I thought, perhaps wrongly, that the Tuscany Wiki space was created to be a space "open to all" where any kind of material can be placed by anyone. This includes different sorts of stuff, I think: a) Material that is being prepared for the Tuscany website, so that it can be checked out before it goes live. b) Discussion and similar material that is useful to help the work within the Tuscany community, but which may never reach the public website, such as design ideas related to discussions in the mailing list (good example is the stuff Simon Laws has created relating to distributed runtime). Currently, the material in the Tuscany Wiki space is simply a mirror of the Apache Tuscany space. I don't think that this is right. First, simply repeating everything that is in the main space is confusing at best. Worse, there needs to be some explanation of the use of the space and some specific navigation available, such as where to create new material and, for material intended for the main Tuscany website, some explanation of the process. I'd like folks views on this. If you agree with me, then I suggest that we should: a) Rewrite the front page of the Tuscany Wiki to explain its purpose b) Remove the Tuscany Wiki pages that are mere copies of pages on the main Wiki and adjust the navigation to separate out discussion pages from pages being prepared for the main site c) Provide an explanation of how to write pages intended for the main Tuscany website and the process for getting them there... Thoughts? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How are we going to use the Tuscany Wiki space?
Folks, I'm a bit confused (nothing out of the ordinary there then!) about how we intend to use the new Tuscany Wiki space. So, the Apache Tuscany space is the material which makes up the external Tuscany website. I understand our desire to control the update of material there - hence there is a restricted list of people who can edit pages there. So, I thought, perhaps wrongly, that the Tuscany Wiki space was created to be a space "open to all" where any kind of material can be placed by anyone. This includes different sorts of stuff, I think: a) Material that is being prepared for the Tuscany website, so that it can be checked out before it goes live. b) Discussion and similar material that is useful to help the work within the Tuscany community, but which may never reach the public website, such as design ideas related to discussions in the mailing list (good example is the stuff Simon Laws has created relating to distributed runtime). Currently, the material in the Tuscany Wiki space is simply a mirror of the Apache Tuscany space. I don't think that this is right. First, simply repeating everything that is in the main space is confusing at best. Worse, there needs to be some explanation of the use of the space and some specific navigation available, such as where to create new material and, for material intended for the main Tuscany website, some explanation of the process. I'd like folks views on this. If you agree with me, then I suggest that we should: a) Rewrite the front page of the Tuscany Wiki to explain its purpose b) Remove the Tuscany Wiki pages that are mere copies of pages on the main Wiki and adjust the navigation to separate out discussion pages from pages being prepared for the main site c) Provide an explanation of how to write pages intended for the main Tuscany website and the process for getting them there... Thoughts? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Status of DAS Release
Hi Luciano, I tested latest from trunk and the issues discussed here seemed to be fixed now. Thank you very much. Regards, Amita On 6/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote: Thanks Amita for looking into this... I have fixed the distribution issue as in TUSCANY-1348, and the logging issue as in TUSCANY-1349. I also noticed an issue with logging in dbConfig, where we were not checking if logging was enabled and always calling log, and I have also fixed that. Please let me know if things are looking better now. On 6/14/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > Small update, tried to build and test with empty repos and it went through > with no issues. > > Regards, > Amita > > On 6/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > Things tested to be working - > > all UT as part of mvn build > > all samples in different browsers. > > > > Apart from das\distribution\binary\pom.xml - change and documentation > > changes in JIRA 1335, I have a doubt in logging mechanism in web samples. > > > > In DBConfig utility , the code uses Logger.getLogger(className) - to get > > logger from log4j. > > > > Whereas in all RDB DAS code, it is > > LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS > > util. > > In this, the level is OFF - hardcoded in the code. > > > > So, when the log4j.properties file is used in tomcat to switch on logging, > > the logging works for DBConfig (as it is using direct log4j), but logging > > does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB > > DAS jar. > > > > Is this the desired behavior? Will there be any need to switch on logging > > in web samples for RDB DAS code and how to do it without touching > > tuscany-das-rdb-1.0-incubating.jar? > > > > Regards, > > Amita > > > > On 6/11/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > > > > > Hi All, > > > > > > When tried mvn -Pdistribution on das:- > > > das\distribution\binary\pom.xml - does not list ajax web sample under > > > dependency and thus does not package same > > > > > > As now, non-committer does not have access to edit wiki, I have created > > > JIRA-TUSCANY-1335 for all the pending updates for DAS I was doing. Please > > > see how these can be completed using attached zipped files. > > > > > > Architecture Guide - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+architecture+guide > > > > > > images to upload - ClassDiag.jpg, rdbDAS.gif > > > > > > User Guide - > > > http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide > > > Under Samples(See Capabilities in use) > > > Put links for:- > > > Web Sample - > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm > > > J2SE Sample - > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm > > > Advanced Web Sample - https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm > > > > > > > > > Development Guide - DAS_Java_Development_Guide.txt - need to add to wiki > > > > > > need to checkin under https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/src/main/release/RELEASE > > > NOTES > > > RELEASE_NOTES.txt > > > > > > About to complete CHANGES.txt , will add by eod to JIRA 1335.. > > > > > > Regards, > > > Amita > > > > > > On 6/10/07, Adriano Crestani <[EMAIL PROTECTED] > wrote: > > > > > > > > I went through all das samples and they seem to be working fine on > > > > Windows > > > > XP Home Edition SP 2 environment. I also corrected some links on > > > > readmes > > > > that were pointing to old tuscany website. > > > > > > > > I ran the rat on java/das directory and added Apache Licence header to > > > > files > > > > that were missing it. > > > > > > > > Regards, > > > > Adriano Crestani > > > > > > > > On 6/8/07, Luciano Resende < [EMAIL PROTECTED]> wrote: > > > > > > > > > > First of all, let me thank you all for helping on this release. > > > > > Recently there has been a lot of progress, and things are looking > > > > good > > > > > from the list of issues we had listed in the wiki [1]. The remaining > > > > > documentation tasks could probably go in parallel with the release > > > > > candidates. So, we should start thinking about creating a branch for > > > > > the next release sometime soon, probably over the weekend or Monday > > > > > and then start publishing release candidates from that. > > > > > > > > > > Also, I think we should look into the following items before we > > > > create > > > > > the first RC : > > > > > > > > > >- run rat and make the results available > > > > >- review the contents of license, readme, release_notes, changes, > > > > etc > > > > >- review javadoc > > > > >- make sure samples readme are updated and correct and the > > > > samples > > > > > are working ok on different environments > > > > > > > > > > I'd also like to suggest two other things : > > > > >- Name the release beta1, to
