Re: Policy and intent framework proposal
Yes there is: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/tuscany-eclipse-codestyle.xml ...ant On 11/2/06, Felix Ren [EMAIL PROTECTED] wrote: Thanks Jim. I will get started from model representation. Perhaps I can create incremental patch every 3 to 4 days. Is there a code style template for Eclipse in Tuscany website? Felix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Website Updates
On 11/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am putting up some proposals for updates to our website and request feedback on this or suggestions for the better. Right away some top level ones are: - Do away with the tabs. This is because I don't see correlation between the Tab options and the options on the navigation pane in the left. i.e . if the tabs are first level navigation then the pane on the left must be sub-options within a selected tab - I don't see such a correlation. So let's avoid confusion to the website visitor - There is lots of green :) and am having some difficulties to get additional colors that gel with this. Either somebody with better colour sense helps or we moderate the green a bit. - The images that are used for the Navigation Optoins on the left pane and for the titles of various boxes may need to be sharpened a bit All this besides the fact the the various navigations paths need to be reviewed and set right. I shall get to these as well. Meanwhile I have created a JIRA http://issues.apache.org/jira/browse/TUSCANY-703 where I have attempted to provide a view of what's in my mind for the Navigation Pane on the left together with some changes for the Downloads page. You simply have to extract the zip that is attached in that JIRA and take a look at /site-publish/downloads.html. Also, I have a diagram posted for the Java_SCA Overview in the same JIRA, please see if you can say somethings about that as well. Thanks. - Venkat Its really good you're looking at the website Venkat, it has become a bit neglected. What you've suggested above all sounds good to me, I'd suggest just going ahead and making changes as you think appropriate as that will be much easier for you. Maybe for big ones mention on the dev list first but otherwise just dive in and send emails after the fact so others can review - just as with the code CTR not RTC :) ...ant
Re: Javadoc for M2
On Nov 1, 2006, at 3:20 PM, Simon Nash wrote: Comments inline below. Simon Jim Marino wrote: On Nov 1, 2006, at 9:33 AM, Raymond Feng wrote: Hi, I think it would be useful to package java in our M2 binary distro. I would like to hear your opinions: I'd say as a separate downloadable jar since this would only be relevant to extensions providers and not applications developers. The spec API and tuscany-api are relevant to application developers and extension developers. The spec API jars are obviously relevant, tuscany api much less so (hopefully applications developers would not use these very much, if at all) tuscany-spi is relevant only to extension developers but as you said in earlier posts, these are an important segment of the audience for M2. Yes and that's why I believe we should bundle them separately. I generally prefer not to download javadoc at all on my machine for two reasons. One is I typically access it online. The second is if I use it a lot, I also want the source. So, I download the source and setup my IDE appropriately; it can display javadoc directly from the source. For simplicity I think it is better to bundle all of these in the standalone distro rather than create many separate downloadable packages. It would probably be informative to look at how other similar projects manage distributions. Spring for instance has a baseline distro without Javadoc or optional dependencies, i.e. something similar to our core distribution. I don't want to belabor the point, however, as I think we have different philosophical views on what is easier, a single large distribution that one must modify to create runtime and dev images or smaller units that people can deal with individually. Perhaps we should just have both? If we want to have both, could you please respond to Jeremy's previous post in this thread with a proposal on how to resolve the issues he raised? Jim Also this would match how javadoc is packaged in SDO M2. 1) What modules should we generate javadoc? I assume only for *- api and *-spi. yes. Core is not an exposed api/spi. Agreed. 2) Should we package the javadoc with the standalone distro or as a separate archive? separate archive Combined (see reasons above). Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-753) JMS Binding
Hi Rajith, Thanks for the patch. I had a few comments regarding test cases... Having a testcase that is run from the checkin build create file system artifacts may be problematic since it can produce side- effects. Setting svn ignores isn't going to fix this so would it be possible to avoid having to create these artifacts? I was thinking this would involve two steps: 1. Have unit tests use EasyMock to stub out JMS APIs such as Destination to test the binding at a granular level independent of a particular JMS implementation. I would imagine there would not be many of these tests as the binding is mostly a wrapper around a JMS provider. These would just be normal JUnit test cases and not extend SCATestCase. 2. Have integration tests which test interoperating the binding with ActiveMQ. Eventually, these would be run as part of the integration test suite being worked on by Jeremy. For now, they could be test cases included as part of the checkin build until the integration test harness is operational. However, couldn't these integration tests use ActiveMQ's in-VM protocol? Also, would using the in-VM protocol eliminate the need to create file system artifacts as well as have port listeners? If there is no way around creating file system artifacts, then I think we really need to segregate these tests so they are not part of the checkin build. I'm happy to help out if needed. Thanks, Jim On Nov 2, 2006, at 1:04 AM, ant elder (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ] ant elder closed TUSCANY-753. - Resolution: Fixed Applied, thanks for the code Rajith! https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ services/bindings/binding.jms/ Right now the testcases create an ActiveMQ folder in the top level binding.jms folder, it would be better if that could be done within the target folder so its excluded from the SVN artifacts. If its a major problem i guess we could just add it to svn ignores but for now I haven't added this to the main build so we can look at this. JMS Binding --- Key: TUSCANY-753 URL: http://issues.apache.org/jira/browse/TUSCANY-753 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-Mx Reporter: Rajith Attapattu Assigned To: ant elder Fix For: Java-Mx Attachments: helloworldws.zip, jms-binding- JIRA_753-01-11-06.patch, jmsbinding_jira753_25sep06.patch Hi All, I have attached a patch for the JMS binding. By no means this is 100% complete. But I decided to post the source code so that others can have a look and comment on the direction and help out if there is something wrong. The unit tests are failing so I haven't attached the test code. JMS binding still has a dependency on SDO since I modeled it on the axis2 binding. However Raymond has changed that in axis2 and I am hoping to do the same soon. Please be kind enough to have a look and start a disucssion on how we can move this forward. Regards, Rajith -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java: Getting Involved -- Tests/Samples
Having tried to respond to Andy's note a couple of times today in a way that was not open to misinterpretation I 'phoned Andy up. I made the point that what we need to be aiming at is open integration of the RogueWave source into Tuscany, and that a process of making drops of code is not a good fit, as we must cater for the possibility of other members of the community having made updates to the tests. So I would say that the ideal way forward is that RogueWave create patches for any updates for code that has been put into the repository and I or another committer will apply them. If in this startup phase you would prefer for a while to continue to attach drops of code to JIRAs then I can apply the updates, The code drop process would have to include the possibility of me sending you back the updated code if it turned out that modifications had been made to the code between drops. It would be great to get you into the mode of creating patches and I'm willing to help you get set up for that if you would like. It would be really good to aim for having some RogueWave committers! Best Reards, Kelvin. On 01/11/06, Andy Grove (Contractor) [EMAIL PROTECTED] wrote: I've just become involved in the effort to make our test suite available and we have an internal meeting later today to discuss the procedures around this. I would have thought that the first sensible step would be for us to split out our current tests into two packages - those that have dependencies on RW internal classes and those that don't. That way we can provide regular code drops of the generic tests (avoiding the need to provide diffs when we make changes) and we can gradually migrate tests from the RW suite to the generic suite. Does that sound like a workable solution? Thanks, Andy. -Original Message- From: kelvin goodson [mailto: [EMAIL PROTECTED] Sent: 01 November 2006 10:05 To: tuscany-dev@ws.apache.org Subject: Re: SDO Java: Getting Involved -- Tests/Samples Andy, that's great thanks. This begs the question of how we proceed with code edits. Would you able to supply any updates you make as patches attached to a JIRA. I can then apply them to the code in svn. If you need any help with that I'm more than happy to help. (If you want interactive help I'm likely to be watching the IRC channel as kgoodson on the #Tuscany channel on irc.freenode.net.) It would be good to understand how you are currently working with this code in terms of source code control etc. and what your plans are as we move forward with this effort. Best Regards, Kelvin. On 01/11/06, Andy Grove (Contractor) [EMAIL PROTECTED] wrote: Hi Kelvin, I agree with your edits to the createTestObjectTypes() test in DataObjectListTest. This was clearly wrong. This has highlighted a general issue on some of our tests which we are now rectifying. We are also investigating issues around INSTANCE variables and I agree that we should at least avoid using them in the test cases so that we can isolate the tests. I'll progress this here and get the tests amended. I like the idea of having one vendor-specific TestHelperImpl abstracted by an interface. I'll start the process of amending out tests to use that. Thanks, Andy Grove. -Original Message- From: Bryan Luoma [mailto: [EMAIL PROTECTED] Sent: 31 October 2006 19:58 To: tuscany-dev@ws.apache.org Subject: RE: SDO Java: Getting Involved -- Tests/Samples Thanks Kelvin, I attached the XML instance documents (testdata.zip) referenced from the junit test XMLDataObjectTest.java https://issues.apache.org/jira/browse/TUSCANY-829 The archive consists of the following documents: - catalog-10.xml - w3_sample.wsdl - lists.xml - simple.xml We are looking into the other questions/concerns and will be addressed shortly. Thanks, Bryan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of kelvin goodson Sent: Monday, October 30, 2006 2:22 PM To: tuscany-dev@ws.apache.org Cc: Bryan Luoma Subject: Re: SDO Java: Getting Involved -- Tests/Samples I added the tests that were attached to TUSCANY-829 to my sandbox and made some changes, see http://svn.apache.org/viewvc?view=revrevision=469239 The exercise has turned up issues in a number of areas; Tuscany specific, interoperability, ... Looking at DataObjectListTest, one specific thing I'd like to understand is what was intended in the method createTestObjectTypes(). What it seemed to be doing is creating a very open model by setting the type of the product2 property to commonj.sdo.DataObject, i.e. a mixed, sequenced, open type that can hold pretty much anything, whereas what I think was intended was that this property should be of type newType2 (i.e. the type with name product2). Frank began looking at this with the view that what was intended was the former arrangement, and the failures we were getting has highlit an issue with
Re: [VOTE] Release DAS Java M2 RC4b
+1 On 01/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Everyone Please vote to approve DAS Java Milestone 2 distributions. The vote is open for at least the next 72 hours. At least three +1 votes are required, and only the votes from Tuscany committees are binding. If the majority of all votes is positive, I will send a summary of that vote to the Incubator's general list to formally request the Incubator PMC to approve the Tuscany DAS M2 release. The release candidate is available at: http://people.apache.org/~kelvingoodson/das_java/RC4b/ http://people.apache.org/%7Ekelvingoodson/das_java/RC4a/ The release is taged at : https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/ What's new in DAS Java M2 DAS Core features - MySQL support - Static Data Objects - Dynamic root for static graphs - Unique attribute on relationships - Explicit ResultSet shape definition - Improved logging - Programmatic Configuration - Helper for empty SDO Graph - Convention over configuration - Column named ID is the PK - Column named xxx_ID is the FK to table xxx DAS Samples - Tomcat integration and automated DAS samples testing (htmlUnit) - DAS Samples now have all dependencies and source code inside the sample war For detailed user documentation and feature descriptions, access Tuscany DAS Wiki page - http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview Thanks Luciano Resende
New committers should subscribe to the private mailing list (was Re: Private mailing list now set up for Tuscany)
Just a reminder to new committers that they should subscribe to the private mailing list as described below. ...ant On 6/23/06, Jeremy Boynes [EMAIL PROTECTED] wrote: We now have a private mailing list (thanks Brett) for use by committers on the project and interested PMC members. This list is similar to the pmc mailing list used by a top-level project's PMC to discuss the few things that can not be done in public. These are things like security or legal issues (and even then only when necessary), or for people related issues like discussion about prospective committers. To subscribe, please send email to tuscany-private-subscribe at incubator.apache.org Subscription is open to all project committers and sponsoring PMC members (and Apache Members of course). I'm the only moderator right now so please bear with any delays. If you would like to volunteer to moderate please let me know (having three people in different timezones works well). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Private mailing list now set up for Tuscany
On 7/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 27, 2006, at 9:02 AM, ant elder wrote: Did you ever add me as a moderator for the private list, I've not seen any moderation requests? So you must have seen all the subscription requests...could you post a list of who has subscribed? (or is there some other way I can find the subscriber list myself and I'll post the list?) I haven't figured out how to add you as a moderator - I'd ask one of our mentors to explain the mechanism ... Dims, any idea how to add me as moderator to the Tuscany lists? Thanks, ...ant
Re: Tuscany Website Updates
On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am putting up some proposals for updates to our website and request feedback on this or suggestions for the better. Right away some top level ones are: - Do away with the tabs. This is because I don't see correlation between the Tab options and the options on the navigation pane in the left. i.e . if the tabs are first level navigation then the pane on the left must be sub-options within a selected tab - I don't see such a correlation. So let's avoid confusion to the website visitor - There is lots of green :) and am having some difficulties to get additional colors that gel with this. Either somebody with better colour sense helps or we moderate the green a bit. - The images that are used for the Navigation Optoins on the left pane and for the titles of various boxes may need to be sharpened a bit All this besides the fact the the various navigations paths need to be reviewed and set right. I shall get to these as well. Meanwhile I have created a JIRA http://issues.apache.org/jira/browse/TUSCANY-703 where I have attempted to provide a view of what's in my mind for the Navigation Pane on the left together with some changes for the Downloads page. You simply have to extract the zip that is attached in that JIRA and take a look at /site-publish/downloads.html. Also, I have a diagram posted for the Java_SCA Overview in the same JIRA, please see if you can say somethings about that as well. Thanks. - Venkat Its really good you're looking at the website Venkat, it has become a bit neglected. What you've suggested above all sounds good to me, I'd suggest just going ahead and making changes as you think appropriate as that will be much easier for you. Maybe for big ones mention on the dev list first but otherwise just dive in and send emails after the fact so others can review - just as with the code CTR not RTC :) I meant to add, I'd like to help, specifically with adding pages with doc about the various extensions, maybe along the lines of that example i posted earlier [1]. Could you find a space for me on the website for me to do that? ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED]
java.lang.IndexOutOfBoundsException trying to consume SCA component in a web app
I have created a simple DASService component, and trying to use it in a client web application (based on webapp sample app)... Although, I'm getting the following exception : java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 java.util.ArrayList.RangeCheck(ArrayList.java:546) java.util.ArrayList.get(ArrayList.java:321) org.apache.tuscany.spi.extension.CompositeComponentExtension.getServiceInstance(CompositeComponentExtension.java:239) org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:269) org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) org.apache.jsp.Company_jsp._jspService(Company_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) das service default.scdl composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite component name=DASServiceComponent implementation.java class= org.apache.tuscany.samples.das.service.DASServiceImpl/ /component /composite das service client default.scdl composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite component name=DASServiceComponent implementation.composite name=DASServiceComposite jarLocation=lib/sample-das-service-1.0-incubator-SNAPSHOT.jar/ /component /composite This is with trunk code... Any ideas on what might be wrong ? - Luciano Resende
Re: Tuscany Website Updates
Sure yes Ant. For the Documentation, as mentioned earlier, I plan to have separate pages for SCA Docs, SDO Docs. and DAS Docs. Each of these pages will have a list of topics that will further link to separate pages. Here is something that I can imagine for now for this. 1) SCA Java Overview will will have something in general about how we have partitioned as APIs SPI Core etc. 2) SCA Java - Extensions About extensions... Implementation Types, Bindings and the general prog. model around loaders, buliders, invokers How to write your own impl. type and binding extensions Tuscany Implementatin Extensions JavaScript Groovy Ruby 3) SCA Java - DataBinding Facility About DataBinding and its advantage How to write your own data bindings 4) Java SCA Runtimes and Application Deployment Standalone WebApp 5) Java SCA Samples Overview of samples available in SCA Java How to write your own SCA Application So I guess, what you wish to do might go into one of the lind uder Topic 2. Please feel free to correct this or fill in if I have grossly missed out on somethings. Thanks - Venkat On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am putting up some proposals for updates to our website and request feedback on this or suggestions for the better. Right away some top level ones are: - Do away with the tabs. This is because I don't see correlation between the Tab options and the options on the navigation pane in the left. i.e . if the tabs are first level navigation then the pane on the left must be sub-options within a selected tab - I don't see such a correlation. So let's avoid confusion to the website visitor - There is lots of green :) and am having some difficulties to get additional colors that gel with this. Either somebody with better colour sense helps or we moderate the green a bit. - The images that are used for the Navigation Optoins on the left pane and for the titles of various boxes may need to be sharpened a bit All this besides the fact the the various navigations paths need to be reviewed and set right. I shall get to these as well. Meanwhile I have created a JIRA http://issues.apache.org/jira/browse/TUSCANY-703 where I have attempted to provide a view of what's in my mind for the Navigation Pane on the left together with some changes for the Downloads page. You simply have to extract the zip that is attached in that JIRA and take a look at /site-publish/downloads.html. Also, I have a diagram posted for the Java_SCA Overview in the same JIRA, please see if you can say somethings about that as well. Thanks. - Venkat Its really good you're looking at the website Venkat, it has become a bit neglected. What you've suggested above all sounds good to me, I'd suggest just going ahead and making changes as you think appropriate as that will be much easier for you. Maybe for big ones mention on the dev list first but otherwise just dive in and send emails after the fact so others can review - just as with the code CTR not RTC :) I meant to add, I'd like to help, specifically with adding pages with doc about the various extensions, maybe along the lines of that example i posted earlier [1]. Could you find a space for me on the website for me to do that? ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED]
Re: What's next for SCA?
At 17:21 24/10/2006, Jim Marino wrote: Existing server integration is a nice-to-have but IMO we require a standalone environment that can support the full range of SCA features which is not easily done in the former. FWIW if you want to drive adoption then I think this is more than nice-to-have. I think you need to seriously tackle the issue of the whole world not being Tuscany (see note below). This is not just the issue of providing a fully featured SCA implementation in hosted environments, but interacting with other SCA runtimes that are not Tuscany and other services that are not SCA at all. I think this probably means a much clearer separation between the parts of the Tuscany runtime that are core and those that are targeted to a particular implementation (standalone for example). Given clearer SPI access into the core I think you will have a lot more success in driving Tuscany into the real world. Yes this will likely entail some type of service discovery. I've been looking at zeroconf and perhaps UPnP as ways of doing this (support should be pluggable) and when I have a better idea I will post a write-up to the list. The key here is pluggable. Any clustering infrastructure does this and to date they are all different (e.g. WebLogic, Geronmo, Active MQ, JBoss, WAS), datacenter managers will not thank you for more :) It might also be worth looking at ActiveCluster since it does something similar here (I think it may use Zeroconf anyway), although I have to say that if I had my way everyone would use UPnP. Although don't you actually need something a bit higher level? E.g. UDDI or AD or something that allows you to publish all of the associated meta data as well. My $0.02 andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to fix problems in tagged artifacts?
With item 1) can we temporarily add to the SCA's pom.xml this repository? This seems to have built for me doing it this way. When Axis/wsCommons goes gold these artifacts will be picked up by http://people.apache.org/repository. We can then remove this repository. Or will timing be an issue here? Similarly, for item 2) I think only BB uses it. Can we add this plugin repository to the samples top pom.xml and just keep it there? It seems the SCA pom is doing that already as a regular repository. Raymond Feng wrote: Hi, I have to fix two issues in the pom/parent/pom.xml which has been tagged and voted for M2: 1) Switch to http://ws.zones.apache.org/repository for the SNAPSHOT versions of Axis2 and its dependencies (which will become obsolete once the Axis2 1.1 is released and published to maven repo). 2) Add http://people.apache.org/repo/m2-incubating-repository as a plugin repository I'm struggling a bit here. I assume that tagged artifacts should be frozen logically. * Should we create a new tag for the new version or is it OK to just commit a new revision? * Should we bump up the version for pom/parent/pom.xml to 2-incubator? If yes, all the groups under tags/java such as sdo, das, buildtools that have dependencies on pom/parent/pom.xml need to be changed and re-tagged/re-voted. Any opinions? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.IndexOutOfBoundsException trying to consume SCA component in a web app
This is because there is no default service for the composite (we should probably check for this and throw a better error). What seems to be happening is that CompositeComponentExtension.locateService() is resolving to a child composite context which has no default service. It looks as if you are trying to have nested composites. If you do this the DAS component needs to be exposed as a service on the inner composite. Another option would be to point the current composite context to the inner composite (there is a config parameter in the servlet context for this). You should be able to find an example of this in the Spring sample. A further option would be just to have one composite (as opposed to the hierarchy) would make things simpler. Jim On Nov 2, 2006, at 3:29 AM, Luciano Resende wrote: I have created a simple DASService component, and trying to use it in a client web application (based on webapp sample app)... Although, I'm getting the following exception : java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 java.util.ArrayList.RangeCheck(ArrayList.java:546) java.util.ArrayList.get(ArrayList.java:321) org.apache.tuscany.spi.extension.CompositeComponentExtension.getServic eInstance(CompositeComponentExtension.java:239) org.apache.tuscany.spi.extension.CompositeComponentExtension.locateSer vice(CompositeComponentExtension.java:269) org.apache.tuscany.core.launcher.CompositeContextImpl.locateService (CompositeContextImpl.java:65) org.apache.jsp.Company_jsp._jspService(Company_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter (TuscanyFilter.java:58) das service default.scdl composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite component name=DASServiceComponent implementation.java class= org.apache.tuscany.samples.das.service.DASServiceImpl/ /component /composite das service client default.scdl composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite component name=DASServiceComponent implementation.composite name=DASServiceComposite jarLocation=lib/sample-das-service-1.0-incubator-SNAPSHOT.jar/ /component /composite This is with trunk code... Any ideas on what might be wrong ? - Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Website Updates
It seems we're going full circle here. We had a site that was based on maven generation and a one step procedure to build and publish. One of the main reasons that was given up was that as I recall it did not have a means to add top tabs and other features that was needed to make the site more visually pleasing. I think we spent a few regular IRC chats just discussing all of this after we received several complaints. Venkata Krishnan wrote: Hi, I am putting up some proposals for updates to our website and request feedback on this or suggestions for the better. Right away some top level ones are: - Do away with the tabs. This is because I don't see correlation between the Tab options and the options on the navigation pane in the left. i.e. if the tabs are first level navigation then the pane on the left must be sub-options within a selected tab - I don't see such a correlation. So let's avoid confusion to the website visitor - There is lots of green :) and am having some difficulties to get additional colors that gel with this. Either somebody with better colour sense helps or we moderate the green a bit. - The images that are used for the Navigation Optoins on the left pane and for the titles of various boxes may need to be sharpened a bit All this besides the fact the the various navigations paths need to be reviewed and set right. I shall get to these as well. Meanwhile I have created a JIRA http://issues.apache.org/jira/browse/TUSCANY-703 where I have attempted to provide a view of what's in my mind for the Navigation Pane on the left together with some changes for the Downloads page. You simply have to extract the zip that is attached in that JIRA and take a look at /site-publish/downloads.html. Also, I have a diagram posted for the Java_SCA Overview in the same JIRA, please see if you can say somethings about that as well. Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-895) getProperties and getDeclaredProperties must return read-only lists [SDO-85]
getProperties and getDeclaredProperties must return read-only lists [SDO-85] Key: TUSCANY-895 URL: http://issues.apache.org/jira/browse/TUSCANY-895 Project: Tuscany Issue Type: Improvement Components: C++ SDO, C++ Specification Affects Versions: Cpp-current Reporter: Geoff Winn Assigned To: Geoff Winn Priority: Minor The getProperties and getDeclaredProperties methods must return read-only lists. This is a 2.1 specification change, identified as SDO-85 in the specification change list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Private mailing list now set up for Tuscany
It's simply sending an e-mail to the infrastructure mailing-list, giving them the mailing-list name and your Apache id and they'll add you as a moderator. Matthieu On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 7/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 27, 2006, at 9:02 AM, ant elder wrote: Did you ever add me as a moderator for the private list, I've not seen any moderation requests? So you must have seen all the subscription requests...could you post a list of who has subscribed? (or is there some other way I can find the subscriber list myself and I'll post the list?) I haven't figured out how to add you as a moderator - I'd ask one of our mentors to explain the mechanism ... Dims, any idea how to add me as moderator to the Tuscany lists? Thanks, ...ant
Testing RC from a remote repository
Hi There has been something that has been on my mind regarding testing the release candidates. The SCA samples has dependencies on SDO and DAS and up to now we test by building these dependencies locally. However, I'm one that likes to test out the real user experience scenario and we don't require them to build these for the SCA samples. Ideally, the scenario would be the SDO, DAS and for completeness sake also SCA runtime should be in a remote repository. The sample source is the only artifact that should needed to download and start a maven build. I know I could set up locally a remote repository and then publish all the dependent RC artifacts to it and then modify locally my sample's POM xml to pick up that local repo I've created. This seems really painful.though. Is there an easier way? Should we just take a leap of faith it will work out? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Website Updates
Venkata, I think the navigation is indeed improved in your latest zip(once all the links are filled in at least). I had also mentioned at some point being interested in helping with SCA documentation. There is one thing I feel is missing/unclear on the site and the SCA outline above; that is the getting started section. Here we have this nice layout of information for SCA/SDO/DAS and download pages, but how do I start using tuscany? I have been looking at this and would like to contribute a section, even if it is just get started by downloading a distribution and run the samples using their respective readme.html. Do you agree this is needed? Also I wouldn't mind trying to put together the information(from the list/wiki/and my own input) I find on #4 above. Is any of this work already being done? thanks, Lee On 11/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Sure yes Ant. For the Documentation, as mentioned earlier, I plan to have separate pages for SCA Docs, SDO Docs. and DAS Docs. Each of these pages will have a list of topics that will further link to separate pages. Here is something that I can imagine for now for this. 1) SCA Java Overview will will have something in general about how we have partitioned as APIs SPI Core etc. 2) SCA Java - Extensions About extensions... Implementation Types, Bindings and the general prog. model around loaders, buliders, invokers How to write your own impl. type and binding extensions Tuscany Implementatin Extensions JavaScript Groovy Ruby 3) SCA Java - DataBinding Facility About DataBinding and its advantage How to write your own data bindings 4) Java SCA Runtimes and Application Deployment Standalone WebApp 5) Java SCA Samples Overview of samples available in SCA Java How to write your own SCA Application So I guess, what you wish to do might go into one of the lind uder Topic 2. Please feel free to correct this or fill in if I have grossly missed out on somethings. Thanks - Venkat On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am putting up some proposals for updates to our website and request feedback on this or suggestions for the better. Right away some top level ones are: - Do away with the tabs. This is because I don't see correlation between the Tab options and the options on the navigation pane in the left. i.e . if the tabs are first level navigation then the pane on the left must be sub-options within a selected tab - I don't see such a correlation. So let's avoid confusion to the website visitor - There is lots of green :) and am having some difficulties to get additional colors that gel with this. Either somebody with better colour sense helps or we moderate the green a bit. - The images that are used for the Navigation Optoins on the left pane and for the titles of various boxes may need to be sharpened a bit All this besides the fact the the various navigations paths need to be reviewed and set right. I shall get to these as well. Meanwhile I have created a JIRA http://issues.apache.org/jira/browse/TUSCANY-703 where I have attempted to provide a view of what's in my mind for the Navigation Pane on the left together with some changes for the Downloads page. You simply have to extract the zip that is attached in that JIRA and take a look at /site-publish/downloads.html. Also, I have a diagram posted for the Java_SCA Overview in the same JIRA, please see if you can say somethings about that as well. Thanks. - Venkat Its really good you're looking at the website Venkat, it has become a bit neglected. What you've suggested above all sounds good to me, I'd suggest just going ahead and making changes as you think appropriate as that will be much easier for you. Maybe for big ones mention on the dev list first but otherwise just dive in and send emails after the fact so others can review - just as with the code CTR not RTC :) I meant to add, I'd like to help, specifically with adding pages with doc about the various extensions, maybe along the lines of that example i posted earlier [1]. Could you find a space for me on the website for me to do that? ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED]
Re: Javadoc for M2
I agree with all these suggestions. In the SCA javadoc downloadable
archive I would include the spec API along with tuscany-api,
tuscany-host-api, and tuscany-spi. (Perhaps this is what you meant
by *-api).
This downloadable javadoc archive could either be combined with the
downloadable standalone distribution, or separate from it. See my
latest response to Jim for the reasons why I think it would be
better to have this as a part of the standalone binary distribution
on the download site for this release. However, I don't think the
same considerations apply to the standalone distribution that we
will publish to the maven repo. I would expect users of this
version to use maven to get the javadoc from the maven repo as well.
So my suggestion would be to not include javadoc in the standalone
runtime that we publish to the maven repo but to include it in the
binary/standalone version that we place on our web site for download.
Simon
Jeremy Boynes wrote:
The maven javadoc goal by default generates a -javadoc.jar for every
artifact it produces and allows that to be deployed to the repo. I
believe it does this because that is the format expected by the
different IDEs (it certainly is for IDEA and I think Raymond said it
worked for Eclipse as well). I think we would be wise to follow this
convention.
That would mean that e.g. for -api there would be
tuscany-api-${version}-javadoc.jar
in the repo.
I agree that we should just do *-api and -spi.
I also think we should do aggregated javadoc for all those modules
online on the website. We could make an archive of that available on
the download site (but I don't think we need to do that through the
maven repos).
--
Jeremy
On 11/1/06, Jim Marino [EMAIL PROTECTED] wrote:
On Nov 1, 2006, at 9:33 AM, Raymond Feng wrote:
Hi,
I think it would be useful to package java in our M2 binary distro.
I would like to hear your opinions:
I'd say as a separate downloadable jar since this would only be
relevant to extensions providers and not applications developers.
1) What modules should we generate javadoc? I assume only for *-api
and *-spi.
yes. Core is not an exposed api/spi.
2) Should we package the javadoc with the standalone distro or as a
separate archive?
separate archive
Thanks,
Raymond
-
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]
--
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: Javadoc for M2
Jim, I have responded to Jeremy's post on the details of what should be released and in which locations. As you say, personal preference on this point does vary, and there is quite a variation between other projects on how they handle this. I looked at a few other project releases to see what they do. Spring has online javadoc, but I don't see a downloadable version. Their minimal download includes source so I presume that people are exepcted to generate it from this (your approach). Tomcat and Axis2 have downloadable javadoc packages that are separate from their binary distribution. Ant, Xerces, XMLBeans, Hibernate, and Celtix include javadoc in their binary distribution, so there are quite a few precedents for doing this. At this stage of Tuscany I think we are targeting application developers and extension developers, so I would be more inclined to have a downloadable binary package that is a development/runtime kit rather than a pure runtime. When we are ready to start promoting Tuscany as a runtime for use with pre-built applications, it would make sense to have a pure runtime download. Simon Jim Marino wrote: On Nov 1, 2006, at 3:20 PM, Simon Nash wrote: Comments inline below. Simon Jim Marino wrote: On Nov 1, 2006, at 9:33 AM, Raymond Feng wrote: Hi, I think it would be useful to package java in our M2 binary distro. I would like to hear your opinions: I'd say as a separate downloadable jar since this would only be relevant to extensions providers and not applications developers. The spec API and tuscany-api are relevant to application developers and extension developers. The spec API jars are obviously relevant, tuscany api much less so (hopefully applications developers would not use these very much, if at all) tuscany-spi is relevant only to extension developers but as you said in earlier posts, these are an important segment of the audience for M2. Yes and that's why I believe we should bundle them separately. I generally prefer not to download javadoc at all on my machine for two reasons. One is I typically access it online. The second is if I use it a lot, I also want the source. So, I download the source and setup my IDE appropriately; it can display javadoc directly from the source. For simplicity I think it is better to bundle all of these in the standalone distro rather than create many separate downloadable packages. It would probably be informative to look at how other similar projects manage distributions. Spring for instance has a baseline distro without Javadoc or optional dependencies, i.e. something similar to our core distribution. I don't want to belabor the point, however, as I think we have different philosophical views on what is easier, a single large distribution that one must modify to create runtime and dev images or smaller units that people can deal with individually. Perhaps we should just have both? If we want to have both, could you please respond to Jeremy's previous post in this thread with a proposal on how to resolve the issues he raised? Jim Also this would match how javadoc is packaged in SDO M2. 1) What modules should we generate javadoc? I assume only for *- api and *-spi. yes. Core is not an exposed api/spi. Agreed. 2) Should we package the javadoc with the standalone distro or as a separate archive? separate archive Combined (see reasons above). Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 DAS Java M2 RC4b
+1 On 11/2/06, Luciano Resende [EMAIL PROTECTED] wrote: Off course, my +1 (not sure if binding yet) On 11/2/06, kelvin goodson [EMAIL PROTECTED] wrote: +1 On 01/11/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi Everyone Please vote to approve DAS Java Milestone 2 distributions. The vote is open for at least the next 72 hours. At least three +1 votes are required, and only the votes from Tuscany committees are binding. If the majority of all votes is positive, I will send a summary of that vote to the Incubator's general list to formally request the Incubator PMC to approve the Tuscany DAS M2 release. The release candidate is available at: http://people.apache.org/~kelvingoodson/das_java/RC4b/ http://people.apache.org/%7Ekelvingoodson/das_java/RC4a/ The release is taged at : https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/ What's new in DAS Java M2 DAS Core features - MySQL support - Static Data Objects - Dynamic root for static graphs - Unique attribute on relationships - Explicit ResultSet shape definition - Improved logging - Programmatic Configuration - Helper for empty SDO Graph - Convention over configuration - Column named ID is the PK - Column named xxx_ID is the FK to table xxx DAS Samples - Tomcat integration and automated DAS samples testing (htmlUnit) - DAS Samples now have all dependencies and source code inside the sample war For detailed user documentation and feature descriptions, access Tuscany DAS Wiki page - http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview Thanks Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem building sdo project
I'm trying to build the sdo project from the sdo-java-M2 branch. I started with an empty local maven repo. All the dependencies built OK, and the build for sdo was going well until it failed with the following error: Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ maven/maven-model/2.0.4/maven-model-2.0.4.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file org.apache.maven:maven-model:jar:2.0.4 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.m1 (http://people.apache.org/repository), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), eclipse.emf (http://download.eclipse.org/tools/emf/maven2) Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubator- M2 2) org.apache.maven:maven-project:jar:2.0.4 3) org.apache.maven:maven-model:jar:2.0.4 Caused by I/O exception: Connection timed out: connect [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 5 minutes 36 seconds [INFO] Finished at: Thu Nov 02 16:44:56 GMT 2006 [INFO] Final Memory: 11M/33M [INFO] I copied maven-model-2.0.4.jar manually and the build appeared to complete successfully. Wbat is the cause of this error and what should I do if it happens again? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-829) Investigate integration of RogueWave tests
[ http://issues.apache.org/jira/browse/TUSCANY-829?page=all ] Bryan Luoma updated TUSCANY-829: Attachment: sdo.zip The archive (sdo.zip) consists of two junit tests (XMLDataObjectTest.java and DataObjectList.java) and a helper class (TestHelper.java). XMLDataObjectTest.java has 120 test-cases that test the DataObject interface. This test uses several underlying RW implementation specific classes to perform some of the work. This is not a generic SDO API test that is ready to integrate into Tuscany. DataObjectListTest.java has 23 test-cases that test list functionality of DataObject. This test does not use RW implementation specific classes and should be easier to integrate into Tuscany as is. TestHelper.java is used by XMLDataObjectTest.java to help create DataGraphs and load input files. The TestHelper also uses RW implementation specific classes. Investigate integration of RogueWave tests -- Key: TUSCANY-829 URL: http://issues.apache.org/jira/browse/TUSCANY-829 Project: Tuscany Issue Type: Test Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson Attachments: sdo.zip, sdo.zip, testdata.zip, testdata.zip Investigation of bringing RogueWave tests into the Tuscany environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Building and running samples for Tuscany M2 SCA Java
At the moment our samples for Tuscany M2 SCA Java all use maven to build and run. Some of the audience for M2 may not be maven users and I think it would be valuable to give them as much help as we can to get the samples building and running in their environment. I'm looking into this and I think a good starting point is to enable an alternative ant-based approach by providing build.xml scripts as we did for M1. I'm going to see how far I can get with this in the time available before we finalize the M2 release. I don't know if I will have time to do this for all the samples, but I think it is useful to do as much as I can, even if I am only able to cover a subset of the samples before we cut the M2 release. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure on latest trunk
I had similar problems, though not with this particular file. For each failure, I copied the missing files from my previous archived local maven repo and restarted the build. All seemed to complete OK in the end. In all I had to copy about 4 or 5 files. Simon Ignacio Silva-Lepe wrote: After a full update and nuking my local repo, I get the following build failure when trying a mvn clean from the root. Any ideas? [INFO] - --- [INFO] Building Tuscany DAS for Relational Databases [INFO]task-segment: [clean] [INFO] - --- [INFO] snapshot org.apache.tuscany.sdo:tuscany-sdo-plugin:1.0-incubator-SNAPSHOT : checking for updates from apache.snapshots [INFO] snapshot org.apache.tuscany.sdo:tuscany-sdo-plugin:1.0-incubator-SNAPSHOT : checking for updates from codehaus-snapshot [INFO] snapshot org.apache.tuscany.sdo:tuscany-sdo-plugin:1.0-incubator-SNAPSHOT : checking for updates from apache.incubator Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tus cany/sdo/tuscany-sdo-plugin/1.0-incubator-SNAPSHOT/tuscany- sdo-plugin-1.0-incuba tor-SNAPSHOT.jar [WARNING] Unable to get resource from repository apache.snapshots ( http://people .apache.org/repo/m2-snapshot-repository) Downloading: http://snapshots.repository.codehaus.org/org/apache/tuscany/sdo/tus cany-sdo-plugin/1.0-incubator-SNAPSHOT/tuscany- sdo-plugin-1.0-incubator-SNAPSHOT .jar [WARNING] Unable to get resource from repository codehaus-snapshot ( http://snaps hots.repository.codehaus.org) Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/t uscany/sdo/tuscany-sdo-plugin/1.0-incubator-SNAPSHOT/tuscany- sdo-plugin-1.0-incu bator-SNAPSHOT.jar [WARNING] Unable to get resource from repository apache.incubator ( http://people .apache.org/repo/m2-incubating-repository) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that t he goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sdo-DartifactId=tusca ny-sdo-plugin \ -Dversion=1.0-incubator-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/t o/file org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubator-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), codehaus-snapshot (http://snapshots.repository.codehaus.org) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubator-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), codehaus-snapshot (http://snapshots.repository.codehaus.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure on latest trunk
Hmm, the reason I nuked my repo in the first place is that I was getting the same failure, and perhaps I was having conflicts with old files. On 11/2/06, Simon Nash [EMAIL PROTECTED] wrote: I had similar problems, though not with this particular file. For each failure, I copied the missing files from my previous archived local maven repo and restarted the build. All seemed to complete OK in the end. In all I had to copy about 4 or 5 files. Simon Ignacio Silva-Lepe wrote: After a full update and nuking my local repo, I get the following build failure when trying a mvn clean from the root. Any ideas? [INFO] - --- [INFO] Building Tuscany DAS for Relational Databases [INFO]task-segment: [clean] [INFO] - --- [INFO] snapshot org.apache.tuscany.sdo:tuscany-sdo-plugin:1.0-incubator-SNAPSHOT : checking for updates from apache.snapshots [INFO] snapshot org.apache.tuscany.sdo:tuscany-sdo-plugin:1.0-incubator-SNAPSHOT : checking for updates from codehaus-snapshot [INFO] snapshot org.apache.tuscany.sdo:tuscany-sdo-plugin:1.0-incubator-SNAPSHOT : checking for updates from apache.incubator Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tus cany/sdo/tuscany-sdo-plugin/1.0-incubator-SNAPSHOT/tuscany- sdo-plugin-1.0-incuba tor-SNAPSHOT.jar [WARNING] Unable to get resource from repository apache.snapshots ( http://people .apache.org/repo/m2-snapshot-repository) Downloading: http://snapshots.repository.codehaus.org/org/apache/tuscany/sdo/tus cany-sdo-plugin/1.0-incubator-SNAPSHOT/tuscany- sdo-plugin-1.0-incubator-SNAPSHOT .jar [WARNING] Unable to get resource from repository codehaus-snapshot ( http://snaps hots.repository.codehaus.org) Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/t uscany/sdo/tuscany-sdo-plugin/1.0-incubator-SNAPSHOT/tuscany- sdo-plugin-1.0-incu bator-SNAPSHOT.jar [WARNING] Unable to get resource from repository apache.incubator ( http://people .apache.org/repo/m2-incubating-repository) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that t he goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sdo-DartifactId=tusca ny-sdo-plugin \ -Dversion=1.0-incubator-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/t o/file org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubator-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 ), codehaus-snapshot (http://snapshots.repository.codehaus.org) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubator-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 ), codehaus-snapshot (http://snapshots.repository.codehaus.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat integration test with Cargo?
I've not tried it but I think it's a good way to go because it is meant to support multiple server types. So hopefully if we base deployment on the Cargo plugin then we should be able to reuse a lot of configuration for testing on Jetty, Geronimo, ... This does not replace things like htmlunit, but then I don't think we need to be testing html, we can use SCA clients or XML/JSON data from the server which is easier to validate. -- Jeremy On Oct 31, 2006, at 4:28 PM, Raymond Feng wrote: Hi, I found Cargo from the Apache maven web site. The URL is http:// cargo.codehaus.org/Home. It seems that we can use it to install/start/stop tomcat as well as deploy/undeploy applications. Is it a good fit? Has anyone tried it before? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-896) java.lang.IndexOutOfBoundsException trying when there is no default service for the composite
java.lang.IndexOutOfBoundsException trying when there is no default service for the composite - Key: TUSCANY-896 URL: http://issues.apache.org/jira/browse/TUSCANY-896 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Environment: Win32 Reporter: Luciano Resende Fix For: Java-Mx See detailed discussion available at : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10273.html Following stack trace of the error. java.lang.IndexOutOfBoundsException : Index: 0, Size: 0 java.util.ArrayList.RangeCheck(ArrayList.java:546) java.util.ArrayList.get(ArrayList.java:321) org.apache.tuscany.spi.extension.CompositeComponentExtension.getServiceInstance(CompositeComponentExtension.java :239) org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:269) org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) org.apache.jsp.Company_jsp._jspService(Company_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java :802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.IndexOutOfBoundsException trying to consume SCA component in a web app
Thanks, I was able to get things working by updating the scdl of the das service like this : composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite service name=DASService interface.java interface= org.apache.tuscany.samples.das.service.DASService/ referenceDASServiceComponent/reference /service component name=DASServiceComponent implementation.java class= org.apache.tuscany.samples.das.service.DASServiceImpl/ /component /composite Basically adding the service name=DASService part. Thank you Luciano Resende On 11/2/06, Jim Marino [EMAIL PROTECTED] wrote: This is because there is no default service for the composite (we should probably check for this and throw a better error). What seems to be happening is that CompositeComponentExtension.locateService() is resolving to a child composite context which has no default service. It looks as if you are trying to have nested composites. If you do this the DAS component needs to be exposed as a service on the inner composite. Another option would be to point the current composite context to the inner composite (there is a config parameter in the servlet context for this). You should be able to find an example of this in the Spring sample. A further option would be just to have one composite (as opposed to the hierarchy) would make things simpler. Jim On Nov 2, 2006, at 3:29 AM, Luciano Resende wrote: I have created a simple DASService component, and trying to use it in a client web application (based on webapp sample app)... Although, I'm getting the following exception : java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 java.util.ArrayList.RangeCheck(ArrayList.java:546) java.util.ArrayList.get(ArrayList.java:321) org.apache.tuscany.spi.extension.CompositeComponentExtension.getServic eInstance(CompositeComponentExtension.java:239) org.apache.tuscany.spi.extension.CompositeComponentExtension.locateSer vice(CompositeComponentExtension.java:269) org.apache.tuscany.core.launcher.CompositeContextImpl.locateService (CompositeContextImpl.java:65) org.apache.jsp.Company_jsp._jspService(Company_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter (TuscanyFilter.java:58) das service default.scdl composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite component name=DASServiceComponent implementation.java class= org.apache.tuscany.samples.das.service.DASServiceImpl/ /component /composite das service client default.scdl composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=DASServiceComposite component name=DASServiceComponent implementation.composite name=DASServiceComposite jarLocation=lib/sample-das-service-1.0-incubator-SNAPSHOT.jar/ /component /composite This is with trunk code... Any ideas on what might be wrong ? - Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc for M2
Hi,
Let me propose the following. We need to close it quickly so that it won't
become a blocker for M2.
1) For *-api and *-spi, we're going to have the javadoc per module and
publish them into maven repo.
2) A separate distro to aggragate all the javadocs into one downloadable
archive.
3) An aggregate online javadoc on Tuscany web site for M2.
What level of linking (to JDK classes or other javadocs) do we want?
I think javadoc is a just a reference for programmers. If there's a
convenient way to get it, I'm statisfied.
Thanks,
Raymond
- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, November 02, 2006 8:01 AM
Subject: Re: Javadoc for M2
I agree with all these suggestions. In the SCA javadoc downloadable
archive I would include the spec API along with tuscany-api,
tuscany-host-api, and tuscany-spi. (Perhaps this is what you meant
by *-api).
This downloadable javadoc archive could either be combined with the
downloadable standalone distribution, or separate from it. See my
latest response to Jim for the reasons why I think it would be
better to have this as a part of the standalone binary distribution
on the download site for this release. However, I don't think the
same considerations apply to the standalone distribution that we
will publish to the maven repo. I would expect users of this
version to use maven to get the javadoc from the maven repo as well.
So my suggestion would be to not include javadoc in the standalone
runtime that we publish to the maven repo but to include it in the
binary/standalone version that we place on our web site for download.
Simon
Jeremy Boynes wrote:
The maven javadoc goal by default generates a -javadoc.jar for every
artifact it produces and allows that to be deployed to the repo. I
believe it does this because that is the format expected by the
different IDEs (it certainly is for IDEA and I think Raymond said it
worked for Eclipse as well). I think we would be wise to follow this
convention.
That would mean that e.g. for -api there would be
tuscany-api-${version}-javadoc.jar
in the repo.
I agree that we should just do *-api and -spi.
I also think we should do aggregated javadoc for all those modules
online on the website. We could make an archive of that available on
the download site (but I don't think we need to do that through the
maven repos).
--
Jeremy
On 11/1/06, Jim Marino [EMAIL PROTECTED] wrote:
On Nov 1, 2006, at 9:33 AM, Raymond Feng wrote:
Hi,
I think it would be useful to package java in our M2 binary distro.
I would like to hear your opinions:
I'd say as a separate downloadable jar since this would only be
relevant to extensions providers and not applications developers.
1) What modules should we generate javadoc? I assume only for *-api
and *-spi.
yes. Core is not an exposed api/spi.
2) Should we package the javadoc with the standalone distro or as a
separate archive?
separate archive
Thanks,
Raymond
-
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]
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Website Updates
Hi, I uploaded Venkat's patch to http://people.apache.org/~rfeng/tuscany/site-publish/index.html for better viewing. I found quite a few links bring me to the wrong page. I would suggest that we keep the GUI template (panes and tabs) as is and focus on adding more contents. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, November 02, 2006 3:33 AM Subject: Re: Tuscany Website Updates Sure yes Ant. For the Documentation, as mentioned earlier, I plan to have separate pages for SCA Docs, SDO Docs. and DAS Docs. Each of these pages will have a list of topics that will further link to separate pages. Here is something that I can imagine for now for this. 1) SCA Java Overview will will have something in general about how we have partitioned as APIs SPI Core etc. 2) SCA Java - Extensions About extensions... Implementation Types, Bindings and the general prog. model around loaders, buliders, invokers How to write your own impl. type and binding extensions Tuscany Implementatin Extensions JavaScript Groovy Ruby 3) SCA Java - DataBinding Facility About DataBinding and its advantage How to write your own data bindings 4) Java SCA Runtimes and Application Deployment Standalone WebApp 5) Java SCA Samples Overview of samples available in SCA Java How to write your own SCA Application So I guess, what you wish to do might go into one of the lind uder Topic 2. Please feel free to correct this or fill in if I have grossly missed out on somethings. Thanks - Venkat On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, ant elder [EMAIL PROTECTED] wrote: On 11/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am putting up some proposals for updates to our website and request feedback on this or suggestions for the better. Right away some top level ones are: - Do away with the tabs. This is because I don't see correlation between the Tab options and the options on the navigation pane in the left. i.e . if the tabs are first level navigation then the pane on the left must be sub-options within a selected tab - I don't see such a correlation. So let's avoid confusion to the website visitor - There is lots of green :) and am having some difficulties to get additional colors that gel with this. Either somebody with better colour sense helps or we moderate the green a bit. - The images that are used for the Navigation Optoins on the left pane and for the titles of various boxes may need to be sharpened a bit All this besides the fact the the various navigations paths need to be reviewed and set right. I shall get to these as well. Meanwhile I have created a JIRA http://issues.apache.org/jira/browse/TUSCANY-703 where I have attempted to provide a view of what's in my mind for the Navigation Pane on the left together with some changes for the Downloads page. You simply have to extract the zip that is attached in that JIRA and take a look at /site-publish/downloads.html. Also, I have a diagram posted for the Java_SCA Overview in the same JIRA, please see if you can say somethings about that as well. Thanks. - Venkat Its really good you're looking at the website Venkat, it has become a bit neglected. What you've suggested above all sounds good to me, I'd suggest just going ahead and making changes as you think appropriate as that will be much easier for you. Maybe for big ones mention on the dev list first but otherwise just dive in and send emails after the fact so others can review - just as with the code CTR not RTC :) I meant to add, I'd like to help, specifically with adding pages with doc about the various extensions, maybe along the lines of that example i posted earlier [1]. Could you find a space for me on the website for me to do that? ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA
Hi, I am trying to create a container for DAS-SCA too (not just for stored procedure) and will be able to send a working code in ML over the weekend. Below is summary of what I got so far from the previous mail discussions and some questions. The integration between DAS and SCA can happen at application level as service or at container level. 2 different possible approaches – static – e.g. getAllCustomers dynamic – e.g. execute(all customers); For application level service – it is the sample * sample-StoredProcedureService.jar* or what Luciano is providing in more details, is an example. In *sample-StoredProcedureService.jar* example dynamic approach is followed For container approach – again static or dynamic approach can be followed. For static – it's like providing service for getAllCompanies(), getAllCustomers() etc. whereas for dynamic its like execute(command) where command can be getAllCompanies, getAllCustomers. Etc. I am working on a container implementation where dynamic approach is followed. There are 2 places where extensibility is required – 1) for providing different data access mechanisms. i.e. today there is RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the scdl will be same, but the exampleconfig.xml will change. In the container I am working on - Scdl has a new tag Scdl has a new tag da:implementation.da script=customersOrders/CustomersOrders.xml dataAccessType=rdb/ Here, dataAccessType – is the key which tells whether it's RDB or something else. And the xml script provides the connection and data store details. 2) for RDB-DAS – providing support for different databases (this portion should be part of DAS and not SCA.) In the current container I am working on it is provided as a package - org.apache.tuscany.container.dataaccessshelper package - which should finally go into DAS codeline(?). For static approach we may need some code generation tooling. Also could not understand how this can be merged into RESTful interfaces. (this was mentioned in some mail conversation) Regards, Amita On 10/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Luciano Resende wrote: Comments in-line... On 10/25/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote: Hi, I would also like to understand this a little better ... here I am thinking aloud and hope the others will help in getting my persceptions right... I guess firstly it is a question of how or where we want to position 'DAS Integration' in SCA. Is is something we want to integrate as the Application Layer, which I understand is what Amita is trying presently and which Jim refers to as component implementation. In this option we get to do some sort of a service wrapper to DAS and then it becomes a demonstration of two Tuscany subprojects integrating at application level. Yes, I think we have space to position DAS both ways, and integrating in the application layer by exposing DAS as a service would be a very easy and quick, this could be exposed as a sample app, and could show we are working on getting a better integration between DAS and SCA Or do we want to position DAS at the infrastructure layer as another extension type (either container or binding). I guess this is where Ant started this - proposing a JDBC container / binding for component implementation in StoredProcedures. I was thinking a DAS was a way to declaratively model heterogeneous data as a service and offer a mechanism for remoting that data. In other words, it provided the ability for an application to perform CRUD using a high-level contract (interface) and having those operations take place across a service network. How this is hooked into the SCA container is probably best done as an extension type, i.e. someone could specify: component name=Foo implementation.das interface.java /implementation.das /component Yes, this goes back to the way I was thinking on my original proposal. If this is the path we should take then we probably have to think beyond DAS - to something more general - of which DAS is just a special case. I suppose this is what Jim has also suggested in trying to explore other persistence mechanisms. This may be the crux of the confusion. I was thinking DAS provides a general mechanism for accessing heterogeneous data and is only right now tied to SQL because of resource constraints (i.e. we have to start somewhere). Ultimately, DAS should provide the infrastructure for dealing with multiple, varied data stores and mechanisms for querying across them. In other words, I guess I am saying DAS should be the general solution (declarative and heterogeneous) since if it is only a programmatic way to access relational data then its value is less clear in comparison to things such as JDBC 4 or JPA.
