[jira] Created: (TUSCANY-927) SCA Policy framework support in Tuscany
SCA Policy framework support in Tuscany --- Key: TUSCANY-927 URL: http://issues.apache.org/jira/browse/TUSCANY-927 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Wish list Environment: all Reporter: Felix Ren Intents and PolicySets support -- 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: Test failure with CastCastException in trunk DAS code
Hi Kelvin, This looks like caused by the changes from Tuscany-885 (revision 474389)... if I remove that, the DAS test cases passes and then there is no build break. Could you please take a look at it ? - Luciano On 11/13/06, Luciano Resende [EMAIL PROTECTED] wrote: Yes, just saw this too... while getting hte lates trunk... investigating... On 11/13/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I ran into this failure when I tried to build the latest trunk code using mvn clean followed by mvn install. Running org.apache.tuscany.das.rdb.test.suites.AllTestsDerby Setting up for Derby run Ending Derby run Tests run: 140, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 21.688sec FAILURE! testReadSingleVerifyShapeUse( org.apache.tuscany.das.rdb.test.ResultSetShapeTests ) Time elapsed: 0.078 sec ERROR! java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl incompatible with java.util.List at org.apache.tuscany.sdo.impl.DataObjectImpl.getList( DataObjectImpl.jav a:376) at org.apache.tuscany.das.rdb.test.ResultSetShapeTests.testReadSingleVer ifyShapeUse( ResultSetShapeTests.java:85) Thanks, Raymond
[jira] Updated: (TUSCANY-927) SCA Policy framework support in Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-927?page=all ] Felix Ren updated TUSCANY-927: -- Attachment: policyinit.patch Initial checkin for policy framework. SCA Policy framework support in Tuscany --- Key: TUSCANY-927 URL: http://issues.apache.org/jira/browse/TUSCANY-927 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Wish list Environment: all Reporter: Felix Ren Attachments: policyinit.patch Intents and PolicySets support -- 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]
[jira] Updated: (TUSCANY-927) SCA Policy framework support in Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-927?page=all ] Felix Ren updated TUSCANY-927: -- Attachment: java.sca.kernel.core.src.test.resources.org.apache.tuscany.core.zip I couldn't package a file in a new folder into the patch, so I upload it as a separated file. SCA Policy framework support in Tuscany --- Key: TUSCANY-927 URL: http://issues.apache.org/jira/browse/TUSCANY-927 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Wish list Environment: all Reporter: Felix Ren Attachments: java.sca.kernel.core.src.test.resources.org.apache.tuscany.core.zip, policyinit.patch Intents and PolicySets support -- 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]
[jira] Commented: (TUSCANY-927) SCA Policy framework support in Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-927?page=comments#action_12449610 ] Felix Ren commented on TUSCANY-927: --- Hi Jim and others, This initial patch including several separated parts of Policy Framework, I did not integrate them into core loading and building phase yet. Model classes for policy artifacts IntentRegistry: Registry for system scope intent. PolicySetLoader: A LoaderExtension load policy set model class from SCDL file. PolicyEngine: Match intent to concrete policy artifacts. I had two problems when I tried to integrate policy support into Tuscany runtime, When policy intent is registered to SCA system, the SCA artifact type which can be applied to is represented with the QName of SCA type. And policy intent applied to an abstract SCA type is applicable for all concrete types of this abstract type. intent name=xs:NCName appliesTo=list of xs:QNames ? description Description of the policy intent /description /intent In SCDL file, SCA type is distinguished with the QName of XML element, after loading phase, the model classes don't hold the reference to QName, so we can't the get the QName of model or SCAObject when building and wiring. Do you think it is reasonable to add QName of SCA artifact type to model classes? Another problem is about scope of PolicySet, I assume the PolicySet embedded in SCDL belongs to the Composite of this SCDL file, so I would add the following methods to CompositeComponentType, and integrate PolicySet loader to composite loader. CollectionPolicySet getAllPolicySet(); PolicySet getPolicySet(QName name); void addPolicySet(PolicySet policySet); Do you think CompositeComponentType is the appropriate place for PolicySet? Regards, Felix SCA Policy framework support in Tuscany --- Key: TUSCANY-927 URL: http://issues.apache.org/jira/browse/TUSCANY-927 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Wish list Environment: all Reporter: Felix Ren Attachments: java.sca.kernel.core.src.test.resources.org.apache.tuscany.core.zip, policyinit.patch Intents and PolicySets support -- 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: [C++] Doxygen documentation for our runtime
On 14/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Definitely! Done under revision r474696. On linux, run configure with the --enable-doxygen option. It's off by default. On Windows run doxygen Doxyfile.w32 from the doc directory. The doc is generated under doc/doxygen. The same scheme can be replicated for SDO. We did this with the tree originally so some of the code has comments in the correct Doxygen format. Is there an option to insert comment headers into the source? The doxygen format is described there: http://www.stack.nl/~dimitri/doxygen/docblocks.html. You can write doc blocks anywhere except inside the body of a function. What did you mean by is there an option to insert comment headers into the source? I meant can we get Doxygen to insert the correct format comment block above methods etc. with blank content. I'm sure not all methods have the correct comments! So for a method int fred(string x); we need /** @param x @return **/ int fred(string x); Just a thought! We need to document our code in a consistent way which it isn't at the moment. Cheers, -- Pete
[jira] Commented: (TUSCANY-928) Define Tuscany SDO options for XMLHelper load and save operations
[ http://issues.apache.org/jira/browse/TUSCANY-928?page=comments#action_12449635 ] Kelvin Goodson commented on TUSCANY-928: TUSCANY-713 represents a specific instance of this issue, and prereqs a solution to this JIRA. Define Tuscany SDO options for XMLHelper load and save operations - Key: TUSCANY-928 URL: http://issues.apache.org/jira/browse/TUSCANY-928 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson XMLHelper's load and save operations take an Object argument options, which is currently cast to a Map and forwarded to EMF. Anyone wishing to influence the behaviour of the save/load operations must understand this aspect of EMF and use EMF artifacts in their programs. We need to design and implement an SDO approach to passing options, hiding the implementation details completely. -- 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]
[jira] Commented: (TUSCANY-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ http://issues.apache.org/jira/browse/TUSCANY-713?page=comments#action_12449633 ] Kelvin Goodson commented on TUSCANY-713: The result of Yangs experimentation was to demonstrate that we can achieve this behaviour by setting options at the EMF level, in particular org.eclipse.emf.ecore.xmi.XMLOptions#setProcessSchemaLocations(true) but this brings up the wider issue of addressing the passing of options, and the fact that it currently exposes EMF, so I believe we should prereq a solution to TUSCANY-928 before we can address this (and indeed this issue may be solved as part of TUSCANY-928). Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: http://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Wish list Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- 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]
[jira] Commented: (TUSCANY-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ http://issues.apache.org/jira/browse/TUSCANY-713?page=comments#action_12449637 ] Kelvin Goodson commented on TUSCANY-713: One other thing I meant to add was to capture the fact that we must be able to be able to define a TypeHelper instance to be used with the load schemas option so that the newly found types can be registered in the context that the application desires. Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: http://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Wish list Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- 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: Setting Open Content (Was Re: SDO Java: Getting Involved -- Tests/Samples)
HI Andy,
the ability to perform open content addition in this way .
DataObject product = catalog.createDataObject(product,
commonj.sdo, DataObject);
is SDO 2.1 behaviour, and we don't have that operating in Tuscany yet.
To set open content you currently need to use the Property variant setters
etc. and you have to find or create a global property that is suitable for
the purpose, e.g.
Type globalType = SDOUtil.createType(TypeHelper.INSTANCE,
some-namespace, null, false);
Property p = SDOUtil.createProperty(globalType, newProp,
TypeHelper.INSTANCE.getType(commonj.sdo,String));
note that the property is interpreted as a global properties becuase its
containing type has a null name.
The alternative is to use global properties generated from global elements
in an xsd to sdo conversion.
Cheers, Kelvin.
On 13/11/06, Andy Grove (Contractor) [EMAIL PROTECTED] wrote:
Hi Kelvin,
I'm in the process of re-organizing our test suite to remove
dependencies on internal classes and I am trying to run the tests
against a current snapshot of Tuscany. I have hit a problem early on
that is causing many tests to fail.
I'm not sure of the correct process for getting questions like this
answered so I'm posting here but please let me know if I should be
posting a JIRA.
The following method is used to create a sample document that many of
the tests then use:
public static XMLDocument createProductCatalogDocument() {
// create a test document using the SDO API
String xml = catalog/catalog;
XMLDocument doc = getXMLHelper().load(xml);
DataObject catalog = doc.getRootObject();
for (int i = 0; i 10; i++) {
DataObject product = catalog.createDataObject(product,
commonj.sdo, DataObject);
product.setInt(identifier, i);
product.setString(theName, Product # + i);
product.setString(theDescription, This is a description
of product # + i);
product.setBigDecimal(thePrice, new BigDecimal(i * 1.5));
product.setDate(theDate, new Date());
}
return doc;
}
The code is failing on the line that attempts to create an open-content
property product with the error Class 'AnyTypeDataObject' does not
have a feature named 'product'.
In the RW implementation this code works because the root DataObject
representing the catalog element is an open DataObject (of type
commonj.sdo#DataObject). However, Tuscany is creating the root object
with the type http://www.apache.org/tuscany/2005/SDO#AnyTypeDataObject.
This appears to be an open type e.g. getType().isOpen() returns true but
it is not letting me create the open content property product.
Is this a bug in Tuscany or am I doing something incorrect in my use of
Tuscany?
Thanks,
Andy.
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 02 November 2006 10:12
To: tuscany-dev@ws.apache.org
Subject: 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
Re: SDO Java: Getting Involved -- Tests/Samples
For the record, as this thread was getting a bit long I responded to this under a new title --- Re: Setting Open Content (Was Re: SDO Java: Getting Involved -- Tests/Samples)
[jira] Created: (TUSCANY-928) Define Tuscany SDO options for XMLHelper load and save operations
Define Tuscany SDO options for XMLHelper load and save operations - Key: TUSCANY-928 URL: http://issues.apache.org/jira/browse/TUSCANY-928 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Kelvin Goodson XMLHelper's load and save operations take an Object argument options, which is currently cast to a Map and forwarded to EMF. Anyone wishing to influence the behaviour of the save/load operations must understand this aspect of EMF and use EMF artifacts in their programs. We need to design and implement an SDO approach to passing options, hiding the implementation details completely. -- 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: [jira] Commented: (TUSCANY-921) wire element in SCDL causes UnrecognizedElementException
Hi Jim,
Please help me understand this... all of what I mention here is in the
context of explicit wire defintions.. i.e. wires defined in scdl by the
'wire' element.
As per the specs it seems like the source of a wire could be a composite's
service's reference. If this is the case can I have a composite whose
service element does not have a 'reference' defined inline but instead has
this wiring mentioned by a separate 'wire' element.
If yes, then the service loader might need some changes since it throws
an exception if a target is not defined as part of the service definition.
If no, then I don't find the specs excluding composite services as
sources of 'wire' definitions.
So which is the direction we take ?
Thanks
- Venkat
On 11/13/06, Venkatakrishnan (JIRA) tuscany-dev@ws.apache.org wrote:
[
http://issues.apache.org/jira/browse/TUSCANY-921?page=comments#action_12449264]
Venkatakrishnan commented on TUSCANY-921:
-
Hi,
I can give this a try with some help from you. Will do some groundwork
and get back asap. Thanks
- Venkat
wire element in SCDL causes UnrecognizedElementException
--
Key: TUSCANY-921
URL: http://issues.apache.org/jira/browse/TUSCANY-921
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Using a wire element in a composite results in an exception.
org.apache.tuscany.spi.loader.UnrecognizedElementException: {
http://www.osoa.org/xmlns/sca/1.0}wire
[{http://www.osoa.org/xmlns/sca/1.0}wire]
Context stack trace: [application]
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:90)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(
CompositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(
CompositeLoader.java:55)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:92)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile
(CompositeComponentTypeLoader.java:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:39)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(
LoaderRegistryImpl.java:159)
at org.apache.tuscany.core.deployer.DeployerImpl.load(
DeployerImpl.java:101)
at org.apache.tuscany.core.deployer.DeployerImpl.deploy(
DeployerImpl.java:76)
--
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: Unit testing/debuging a SCA Container
Hi Luciano, Presently there are some unit tests in the JavaScript and Ruby containers. You could probably get to do similar ones for DAS as well. Though you might have to cover a little more I am sure you will get a good idea of how to go about this on you take a look at them. - Venkat On 11/13/06, Luciano Resende [EMAIL PROTECTED] wrote: I'm working with Amita's contribution ( http://issues.apache.org/jira/browse/TUSCANY-904) to modify the DAS container implementation in order to get it ready to go to the trunk and would like to see what's the best approach for performing unit testing and debuging a SCA Container. Any help would be appreciated Thanks Luciano Resende
[jira] Updated: (TUSCANY-906) Provide ant scripts to build selected samples
[ http://issues.apache.org/jira/browse/TUSCANY-906?page=all ] Simon Nash updated TUSCANY-906: --- Attachment: build.xml Updated build.xml file for calculator sample, eliminating copy tasks Provide ant scripts to build selected samples - Key: TUSCANY-906 URL: http://issues.apache.org/jira/browse/TUSCANY-906 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Environment: Java5, Windows XP Reporter: Simon Nash Attachments: build.xml, build.xml, build.xml The samples in the M2 branch are all set up to be built using maven. For non-maven users, there is currently no alternative approach to building that is supported or documented. This will be a significant inhibitor to non-maven users picking up and using the M2 release. We should include ant scripts for at least least some of the samples to provide an alternative approach that works out of the box for ant and is easy to customize for other build environments. -- 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]
Howto
Willian, Luciano said to upload the howto in the wiki, no matter if it's finished or not. Report us when you have uploaded it ; ) Then I will try to describe the the xml configuration file you've made. Adriano Crestani
Re: DAS Container - First part ready for review....
Hi, I have tried my best to explain... just in case something is not right in this could somebody pitch in please. Thanks. - Venkat On 11/14/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi All I have updated (Tuscany-904) with a new version of the DAS container. This is based on the initial contribution that Amita did, with some clean-up, refactoring and additions to try to fix a possible problem with mutable properties that are shared among instance (pointed by Jim Marino)... Currently, this is just the initial drop that I want to make available in the trunk so other can start to take a look and Amita and I could collaborate easier... unit testings, sample, etc are coming... I'd appreciate if anyone could help get this to the trunk if there is nothing wrong with this... Couple Questions: Could someone take a quick look at ComponentTypeLoader and see if it's looking Ok ? I was not sure about what this loadFromSideFile means ? what is the side file? Is this something particular to Script container ? A sidefile is one way of exposing the configurable aspects of an implementation. The other way is thro annotations. Yet another is to follow some coding conventions so that this information is introspectable. The sidefile way of doing things is, to the best of what I understand, a common means across containers. i.e. you can have javascript, java, ruby, das (if you will) components all using the sidefile in a similar manner as this is prescribed by the specs. For the introspectable way you will see Java and JavaScript vary in how they achieve this. The same goes for annotations - right now the java container alone can leverage this (as far as I know). Also, I wasn't sure what time is the appropriate time to load the das config file when provided ? Right now is being loaded at DataAccessImplementationLoader, if you guys think this should go in a different place, please let me know... also would be good to know why :) The config file could very well be read / parsed during 'load' time using the loader. The loading is just about picking up the component definition information from the scdl file and creating a java object model for them. The next phase is the 'build' phase where you must create the necessary runtime artifacts making use of the model you have defined in the loading phase. In your case I would imagine that you would inject the config values into the DAS Engine during the build time. Well, comments and feedback are welcome... Note that I'm still getting familiar with the Container SPI, so, please let me know if I misunderstood something on the implementation. - Luciano Resende Apache Tuscany
[jira] Updated: (TUSCANY-906) Provide ant scripts to build selected samples
[ http://issues.apache.org/jira/browse/TUSCANY-906?page=all ] Simon Nash updated TUSCANY-906: --- Attachment: build.xml Update build.xml file for helloworldws sample, eliminating copy tasks Provide ant scripts to build selected samples - Key: TUSCANY-906 URL: http://issues.apache.org/jira/browse/TUSCANY-906 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Environment: Java5, Windows XP Reporter: Simon Nash Attachments: build.xml, build.xml, build.xml, build.xml The samples in the M2 branch are all set up to be built using maven. For non-maven users, there is currently no alternative approach to building that is supported or documented. This will be a significant inhibitor to non-maven users picking up and using the M2 release. We should include ant scripts for at least least some of the samples to provide an alternative approach that works out of the box for ant and is easy to customize for other build environments. -- 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]
Review of Tuscany Java M2 Samples/Readme
After yesterday's chat I took some time to look at the samples/readmes from the M2 branch. Minus a few grammatical mistakes, I found the content consistent and easy to follow. Here are a few minor questions/concerns: - Why is the core-1.0-incubator-M2-SNAPSHOT.jar included in the contrib dir? - Are the runtime property (-D) options documented somewhere? It took me a while to find -Doffline=true for the standalone runtime. - The BigBank Sample Location section of the readme incorrectly states that BigBank is located in the sampleapps/bigbank dir. - When I try to run mvn tomcat:deploy on sample-helloworldjsonrpc.warfrom eclipse, I obtain the following error: LifecycleExecutionException: No Java test frameworks found. The command works fine from terminal. Strange because I can deploy all the other samples from eclipse. - Why are binding.axis2.scdl and databinding.sdo.scdl included at sca/runtime/webapp-host/src/main/resources/META-INF/sca/? - It seems unclear/confusing to me to include the outdated documents at tuscany-sca-1.0-incubator-M2-src\src\sca\doc in the source distro. thanks, -Lee
Updated ant scripts attached to TUSCANY-906
I have attached updated ant scripts for calculator and helloworldws to TUSCANY-906. Following Raymond's suggestion, they eliminate all the copy tasks. This makes them less scary than the previous versions, and makes it easier to see how to build a Tuscany standalone application or a Tuscany webapp. Any further suggestions for improvement are very welcome. At present these scripts still use standard ant tasks and so require the 2 Tuscany webapp jars to be available locally. I'm now going to start working on a solution that can handle remote dependencies. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 1.1 timeframes
Hi, all. I'll make the changes to change the axis2 version to 1.1 as well as other related artifacts. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 14, 2006 8:15 AM Subject: Re: Axis2 1.1 timeframes On 11/13/06, Raymond Feng [EMAIL PROTECTED] wrote: The axis2 1.1 is out! Please see the link @ http://ws.apache.org/axis2/index.html. But the artfiacts are not available in maven repo at the moment. They are now in the M1 repo at ibiblio: http://www.ibiblio.org/maven/org.apache.axis2/jars/ I think this replicates to the M2 repo as well but for now we can use the legacy repo. -- Jeremy - 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: Conversational services
I have also changed the non-blocking interceptor to propagate conversation ids to support async ops. An issue that comes up with this is that if a conversational service also uses async ops (e.g., one-ways), the corresponding implementations (client and/or service) need to be careful about concurrency. For instance, in the loan app sample, I made the cancel op a one-way. The client applies for a loan, displays the loan app, cancels it and displays again. So now the cancel thread is competing with the main thread for access to the service. The simple fix in the sample is to hold the main thread to let the cancel thread complete, which is impacting the client code. The spec(s) does not seem to be clear about whether the infrastructure must provide support to relieve the user from dealing with concurrency. For the remote case, the various bindings can provide support depending on policy and some handshaking with the core. For instance, for ws WS-RM can be used to provide ordering support but even that may not be sufficient in the face of potential races into an Axis2Reference. For the local case, it may be possible to provide some ordering support on a per conversation basis by sequencing invocations (a la WS-RM) but it's not clear the current architecture is there for this requirement. That is, an invocation handler may be able to behave as a conversation source for sequencing, but since there is a separate target invoker per operation, something would need to happen to get them in order. In any case, this are just some spur-of-the-moment thoughts. Others may have different ideas about whether or how to handle this issue. On 11/13/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: I have checked in code to complete a minimal implementation of conversational services, including a sample adapted from the CI spec. Still not using UUID for conversation ids, need to change. Rick, you can go ahead and test it (I did not include the sample in the main pom, you can run it from its own dir though). On 11/11/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 11, 2006, at 6:16 AM, Ignacio Silva-Lepe wrote: The CI spec defines a conversational interface as annotated with @Scope(session) but since we are also considering HTTP Session scopes, it seems that using @Scope(CONVERSATIONAL) would make things clearer. Notice that earlier in the spec (sec 1.2.1.4) the annotation @Scope(CONVERSATION) is used in passing, so it looks like the spec needs to be revised anyway. I think I may have missed a couple of places in the spec where things should have been changed from session to conversation. We also need a description for scopes to be placed back in the Java CI spec (it was originally in, moved to Assembly, and then the spec group decided to move it back to the respective CI specs) so I'll include this in that proposal. Jim For the current SCA/Java implementation of conversational services just getting under way, the current thought is to use @Scope(CONVERSATIONAL) On 11/11/06, Pete Robbins [EMAIL PROTECTED] wrote: Quick question: Is there an annotation that marks an interface as conversational? Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OSGi IRC discussion transcript
A few of us had a discussion about OSGi integration today on IRC for those interested: [08:11am] jhawkins: Welcome, Nicole! [08:11am] jmarino: Hi Nicole [08:11am] jmarino: should we begin? [08:11am] Nicole: yes Should we start asking questions? [08:12am] jhawkins: Lets. Where do you want to start? [08:13am] Nicole: I would like to talk about the requirement having the same jars for OSGi and other hosts. [08:13am] jmarino: k what do you guys think of that? [08:14am] Nicole: From my point of view it should not be a problem to generate bundles out of the JARs which we can use in OSGi. [08:14am] jhawkins: I think we'll probably have a requirmeent for dual packaging. In other words, there will be some bpeople who will want an OSGi centric capability, and otheres who'll opt fo conveince. [08:15am] jmarino: ok my thinking around wanting to have the same was that we could reuse extensions across runtime hosts. So if someone wanted to write an extension, it would run on OSGi or in a servlet container, etc. [08:16am] jhawkins: I did take a look at the Spring virtual bundle code (thanks Nicole), and it's true that we could pretty easily do that. However I think some of the cases where extensions share dependencies will be problimatic [08:16am] Nicole: We could have the sources of the binding in OSGi and provide 2 maven tags. One for the simple JAR, one for a bundle. [08:17am] jmarino: In the extension model now, we have the depenency tag...could we programatically create the OSGi bundle? I was thinking we could support both bundles directly (pure OSGi) and jars [08:18am] Nicole: What is the meaning of the dependency? Dependency to other jars? [08:19am] jmarino: yes it's basically from Maven. It's more coarse grained than package dependencies [08:20am] jhawkins: Sure. The problem comes I see is getting the import/exports right. Are you planning on doing this at runtime, or during provisioning? [08:20am] jmarino: I was thinking this would be done when the extension is deployed into the runtime. This could be live or some time earlier. [08:21am] jmarino: I should step back and describe what we are doing in the spec a little since we are talking about deployment [08:21am] jhawkins: That would help. [08:21am] dkulp joined the chat room. [08:21am] jmarino: ok we are still in the early stages [08:22am] jmarino: but what we wanted was a way to express dependencies as well as the equivalent of exports in a language neutral way... [08:22am] jmarino: for example, there are not just Java packages, classes, etc. but also things like WSDL, XSDs, etc. [08:23am] jmarino: we were thinking about having a syntax for that. It would share some concepts to OSGi [08:23am] jmarino: I was thinking we could interpret this syntax and convert it to creating bundles in OSGi [08:23am] jhawkins: Where would this metadata reside? SCDL? Manifest? [08:24am] jmarino: yes the metadata would be in SCDL [08:25am] Nicole: It will not work out of the box, but we could adapt the Spring-OSGi stuff. They are reading export/import info out of a file. [08:25am] Nicole: We could read the SCDL and create bundle with manifest. [08:26am] jhawkins: OK. So imagining we've got that, the question becomes what would the translation result look like. [08:26am] Nicole: A fragment bundle? [08:27am] jhawkins: Good question. Jim's statement that extensions should have their own class loaders kills fragment bundes (unless we want to dig into that deeper). [08:27am] jmarino: maybe we should dig deeper into that? [08:28am] jmarino: we don't have this implemented yet but... [08:28am] jhawkins: Also, the fragment bundle solution has implications on runtime isolation. Do we want to support multiple runtimes in a single OSGi? [08:29am] jmarino: I assumed there would be one but that was just an assumption without much thought. Is that a bad assumption? [08:29am] jhawkins: You da' man - how many do you want? [08:29am] jmarino: not sure about that My OSGi knowledge is pretty basic [08:29am] Nicole: Now I'm confused. I Thought one Runtime and X system/application composites ... [08:30am] jmarino: that's what I was thinking [08:30am] Nicole: What would be the advantage of having more than one Joel? [08:32am] jhawkins: That would make life easier. To me, this gets into a who's on top discussion. If I see OSGi as some sort of container container, then I would need to be able to support mutlipe runtimes (just like a web container supports multiple web apps)... [08:32am] jhawkins: I don't have a dog in this hunt... just a question [08:32am] rfeng joined the chat room. [08:33am] jmarino: I'm wondering if it makes things simpler to assume one runtime per OSGi container? [08:33am] jhawkins: If we go with one runtime, then taking a fragment bundle approach is more defensible, and we can probably leverage more from OSGi. [08:33am] Nicole: Only to get the 'big picture'. If we have one runtime,
[jira] Commented: (TUSCANY-885) Property DataObject.getProperty(String propertyName) should return null if the property cannot be found
[ http://issues.apache.org/jira/browse/TUSCANY-885?page=comments#action_12449716 ] Luciano Resende commented on TUSCANY-885: - After this changes, DAS test case is failing at : Running org.apache.tuscany.das.rdb.test.suites.AllTestsDerby Setting up for Derby run Ending Derby run Tests run: 140, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 21.688 sec FAILURE! testReadSingleVerifyShapeUse(org.apache.tuscany.das.rdb.test.ResultSetShapeTests ) Time elapsed: 0.078 sec ERROR! java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl incompatible with java.util.List at org.apache.tuscany.sdo.impl.DataObjectImpl.getList(DataObjectImpl.jav a:376) at org.apache.tuscany.das.rdb.test.ResultSetShapeTests.testReadSingleVer ifyShapeUse(ResultSetShapeTests.java:85) Property DataObject.getProperty(String propertyName) should return null if the property cannot be found --- Key: TUSCANY-885 URL: http://issues.apache.org/jira/browse/TUSCANY-885 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Assigned To: Kelvin Goodson Priority: Minor Fix For: Java-Mx Attachments: tuscany-885.patch Based on SDO 2.01 specification, DataObject.getProperty(String propertyName) should return null if the property cannot be found. Unfortunately, it returns IlegalArgumentException now. -- 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: Review of Tuscany Java M2 Samples/Readme
Hi, Lee. Thank you very much for the review. Please see my comments below. Raymond - Original Message - From: Lee Surprenant [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 14, 2006 8:25 AM Subject: Review of Tuscany Java M2 Samples/Readme After yesterday's chat I took some time to look at the samples/readmes from the M2 branch. Minus a few grammatical mistakes, I found the content consistent and easy to follow. Here are a few minor questions/concerns: - Why is the core-1.0-incubator-M2-SNAPSHOT.jar included in the contrib dir? It was brought in by a dependency with wrong scope (test instead of compile) and I fixed it. - Are the runtime property (-D) options documented somewhere? It took me a while to find -Doffline=true for the standalone runtime. I'll find a place for this :-) - The BigBank Sample Location section of the readme incorrectly states that BigBank is located in the sampleapps/bigbank dir. Fixed. - When I try to run mvn tomcat:deploy on sample-helloworldjsonrpc.warfrom eclipse, I obtain the following error: LifecycleExecutionException: No Java test frameworks found. The command works fine from terminal. Strange because I can deploy all the other samples from eclipse. Need some investigation. - Why are binding.axis2.scdl and databinding.sdo.scdl included at sca/runtime/webapp-host/src/main/resources/META-INF/sca/? I'll check. - It seems unclear/confusing to me to include the outdated documents at tuscany-sca-1.0-incubator-M2-src\src\sca\doc in the source distro. The docs are now removed from the distro. And will see if we can make them updated for the web site. thanks, -Lee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Container - First part ready for review....
On Nov 14, 2006, at 8:15 AM, Venkata Krishnan wrote: Hi, I have tried my best to explain... just in case something is not right in this could somebody pitch in please. Thanks. - Venkat On 11/14/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi All I have updated (Tuscany-904) with a new version of the DAS container. This is based on the initial contribution that Amita did, with some clean-up, refactoring and additions to try to fix a possible problem with mutable properties that are shared among instance (pointed by Jim Marino)... Currently, this is just the initial drop that I want to make available in the trunk so other can start to take a look and Amita and I could collaborate easier... unit testings, sample, etc are coming... I'd appreciate if anyone could help get this to the trunk if there is nothing wrong with this... Couple Questions: Could someone take a quick look at ComponentTypeLoader and see if it's looking Ok ? I was not sure about what this loadFromSideFile means ? what is the side file? Is this something particular to Script container ? A sidefile is one way of exposing the configurable aspects of an implementation. The other way is thro annotations. Yet another is to follow some coding conventions so that this information is introspectable. The sidefile way of doing things is, to the best of what I understand, a common means across containers. i.e. you can have javascript, java, ruby, das (if you will) components all using the sidefile in a similar manner as this is prescribed by the specs. Yes component type is a common means but allows an implementation type (e.g. implementation.java, implementation.ruby) to extend the component type schema with specific metadata. Also, there is a 1:1 relationship between a component type and an component implementation. For the introspectable way you will see Java and JavaScript vary in how they achieve this. The same goes for annotations - right now the java container alone can leverage this (as far as I know). Also, I wasn't sure what time is the appropriate time to load the das config file when provided ? Right now is being loaded at DataAccessImplementationLoader, if you guys think this should go in a different place, please let me know... also would be good to know why :) I think this begs the question of what DAS configuration is. I'm not sure all configuration is part of a component type since the latter always has a 1:1 relationship with its implementation. For example, I believe the DAS configuration specifies mappings to database tables. Are these mappings potentially sharable across different components? JPA has the PersistenceUnit concept to express this. A PersistenceUnit defines the set of entities that can be managed by a particular context but must always correspond to one database. For example, an application may have one or more PersistenceUnits (I would imagine in typical cases it is one but not always). Related to this, configuration may define which DataSource to use. In DAS, is it possible that multiple implementation.das entries want to use the same mapping and DataSource configuration? If that is the case, you can probably do something similar to what Meeraj is doing with the JPA integration and have the configuration information parsed and cached as a special system service in the application composite. If so, we can drill down into more detail here. The config file could very well be read / parsed during 'load' time using the loader. The loading is just about picking up the component definition information from the scdl file and creating a java object model for them. The next phase is the 'build' phase where you must create the necessary runtime artifacts making use of the model you have defined in the loading phase. In your case I would imagine that you would inject the config values into the DAS Engine during the build time. One minor thing here. Unless the configuration values are always immutable, an ObjectFactory should be injected otherwise one component could accidentally modify a configuration parameter of another as instances will be shared. When the component implementation instance is created, the AtomicComponent will need to call all of the ObjectFactory.getInstance methods to retrieve configuration values that are injected. If the values are mutable, the ObjectFactory will need to instantiate, copy or clone a value. If the value is immutable, it can always pass the same one. In part of the refactors to container.script, I introduced some code that does this which can be used as an example. Well, comments and feedback are welcome... Note that I'm still getting familiar with the Container SPI, so, please let me know if I misunderstood something on the implementation. - Luciano Resende Apache Tuscany
Re: A few issues around axis2 1.1 maven artifacts
Hi, Dims. Is it OK to release our stuff (Tuscany M2) based on the following two repositories? http://people.apache.org/repo/m1-ibiblio-rsync-repository http://ws.zones.apache.org/repository Thanks, Raymond - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: axis-dev@ws.apache.org Sent: Tuesday, November 14, 2006 5:53 AM Subject: Re: A few issues around axis2 1.1 maven artifacts 1) See http://people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.ws.commons.schema/jars/ there is probably some config issue on the repo1 box. No clue. 2) Please use http://ws.zones.apache.org/repository/ thanks, -- dims On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I ran into two issues with the maven artifacts from the latest axis2 1.1 release. 1) http://repo1.maven.org/maven/org.apache.ws.commons.schema/jars/XmlSchema-1.2.jar is not available (HTTP 404) even the links are there @ http://repo1.maven.org/maven/org.apache.ws.commons.schema/jars/. 2) Is http://ws.zones.apache.org/repository/incubator-woden/jars/ the only location where incubator-woden/woden-1.0.0M6.jar can be resolved? I could find it anywhere else. Thanks, Raymond -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - 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: A few issues around axis2 1.1 maven artifacts
On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Dims. Is it OK to release our stuff (Tuscany M2) based on the following two repositories? http://people.apache.org/repo/m1-ibiblio-rsync-repository It would be better to use the M1 repo at ibiblio http://www.ibiblio.org/maven http://ws.zones.apache.org/repository If this is mirrored I'd suggest using that, if not I don't think you have a option :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Container - First part ready for review....
On 11/14/06, Jim Marino [EMAIL PROTECTED] wrote: One minor thing here. Unless the configuration values are always immutable, an ObjectFactory should be injected otherwise one component could accidentally modify a configuration parameter of another as instances will be shared. When the component implementation instance is created, the AtomicComponent will need to call all of the ObjectFactory.getInstance methods to retrieve configuration values that are injected. If the values are mutable, the ObjectFactory will need to instantiate, copy or clone a value. If the value is immutable, it can always pass the same one. In part of the refactors to container.script, I introduced some code that does this which can be used as an example. This is really to protect against accidental (or malicious) alteration by a user-supplied implementation. I don't think this is necessary here as we should be able to trust the DAS implementation not to try and mutate the value. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Container - First part ready for review....
On Nov 14, 2006, at 12:02 PM, Jeremy Boynes wrote: On 11/14/06, Jim Marino [EMAIL PROTECTED] wrote: One minor thing here. Unless the configuration values are always immutable, an ObjectFactory should be injected otherwise one component could accidentally modify a configuration parameter of another as instances will be shared. When the component implementation instance is created, the AtomicComponent will need to call all of the ObjectFactory.getInstance methods to retrieve configuration values that are injected. If the values are mutable, the ObjectFactory will need to instantiate, copy or clone a value. If the value is immutable, it can always pass the same one. In part of the refactors to container.script, I introduced some code that does this which can be used as an example. This is really to protect against accidental (or malicious) alteration by a user-supplied implementation. I don't think this is necessary here as we should be able to trust the DAS implementation not to try and mutate the value. I would strongly recommend it since code has a habit of getting copied and in user-supplied implementations we shouldn't be so trustworthy. An ObjectFactory is still free to make the optimization of passing back the same immutable property instance :-) -- Jeremy - 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: Unit testing/debuging a SCA Container
Hi Luciano, Sorry to get on my soapbox but...I would break this down into two separate areas, testing and debugging of an extension versus an application: 1. Testing and debugging of an extension I would separate testing into three categories: unit testing, integration testing, and acceptance testing. Unit testing the container should focus on verifying very fine- grained things, typically one class. Sometimes a class may depend on another in which case we have been using EasyMock as a way to stub it out. If it doesn't make sense to stub things out, then unit testing may involve more than one class but if there are a lot of classes that are required generally it is a sign that the design needs to be refactored... In unit tests, the SCA container is not needed and accessing external things like SCDL or writing to the file system should be avoided. Just extend TestCase. In core we were even able to do this for the STaXElementLoader implementations by using EasyMock to mock out XMLStreamReader (e.g. ComponentTypeElementLoaderTestCase). Taking this approach offers a number of benefits. It helps with design since if a class cannot be tested on a fine grained level, something is generally wrong with the design (http://no-new-ideas.blogspot.com/2006/11/is-clutter-in-your- test-trying-to-tell.html). If a test fails, it is apparent what broke since the test is very specific, generally verifying one thing. Unit tests document the operation of particular classes, making it easier for people coming into the project to understand the architecture. Not accessing external artifacts avoids side effects (and failed tests due to things like classpath peculiarities) and makes things run fast. Also, all of this makes it easy to run the entire unit test battery very frequently and hence speeds up the dev cycle. I typically make changes on core and then run the ~500 unit tests in about 10 seconds. Hopefully we will wind up with a lot more tests but if we can keep the time it takes to run them down, developing Tuscany will be easier. Unit tests are always run prior to checkin. Debugging individual classes is also dead simple in this case as there is just a JUnit TestCase to run. Integration testing for me breaks down into a couple of types. Tests that are a little larger than unit tests which are design to verify the interaction of parts of an extension.There are also integration tests that deal with particular code paths through an extension but not an application scenario (the paths are more specific and may involve negative testing). For example, ensuring that an extension can properly boot from the extension SCDL. For this, there is SCATestCase. There are a third type of integration tests which deal with larger issues such as verifying an extension works with other extensions are in a particular host environment (e.g. standalone, Tomcat, etc.). Some integration tests (the first type) would be run as part of the checkin build. Types 2-3 would be run as part of Maven's integration test phase on an integration server (in case you haven't come across it, Fowler has a good overview: http:// www.martinfowler.com/articles/continuousIntegration.html). Debugging in this case could be done either remotely or by running SCATestCase in an IDE. Acceptance testing verifies applications function correctly from an end-user perspective. This would involve testing the samples. I would expect these tests would only be run infrequently to verify if a particular build was stable. 2. Application testing/debuging I think there is a separate issue around allowing end users to test and debug their applications. Typically, for testing they should not need SCA until they perform integration tests. Here I think DAS is not much different than an application that runs with JPA or Hibernate (sorry to keep drawing the same analogy). In most cases, I stub out the service that persists things (i.e. the DAS component or the service that uses JPA/Hibernate) with EasyMock or something else. However, I probably also want to test that my DAS service works correctly. In this case, I think it would be helpful to build a simple test harness for users to be able to bootstrap the DAS component and fire of tests. This may include loading a DataSource (DBCP works well for this stuff) and an embedded database (I think you guys are using Derby, I really like HSQLDB since it is small and has an in-memory mode). You could even create something like SCATestCase that either takes a SCDL on the file system or some type of InputStream. This would make debugging really easy. It also makes testing for very specific things like transaction rollbacks and deadlock detection much easier. Sorry for such a long winded reply - I'm happy to help out with anything that I can. Jim On Nov 13, 2006, at 10:27 AM, Luciano Resende wrote:
Re: A few issues around axis2 1.1 maven artifacts
incubation artifacts can't go to maven central repo... -- dims On 11/14/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Dims. Is it OK to release our stuff (Tuscany M2) based on the following two repositories? http://people.apache.org/repo/m1-ibiblio-rsync-repository It would be better to use the M1 repo at ibiblio http://www.ibiblio.org/maven http://ws.zones.apache.org/repository If this is mirrored I'd suggest using that, if not I don't think you have a option :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Container - First part ready for review....
I think this begs the question of what DAS configuration is. I'm not sure all configuration is part of a component type since the latter always has a 1:1 relationship with its implementation. For example, I believe the DAS configuration specifies mappings to database tables. Are these mappings potentially sharable across different components? JPA has the PersistenceUnit concept to express this. A PersistenceUnit defines the set of entities that can be managed by a particular context but must always correspond to one database. For example, an application may have one or more PersistenceUnits (I would imagine in typical cases it is one but not always). Related to this, configuration may define which DataSource to use. In DAS, is it possible that multiple implementation.das entries want to use the same mapping and DataSource configuration? If that is the case, you can probably do something similar to what Meeraj is doing with the JPA integration and have the configuration information parsed and cached as a special system service in the application composite. If so, we can drill down into more detail here. If I understood your question correctly, DAS allows a 1:1 and 1:N relationship, An application could have multiple components using the same config file, or could split the config file based on the components model... but the choice is really made by the app developer. - Luciano On 11/14/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 14, 2006, at 8:15 AM, Venkata Krishnan wrote: Hi, I have tried my best to explain... just in case something is not right in this could somebody pitch in please. Thanks. - Venkat On 11/14/06, Luciano Resende [EMAIL PROTECTED] wrote: Hi All I have updated (Tuscany-904) with a new version of the DAS container. This is based on the initial contribution that Amita did, with some clean-up, refactoring and additions to try to fix a possible problem with mutable properties that are shared among instance (pointed by Jim Marino)... Currently, this is just the initial drop that I want to make available in the trunk so other can start to take a look and Amita and I could collaborate easier... unit testings, sample, etc are coming... I'd appreciate if anyone could help get this to the trunk if there is nothing wrong with this... Couple Questions: Could someone take a quick look at ComponentTypeLoader and see if it's looking Ok ? I was not sure about what this loadFromSideFile means ? what is the side file? Is this something particular to Script container ? A sidefile is one way of exposing the configurable aspects of an implementation. The other way is thro annotations. Yet another is to follow some coding conventions so that this information is introspectable. The sidefile way of doing things is, to the best of what I understand, a common means across containers. i.e. you can have javascript, java, ruby, das (if you will) components all using the sidefile in a similar manner as this is prescribed by the specs. Yes component type is a common means but allows an implementation type (e.g. implementation.java, implementation.ruby) to extend the component type schema with specific metadata. Also, there is a 1:1 relationship between a component type and an component implementation. For the introspectable way you will see Java and JavaScript vary in how they achieve this. The same goes for annotations - right now the java container alone can leverage this (as far as I know). Also, I wasn't sure what time is the appropriate time to load the das config file when provided ? Right now is being loaded at DataAccessImplementationLoader, if you guys think this should go in a different place, please let me know... also would be good to know why :) I think this begs the question of what DAS configuration is. I'm not sure all configuration is part of a component type since the latter always has a 1:1 relationship with its implementation. For example, I believe the DAS configuration specifies mappings to database tables. Are these mappings potentially sharable across different components? JPA has the PersistenceUnit concept to express this. A PersistenceUnit defines the set of entities that can be managed by a particular context but must always correspond to one database. For example, an application may have one or more PersistenceUnits (I would imagine in typical cases it is one but not always). Related to this, configuration may define which DataSource to use. In DAS, is it possible that multiple implementation.das entries want to use the same mapping and DataSource configuration? If that is the case, you can probably do something similar to what Meeraj is doing with the JPA integration and have the configuration information parsed and cached as a special system service in the application composite. If so, we can drill down into more detail here. The config file could very well be read / parsed during 'load' time
[jira] Commented: (TUSCANY-885) Property DataObject.getProperty(String propertyName) should return null if the property cannot be found
[ http://issues.apache.org/jira/browse/TUSCANY-885?page=comments#action_12449772 ] Kelvin Goodson commented on TUSCANY-885: The fix applied would seem to have exposed an issue with the TestCase, as there would seem to be a !isMany property referenced by the CUSTOMER property name. Attempting to get this single valued property as a list is causing the problem. I have commented out the test case a luciano's request. Property DataObject.getProperty(String propertyName) should return null if the property cannot be found --- Key: TUSCANY-885 URL: http://issues.apache.org/jira/browse/TUSCANY-885 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Assigned To: Kelvin Goodson Priority: Minor Fix For: Java-Mx Attachments: tuscany-885.patch Based on SDO 2.01 specification, DataObject.getProperty(String propertyName) should return null if the property cannot be found. Unfortunately, it returns IlegalArgumentException now. -- 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: A few issues around axis2 1.1 maven artifacts
There are something wrong with the maven repo sync-up and that's why I asked for http://people.apache.org/repo/m1-ibiblio-rsync-repository instead. It always complains that HTTP 404 File Not Found following the two links. http://www.ibiblio.org/maven/org.apache.ws.commons.schema/jars/XmlSchema-1.2.jar http://repo1.maven.org/maven/org.apache.ws.commons.schema/jars/XmlSchema-1.2.jar Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Cc: axis-dev@ws.apache.org Sent: Tuesday, November 14, 2006 11:59 AM Subject: Re: A few issues around axis2 1.1 maven artifacts On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Dims. Is it OK to release our stuff (Tuscany M2) based on the following two repositories? http://people.apache.org/repo/m1-ibiblio-rsync-repository It would be better to use the M1 repo at ibiblio http://www.ibiblio.org/maven http://ws.zones.apache.org/repository If this is mirrored I'd suggest using that, if not I don't think you have a option :-) -- Jeremy - 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]
[Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
More than 72 hours have passed, and presumably everybody on the incubator PMC that cares to vote has done so (Thanks Robert!). Please proceed with the release. If anybody objects to this process, point them my way. - Sam Ruby Original Message Subject: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts Date: Sun, 5 Nov 2006 14:10:40 -0800 From: Luciano Resende [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org The Tuscany PPMC has voted to Release DAS for Java API Implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10257.html Vote result : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10373.html The release candidate is available at: http://people.apache.org/~kelvingoodson/das_java/RC4b/http://people.apache.org/%7Ekelvingoodson/das_java/RC4b/ 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 https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/ Thanks - Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A few issues around axis2 1.1 maven artifacts
Hi, Sorry that I confused you. I didn't mean to upload Tuscany artifacts to the maven central repo. I was wondering if we can use the two repos I mentioned as the remote repositories to be referenced by our M2 artifacts in maven (http://people.apache.org/repo/m2-incubating-repository/). Thanks, Raymond - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Cc: axis-dev@ws.apache.org Sent: Tuesday, November 14, 2006 12:28 PM Subject: Re: A few issues around axis2 1.1 maven artifacts incubation artifacts can't go to maven central repo... -- dims On 11/14/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Dims. Is it OK to release our stuff (Tuscany M2) based on the following two repositories? http://people.apache.org/repo/m1-ibiblio-rsync-repository It would be better to use the M1 repo at ibiblio http://www.ibiblio.org/maven http://ws.zones.apache.org/repository If this is mirrored I'd suggest using that, if not I don't think you have a option :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - 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: Conversational services
Hi Ignacio, I think we want to support ordering as an intent both over a binding as well as locally. The spec group is currently working on reliable messaging intents for: - at-least-once - at-most-once - ordered For the local case (i.e. in-VM) I think we assume the first two will happen and for the third we introduce a queuing mechanism per AtomicComponent that will begin to queue dispatches if ordering becomes out of sync (we could use an AtomicInteger as a counter). We will probably need a timeout mechanism to guarantee threads don't get stuck or requests pile up indefinitely. As a default (when no intent is specified), I think we don't guarantee ordering and leave it to the application since this could be quite a bit of overhead. I think we can look at supporting this once we get the basic conversational framework in place. Jim On Nov 14, 2006, at 9:36 AM, Ignacio Silva-Lepe wrote: I have also changed the non-blocking interceptor to propagate conversation ids to support async ops. An issue that comes up with this is that if a conversational service also uses async ops (e.g., one-ways), the corresponding implementations (client and/or service) need to be careful about concurrency. For instance, in the loan app sample, I made the cancel op a one-way. The client applies for a loan, displays the loan app, cancels it and displays again. So now the cancel thread is competing with the main thread for access to the service. The simple fix in the sample is to hold the main thread to let the cancel thread complete, which is impacting the client code. The spec(s) does not seem to be clear about whether the infrastructure must provide support to relieve the user from dealing with concurrency. For the remote case, the various bindings can provide support depending on policy and some handshaking with the core. For instance, for ws WS-RM can be used to provide ordering support but even that may not be sufficient in the face of potential races into an Axis2Reference. For the local case, it may be possible to provide some ordering support on a per conversation basis by sequencing invocations (a la WS-RM) but it's not clear the current architecture is there for this requirement. That is, an invocation handler may be able to behave as a conversation source for sequencing, but since there is a separate target invoker per operation, something would need to happen to get them in order. In any case, this are just some spur-of-the-moment thoughts. Others may have different ideas about whether or how to handle this issue. On 11/13/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: I have checked in code to complete a minimal implementation of conversational services, including a sample adapted from the CI spec. Still not using UUID for conversation ids, need to change. Rick, you can go ahead and test it (I did not include the sample in the main pom, you can run it from its own dir though). On 11/11/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 11, 2006, at 6:16 AM, Ignacio Silva-Lepe wrote: The CI spec defines a conversational interface as annotated with @Scope(session) but since we are also considering HTTP Session scopes, it seems that using @Scope(CONVERSATIONAL) would make things clearer. Notice that earlier in the spec (sec 1.2.1.4) the annotation @Scope(CONVERSATION) is used in passing, so it looks like the spec needs to be revised anyway. I think I may have missed a couple of places in the spec where things should have been changed from session to conversation. We also need a description for scopes to be placed back in the Java CI spec (it was originally in, moved to Assembly, and then the spec group decided to move it back to the respective CI specs) so I'll include this in that proposal. Jim For the current SCA/Java implementation of conversational services just getting under way, the current thought is to use @Scope(CONVERSATIONAL) On 11/11/06, Pete Robbins [EMAIL PROTECTED] wrote: Quick question: Is there an annotation that marks an interface as conversational? Cheers, -- Pete - 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: A few issues around axis2 1.1 maven artifacts
I think so. -- dims On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Sorry that I confused you. I didn't mean to upload Tuscany artifacts to the maven central repo. I was wondering if we can use the two repos I mentioned as the remote repositories to be referenced by our M2 artifacts in maven (http://people.apache.org/repo/m2-incubating-repository/). Thanks, Raymond - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Cc: axis-dev@ws.apache.org Sent: Tuesday, November 14, 2006 12:28 PM Subject: Re: A few issues around axis2 1.1 maven artifacts incubation artifacts can't go to maven central repo... -- dims On 11/14/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Dims. Is it OK to release our stuff (Tuscany M2) based on the following two repositories? http://people.apache.org/repo/m1-ibiblio-rsync-repository It would be better to use the M1 repo at ibiblio http://www.ibiblio.org/maven http://ws.zones.apache.org/repository If this is mirrored I'd suggest using that, if not I don't think you have a option :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - 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] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BPEL] Transaction managers, datasources and more
Hi, I have a better and better idea on how Apache Ode could be used as a Tuscany container. However I'm still wondering how I can get hold on some resources in Tuscany. To run Ode's BPEL engine we need basic services like a transaction manager, a datasource or a thread scheduler ( java.util.concurrent.ExecutorService). How could these be provided to the BPEL container? Do you already have something for this? Or should we assume that we're running in a managed environment (i.e. Geronimo) and lookup these things ourselves? Thanks, Matthieu
Re: svn commit: r475086 - /incubator/tuscany/branches/sca-java-M2/sca/distribution/build.xml
On 11/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Log: Add the SCA spec source code to the source distro Modified: incubator/tuscany/branches/sca-java-M2/sca/distribution/build.xml This should not be part of the Tuscany distribution. Please can we keep with the modularity and keep seperate things separate. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r475086 - /incubator/tuscany/branches/sca-java-M2/sca/distribution/build.xml
Hi, Jeremy. Should we have a separate source distro for the SCA spec then? Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 14, 2006 4:57 PM Subject: Re: svn commit: r475086 - /incubator/tuscany/branches/sca-java-M2/sca/distribution/build.xml On 11/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Log: Add the SCA spec source code to the source distro Modified: incubator/tuscany/branches/sca-java-M2/sca/distribution/build.xml This should not be part of the Tuscany distribution. Please can we keep with the modularity and keep seperate things separate. -- Jeremy - 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: [BPEL] Transaction managers, datasources and more
Hi Matthew, Comments inline... Jim On Nov 14, 2006, at 4:12 PM, Matthieu Riou wrote: Hi, I have a better and better idea on how Apache Ode could be used as a Tuscany container. However I'm still wondering how I can get hold on some resources in Tuscany. To run Ode's BPEL engine we need basic services like a transaction manager, a datasource or a thread scheduler ( java.util.concurrent.ExecutorService). You can do this one of two ways, either by autowiring (@Autowire) or through resource injection (@Resource). Autowiring right now is pretty basic as in: @Autowire public void setSomething(Something something); This will tell the runtime to inject your component with an implementation of the interface Something. We are planning on enhancing this by providing the ability to specify parameters and intents but I think this should be sufficient for what you need. Specifically, in the runtime, work is dispatched using a WorkScheduler. If you extend from ComponentBuilderExtension you get one for free (it uses autowiring to obtain one from the runtime). Otherwise, you need to do the following: @Autowire public void setScheduler(WorkScheduler scheduler) This will also work on constructors as well: @Constructor public MyConstructor(@Autowire WorkScheduler scheduler) In a managed environment, WorkScheduler will be a wrapper around some scheduling mechanism provided by the host. For resources such as DataSource you can use @Resource in the same manner. W have started implementing support for this as described here: http://wiki.apache.org/ws/Tuscany/SpecProposals/Resources. In order to get at data sources, you will need to configure the datasource extension located under /persistence. This can use DBCP or another provider. A JTA TransactionManager should be accessible in the same way - through @Resource. This means we will need to provide transactional infrastructure in cases where we do not run on a host that has a JTA implementation. We don't have a JTA implementation integrated yet but Jeremy was going to look into seeing if we can separate out the Geronimo transaction manager for this purpose (right now it seems to drag in a bunch of other Geronimo dependencies). In doing so, we will need to also be able to enlist DataSource resources in transactions. I'm happy to help out so the best way to proceed is to probably start asking more questions and I will try to answer them as best I can. How could these be provided to the BPEL container? Do you already have something for this? Or should we assume that we're running in a managed environment (i.e. Geronimo) and lookup these things ourselves? Just to reiterate what I mentioned above, I wouldn't assume Tuscany would be deployed in a managed environment. If you use @Autowire and @Resource Tuscany will handle the portability issues. Thanks, Matthieu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please review of the Tuscany SCA Java M2 release candidate
Hi, I have refreshed the distros for our M2 release candidate at http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. It contains the following update: 1) Move to axis2 1.1 release as well as the corresponding axiom, XmlSchema and other dependencies. 2) Add two additional source distros for SCA and CommonJ specs I have also uploaded the latest SNAPSHOT versions of M2 artifacts to http://people.apache.org/repo/m2-snapshot-repository. Please review the contents before we tag the branch and submit it for PPMC vote. Your help will be greatly appreciated. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Doxygen documentation for our runtime
Pete Robbins wrote: On 14/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Definitely! Done under revision r474696. On linux, run configure with the --enable-doxygen option. It's off by default. On Windows run doxygen Doxyfile.w32 from the doc directory. The doc is generated under doc/doxygen. The same scheme can be replicated for SDO. We did this with the tree originally so some of the code has comments in the correct Doxygen format. Is there an option to insert comment headers into the source? The doxygen format is described there: http://www.stack.nl/~dimitri/doxygen/docblocks.html. You can write doc blocks anywhere except inside the body of a function. What did you mean by is there an option to insert comment headers into the source? I meant can we get Doxygen to insert the correct format comment block above methods etc. with blank content. I'm sure not all methods have the correct comments! So for a method int fred(string x); we need /** @param x @return **/ int fred(string x); Just a thought! We need to document our code in a consistent way which it isn't at the moment. Cheers, Ok I understand now. It doesn't look like Doxygen can generate comment skeletons. Usually editors provide templates and content assist for this. You can find a list of plugins/helpers for popular editors there: http://www.stack.nl/~dimitri/doxygen/helpers.html, including a Visual Studio 2005 helper there: http://doxycomment.sourceforge.net/vs2005_addin.html. I thought that Eclipse CDT templates could be used for this but I've not been able able to get them to work... so I'll type these comments by hand for now, and may try to write an Eclipse plugin to automate the generation of comment skeletons when I get tired of it :) Doxygen supports Qt style comments: /*! ... and javadoc style comments /** ... Both styles seem to support \param \return and @param @return Could people in the group experiment a bit with the available editor tools and say which style they like? Details and examples can be found there: http://www.stack.nl/~dimitri/doxygen/docblocks.html Personally I'm OK with either one, the most important is to get meaningful text after the \ or @ :) We could also use both styles for a while, time to get some experience with any of the tools, and do a global change to our official format later. Comments? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Doxygen documentation for our runtime
I prefer the /** and @ notation On 15/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: On 14/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Definitely! Done under revision r474696. On linux, run configure with the --enable-doxygen option. It's off by default. On Windows run doxygen Doxyfile.w32 from the doc directory. The doc is generated under doc/doxygen. The same scheme can be replicated for SDO. We did this with the tree originally so some of the code has comments in the correct Doxygen format. Is there an option to insert comment headers into the source? The doxygen format is described there: http://www.stack.nl/~dimitri/doxygen/docblocks.html. You can write doc blocks anywhere except inside the body of a function. What did you mean by is there an option to insert comment headers into the source? I meant can we get Doxygen to insert the correct format comment block above methods etc. with blank content. I'm sure not all methods have the correct comments! So for a method int fred(string x); we need /** @param x @return **/ int fred(string x); Just a thought! We need to document our code in a consistent way which it isn't at the moment. Cheers, Ok I understand now. It doesn't look like Doxygen can generate comment skeletons. Usually editors provide templates and content assist for this. You can find a list of plugins/helpers for popular editors there: http://www.stack.nl/~dimitri/doxygen/helpers.html, including a Visual Studio 2005 helper there: http://doxycomment.sourceforge.net/vs2005_addin.html. I thought that Eclipse CDT templates could be used for this but I've not been able able to get them to work... so I'll type these comments by hand for now, and may try to write an Eclipse plugin to automate the generation of comment skeletons when I get tired of it :) Doxygen supports Qt style comments: /*! ... and javadoc style comments /** ... Both styles seem to support \param \return and @param @return Could people in the group experiment a bit with the available editor tools and say which style they like? Details and examples can be found there: http://www.stack.nl/~dimitri/doxygen/docblocks.html Personally I'm OK with either one, the most important is to get meaningful text after the \ or @ :) We could also use both styles for a while, time to get some experience with any of the tools, and do a global change to our official format later. Comments? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Doxygen documentation for our runtime
/** and @ for me too. On 11/15/06, Pete Robbins [EMAIL PROTECTED] wrote: I prefer the /** and @ notation On 15/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: On 14/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Definitely! Done under revision r474696. On linux, run configure with the --enable-doxygen option. It's off by default. On Windows run doxygen Doxyfile.w32 from the doc directory. The doc is generated under doc/doxygen. The same scheme can be replicated for SDO. We did this with the tree originally so some of the code has comments in the correct Doxygen format. Is there an option to insert comment headers into the source? The doxygen format is described there: http://www.stack.nl/~dimitri/doxygen/docblocks.html. You can write doc blocks anywhere except inside the body of a function. What did you mean by is there an option to insert comment headers into the source? I meant can we get Doxygen to insert the correct format comment block above methods etc. with blank content. I'm sure not all methods have the correct comments! So for a method int fred(string x); we need /** @param x @return **/ int fred(string x); Just a thought! We need to document our code in a consistent way which it isn't at the moment. Cheers, Ok I understand now. It doesn't look like Doxygen can generate comment skeletons. Usually editors provide templates and content assist for this. You can find a list of plugins/helpers for popular editors there: http://www.stack.nl/~dimitri/doxygen/helpers.html, including a Visual Studio 2005 helper there: http://doxycomment.sourceforge.net/vs2005_addin.html. I thought that Eclipse CDT templates could be used for this but I've not been able able to get them to work... so I'll type these comments by hand for now, and may try to write an Eclipse plugin to automate the generation of comment skeletons when I get tired of it :) Doxygen supports Qt style comments: /*! ... and javadoc style comments /** ... Both styles seem to support \param \return and @param @return Could people in the group experiment a bit with the available editor tools and say which style they like? Details and examples can be found there: http://www.stack.nl/~dimitri/doxygen/docblocks.html Personally I'm OK with either one, the most important is to get meaningful text after the \ or @ :) We could also use both styles for a while, time to get some experience with any of the tools, and do a global change to our official format later. Comments? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [C++] Where next for Tuscany C++?
forwarding to dev-list -- Forwarded message -- From: Pete Robbins [EMAIL PROTECTED] Date: 15-Nov-2006 07:30 Subject: Re: [C++] Where next for Tuscany C++? To: tuscany-user@ws.apache.org On 15/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: [snip] I'd like to see closer integration between the Tuscany Java and C++ runtimes, with seamless cross-runtime wiring, deployment, and composition. The application developer would write SCDL containing components with different implementation types, and the application would be deployed to a combination of both runtimes according to the hosting needs of the components. Users would see a single federated Tuscany runtime environment hosting multiple implementation languages and component types, rather than being aware of two Tuscany runtimes written in Java and C++ as they are at present. Simon Right, I could imagine an application made of Java, C++, BPEL and PHP components, using Web and JMS services for example: - The Java components would run in a Java component runtime. - The C++ components would run in a C++ component runtime. - The BPEL components would run in a runtime equipped with a BPEL engine. - The PHP components would run in a PHP runtime environment. - The Web services and JMS services would be deployed to Web service and JMS enabled runtimes. Small specialized runtimes would host the various pieces of my application and communicate over a service network. As an application developer, I wouldn't care or want to know the particular language - Java, C++ - used to implement a particular runtime. I would be more interested in its capabilities and the component programming model it supports. I'd be willing to help anybody interested in working on any scenarios demonstrating this approach. Maybe we could use the WS-I supply chain scenario that we had started at http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/SupplyChain/ for example, or any other scenario that people would be interested in working on... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The scenario is what we want here. Also I see this more as a Next steps for Tuscany rather than a Next steps for Tuscany C++! -- Pete -- Pete
Re: [Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
-1 on the release. The simple rule is - you need 3 PMC votes to release (or add a committer). You currently have 1 (Robert's). That should be enough if Sam and Dims (your mentors) vote; however they currently haven't voted on either the [EMAIL PROTECTED] thread or the original. Hen On 11/14/06, Sam Ruby [EMAIL PROTECTED] wrote: More than 72 hours have passed, and presumably everybody on the incubator PMC that cares to vote has done so (Thanks Robert!). Please proceed with the release. If anybody objects to this process, point them my way. - Sam Ruby Original Message Subject: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts Date: Sun, 5 Nov 2006 14:10:40 -0800 From: Luciano Resende [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org The Tuscany PPMC has voted to Release DAS for Java API Implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10257.html Vote result : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10373.html The release candidate is available at: http://people.apache.org/~kelvingoodson/das_java/RC4b/http://people.apache.org/%7Ekelvingoodson/das_java/RC4b/ 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 https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/ Thanks - Luciano Resende - 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: [Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
Justin Erenkrantz wrote: On 11/14/06, Sam Ruby [EMAIL PROTECTED] wrote: More than 72 hours have passed, and presumably everybody on the incubator PMC that cares to vote has done so (Thanks Robert!). Please proceed with the release. If anybody objects to this process, point them my way. -1. We don't release based on lazy consensus. Agreed. Sam, there's no reason for you -not- to be on the IPMC, so please join so your vote is weighed? That brings us to needing just one more binding vote. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
On Nov 14, 2006, at 3:03 PM, Henri Yandell wrote: Probably. -1 is nice and bombastic and makes people pay attention (rob me of my drama why don't you!). Apologies ;-) Said -1 is withdrawn when the vote is complete. 'nuff said. Craig Hen On 11/14/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Henri, Point of order. I don't believe that you really are voting -1 on the release. Rather, you are pointing out that the vote is incomplete until 3 binding votes of the Incubator PMC are received. I think there is a big difference... Craig On Nov 14, 2006, at 2:43 PM, Henri Yandell wrote: -1 on the release. The simple rule is - you need 3 PMC votes to release (or add a committer). You currently have 1 (Robert's). That should be enough if Sam and Dims (your mentors) vote; however they currently haven't voted on either the [EMAIL PROTECTED] thread or the original. Hen On 11/14/06, Sam Ruby [EMAIL PROTECTED] wrote: More than 72 hours have passed, and presumably everybody on the incubator PMC that cares to vote has done so (Thanks Robert!). Please proceed with the release. If anybody objects to this process, point them my way. - Sam Ruby Original Message Subject: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts Date: Sun, 5 Nov 2006 14:10:40 -0800 From: Luciano Resende [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org The Tuscany PPMC has voted to Release DAS for Java API Implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg10257.html Vote result : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg10373.html The release candidate is available at: http://people.apache.org/~kelvingoodson/das_java/RC4b/http:// people.apache.org/%7Ekelvingoodson/das_java/RC4b/ 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 https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/ 1.0-incubator-M2/ Thanks - Luciano Resende - 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] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: [Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
Henri wrote: you need 3 PMC votes to release (or add a committer). You currently have 1 (Robert's). Two. Dims voted tonight. Since one vote was missing, I took the time to review the packages, and they appear to have the necessary disclaimer, etc., although the information in the .WAR files is in an obscure location (and should be changed for future packages). Plus the community seems to have done the right things in their vote. And they appear to have updated their STATUS file, as well. +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
