Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bi
Raymond Feng wrote: Hi, Sebastien. I'm trying to play with this cool demo and I have a few questions: 1) How can I start the stockquote and accountservice under different HTTP ports (8081, 8082)? 2) What's the URL of the web 2.0 demo page? In my case, I first started StockQuoteServer, CalculatorServer and BigBankServer. Then when I tried to run BigBankClient, it failed with an exception complaining connect refused. I guess it tried to connect to the port 8081 or 8082. Thanks, Raymond The port numbers are configured in the bindings of the various services: StockQuoteService uses port 8081, as configured in StockQuote.wsdl AccountService uses port 8082, as configured in AccountService.wsdl The way the demo is configured, you can do the following: - First start both the StockQuoteServer and CalculatorServer - Then run BigBankClient. It will make a local to call the AccountService, which will in turn invoke the StockQuote service over SOAP and Calculator service over RMI. - Or run BigBankServer, and invoke the AccountService Web service using a SOAP client tool. I've been successful with the Web Services tool from the Eclipse WTP project (just right click on AccountService.wsdl and go from there). - Or deploy demo-bigbank-account .war to Tomcat (in this case the AccountService will be provided on port 8080) and again invoke the AccountService Web Service using your Web Services tool. When running on top of Tomcat, the demo also provides a DOJO based UI at http://localhost:8080/demo-bigbank-account/, which will will invoke the AccountService JSON-RPC service when you click the getAccountReport button. BigBankClient runs the same SCA composites as BigBankServer, so you'll get AddressInUse errors if you try to run it at the same time as BigBankServer. If you wanted to have a separate BigBankClient talking to the AccountService Web service it would have to be in a different Maven module and use a different composite containing an SCA reference for the AccountService. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
I think building the samples with mvn from an empty local mvn repo isn't going to work until we've actually released the 0.90 artifacts into the Incubator repository. The samples do define the Incubatory repository in their pom.xml's so it should work once released, but we can't easily test it until then ...ant On 5/23/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I downloaded the 0.90 binary distro and unzipped it locally. I also deleted my local maven repo. Then when I follow the README in tuscany-sca-0.90-incubating\samples\calculator to run mvn to build the samples, I get the following error as appended later. Am I not supposed to build the sample this way since it's a binary distro? I can see the jar is pre-built. Other than that, the ant script works well to run the pre-built samples. I think it is very nice for users to see the samples actually run in this simple way. Thanks, Raymond C:\Apache\tuscany-sca-0.90-incubating\samples\calculatormvn [INFO] Scanning for projects... Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/t uscany/sca/tuscany-sca/0.90-incubating/tuscany-sca-0.90-incubating.pom Downloading: http://repo1.maven.org/maven2/org/apache/tuscany/sca/tuscany-sca/0. 90-incubating/tuscany-sca-0.90-incubating.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:sample-calculator:jar:null Reason: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null :sample-calculator:jar:null [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache .tuscany.sca:tuscany-sca for project: null:sample-calculator:jar:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent : org.apache.tuscany.sca:tuscany-sca for project: null:sample-calculator:jar:nul l at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tu scany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:0.90-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository ) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1260) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:0.90-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository ) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:73) at
Fwd: Tuscany sample app
Hi, Really Sorry :) forgot to include geronimo-dev list in the cc after saying it should be tracked on both the lists. Please respond to this mail from now on as it has both the lists included. Regards Manu -- Forwarded message -- From: Manu George [EMAIL PROTECTED] Date: May 23, 2007 11:08 AM Subject: Re: Tuscany sample app To: tuscany-dev@ws.apache.org Hi Raymond, Thank you for the warm welcome and for the prompt response. I am adding my comments inline below. On 5/23/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Manu. Welcome to Tuscany and thank you for looking into Tuscany/Geronimo integration. Please see my comments inline below. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 22, 2007 1:00 PM Subject: Re: Tuscany sample app Hi, I am new to this list and product. I just wanted to know if there is any work going on in implementing deep integration with apache geronimo app server. If it is going on I am volunteering to help. If not I would again like to volunteer to take up that task along with anyone else interested. It would be really great that we start the Tuscany/Geronimo integration now as we have a stable Tuscany code base (the 0.90 relase are being voted on). A few of other folks have also expressed their interests in this area. Let's keep all the discussions on this ML so that all of us can participate. I'm not sure what's the best way to Sure thats the best way. Currently I have experimented a bit with deep integration and got the calculator service to deploy on geronimo.What I have achieved is the ability to deploy Tuscany services on geronimo packaged in a jar with a geronimo specific deployment descriptor. This is a very good step forward. Did you use the geronimo module plan for the jar? What I have done is I wrote 2 gbeans. One GBean takes care of rigging up and starting the ReallySmallRuntime that provided with Tuscany. The other GBean takes care of instantiating the GeronimoSCADomain class. The latter GBean should be run in the same class loader as the SCA application so that during the SCADomain creation the .composite files can be picked up. I then wrote a deployer that implements the ConfigurationBuilder interface of geronimo and implemented the methods. This deployer is also a gbean and after registration it will be called for all jars that are deployed that have META-INF/geronimo-tuscany.xml files with a particular namespace. What this deployer does is create a configuration whose classloader contains all the classes in the jar, rig the second GBean and add it to the configuration so that an SCADomain is created. In case of J2EE modules I created a Deployment Watcher class which again adds the second gbean to the configuration of the j2ee module if it contains META-INF/geronimo-tuscany.xml So when the configuration starts the second gbean also starts which starts the SCADomain and registers it in Global JNDI. When the configuration stops the domain is closed and removed from JNDI. Since the runtime just provides services to the SCADomain that contains it, I just inject the ReallySmallRuntime I created earlier into the SCADomain. What I have done is created a new Domain class GeronimoSCADomain and the only difference of this from default SCA domain is that it takes a ReallySmallRuntime as a parameter instead of creating it. So effectively one Runtime can be shared among all the SCADomains. I am assuming that there will be a single SCADomain per application and all SCADomains will share the same Runtime. Due to my lack of tuscany knowledge I am not sure if this is the way to go about it. Can any one of the tuscany gurus clarify if this is the correct approach? The SCA domain is a collection of runtimes that can host SCA composites. The domain is logically represented as a SCA composite which include all the deployable composites activated by all runtimes in the SCA domain. A SCA domain can span multiple machines over the network. It consists of all the runtimes that run SCA applications. Ok, I was unaware that a domain can have multiple runtimes. But like the webapp sample which has a single runtime I am thinking that Geronimo will also have a single runtime only. ATleast initially that may be the way to go forward. Also from what i see of the code, the runtimes just provide services which the sca domain uses to set itself up. So its my assumption that a runtime that an SCADomain accesses doesn't need to be exclusive to it but can be shared among domains. Can you advise me if this assumtion is ok? I was unable to understand the need to create multiple runtimes for each sca domain (other than for the web app based integration). If there are any other reasons can someone please explain why we need a runtime per app? ? Other things that i am experimenting with is the ability to package the tuscany service along
Re: Chat-webapp status : Fwd: Java SCA 0.90 branch
You know, I quite liked it with the -webapp suffix and had been thinking about renaming the others to be that instead of -web. What do people think, isn't -webapp much more descriptive about what the samples are? ...ant On 5/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I have fixed a small issue on on the ajax binding, that was causing a NPE during server shutdown, and also renamed the chat sample application to follow the same pattern other web applications were using (e.g calculator-web). With this, here is my +1 to get the sample added to the build. On 5/21/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ant The problem was due case mismatches on the case of the composite name (chat versus Chat), after fixing, there was no requirement to have the sca-deployables anymore. I have committed these changes + some small changes to send the message when you press ENTER under revision #540345. BTW, any plans to get the binding and sample in the build ? -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: May 18, 2007 2:07 AM Subject: Re: Java SCA 0.90 branch To: tuscany-dev@ws.apache.org I've tried to use this with the ajax chat sample but can't get it to work. I suppose as the calculator-web sample works this is probably a problem with the sample but I can't see anything wrong, can any one else? I've moved the chat sample and binding-ajax to trunk, but they're not in the build so you need to build them separately, then the chat sample only works with the sca-deployables directory, delete that and it should use the sca-contribution.xml file but that seems to be ignored, can anyone see why? ...ant On 5/17/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed to trunk, under revision # r539127 a fix to place sca-contribution on the right location in a war file, this also had a small change on the host-webapp module in order to properly find the root of the contribution. Should these changes be merged into the branch ? What's the right process to do this ? Just merge ? or via JIRA ? On 5/17/07, ant elder [EMAIL PROTECTED] wrote: The Tuscany Java SCA 0.90 release branch is available now: https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.90/ It all seems to build cleanly and the samples work, the source and binary distributions created from that are available at: http://people.apache.org/~antelder/tuscany/latest/ All going well I'll make an official RC from that to vote on tomorrow, be great if anyone could give it a try to test things out before then. There's still some open JIRA's: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312478 The branch version is 0.90-incubating-SNAPSHOT and the final release will be 0.90-incubating, does that sound ok? And we still need to finish the release notes... ...ant -- Luciano Resende http://people.apache.org/~lresende -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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]
CTS suite SDO version 1.0-incubator-SNAPSHOT or 1.0-incubating-SNAPSHOT?
The CTS code pom.xml's currently use SDO version 1.0-incubator-SNAPSHOT but that should be 1.0-incubating-SNAPSHOT now shouldn't it? Using the 1.0-incubating-SNAPSHOT SDO version and running CTS I get: Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite CTS_TEST_HELPER was not set - attempting Tuscany implementation : null Loaded test.sdo21.vendor.tuscany.testHelper.TuscanyTestHelper Tests run: 486, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 3.891 sec FAILURE! Is this expected? Could I comment out the failing test with a FIXME comment so the CTS build runs clean? ...ant
[jira] Commented: (TUSCANY-1295) Resolve Memory Leaks in RDB DAS source and test cases code
[ https://issues.apache.org/jira/browse/TUSCANY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498146 ] Adriano Crestani commented on TUSCANY-1295: --- Hi Amita, I got a problem with the file MultiSchemaTests.java. It seems mixed the data of three files in one. Cause there are three MultiSchemaTests class defined along the file. I haven't check if they are the same, like if someone copied the class and pasted twice in the same file. Can you check this out? The same happens on MultiSchemaData.java. Resolve Memory Leaks in RDB DAS source and test cases code -- Key: TUSCANY-1295 URL: https://issues.apache.org/jira/browse/TUSCANY-1295 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M3 Reporter: Amita Vadhavkar Fix For: Java-DAS-Mx Attachments: JIRA1295_952_May21.txt, JIRA1295_952_May21.txt, JIRA1295_952_May22.txt, JProfReportsMay21.zip, JProfReportsMay21.zip It is seen that as the number of test cases in RDB DAS JUnit testing increase, the memory consumption increase and beyond a certail limit, there is OutOfMemory exception for heap memory. This JIRA is created to elaborate the cause-solution for this and provide the fix. -- 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: Java SCA - Including fix numbers in release docs
Yes +1 to XXX-Next. I really don't like making unnecessary 'rules' or policy or trying to restrict or control who can do something. If we can't find a less relaxed way to do this then I'd prefer to just not include the JIRA list in the release notes. Couldn't it just be whoever adds the jira list to the release notes checks the list is correct and that will also be validated during everyones review of the release? ...ant On 5/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I think using XXX-Next seems more appropriate now, that we are going out of milestone releases. As for the JIRA process, I think that Kevin's original proposal seems good and would be consistent no matter witch phase of development/release we are, it also leaves room to the Release Manager to control the open issues, like Ant suggested, as the RM can start moving open issues to a specific fix version when approaching the release time. As for Release process, some info available at [1] and we could probably make it more generic to be a Tuscany release process. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Release+Process On 5/22/07, kelvin goodson [EMAIL PROTECTED] wrote: I think my proposal is consistent with your desire to get the overview. When entering the new release phase, all JIRAs fixed in the period since the last release would be reclassified to the newly created version tag, along with all JIRAs that the community sees as important for the forthcoming release. However, an alternative rule of thumb would be that its always safe to use the *Next version as the fix version, whether raising or resolving a JIRA. Only use a specific version if you really are sure that either the resolution of the defect is a blocker for a release or that the fix you have committed will definitely make it into a release. I just liked the simplicity of my original proposal. Kelvin On 22/05/07, ant elder [EMAIL PROTECTED] wrote: One of the problems with not assigning the specific fix version to JIRA's till the end is that you can't see whats outstanding from the JIRA overview page which is something I've found useful and have used it in past releases to manage what things need to get done. See http://issues.apache.org/jira/browse/TUSCANY Maybe just more knowledge about how the versions get used would be enough? ...ant On 5/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Java SDO has been doing this using an Java-SDO-Mx release rather than Java-SDO-Next, but as I said on IRC I think the Next naming is much better. I propose that we adopt the policy that no-one other than a release manager ever assigns anything other than a *Next value for the fix release of a JIRA. The reason I say this is that it makes it simpler around the time of the release. I noted that at the time of the recent SDO release a couple of JIRAs got closed with a fix-version of beta1 after the last release candidate had been cut, but before the beta1 had been released. As there is this time of uncertainty I think its far better to leave the job of assigning a real fix-release value to a JIRA. Its easy for the RM to do a bulk change on all *Next jiras at the appropriate time to whatever the real release becomes know as. Regards, Kelvin. On 21/05/07, haleh mahbod [EMAIL PROTECTED] wrote: It would be good if all subprojects used whatever scheme it is agreed to so a developer going across projects does not have to think about adjusting. On 5/21/07, Simon Laws [EMAIL PROTECTED] wrote: This time round, as so much had changed, we didn't include JIRA numbers in the release docs. It seems like a good thing to do in the future though. If everyone agrees that this is a good thing we need to be fairly organized about how we use JIRA otherwise we suffer a lot of pain come release time working out what the list should look like. So, from the IRC today, it has been suggested that we take care to note what release a fix targets using the protocol that the release is Java-SCA-Next until we get to release time and decide what the release number is. At that point we switch over all the fixes that make the release to the right number. This may well have been the intention all along as I note that the Java-SCA-Next category has a lot of fixes in it. I'll take a look through it and see if I can work out what the state of play is so we can start filling it up again. Anything else we should be doing with respect to JIRA to make the release process easier? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: CTS suite SDO version 1.0-incubator-SNAPSHOT or 1.0-incubating-SNAPSHOT?
Ant, I changed the dependency versions, and I added incubating to the version tags of the CTS artifacts. I still suffer from the issue that I get 0 tests run in my maven environment, but I get 100% success when running the tests in eclipse. Can you please update and rerun in maven and let me know if that fixes your failing test. Kelvin. On 23/05/07, ant elder [EMAIL PROTECTED] wrote: The CTS code pom.xml's currently use SDO version 1.0-incubator-SNAPSHOTbut that should be 1.0-incubating-SNAPSHOT now shouldn't it? Using the 1.0-incubating-SNAPSHOT SDO version and running CTS I get: Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite CTS_TEST_HELPER was not set - attempting Tuscany implementation : null Loaded test.sdo21.vendor.tuscany.testHelper.TuscanyTestHelper Tests run: 486, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 3.891sec FAILURE! Is this expected? Could I comment out the failing test with a FIXME comment so the CTS build runs clean? ...ant
Re: CTS suite SDO version 1.0-incubator-SNAPSHOT or 1.0-incubating-SNAPSHOT?
Hi, just spotted that you were already running with the incubating version, so there's a mystery why there is a failing test. Can you let me have the surefire report please? Kelvin. On 23/05/07, ant elder [EMAIL PROTECTED] wrote: The CTS code pom.xml's currently use SDO version 1.0-incubator-SNAPSHOTbut that should be 1.0-incubating-SNAPSHOT now shouldn't it? Using the 1.0-incubating-SNAPSHOT SDO version and running CTS I get: Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite CTS_TEST_HELPER was not set - attempting Tuscany implementation : null Loaded test.sdo21.vendor.tuscany.testHelper.TuscanyTestHelper Tests run: 486, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 3.891sec FAILURE! Is this expected? Could I comment out the failing test with a FIXME comment so the CTS build runs clean? ...ant
Re: CTS suite SDO version 1.0-incubator-SNAPSHOT or 1.0-incubating-SNAPSHOT?
All works for me now, there's was a missing woodstox dependency, I've added that and now i get: [INFO] [INFO] Reactor Summary: [INFO] [INFO] Community Test Suite .. SUCCESS [ 1.547s] [INFO] Community Test Suite for SDO 2.1 .. SUCCESS [ 2.969s] [INFO] Tuscany SDO 2.1 CTS ... SUCCESS [ 5.078s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] ...ant On 5/23/07, kelvin goodson [EMAIL PROTECTED] wrote: Ant, I changed the dependency versions, and I added incubating to the version tags of the CTS artifacts. I still suffer from the issue that I get 0 tests run in my maven environment, but I get 100% success when running the tests in eclipse. Can you please update and rerun in maven and let me know if that fixes your failing test. Kelvin. On 23/05/07, ant elder [EMAIL PROTECTED] wrote: The CTS code pom.xml's currently use SDO version 1.0-incubator-SNAPSHOTbut that should be 1.0-incubating-SNAPSHOT now shouldn't it? Using the 1.0-incubating-SNAPSHOT SDO version and running CTS I get: Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite CTS_TEST_HELPER was not set - attempting Tuscany implementation : null Loaded test.sdo21.vendor.tuscany.testHelper.TuscanyTestHelper Tests run: 486, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 3.891sec FAILURE! Is this expected? Could I comment out the failing test with a FIXME comment so the CTS build runs clean? ...ant
[jira] Commented: (TUSCANY-1295) Resolve Memory Leaks in RDB DAS source and test cases code
[ https://issues.apache.org/jira/browse/TUSCANY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498182 ] Amita Vadhavkar commented on TUSCANY-1295: -- Hi Adriano, First apologies as my connection to chat dropped for 40 mins, some n/w issues. Now in the JIRA1295_952_May22.txt below are the lines - 704-795-MultiSchemaData, 1159-1181-MultiSchemaTests Here in the patch file itself the code is not appearing more than once, so when applying the patch on the code from trunk same should be the case. I verified it by applying on the trunk code too. Is there a chance that you are applying this patch on the top of some previous patch? (I also found that revert command from svn is removing these 2 files from svn but keeping a local copy in the eclipse workspace. So, if you are having an old workspace and might have done revert on some old patch, these 2 files in questions will still be there locally, though not under version control. And then if you apply the May 22nd patch, you may be getting this issue.) In that case, please take a fresh code from trunk and apply this patch, it should not give any duplicate / triplicate code. Please let me know what you find. Regards, Amita Resolve Memory Leaks in RDB DAS source and test cases code -- Key: TUSCANY-1295 URL: https://issues.apache.org/jira/browse/TUSCANY-1295 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M3 Reporter: Amita Vadhavkar Fix For: Java-DAS-Mx Attachments: JIRA1295_952_May21.txt, JIRA1295_952_May21.txt, JIRA1295_952_May22.txt, JProfReportsMay21.zip, JProfReportsMay21.zip It is seen that as the number of test cases in RDB DAS JUnit testing increase, the memory consumption increase and beyond a certail limit, there is OutOfMemory exception for heap memory. This JIRA is created to elaborate the cause-solution for this and provide the fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS M3 Release
Hi, Please take a look at the section Ongoing work items on page http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release and whatever is marked under review, please review and give your comments. This will help a lot in doing any necessary modifications to the DAS part of site. Also, I am gathering DAS questions discussed on ML and forming a FAQ, some archived messages are listed in the same section at the bottom. Please forward any FAQs you would like to include. Regards, Amita (Note: For memory analysis JIRA 1295 is added and patch is submitted, currently under review.) On 5/21/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, It is still work-in-progress. Main changes I did are 1) use simple connection pool on Test Cases framework 2) use finalize() in RDB DAS code 3) Do cleanup (removing references) as needed 4) Decouple DatabaseSetup and DasTest - do not share connections With this, there is some success (i.e. I modified a few cases with these changes effective and the multi-schema are running with no out of memory , I repeated the same testcases multiple times to increase number of test cases) Now, I am trying the change on all test cases and will create a new JIRA with patch for the changes. This is not eliminating the memory leak 100% ,but reducing it. Will respond to this mail with the new JIRA number. Regards, Amita On 5/19/07, Adriano Crestani [EMAIL PROTECTED] wrote: Amita, did you solve the JIRA 952 memory leak problem? Except JIRA 800 that luciano is going to commit, is there any other new feature or bug to be implemented for this release? Adriano Crestani On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the initial part of TUSCANY-863 under revision 538267.** On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, Points I gathered so far, we can sort out today. Will check more TODOs: 1) close JIRA-800, 863 2) remove JIRA-952 ? please see my last mail for memory leak, it still can happen with code without JIRA-952. It looks like it has to do with how our UT framework is setup.But so far I have not pin pointed the problem. So what path to follow for this JIRA? I will try more and find exact cause and resolution. 3) check all files license info (Adriano did this before, so just for any new code after that, we might need to do this.) 4) update http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+M3+Release with closed/removed JIRAs 5) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS [javadoc] - give link *Guides:- -Architecture Guide - should be on Tuscany Home Page and not DAS -Developer Guide - complete - how is working on it? (Some content from http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp can be used and completed here) Some content for htmlunit - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg06053.html -User Guide - Advanced Web Sample - add link to this after JIRA-863, 800 are commited , dbsetuputility - as its a handy tool for users too -What's new? - list new features in this release -Downloads - add links after 1st RC - [New]Useful Links - http://incubator.apache.org/tuscany/RDB_DAS_white_paper_v-0.2.pdf(for outdated info - how to update?)http://issues.apache.org/jira/browse/TUSCANY-594 - TBD http://java.sys-con.com/read/260053.htm (for outdated info - how to update?) 6) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS 7) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Releases Make this page in sync with what is going out in M3 8) page - http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+Java+-+FAQ Can add below list:- http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04822.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16300.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16711.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01162.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16520.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg00589.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg06635.html How to create non containment association ? http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12091.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17136.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg05860.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17146.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09827.html
Re: Better support for dynamic language components
Hi Just started looking at this in the context of bringing the aggregator sample to the Java runtime. I like the idea of having a dynamic interface as an option as it reduces the amount of configuration. The term dynamic term confused me to start with - I initially thought this was about constructing scripts with dynamic invocation style operations rather than the about the relationship between the SCA model and the defined script interface. Not really deeply into this yet but a question to start with. Is there any way with the script container you are using of introspecting the methods that scripts provide? Simon
Re: Tuscany DAS Features/Questions
Hi Folks,
Can I create JIRAs for these and mark them for DAS Mx, just to have a
pointer to come back to these features?
Regards,
Amita
On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
It will be interesting to get these features into DAS using JIRAs.
I am just trying to get a clear picture of what all details these features
can consist.
1. This can be support for explicit as well as SDO-integrated
inserts/updates
2. a. Here validations can be based on Database provided Meta Data, also,
we can think of defining custom validations per Command basis in DAS
config. What do you think?
2. b. As part of {2. c. 2} , This will have more control on individual
DataGraphs contained
in the root Data Graph. With this, invalid (validation failed) Data Graphs
can be
deleted from the tree. The dependency management logic will need to handle
the consequent
actions for this deletion(parent-child etc.).
2. c. There can be 2 situations -
1 when the data graphs are not of related database entities, here
different config files can split the work
2 when they are for related entities, the worker threads will be sharing
part of load
of same transaction.
Please add your thoughts and any more desirable but missing features, that
DAS can
take up.
Regards,
Amita
On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote:
Should we start creating some JIRAs for these enhancement requests ?
On 5/14/07, Brent Daniel [EMAIL PROTECTED] wrote:
1. Not today, though I think this would be a good feature for the DAS
to pick up.
2 a. No, but that would be an interesting capability. Today I think
validation would best be performed at the client level.
b. It's probably easiest to do this on a case by case basis..
Unfortunately I don't think there's an easy way to undo individual
changes (though you can always undo everything using
ChangeSummary.undoChanges()). To undo an insert, you can simply
delete the DataObject. For property changes, you can use
changeSummary.getOldValues () to get the previous values and re-set
them. I'm not sure if anything easier is coming in future versions of
SDO or not.
c. The DAS has some paging capability for situations like this. From
your description of your application, it sounds like you may also be
able to simply break the app down so that you use several different
config files with independent DataGraphs.
Brent
On 5/11/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Greetings,
We are considering replacing some of our custom, home-grown DAS'
with
Tuscany DAS. As a result, I have a few Tuscany DAS questions.
1. Does the Tuscany DAS have any support for JDBC Batch
Update/Insert
operations?
2. I have a multi-tiered application in which I send a DataGraph of
DataObjects from the middle-tier to a client and later receive the
updated
DataGraph from that client. I would like to apply validation to some
of the
DataObjects in the DataGraph before the changes are persisted to the
database.
a. Is there a mechanism for integrating my validation into the
DAS'
applyChanges() operation to avoid the overhead of traversing the
ChangeSummary twice, once by me and once by the DAS?
b. When a single DataObject fails validation, what is the best
way
for me to undo the changes to that particular DataObject so the DAS
ignores
just those changes and doesn't persist them to the database?
c. The DataGraph of changed DataObjects if often large in my
application. Also, my custom validation logic is quite expensive. So,
I
would like to break the DataGraph into multiple sub-DataGraphs and
execute
the validation logic and the DAS' applyChanges() on separate
WorkManager
threads. I am doing something like that today with my own home-grown
DAS
that is custom to my trivial data model, whereby the DataGraph is
simply a
container for a list of DataObjects that map one-to-one to a database
table.
Thanks in advance for your assistance/insights,
- Ron
-
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
http://people.apache.org/~lresende
Re: Better support for dynamic language components
On 5/23/07, Simon Laws [EMAIL PROTECTED] wrote: Hi Just started looking at this in the context of bringing the aggregator sample to the Java runtime. I like the idea of having a dynamic interface as an option as it reduces the amount of configuration. The term dynamic term confused me to start with - I initially thought this was about constructing scripts with dynamic invocation style operations rather than the about the relationship between the SCA model and the defined script interface. Very open to alternative names, an 'any' interface was also suggested previously is that better? or something else? Not really deeply into this yet but a question to start with. Is there any way with the script container you are using of introspecting the methods that scripts provide? Not yet no, currently neither JSR-223 or BSF really provide any introspection capabilities. I'd like to get this capability added to BSF. We could do this on a language by language basis doing language specific things in Tuscany and eventually moving that to BSF, so if you have a specific language you'd like to get working with introspection go for it, and I'd be happy to help. One problem with introspection and dynamic languages is that as things can be handled dynamically at runtime there's not necessarily going to be anything there to introspect, so ideally most things should work without requiring introspection. The latest Groovy beta release now supports annotations, I'd really like to get that working with Tuscany so it supports the SCA annotations spec, we'd need introspection to support that. Probably be easiest to do this in a separate implementation.groovy module (at least to start with), be a great thing to look at if anyone is interested in having a go. ...ant
Re: Tuscany DAS Features/Questions
How about DAS-Next as thats what we've talked about using as the name for
the next release of all the other Tuscany projects? (I've just renamed
DAS-Mx to DAS-Next in JIRA).
...ant
ps, you don't need to be asking to create a jira, just do it if you think it
helps.
On 5/23/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi Folks,
Can I create JIRAs for these and mark them for DAS Mx, just to have a
pointer to come back to these features?
Regards,
Amita
On 5/15/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
It will be interesting to get these features into DAS using JIRAs.
I am just trying to get a clear picture of what all details these
features
can consist.
1. This can be support for explicit as well as SDO-integrated
inserts/updates
2. a. Here validations can be based on Database provided Meta Data,
also,
we can think of defining custom validations per Command basis in DAS
config. What do you think?
2. b. As part of {2. c. 2} , This will have more control on individual
DataGraphs contained
in the root Data Graph. With this, invalid (validation failed) Data
Graphs
can be
deleted from the tree. The dependency management logic will need to
handle
the consequent
actions for this deletion(parent-child etc.).
2. c. There can be 2 situations -
1 when the data graphs are not of related database entities, here
different config files can split the work
2 when they are for related entities, the worker threads will be
sharing
part of load
of same transaction.
Please add your thoughts and any more desirable but missing features,
that
DAS can
take up.
Regards,
Amita
On 5/15/07, Luciano Resende [EMAIL PROTECTED] wrote:
Should we start creating some JIRAs for these enhancement requests ?
On 5/14/07, Brent Daniel [EMAIL PROTECTED] wrote:
1. Not today, though I think this would be a good feature for the
DAS
to pick up.
2 a. No, but that would be an interesting capability. Today I think
validation would best be performed at the client level.
b. It's probably easiest to do this on a case by case basis..
Unfortunately I don't think there's an easy way to undo individual
changes (though you can always undo everything using
ChangeSummary.undoChanges()). To undo an insert, you can simply
delete the DataObject. For property changes, you can use
changeSummary.getOldValues () to get the previous values and re-set
them. I'm not sure if anything easier is coming in future versions
of
SDO or not.
c. The DAS has some paging capability for situations like this. From
your description of your application, it sounds like you may also be
able to simply break the app down so that you use several different
config files with independent DataGraphs.
Brent
On 5/11/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Greetings,
We are considering replacing some of our custom, home-grown DAS'
with
Tuscany DAS. As a result, I have a few Tuscany DAS questions.
1. Does the Tuscany DAS have any support for JDBC Batch
Update/Insert
operations?
2. I have a multi-tiered application in which I send a DataGraph
of
DataObjects from the middle-tier to a client and later receive the
updated
DataGraph from that client. I would like to apply validation to some
of the
DataObjects in the DataGraph before the changes are persisted to the
database.
a. Is there a mechanism for integrating my validation into the
DAS'
applyChanges() operation to avoid the overhead of traversing the
ChangeSummary twice, once by me and once by the DAS?
b. When a single DataObject fails validation, what is the best
way
for me to undo the changes to that particular DataObject so the DAS
ignores
just those changes and doesn't persist them to the database?
c. The DataGraph of changed DataObjects if often large in my
application. Also, my custom validation logic is quite expensive.
So,
I
would like to break the DataGraph into multiple sub-DataGraphs and
execute
the validation logic and the DAS' applyChanges() on separate
WorkManager
threads. I am doing something like that today with my own home-grown
DAS
that is custom to my trivial data model, whereby the DataGraph is
simply a
container for a list of DataObjects that map one-to-one to a
database
table.
Thanks in advance for your assistance/insights,
- Ron
-
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
http://people.apache.org/~lresende
Re: Java SCA - Including fix numbers in release docs
+1 XXX-Next I don't mind who assigns JIRA to the release number. It can't be done though until we know that the release number will be (was quite late in the last cycle). Hopefully we will do more frequent releases from now so there will be few JIRAs in the XXX-Next box and more with the actual release tag. Simon
Work items for the next release?
Now that the 0.90 release is almost out i was wondering about what things to work on next and came up a list of possibilities. Its not meant as any sort of complete list, just things that came to mind skimming over SVN, and it leaves out things others have been talking about as it was more for what I could be doing. I wondered if any one had any comments on which of these sounded useful, or not so useful, which would be good to get done soon or in the next release, of if there were other things not on this list which might be better to get done first? Anyone want to do or help with any of these? Ones that interest me for the next release which I've already started looking at are some of the Script items and the JMS and AMQP bindings. ...ant Axis2 - work without pre-existing wsdl doc - support attachments - support accessing/setting SOAP headers - WS-RM and WS-Security - support WSA EPR in binding.ws - async - conversational - Fix open jira's about ?wsdl and endpoint url - support setting some optional stuff like Axis2 handlers, chunking, soap version etc Sort out our WSDL tooling story - get SDO integrated into Axis2? IDLs - support WSDL 2.0 Runtime - async - conversational Script - optional .componentType sidefile - 'any' style proxy for languages that support this - support XML style as appropriate - E4X, ReXML etc - groovy with annotations WebApp - conversational and sessions - fix static servletHost - deep integration Binding-JMS - get going agian - support async - support 1.0 spec Binding-ampq - create a new amqp binding - support async Binding-hessian - get going agian binding-ajax - fix issue with reference needing same thread as a service binding-jsonrpc - fix current issues - servlet non-transient etc - can we get comet/reverse ajax style references working? implementation-bpel - get old Ode code going again and finish EJB extension - get JIRA code integrated and working in the new runtime policy - get at least one working (security/rm in Axis2?) spring container - get it going again Mediation - as a minimum some sort of Mediator.mediate(Message) interface services can use? Distributions - don't want to always distribute *everything* - maybe distributions targeting each runtime and you can +/- extensions when you build the distro?
Re: Java SCA - Including fix numbers in release docs
I really don't like making unnecessary 'rules' or policy or trying to restrict or control who can do something I think you are probably right, that's why I suggested the alternative rule of thumb, which is nothing more than common sense really. I think the important thing is instilling an understanding that the field will be used at release time and therefore its helpful to do the right thing with it. If we can't find a less relaxed way to do this then I'd prefer to just not include the JIRA list in the release notes. Couldn't it just be whoever adds the jira list to the release notes checks the list is correct and that will also be validated during everyones review of the release? Sure, but in the absence of certainty about the fix-release field accuracy the query that the RM must use would probably be based on the fixes that occurred between the revision numbers for when the branches and tags of the previous and current releases were cut, taking into account any porting of fixes between trunk/branch/tag after their creation. It works, I'm sure, it's just harder work :-( Kelvin. ...ant On 5/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I think using XXX-Next seems more appropriate now, that we are going out of milestone releases. As for the JIRA process, I think that Kevin's original proposal seems good and would be consistent no matter witch phase of development/release we are, it also leaves room to the Release Manager to control the open issues, like Ant suggested, as the RM can start moving open issues to a specific fix version when approaching the release time. As for Release process, some info available at [1] and we could probably make it more generic to be a Tuscany release process. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Release+Process On 5/22/07, kelvin goodson [EMAIL PROTECTED] wrote: I think my proposal is consistent with your desire to get the overview. When entering the new release phase, all JIRAs fixed in the period since the last release would be reclassified to the newly created version tag, along with all JIRAs that the community sees as important for the forthcoming release. However, an alternative rule of thumb would be that its always safe to use the *Next version as the fix version, whether raising or resolving a JIRA. Only use a specific version if you really are sure that either the resolution of the defect is a blocker for a release or that the fix you have committed will definitely make it into a release. I just liked the simplicity of my original proposal. Kelvin On 22/05/07, ant elder [EMAIL PROTECTED] wrote: One of the problems with not assigning the specific fix version to JIRA's till the end is that you can't see whats outstanding from the JIRA overview page which is something I've found useful and have used it in past releases to manage what things need to get done. See http://issues.apache.org/jira/browse/TUSCANY Maybe just more knowledge about how the versions get used would be enough? ...ant On 5/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Java SDO has been doing this using an Java-SDO-Mx release rather than Java-SDO-Next, but as I said on IRC I think the Next naming is much better. I propose that we adopt the policy that no-one other than a release manager ever assigns anything other than a *Next value for the fix release of a JIRA. The reason I say this is that it makes it simpler around the time of the release. I noted that at the time of the recent SDO release a couple of JIRAs got closed with a fix-version of beta1 after the last release candidate had been cut, but before the beta1 had been released. As there is this time of uncertainty I think its far better to leave the job of assigning a real fix-release value to a JIRA. Its easy for the RM to do a bulk change on all *Next jiras at the appropriate time to whatever the real release becomes know as. Regards, Kelvin. On 21/05/07, haleh mahbod [EMAIL PROTECTED] wrote: It would be good if all subprojects used whatever scheme it is agreed to so a developer going across projects does not have to think about adjusting. On 5/21/07, Simon Laws [EMAIL PROTECTED] wrote: This time round, as so much had changed, we didn't include JIRA numbers in the release docs. It seems like a good thing to do in the future though. If everyone agrees that this is a good thing we need to be fairly organized about how we use JIRA otherwise we suffer a lot of pain come release time working out what the list should look like. So, from the IRC today, it has been suggested that we take care to note what release a fix targets
Re: Work items for the next release?
Ant Wow, thats what I call a list. I can add a couple of things to the list that I want to work on for the next release. Runtime Distributed domains (simple version of anyhow) Demos Port feed aggregator over from Native SCA - has implications for scriting so I can help out there a bit. So from this there are bound to be some runtime implementation additions and I can support a bit of effort on the scripting side of things. Other than that I see this as a breadth vs depth question. I.e. Do we make what we have 100% or do we add new features. Certainly there needs to be a bit of both but as we are not at 1.0 yet, It would be good to get more breadth first to really shake down the runtime with the widest possible set of features and then consolidate into 1.0. Just my opinion. On this basis I would also like to add CXF integration to the list as I discussed it at ApacheCon. I have also seen other things mentioned on the list recently Deeper integration with Geronimo (is this what you mean by WebApp - deep integration?) host/implementation.osgi? implementation.xslt (some support in scripting now - do we need more) Not sure what timescales for last points are of course, and I'm not suggesting all this for the next release, but they have at least been raised as interesting on the list. So what do we do with out wish list? How about we Raise all of these as feature requests in JIRA and put a query up on the web site for retrieving them? We could even use the voting feature to indicate who is interested in what? Simon
Re: Chat-webapp status : Fwd: Java SCA 0.90 branch
I'm fine with both ways, just want to make consistent. On 5/23/07, ant elder [EMAIL PROTECTED] wrote: You know, I quite liked it with the -webapp suffix and had been thinking about renaming the others to be that instead of -web. What do people think, isn't -webapp much more descriptive about what the samples are? ...ant On 5/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I have fixed a small issue on on the ajax binding, that was causing a NPE during server shutdown, and also renamed the chat sample application to follow the same pattern other web applications were using (e.g calculator-web). With this, here is my +1 to get the sample added to the build. On 5/21/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ant The problem was due case mismatches on the case of the composite name (chat versus Chat), after fixing, there was no requirement to have the sca-deployables anymore. I have committed these changes + some small changes to send the message when you press ENTER under revision #540345. BTW, any plans to get the binding and sample in the build ? -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: May 18, 2007 2:07 AM Subject: Re: Java SCA 0.90 branch To: tuscany-dev@ws.apache.org I've tried to use this with the ajax chat sample but can't get it to work. I suppose as the calculator-web sample works this is probably a problem with the sample but I can't see anything wrong, can any one else? I've moved the chat sample and binding-ajax to trunk, but they're not in the build so you need to build them separately, then the chat sample only works with the sca-deployables directory, delete that and it should use the sca-contribution.xml file but that seems to be ignored, can anyone see why? ...ant On 5/17/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed to trunk, under revision # r539127 a fix to place sca-contribution on the right location in a war file, this also had a small change on the host-webapp module in order to properly find the root of the contribution. Should these changes be merged into the branch ? What's the right process to do this ? Just merge ? or via JIRA ? On 5/17/07, ant elder [EMAIL PROTECTED] wrote: The Tuscany Java SCA 0.90 release branch is available now: https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.90/ It all seems to build cleanly and the samples work, the source and binary distributions created from that are available at: http://people.apache.org/~antelder/tuscany/latest/ All going well I'll make an official RC from that to vote on tomorrow, be great if anyone could give it a try to test things out before then. There's still some open JIRA's: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312478 The branch version is 0.90-incubating-SNAPSHOT and the final release will be 0.90-incubating, does that sound ok? And we still need to finish the release notes... ...ant -- Luciano Resende http://people.apache.org/~lresende -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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] -- 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: [VOTE] Release Tuscany Java SCA 0.90-incubating
This seems quite scary: Release then Test. Can't we use a staging maven respository to perform a pre-release test? Would this require extensive changes to POMs? I'm at a conference this week and unfortunately I haven't been able to give the release candidate a thorough review and workout. I have looked through the contents and tried a few samples. I noticed a minor problem with the javadoc, which isn't a showstopper for this release. The top-level docs/javadoc/index.html file only lists the org.apache.tuscany.* packages. It should also list the org.osoa.sca.* packages. Simon ant elder wrote: I think building the samples with mvn from an empty local mvn repo isn't going to work until we've actually released the 0.90 artifacts into the Incubator repository. The samples do define the Incubatory repository in their pom.xml's so it should work once released, but we can't easily test it until then ...ant On 5/23/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I downloaded the 0.90 binary distro and unzipped it locally. I also deleted my local maven repo. Then when I follow the README in tuscany-sca-0.90-incubating\samples\calculator to run mvn to build the samples, I get the following error as appended later. Am I not supposed to build the sample this way since it's a binary distro? I can see the jar is pre-built. Other than that, the ant script works well to run the pre-built samples. I think it is very nice for users to see the samples actually run in this simple way. Thanks, Raymond C:\Apache\tuscany-sca-0.90-incubating\samples\calculatormvn [INFO] Scanning for projects... Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/t uscany/sca/tuscany-sca/0.90-incubating/tuscany-sca-0.90-incubating.pom Downloading: http://repo1.maven.org/maven2/org/apache/tuscany/sca/tuscany-sca/0. 90-incubating/tuscany-sca-0.90-incubating.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:sample-calculator:jar:null Reason: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null :sample-calculator:jar:null [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache .tuscany.sca:tuscany-sca for project: null:sample-calculator:jar:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent : org.apache.tuscany.sca:tuscany-sca for project: null:sample-calculator:jar:nul l at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tu scany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:0.90-incubating from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository ) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1260)
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
I think the shop window factor is an important consideration. The cumulative effect of the issues that people have reported seems to be significant enough from this perspective that a respin is desirable. In particular, the build and sample README problems could be quite off-putting to a novice user. Simon Simon Laws wrote: I've given the src and binary distros a spin on linux. My configuration is Fedora Core5 IBM JDK 1.5.0 Maven 2.0.6 Binary: I concur with Luciano that the READMEs for calculator-rmi-reference calculator-rmi-service implementation-crud now don't match the way that the samples are currently organized. I'm reluctant to agree to go with this release when our shop window isn't fully functional. I have checked fixes in for the calculator sample to the 0.9branch and head. Luciano's fix for implementation-crud looks good to me. Source: This fails to build under maven in my environment. The culprit is the maven-jaxb-plugin. The pom provided with the version that we refer in our poms, e.g. databinding-jaxb, has a non-UTF8 character in one of the author names which causes the maven build to fail with the IBM JDK 1.5.0 on Linux. I can confirm that this does not cause a problem with the same JDK (same version and build at least) on Windows XP. I tried using different maven-jaxb-plugins from a variety of repositories. All failed for other reasons. There is a manual work around to the problem, i.e. remove the non-UTF8 characters, so I don't think that this, on its own is a blocker. I've raised http://issues.apache.org/jira/browse/TUSCANY-1296 for this. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
Hi, Simon. Do you have any luck to fix the problem? If not, we probably have to document the limitation and let the release out. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 22, 2007 10:35 AM Subject: Re: [VOTE] Release Tuscany Java SCA 0.90-incubating OK, so I can't get the compile to work on my linux box with a simple change to the version/location of the maven-jaxb-plugin that the build uses. I'm going to upgrade my JDK and see if that has a positive effect but of course that has no bearing on the SCA release. As this problem is restricted to a particular JDK on a particular platform then we can post a note about how to get round the problem manually. I would really like to fix the readmes but if that's the only thing then I can live with a note on the web page for that. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bi
Hi, I followed your instructions, but I still saw the failure as shown below. It seems that the web services are running under 8080. Does the binding.axis2 now honor the port from the soap address in the WSDL? Thanks, Raymond log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Calling account service for customer: 1234 Checking account: CHA_1234, balance:500.0 Savings account: SAA_1234, balance:1500.0 Stock account: STA_1234, symbol:IBM, quantity:100 Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy7.getQuote(Unknown Source) at bigbank.account.AccountServiceImpl.getAccountReport(AccountServiceImpl.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy4.getAccountReport(Unknown Source) at bigbank.client.BigBankClient.main(BigBankClient.java:42) Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:221) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:92) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:71) at org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) ... 14 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:314) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:201) ... 22 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:179) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:73) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) ... 23 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346) at
Tuscany/Geronimo deep integration was: Re: Tuscany sample app
Hi, Manu. Would it be possible that you make your code available in a JIRA? This way, we can look into it to better understand your approach. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 22, 2007 10:38 PM Subject: Re: Tuscany sample app Hi Raymond, Thank you for the warm welcome and for the prompt response. I am adding my comments inline below. On 5/23/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Manu. Welcome to Tuscany and thank you for looking into Tuscany/Geronimo integration. Please see my comments inline below. Thanks, Raymond - Original Message - From: Manu George [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 22, 2007 1:00 PM Subject: Re: Tuscany sample app Hi, I am new to this list and product. I just wanted to know if there is any work going on in implementing deep integration with apache geronimo app server. If it is going on I am volunteering to help. If not I would again like to volunteer to take up that task along with anyone else interested. It would be really great that we start the Tuscany/Geronimo integration now as we have a stable Tuscany code base (the 0.90 relase are being voted on). A few of other folks have also expressed their interests in this area. Let's keep all the discussions on this ML so that all of us can participate. I'm not sure what's the best way to Sure thats the best way. Currently I have experimented a bit with deep integration and got the calculator service to deploy on geronimo.What I have achieved is the ability to deploy Tuscany services on geronimo packaged in a jar with a geronimo specific deployment descriptor. This is a very good step forward. Did you use the geronimo module plan for the jar? What I have done is I wrote 2 gbeans. One GBean takes care of rigging up and starting the ReallySmallRuntime that provided with Tuscany. The other GBean takes care of instantiating the GeronimoSCADomain class. The latter GBean should be run in the same class loader as the SCA application so that during the SCADomain creation the .composite files can be picked up. I then wrote a deployer that implements the ConfigurationBuilder interface of geronimo and implemented the methods. This deployer is also a gbean and after registration it will be called for all jars that are deployed that have META-INF/geronimo-tuscany.xml files with a particular namespace. What this deployer does is create a configuration whose classloader contains all the classes in the jar, rig the second GBean and add it to the configuration so that an SCADomain is created. In case of J2EE modules I created a Deployment Watcher class which again adds the second gbean to the configuration of the j2ee module if it contains META-INF/geronimo-tuscany.xml So when the configuration starts the second gbean also starts which starts the SCADomain and registers it in Global JNDI. When the configuration stops the domain is closed and removed from JNDI. Since the runtime just provides services to the SCADomain that contains it, I just inject the ReallySmallRuntime I created earlier into the SCADomain. What I have done is created a new Domain class GeronimoSCADomain and the only difference of this from default SCA domain is that it takes a ReallySmallRuntime as a parameter instead of creating it. So effectively one Runtime can be shared among all the SCADomains. I am assuming that there will be a single SCADomain per application and all SCADomains will share the same Runtime. Due to my lack of tuscany knowledge I am not sure if this is the way to go about it. Can any one of the tuscany gurus clarify if this is the correct approach? The SCA domain is a collection of runtimes that can host SCA composites. The domain is logically represented as a SCA composite which include all the deployable composites activated by all runtimes in the SCA domain. A SCA domain can span multiple machines over the network. It consists of all the runtimes that run SCA applications. Ok, I was unaware that a domain can have multiple runtimes. But like the webapp sample which has a single runtime I am thinking that Geronimo will also have a single runtime only. ATleast initially that may be the way to go forward. Also from what i see of the code, the runtimes just provide services which the sca domain uses to set itself up. So its my assumption that a runtime that an SCADomain accesses doesn't need to be exclusive to it but can be shared among domains. Can you advise me if this assumtion is ok? I was unable to understand the need to create multiple runtimes for each sca domain (other than for the web app based integration). If there are any other reasons can someone please explain why we need a runtime per app? ? Other things that i am experimenting with is the ability to package the tuscany service along with an ear/war/ejb-jar. The SCA
[jira] Created: (TUSCANY-1297) xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope
xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope -- Key: TUSCANY-1297 URL: https://issues.apache.org/jira/browse/TUSCANY-1297 Project: Tuscany Issue Type: Bug Components: C++ DAS Affects Versions: Cpp-current Environment: any Reporter: Matthew Peters We use SDO to build and generate WSDL. We use the standard WSDL and SOAP schemas (schemata?) to build the model then add port, operation, binding etc. elements, then serialise the lot to XML. There are occasional xsi:type attributes in the serialised XML which cause the WSDL not to validate or load in visual studio. Here is a snippet from WSDL that we have generated in this way: binding name=Labnet_API_LabnetOnline_001_ImplementationBinding type=tns2:Labnet_API_LabnetOnline_001_ImplementationPortType operation name=getRestorations input tns3:body xsi:type=tns3:tBody use=literal/ /input output tns3:body xsi:type=tns3:tBody use=literal/ /output tns3:operation xsi:type=tns3:tOperation soapAction=/ /operation tns3:binding xsi:type=tns3:tBinding transport=http://schemas.xmlsoap.org/soap/http; style=document/ /binding These xsi:type attributes cause this WSDL to fail to load. I quote one of our users: MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will not import a SCA generated WSDL. It complains that it does not validate because of the following element attributes: xsi:type=tns3:tBody of tns3:body xsi:type=tns3:tAddress of tns3:address Stripping out these attributes resolved the VS WSDL import problem. and a different bug report but the same problem: WSDL generated does not validate (ran against the oXygen editor and Mindreef SOAPscope). -- 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-1112) Incorrect namespaces in generated XML
[
https://issues.apache.org/jira/browse/TUSCANY-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498284
]
Matthew Peters commented on TUSCANY-1112:
-
Is there anything happening to this defect, which is several months old by now?
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-current
Environment: WinXP
Reporter: Matthew Peters
Fix For: Cpp-current
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:
?xml version=1.0 encoding=UTF-8?
BOGUS xmlns=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
person
tns2:name
firstWill/first
lastShakespeare/last
/tns2:name
/person
/BOGUS
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 person
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:
---
?php
$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:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:ns0=http://www.test.com/info;
targetNamespace=http://Component;
elementNameDefault=qualified
xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
xs:element name=add
xs:complexType
xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.test.com/info;
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType
/schema
Expected result:
see above
Actual result:
--
see above
[2007-01-31 12:21 UTC] mfp at php dot net
I just came across what I think is another example of this. Now I
understand better how namespaces work, I suspect it is more common than
we realise.
Here's the example in a nutshell:
Catalog.xsd defines a catalog element in the catalogNS namespace, which
contains items defined in a different namespace in a different file,
Order.xsd:
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:cat=catalogNS xmlns:ord=orderNS targetNamespace=catalogNS
include schemaLocation=Order.xsd/
element name=catalog type=cat:CatalogType/
complexType name=CatalogType
sequence
element maxOccurs=unbounded ref=ord:item/
/sequence
/complexType
/schema
Order.xsd defines the item element as being in the OrderNS namespace:
.../...
schema
Automated nightly builds
I'm starting to pursue a nightly build for Apache Tuscany with the Apache Infra guys, and I just want to double check what people think it's the best build layout that we should use - Have one top-down build, that would build all Tuscany subprojects (SCA/SDO/DAS) - Have three builds, that would build each project separately I particularly would prefer the second option, as that would ensure each subproject can work independently, based on published releases/snapshots of it's dependencies. Thoughts ? -- 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: [VOTE] Release Tuscany Java SCA 0.90-incubating
I didn't. I looked at both versions of maven-jaxb-plugin at https://maven-repository.dev.java.net/repository/com.sun.tools.xjc.maven2/poms/and both have the odd characters in. There seem to be other implementations of the maven-jaxb-plugin around and I tried the ones I could find but got NPEs in maven. Not sure whether this is the version of the plugin, the version of jaxb or a real problem. I'm not that faimiliar with JAXB and what version works with what so I don't have a quick fix. Also tried upgrading my JDK but that didn't work either. Am already on Maven 2.0.6. Happy to try any other ideas people have. What I have to do is work backwards through this and work out what version of what will actually work for us (I find trying to work this out for maven plugins very difficult) and see if I can get a combination that doesn't have the author name with the non-UTF8 character or where this particular fault has been fixed. Failing this we will have to get on whatever mail list deals with it and ask for a fix. As it stands we can offer a manual fix for anyone who has Linux/IBM JDK, i.e. run the build until it fails and then remove the problematic characters manually from the offending pom in the local repo. I can't say how long this will take but I think we need to get on with the release and address is next time. Simon
Re: Automated nightly builds
+1 for - Have three builds, that would build each project separately Simon
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
ant elder wrote: Please review and vote on the 0.90 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/0.90-rc1/ This includes the binary and source distributions, the RAT reports, and the Maven staging repository. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.90-incubating/ Looks ok to me so here's my +1. Thanks in advance, ...ant I've reviewed the binary release on Linux. It looks pretty good to me but I have a few comments, some minor, some more important: 1) CHANGES file, I'd suggest to move the API / user items to the top and move the SPI related section to the bottom, and change Host extensions to Host integrations or Host environments. 2) RELEASE_NOTES, I'd suggest to change The Tuscany all and manifest jars... to The tuscany-sca-all and tuscany-sca-manifest jars... 3) In docs/, wer'e missing Javadoc for a number of SPI packages listed in CHANGES, and more importantly, Javadoc for the SCA Java APIs . 4) I couldn't find text explaining that tuscany-sca-all contains all the other Tuscany JARs and that you don't need them as well if you're using it. 5) The RMI READMEs seem out of sync. Also I found having the build_client and build_server in both the rmi-reference and rmi-service samples confusing, how about just having a single build.xml like the other samples do (e.g. helloworld-ws-reference and helloworld-ws-service). Build.xml would start the server in rmi-service and the client in rmi-reference. 6) The implementation-crud-client does not work (I'm probably responsible for breaking this one...) 7) Like Ant said in another email, it would be good to rename calculator-web to calculator-webapp 8) I'd suggest to rename the binding-echo-appl and implementation-crud-client to something else, as most of these samples are appls as well, and implementation-crud is not a client, but I don't have a good name proposal. I had proposed to rename echo-binding to echo-binding-extension but it doesn't fit either as none of our other extension modules are named *-extension. These two samples look too complicated to me now, but I'm not sure if we can do anything about it for this release. 8) In the helloworld-jsonrpc sample, clicking the services/HelloWorldService link at the top of the page shows an exception, this probably normal as the server expects a JSON request, but confusing. I'd suggest to remove that link. 9) I could not find text in a README describing how I would use the binary distro, load one of the samples in Eclipse or IDEA and run it from there. As a developer that's one of the things I'd like to do first to browse the sample code and experiment with it. The steps described in the samples README only apply to the source distro and require Maven expertise, we should document simpler steps for somebody using the binary distro without Maven. 10) The samples/README says that you can build with mvn from both the source and binary distros, but the steps seem to apply to only the source distro. 11) None of the samples shows the use of META-INF/sca-deployables. I'd suggest to have one of the Webapp samples use that instead of sca-contribution.xml. I think it would be good to respin another release candidate with fixes for (1), (3), (4), (5), (6), (9) and (11) at least... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1297) xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope
[ https://issues.apache.org/jira/browse/TUSCANY-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1297: -- Component/s: (was: C++ DAS) C++ SDO xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope -- Key: TUSCANY-1297 URL: https://issues.apache.org/jira/browse/TUSCANY-1297 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: any Reporter: Matthew Peters We use SDO to build and generate WSDL. We use the standard WSDL and SOAP schemas (schemata?) to build the model then add port, operation, binding etc. elements, then serialise the lot to XML. There are occasional xsi:type attributes in the serialised XML which cause the WSDL not to validate or load in visual studio. Here is a snippet from WSDL that we have generated in this way: binding name=Labnet_API_LabnetOnline_001_ImplementationBinding type=tns2:Labnet_API_LabnetOnline_001_ImplementationPortType operation name=getRestorations input tns3:body xsi:type=tns3:tBody use=literal/ /input output tns3:body xsi:type=tns3:tBody use=literal/ /output tns3:operation xsi:type=tns3:tOperation soapAction=/ /operation tns3:binding xsi:type=tns3:tBinding transport=http://schemas.xmlsoap.org/soap/http; style=document/ /binding These xsi:type attributes cause this WSDL to fail to load. I quote one of our users: MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will not import a SCA generated WSDL. It complains that it does not validate because of the following element attributes: xsi:type=tns3:tBody of tns3:body xsi:type=tns3:tAddress of tns3:address Stripping out these attributes resolved the VS WSDL import problem. and a different bug report but the same problem: WSDL generated does not validate (ran against the oXygen editor and Mindreef SOAPscope). -- 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: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bi
Raymond Feng wrote: Hi, I followed your instructions, but I still saw the failure as shown below. It seems that the web services are running under 8080. Does the binding.axis2 now honor the port from the soap address in the WSDL? Thanks, Raymond log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Calling account service for customer: 1234 Checking account: CHA_1234, balance:500.0 Savings account: SAA_1234, balance:1500.0 Stock account: STA_1234, symbol:IBM, quantity:100 Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy7.getQuote(Unknown Source) at bigbank.account.AccountServiceImpl.getAccountReport(AccountServiceImpl.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy4.getAccountReport(Unknown Source) at bigbank.client.BigBankClient.main(BigBankClient.java:42) Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:221) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:92) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:71) at org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) ... 14 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:314) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:201) ... 22 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:179) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:73) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) ... 23 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
Website / Wiki was:Tuscany Logo..
Hi, I have started to look at getting our wiki to look a bit like a website and am working a bit with Confluence to figure out how this can be achieved. I looked up a couple of sites for ideas and quite liked the Geronimo site exported from the wiki - http://cwiki.apache.org/GMOxSITE. I am going to see if we can borrow the templates from Geronimo, folks to start with. Also if we have to update the template for the Tuscany Space on the Apache Confluence Server, we need administration access on that server. Does anybody have this on Tuscany Team? If I manage to get the templates going then here is what I intend to do ... - Get the navigation bar of our wiki site http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a classic navigation bar with menu items - Ensure that all pages have the menu bars. Right now there are pages that do not have this Navigation bar - Export the wiki thro the Geronimo template and .css for first iteration and help to get a different look on http://cwiki.apache.org/TUSCANY/ than what exists today. As we move forward we can customize the template and .css as people might fancy. I hope to be able to get all this done for people to get a feel of it tomorrow. Thanks - Venkat
Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bi
Hi, I started the StockQuoteServer and it was listening on 8080. Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, May 23, 2007 10:25 AM Subject: Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bigbank/ bigbank-account/src/main/java/bigbank/account/ bi Raymond Feng wrote: Hi, I followed your instructions, but I still saw the failure as shown below. It seems that the web services are running under 8080. Does the binding.axis2 now honor the port from the soap address in the WSDL? Thanks, Raymond log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Calling account service for customer: 1234 Checking account: CHA_1234, balance:500.0 Savings account: SAA_1234, balance:1500.0 Stock account: STA_1234, symbol:IBM, quantity:100 Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy7.getQuote(Unknown Source) at bigbank.account.AccountServiceImpl.getAccountReport(AccountServiceImpl.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy4.getAccountReport(Unknown Source) at bigbank.client.BigBankClient.main(BigBankClient.java:42) Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:221) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:92) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:71) at org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) ... 14 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:314) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:201) ... 22 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:179) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:73) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) ... 23 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706) at
Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bi
Raymond Feng wrote: Hi, I started the StockQuoteServer and it was listening on 8080. Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, May 23, 2007 10:25 AM Subject: Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bigbank/ bigbank-account/src/main/java/bigbank/account/ bi Raymond Feng wrote: Hi, I followed your instructions, but I still saw the failure as shown below. It seems that the web services are running under 8080. Does the binding.axis2 now honor the port from the soap address in the WSDL? Thanks, Raymond log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Calling account service for customer: 1234 Checking account: CHA_1234, balance:500.0 Savings account: SAA_1234, balance:1500.0 Stock account: STA_1234, symbol:IBM, quantity:100 Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy7.getQuote(Unknown Source) at bigbank.account.AccountServiceImpl.getAccountReport(AccountServiceImpl.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy4.getAccountReport(Unknown Source) at bigbank.client.BigBankClient.main(BigBankClient.java:42) Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:221) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:92) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:71) at org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) ... 14 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:314) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:201) ... 22 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:179) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:73) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) ... 23 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:139) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:124) at
Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bi
Hi, I found out the StockQuoteServer is using TomcatServer which doesn't handle the uri port at all. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, May 23, 2007 11:20 AM Subject: Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bigbank/ bigbank-account/src/main/java/bigbank/account/ bi Raymond Feng wrote: Hi, I started the StockQuoteServer and it was listening on 8080. Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, May 23, 2007 10:25 AM Subject: Re: svn commit: r540764 [1/2] - in /incubator/tuscany/java/sca/demos: ./ bigbank-account/ bigbank-account/src/ bigbank-account/src/main/ bigbank-account/src/main/java/ bigbank-account/src/main/java/bigbank/ bigbank-account/src/main/java/bigbank/account/ bi Raymond Feng wrote: Hi, I followed your instructions, but I still saw the failure as shown below. It seems that the web services are running under 8080. Does the binding.axis2 now honor the port from the soap address in the WSDL? Thanks, Raymond log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Calling account service for customer: 1234 Checking account: CHA_1234, balance:500.0 Savings account: SAA_1234, balance:1500.0 Stock account: STA_1234, symbol:IBM, quantity:100 Exception in thread main java.lang.reflect.UndeclaredThrowableException at $Proxy7.getQuote(Unknown Source) at bigbank.account.AccountServiceImpl.getAccountReport(AccountServiceImpl.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy4.getAccountReport(Unknown Source) at bigbank.client.BigBankClient.main(BigBankClient.java:42) Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:221) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:452) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:92) at org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:71) at org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) ... 14 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:314) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:201) ... 22 more Caused by: org.apache.axis2.AxisFault: Connection refused: connect at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:179) at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:73) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:305) ... 23 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Website / Wiki was:Tuscany Logo..
Hi Venkat, sounds great. Can I just ask, when you say... snip - Get the navigation bar of our wiki site http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a classic navigation bar with menu items Do you mean the one on the left hand side or the tabs at the top or something else? Simon
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
On 5/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Please review and vote on the 0.90 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/0.90-rc1/ This includes the binary and source distributions, the RAT reports, and the Maven staging repository. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.90-incubating/ Looks ok to me so here's my +1. Thanks in advance, ...ant I've reviewed the binary release on Linux. It looks pretty good to me but I have a few comments, some minor, some more important: 1) CHANGES file, I'd suggest to move the API / user items to the top and move the SPI related section to the bottom, and change Host extensions to Host integrations or Host environments. 2) RELEASE_NOTES, I'd suggest to change The Tuscany all and manifest jars... to The tuscany-sca-all and tuscany-sca-manifest jars... 3) In docs/, wer'e missing Javadoc for a number of SPI packages listed in CHANGES, and more importantly, Javadoc for the SCA Java APIs . 4) I couldn't find text explaining that tuscany-sca-all contains all the other Tuscany JARs and that you don't need them as well if you're using it. 5) The RMI READMEs seem out of sync. Also I found having the build_client and build_server in both the rmi-reference and rmi-service samples confusing, how about just having a single build.xml like the other samples do (e.g. helloworld-ws-reference and helloworld-ws-service). Build.xml would start the server in rmi-service and the client in rmi-reference. 6) The implementation-crud-client does not work (I'm probably responsible for breaking this one...) 7) Like Ant said in another email, it would be good to rename calculator-web to calculator-webapp 8) I'd suggest to rename the binding-echo-appl and implementation-crud-client to something else, as most of these samples are appls as well, and implementation-crud is not a client, but I don't have a good name proposal. I had proposed to rename echo-binding to echo-binding-extension but it doesn't fit either as none of our other extension modules are named *-extension. These two samples look too complicated to me now, but I'm not sure if we can do anything about it for this release. 8) In the helloworld-jsonrpc sample, clicking the services/HelloWorldService link at the top of the page shows an exception, this probably normal as the server expects a JSON request, but confusing. I'd suggest to remove that link. 9) I could not find text in a README describing how I would use the binary distro, load one of the samples in Eclipse or IDEA and run it from there. As a developer that's one of the things I'd like to do first to browse the sample code and experiment with it. The steps described in the samples README only apply to the source distro and require Maven expertise, we should document simpler steps for somebody using the binary distro without Maven. 10) The samples/README says that you can build with mvn from both the source and binary distros, but the steps seem to apply to only the source distro. 11) None of the samples shows the use of META-INF/sca-deployables. I'd suggest to have one of the Webapp samples use that instead of sca-contribution.xml. I think it would be good to respin another release candidate with fixes for (1), (3), (4), (5), (6), (9) and (11) at least... Which things MUST be fixed to avoid -1s on the next rc? Is 11 on this list a blocker? Is the linux compile problem a blocker? Also which things are people volunteering to fix? The javadoc one (3) seems a difficult one to fix to me which could easily end up just making things worse if we rush it. The 0.90 branch is open to everyone for updating so ideally I'd like to just get up tomorrow morning to find all the blockers fixed so I can cut anther rc, but so far its not clear what are the blockers or what the correct fix is, so its going to be difficult to know if things are in a state where I can cut another rc or not. We could spend weeks polishing this point release, is that what we want to be doing? ..ant
Missing:org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incubating-SNAPSHOT
Hi, I've just updated tuscany local sources and run mvn test in samples/calculator-script with a clean m2 repo. I meant to make sure that when my sample is run no earlier m2 repo should exist. The command failed with the following error message: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-host-embedded \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sca:sample-calculator-script:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-calculator-script:jar:1.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Why isn't the module - tuscany-host-embedded - published on apache.incubator? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing:org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incubating-SNAPSHOT
Hi Jacek It's because we haven't pushed any snapshots out to the Apache Incubator repository yet. Primarily this is because the code has been changing a lot in the run up to the current 0.90 release vote and we have concentrated on getting all the modules to build together rather than pushing out snapshots of the individual modules. To fix this you need to run mvn from the sca level so that all the sca modules are built and installed into your local repository. Regards Simon
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
I found a serious problem in the calculator-web sample in the 0.90 release candidate. The ant script for this sample builds a war that is not deployable because of two missing files. The pre-built war file that is shipped as part of the binary distro is fine. I discovered this as a last-minute glitch with my demo for the Tuscany presentation that I gave today at the IBM Impact conference. I'll write a JIRA for this now and post a patch asap (later today EDT). Simon Simon Nash wrote: I think the shop window factor is an important consideration. The cumulative effect of the issues that people have reported seems to be significant enough from this perspective that a respin is desirable. In particular, the build and sample README problems could be quite off-putting to a novice user. Simon Simon Laws wrote: I've given the src and binary distros a spin on linux. My configuration is Fedora Core5 IBM JDK 1.5.0 Maven 2.0.6 Binary: I concur with Luciano that the READMEs for calculator-rmi-reference calculator-rmi-service implementation-crud now don't match the way that the samples are currently organized. I'm reluctant to agree to go with this release when our shop window isn't fully functional. I have checked fixes in for the calculator sample to the 0.9branch and head. Luciano's fix for implementation-crud looks good to me. Source: This fails to build under maven in my environment. The culprit is the maven-jaxb-plugin. The pom provided with the version that we refer in our poms, e.g. databinding-jaxb, has a non-UTF8 character in one of the author names which causes the maven build to fail with the IBM JDK 1.5.0 on Linux. I can confirm that this does not cause a problem with the same JDK (same version and build at least) on Windows XP. I tried using different maven-jaxb-plugins from a variety of repositories. All failed for other reasons. There is a manual work around to the problem, i.e. remove the non-UTF8 characters, so I don't think that this, on its own is a blocker. I've raised http://issues.apache.org/jira/browse/TUSCANY-1296 for this. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
I fixed the sample problems when we mentioned them before (that's 5 and 6 from Sebatien's list). I can look at other things first thing as it sounds like we are going to respin. Too tired now to get it right. I still don't think we wait for a fix for my build problem. It's the first time it's come up, it's only on the combination of software I have and there is a (manual) work around. Simon
[jira] Created: (TUSCANY-1298) calculator-web build.xml file produces bad war file
calculator-web build.xml file produces bad war file --- Key: TUSCANY-1298 URL: https://issues.apache.org/jira/browse/TUSCANY-1298 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Nash Assigned To: Simon Nash Fix For: Java-SCA-0.90 The ant script for this sample builds a war that is not deployable because of two missing files: sca-api-0.90-incubating.jar tuscany-host-webapp-0.90-incubating.jar The pre-built war file that is shipped as part of the binary distro is fine. The missing sca-api-0.90-incubating.jar file is caused by a bug in the build.xml file for calculator-web, which attempts to pull this file in from ../../lib instead of ../../modules. The missing tuscany-host-webapp-0.90-incubating.jar file is not packaged in the binary distro, and is therefore beyond the powers of build.xml to pull into the webapp. It needs to be added to the modules directory in the binary distro. -- 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: [VOTE] Release Tuscany Java SCA 0.90-incubating
Jean-Sebastien Delfino wrote: (cut) 3) In docs/, wer'e missing Javadoc for a number of SPI packages listed in CHANGES, and more importantly, Javadoc for the SCA Java APIs . The javadoc for org.osoa.sca.* is there but these packages aren't being included in the top-level index. (cut) 8) I'd suggest to rename the binding-echo-appl and implementation-crud-client to something else, as most of these samples are appls as well, and implementation-crud is not a client, but I don't have a good name proposal. I had proposed to rename echo-binding to echo-binding-extension but it doesn't fit either as none of our other extension modules are named *-extension. These two samples look too complicated to me now, but I'm not sure if we can do anything about it for this release. I don't see a problem with naming these samples *-extension to differentiate them from the other non-extension samples. As you said in an earlier post, this makes it easy for users to find the sample extensions. These are only sample toy extensions and I don't think this would cause users to put -extension on the end of the names of real extensions that they build. I think we should leave the structure of these two samples as is for this elease (modulo possible renaming), and discuss other alternatives later. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1298) calculator-web build.xml file produces bad war file
[ https://issues.apache.org/jira/browse/TUSCANY-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1298: Attachment: patch1298 Updated distribution/bundle/pom.xml to include tuscany-host-webapp-0.90-incubating.jar Updated samples/calculator-web//buld.xml to include sca-api-0.90-incubating.jar calculator-web build.xml file produces bad war file --- Key: TUSCANY-1298 URL: https://issues.apache.org/jira/browse/TUSCANY-1298 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Nash Assigned To: Simon Nash Fix For: Java-SCA-0.90 Attachments: patch1298 The ant script for this sample builds a war that is not deployable because of two missing files: sca-api-0.90-incubating.jar tuscany-host-webapp-0.90-incubating.jar The pre-built war file that is shipped as part of the binary distro is fine. The missing sca-api-0.90-incubating.jar file is caused by a bug in the build.xml file for calculator-web, which attempts to pull this file in from ../../lib instead of ../../modules. The missing tuscany-host-webapp-0.90-incubating.jar file is not packaged in the binary distro, and is therefore beyond the powers of build.xml to pull into the webapp. It needs to be added to the modules directory in the binary distro. -- 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: Website / Wiki was:Tuscany Logo..
Hi Venkat, I'm helping with the documentation and web site for the Geronimo project. We recently moved the authoring of our web site to Confluence, now it is a lot easier to maintain. If you folks don't have a Confluence admin I'll be happy to help updating the templates. I just sent you a sample template for the autoexport plugin, you may want to make some updates to it ;-) Let me know if you get stuck anywhere with the template. Once you have it ready for the first test run let me know and I can update it in Confluence so everybody else can see how the website could look like ;-) Not sure how is the process to get an admin account in confluence, probably sending a req to infra@ or opening a JIRA, don't really know. Keep in mind that if you folks decide to implement this approach you will need to have more control on the TUSCANY space in Confluence. For the Geronimo website (GMOxSITE space) we have only project's committers with edit access. If you guys have only one space then you should start planning for having one for the web site and at least another for the formal wiki. Does that make sense!? Here is a doc I put together for how the Geronimo spaces (documentation and web site) are organized. http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html HTH Cheers! Hernan Venkata Krishnan wrote: Hi, I have started to look at getting our wiki to look a bit like a website and am working a bit with Confluence to figure out how this can be achieved. I looked up a couple of sites for ideas and quite liked the Geronimo site exported from the wiki - http://cwiki.apache.org/GMOxSITE. I am going to see if we can borrow the templates from Geronimo, folks to start with. Also if we have to update the template for the Tuscany Space on the Apache Confluence Server, we need administration access on that server. Does anybody have this on Tuscany Team? If I manage to get the templates going then here is what I intend to do ... - Get the navigation bar of our wiki site http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a classic navigation bar with menu items - Ensure that all pages have the menu bars. Right now there are pages that do not have this Navigation bar - Export the wiki thro the Geronimo template and .css for first iteration and help to get a different look on http://cwiki.apache.org/TUSCANY/ than what exists today. As we move forward we can customize the template and .css as people might fancy. I hope to be able to get all this done for people to get a feel of it tomorrow. Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.90-incubating
ant elder wrote: On 5/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Please review and vote on the 0.90 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/0.90-rc1/ This includes the binary and source distributions, the RAT reports, and the Maven staging repository. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.90-incubating/ Looks ok to me so here's my +1. Thanks in advance, ...ant I've reviewed the binary release on Linux. It looks pretty good to me but I have a few comments, some minor, some more important: 1) CHANGES file, I'd suggest to move the API / user items to the top and move the SPI related section to the bottom, and change Host extensions to Host integrations or Host environments. 2) RELEASE_NOTES, I'd suggest to change The Tuscany all and manifest jars... to The tuscany-sca-all and tuscany-sca-manifest jars... 3) In docs/, wer'e missing Javadoc for a number of SPI packages listed in CHANGES, and more importantly, Javadoc for the SCA Java APIs . 4) I couldn't find text explaining that tuscany-sca-all contains all the other Tuscany JARs and that you don't need them as well if you're using it. 5) The RMI READMEs seem out of sync. Also I found having the build_client and build_server in both the rmi-reference and rmi-service samples confusing, how about just having a single build.xml like the other samples do (e.g. helloworld-ws-reference and helloworld-ws-service). Build.xml would start the server in rmi-service and the client in rmi-reference. 6) The implementation-crud-client does not work (I'm probably responsible for breaking this one...) 7) Like Ant said in another email, it would be good to rename calculator-web to calculator-webapp 8) I'd suggest to rename the binding-echo-appl and implementation-crud-client to something else, as most of these samples are appls as well, and implementation-crud is not a client, but I don't have a good name proposal. I had proposed to rename echo-binding to echo-binding-extension but it doesn't fit either as none of our other extension modules are named *-extension. These two samples look too complicated to me now, but I'm not sure if we can do anything about it for this release. 8) In the helloworld-jsonrpc sample, clicking the services/HelloWorldService link at the top of the page shows an exception, this probably normal as the server expects a JSON request, but confusing. I'd suggest to remove that link. 9) I could not find text in a README describing how I would use the binary distro, load one of the samples in Eclipse or IDEA and run it from there. As a developer that's one of the things I'd like to do first to browse the sample code and experiment with it. The steps described in the samples README only apply to the source distro and require Maven expertise, we should document simpler steps for somebody using the binary distro without Maven. 10) The samples/README says that you can build with mvn from both the source and binary distros, but the steps seem to apply to only the source distro. 11) None of the samples shows the use of META-INF/sca-deployables. I'd suggest to have one of the Webapp samples use that instead of sca-contribution.xml. I think it would be good to respin another release candidate with fixes for (1), (3), (4), (5), (6), (9) and (11) at least... Which things MUST be fixed to avoid -1s on the next rc? Is 11 on this list a blocker? Is the linux compile problem a blocker? Also which things are people volunteering to fix? The javadoc one (3) seems a difficult one to fix to me which could easily end up just making things worse if we rush it. The 0.90 branch is open to everyone for updating so ideally I'd like to just get up tomorrow morning to find all the blockers fixed so I can cut anther rc, but so far its not clear what are the blockers or what the correct fix is, so its going to be difficult to know if things are in a state where I can cut another rc or not. We could spend weeks polishing this point release, is that what we want to be doing? ..ant None of them, that's why I didn't -1 the RC1. If you end up respinning an RC for other reasons then I'd say that the more important ones for me are (3), (5), (6) and (9) and it looks like Simon Laws has already fixed (5) and (6). If there's no other good reason for respinning an RC then you get my +1 for RC1 as long as we have JIRAs for these issues, and more importantly an Errata document clearly posted on our download page, documenting them and how to get around them. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website / Wiki was:Tuscany Logo..
Hi Simon, I mean the ones on the left. - Venkat On 5/24/07, Simon Laws [EMAIL PROTECTED] wrote: Hi Venkat, sounds great. Can I just ask, when you say... snip - Get the navigation bar of our wiki site http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a classic navigation bar with menu items Do you mean the one on the left hand side or the tabs at the top or something else? Simon
Re: Missing:org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incubating-SNAPSHOT
I just ran a build this morning and it looks like some kind sole has deployed some snapshots so it may work now. I only say may as I haven't tried from a completely clean repo yet. Regards Simon
Re: Website / Wiki was:Tuscany Logo..
Hi Hernan, This is really great!. Its just about the help that I have been looking for. Since we have a release round the corner we need to have the website up quickly as that's our shop window to the world. So I am going to certainly take your help for Confluence Admin. The other link that you have attached is also quite useful and seems like in the next iteration we will certainly be exploring having multiple spaces. Where is the template that you have mentioned? I don't see any attachment here. Maybe you must zip and attach otherwise the MLs skip the attachments from what I know. I shall update the wiki now so that all pages have menus. After this I shall work on the template (maybe you'd send it by then ;-)) and keep things in shape for you to simply go over and export. Thank you so much for helping in this. - Venkat On 5/24/07, Hernan Cunico [EMAIL PROTECTED] wrote: Hi Venkat, I'm helping with the documentation and web site for the Geronimo project. We recently moved the authoring of our web site to Confluence, now it is a lot easier to maintain. If you folks don't have a Confluence admin I'll be happy to help updating the templates. I just sent you a sample template for the autoexport plugin, you may want to make some updates to it ;-) Let me know if you get stuck anywhere with the template. Once you have it ready for the first test run let me know and I can update it in Confluence so everybody else can see how the website could look like ;-) Not sure how is the process to get an admin account in confluence, probably sending a req to infra@ or opening a JIRA, don't really know. Keep in mind that if you folks decide to implement this approach you will need to have more control on the TUSCANY space in Confluence. For the Geronimo website (GMOxSITE space) we have only project's committers with edit access. If you guys have only one space then you should start planning for having one for the web site and at least another for the formal wiki. Does that make sense!? Here is a doc I put together for how the Geronimo spaces (documentation and web site) are organized. http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html HTH Cheers! Hernan Venkata Krishnan wrote: Hi, I have started to look at getting our wiki to look a bit like a website and am working a bit with Confluence to figure out how this can be achieved. I looked up a couple of sites for ideas and quite liked the Geronimo site exported from the wiki - http://cwiki.apache.org/GMOxSITE. I am going to see if we can borrow the templates from Geronimo, folks to start with. Also if we have to update the template for the Tuscany Space on the Apache Confluence Server, we need administration access on that server. Does anybody have this on Tuscany Team? If I manage to get the templates going then here is what I intend to do ... - Get the navigation bar of our wiki site http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a classic navigation bar with menu items - Ensure that all pages have the menu bars. Right now there are pages that do not have this Navigation bar - Export the wiki thro the Geronimo template and .css for first iteration and help to get a different look on http://cwiki.apache.org/TUSCANY/than what exists today. As we move forward we can customize the template and .css as people might fancy. I hope to be able to get all this done for people to get a feel of it tomorrow. Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
