Re: Simplifying import/export itest ids
Done under revision #561191 On 7/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: How about : tuscany-itest-contribution-export-composite tuscany-itest-contribution-export-wsdl tuscany-itest-contribution-import-composite tuscany-itest-contribution-import-wsdl This would still group them together in the IDE. +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO Static Type introspection on web apps, was : Re: svn commit: r561293 - /incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcess
Looks like things are still working because the composite file
explicitly add the SDO factory
dbsdo:import.sdo factory=helloworld.HelloworldFactory/
As for the WEB-INF\classes\, there was some discussion before, and at
that time, we decided to keep the artifact URI as is, so I have
introduced some more logic on the SDO Processor to handle this
scenario, and get the right class name when it's in a web app. I also
removed the import.sdo from the sample application composite file.
BTW, one way or another, I still get an exception on the JSP, did you see that ?
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18008.html
On 7/31/07, ant elder [EMAIL PROTECTED] wrote:
On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: antelder
Date: Tue Jul 31 03:05:21 2007
New Revision: 561293
URL: http://svn.apache.org/viewvc?view=revrev=561293
Log:
Fix NPE when clazz not resolved
Modified:
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
Modified:
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java?view=diffrev=561293r1=561292r2=561293
==
---
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
(original)
+++
incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostProcessor.java
Tue Jul 31 03:05:21 2007
@@ -56,7 +56,7 @@
String factoryName = getFactoryClassName(artifactURI);
ClassReference clazz = new ClassReference(factoryName);
clazz = contribution.getModelResolver().resolveModel(
ClassReference.class, clazz);
-if (clazz.getClass() != null) {
+if (clazz.getJavaClass() != null) {
try {
//check if it's a SDO factory by introspecting
INSTANCE field
if (isSDOFactory(clazz.getJavaClass())) {
The actual cause of this problem seems to be a different bug where the
class name is prefixed with WEB-INF\classes\ when running in a webapp so
the classes never get resolved. Although that doesn't seem to stop things
from still working ok so I'm not sure what this is code is really trying to
do? Can see this by debugging with a break point in the above code and
running the new helloworld sdo webapp sample.
...ant
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Build Issues with SCA 0.91 and later
Hi Mike This is a MAVEN issue, and we are trying to get help from the maven developers [1]. In the meantime, a workaround we found was to publish snapshots of all artifacts, the ones you mentioned, for itest/contribution-import-export were renamed recently, let me publish new snapshots in one hour or so, I'll let you know when they are published. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20844.html On 8/1/07, Mike Spendlove [EMAIL PROTECTED] wrote: Hey Tuscany gurus, I've been (unsuccessfully) trying to get the SCA source code to build for the last day or two using Maven. While I eventually got the 0.91 baseline to build, I've had no real progress on the HEAD code. The most common problem when building either the baseline or Head (using mvn or 'mvn -U -cpu') is missing artifacts, although since the absent resource is often a Tuscany file, I've been able to fix some of the issues by just running mvn in the required directory. That only gets me so far with the HEAD, since I either end up trying to build a resource that's missing other dependencies I can't get to build or I get a ClassNotFoundException. For example, my most recent error stated I was missing this artifact: org.apache.tuscany.sca:tuscany-itest-contribution-import-export-contrib-composite:jar:1.0-incubating-SNAPSHOT I tried running maven in Tuscany\java\sca\itest\contribution-import-export but got this error: ... Running helloworld.HelloWorldServerTestCase Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.688 sec FAILURE! testPing(helloworld.HelloWorldServerTestCase) Time elapsed: 2.578 sec ERROR! org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl Other files I've had to build manually include: -org.apache.tuscany.sca:tuscany-interface-java:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT - org.apache.tuscany.sca:tuscany-implementation-notification:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:tuscany-topology:jar:1.0-incubating-SNAPSHOT and a few others... None were available when I navigated to their location using my browser. The POM files all seem to roughly match the directory structure (any missing or commented modules in the POM file are not the ones causing problems in the build) and I've tried clean builds repeatedly (cleaning my local repository and the target directories) with no luck. My setup: -Intel Core 2/2 GB Ram/Win XP -Maven 2.0.7 (although I've also tried 2.0.6) -Java SE 5 (JDK 5.0_12) since Java SE 6 was causing javax problems: Running crud.CRUDTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.625 sec FAILURE! testCRUD(crud.CRUDTestCase) Time elapsed: 0.578 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java :158) ... -going through a web proxy configured as below: (although I've tried direct and not resolved any issues.) proxies proxy activetrue/active protocolhttp/protocol hostgateway.xxx/host port8000/port nonProxyHosts10.*.*.*|172.*.*.*|192.*.*.*|*.xxx|sysgroupsps1|localhost|127.0.0.1/nonProxyHosts /proxy /proxies Any suggestions as to how I can find the missing artifacts (perhaps a better repository?) are greatly appreciated! Thanks for your help, -Mike -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven tries to resolve artifact in the reactor to SNAPSHOT version in Apache Tuscany build
Just trying to give some updates here... looks like this recent build issues we are having might be a side effect of the fix for Maven JIRA MNG-1577 [1], some more details are available here [2] and [3]. While we investigate the issue further, a possible workaround (that worked for me) is to move back to maven 2.0.5 client [4]. Please let me know if this works for you as a temporary workaround. And many thanks to brett_ and others for helping on IRC. [1] http://jira.codehaus.org/browse/MNG-1577 [2] http://maven.apache.org/release-notes.html [3] http://maven.apache.org/plugins/maven-dependency-plugin/examples/preparing-dependencies.html [4] http://archive.apache.org/dist/maven/binaries/maven-2.0.5-bin.zip On 7/27/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Guys We are experiencing some issues in Apache Tuscany build recently as described on this thread [1]. Basically, anyone starting with a clean local maven repo are seeing the artifacts that are supposed to be built in the reactor, to be resolved to a published SNAPSHOT version, and thus, the build is failing if any of the problematic artifacts doesn't have a published snapshot. This only started recently, around July 24th or 25th, and looks like people that have an old maven repository can build things OK. Could someone please give us some help, or guidance on how to investigate the issue. If you need any other information, please let us know, and our source code is available at [2] and we are trying to build [3]. BTW, could you please post a response to both lists. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20739.html [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/ [3] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: August Reports
It's that time again for us, I have started a draft report on our wiki [1], let's get it updated asap. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 -- Forwarded message -- From: Noel J. Bergman [EMAIL PROTECTED] Date: Aug 1, 2007 7:52 PM Subject: August Reports To: [EMAIL PROTECTED] Just getting the reminder in early --- those projects reporting in August, please start working on and posting your reports. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
I have reopened the JIRA and will give it a try... On 8/2/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I agree with Simon's comment - this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Yours, Mike. ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL implementation: WSDL and BPEL resolving
The loading of contribution has two phases : read and resolve. * read phase : This is where you read an artifact (a document, an XML element, classes etc.), populate a model representing the artifact and return it. The SCA contribution service calls ArtifactProcessor.read() on all artifacts that have an ArtifactProcessor registered for them. If your model points to other models, instead of trying to load these other models right away, you should just keep the information representing that reference, which you'll turn into a pointer to the referenced model in the resolve() phase. Note that you don't necessarily need to fully read and populate your model at this point, you can choose to complete it later. * resolve phase : This phase gives you the opportunity to resolve references to other models (a WSDL, a class, another composite, a componentType). At this point, all models representing the artifacts in your SCA contribution have been read, registered in the contribution's ArtifactResolver, and are ready to be resolved. The resolution is going to happen when the contribution is loaded, and my understanding is that some recent changes from Raymond will also make some loading/resolution only happen if the artifact is indeed referenced. Some more info here [1] [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Architecture+Guide On 8/3/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi Raymond, Sorry for the late reply, your e-mail passed through my filters :) The approach described in the document sounds good to me, it's similar to what we're doing for import resolution within an ODE deployment package. So that should work. The only part I'm not so clear about though is when the resolution occurs, is it when the contribution is loaded? And thanks for the congrats! Matthieu On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Matthieu. Congratulations on the ODE graduation! We have made some processes in Tuscany regarding to the artifact resolving. Please see more details at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts . I think the strategy will apply to BPEL as well. Would you please take a look? Hopefully, we can get the implementation.bpel working soon. Thanks, Raymond - Original Message - From: Matthieu Riou [EMAIL PROTECTED] To: Luciano Resende [EMAIL PROTECTED] Cc: tuscany-dev@ws.apache.org Sent: Thursday, July 05, 2007 5:08 PM Subject: Re: BPEL implementation: WSDL and BPEL resolving Sure, no problem. And thanks :-) On 7/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Matthieu I'm little overbooked these days, but let me see if I could try to look into the resolution thing over the weekend. Is that OK ? On 7/5/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1397
Hey Andy, It should be OK for you to committ it directly, if you need a review just forward the committ log and ask people to review (but I guess they will be reviewing it anyway from the mail notifications). On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote: Andy, please, check if everything was commited as expected to resolve the JIRA1397. Regards, Adriano Crestani On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote: Applyed the new patch, tests ran OK, commited. Adriano Crestani On 8/3/07, Andy Grove [EMAIL PROTECTED] wrote: Thanks Adriano, Fuhwei, I've re-created the patch using the trunk code as at revision 562418 and attached it to the JIRA. I'm happy to submit the patch directly if everyone is happy with the approach I'm taking on this issue. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: 03 August 2007 05:41 To: tuscany-dev@ws.apache.org Subject: Re: Patch for TUSCANY-1397 I've patched the sdo trunk under revision 562325 with the patch Andy created. All tests ran fine, even though it failed on the tests described on thread [1], but I these fails have nothing to do with Andy patch, so it's ok for me ; ). Anyway, I will wait for a new created patch from Andy, once Fuhwei is saying the actual patch is based on an older version. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/brow ser Regards, Adriano Crestani On 8/2/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: I think the patch is based on an older version of DataObjectUtil.java. Can you create a new patch? Thanks. Adriano Crestani [EMAIL PROTECTED] wrote: I may commit it till the eod if nobody has no objection ; ) Adriano Crestani On 8/2/07, Andy Grove wrote: I've submitted a patch for TUSCANY-1397 and I'd like someone to review this before I apply it since it is my first patch to the Tuscany SDO implementation (I've only been submitting to the CTS until now). The purpose of this patch is to implement on-demand creation of properties in createDataObject(). https://issues.apache.org/jira/browse/TUSCANY-1397 Thanks, Andy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fisheye view for the Apache Tuscany repository?
I was wondering if it would be possible to get Fisheye setup for Apache Tuscany tree? https://svn.apache.org/repos/asf/incubator/tuscany/ Fisheye is a wonderful tool and the Tuscany community would benefit by having this tool available. Would it be possible to get this setup similar to other ASF projects [1]. [1] http://fisheye6.cenqua.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fisheye view for the Apache Tuscany repository?
Thanks Matthieu The e-mail was already sent to [EMAIL PROTECTED], and they advised us to check with infra first. [TN#106588] Fisheye view for the Apache Tuscany repository? This should not be a problem. Please send an email to [EMAIL PROTECTED] and let them know that you would like this set up and if there are any problems. Once infra ok's this, we'll take it from there. We will usually wait till the weekend for adding a new repo. Who can give an OK from the infra side ? On 8/4/07, Matthieu Riou [EMAIL PROTECTED] wrote: I think there's nothing specific to do on the Apache infra side. You just need to send an e-mail to Cenqua at [EMAIL PROTECTED] to ask them to add your project. Cheers, Matthieu On 8/3/07, Luciano Resende [EMAIL PROTECTED] wrote: I was wondering if it would be possible to get Fisheye setup for Apache Tuscany tree? https://svn.apache.org/repos/asf/incubator/tuscany/ Fisheye is a wonderful tool and the Tuscany community would benefit by having this tool available. Would it be possible to get this setup similar to other ASF projects [1]. [1] http://fisheye6.cenqua.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany vmbuild
I have created my account : lresende Please give me the administration roles, so I can go ahead and setup it up for Tuscany project builds. On 8/5/07, Brett Porter [EMAIL PROTECTED] wrote: Hi, vmbuild1 is now set up. I have created a group for Tuscany but have not added the projects - I thought that individual projects might like to set them up to their liking (though I'm happy to help with anything). If you'd like to register for an account I can give you the group administration roles so that you can do this and assign rights to other users. http://vmbuild1.apache.org/continuum/security/register.action Cheers, Brett On 12/07/2007, at 3:24 AM, Luciano Resende wrote: Thanks for checking Brett, it would be great to have history moved to the new machine (if possible) as well. Otherwise, just setting up the project on the new machine is fine. [x] you would like the project (and it's build history if possible) moved over On 7/11/07, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm not on this list, so please reply directly - thanks. Tuscany currently have a build set up in vmbuild.apache.org. It's been down for little bit, but is now back up. vmbuild is scheduled to be moved to a faster machine, and I intend to install a more recent build of Continuum (that supports grouping projects and is generally faster, more managable and more stable). I'm able to help get it set up as effectively as possible. There are a lot of failing builds on the machine right now (probably unused by the corresponding projects), so I'm cleaning house before the move. Please let me know if: [ ] you would like the project set up on the new machine with a clean slate [ ] you would like the project (and it's build history if possible) moved over [ ] you are no longer interested in using vmbuild for CI/nightlies/ whatever Thanks! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release SDO Java version 1.0-incubating (release candidate 4)
() TUSCANY-1214SDO 2.1 feature: XMLHelper.load (Source) and XMLHelper.save(Result) TUSCANY-1197Sequence composition TUSCANY-1317Provide a way to set default XML load options to be used during Java deserialization Improvement TUSCANY-1350Reorganise SDO build / distribution layout TUSCANY-1459Remove package registry delegation to EPackage.Registry.INSTANCE TUSCANY-1110Improve the performance of TypeHelperImpl.getType(Class) TUSCANY-1391Provide capability to load and save XML with unknown features TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars TUSCANY-513Implement support for dynamic subclasses of statically generated types TUSCANY-1233Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a single pass. Bug TUSCANY-1143Generated code should separate metadata creation from registration to permit proper scoping TUSCANY-1428XSD2JavaGenerator.GeneratePackage information is invalid TUSCANY-1429Using default helper context got ClassCastException due to T-1317 TUSCANY-1446Java SDO samples don't compile with JDK 1.4.2 TUSCANY-1457Unable to code gen SDOModel.xsd TUSCANY-1430SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls TUSCANY-1207TCCL-specific EcoreBuilders must be used by default XSDHelper TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content TUSCANY-1254Codegen on a type inheriting from a type in different namespace will result in mis-mapping the feature IDs TUSCANY-993Problems with sdoModelExtended.xsd TUSCANY-1223XSD base64Binary type mapping to wrong SDO type TUSCANY-1251Code generated from xsd:base64Binary types fail to compile TUSCANY-1333[Java SDO] ClassCastException when defining schema file without .xsd extension TUSCANY-1410DataHelperImpl.toCalendar() with null locale should use default locale TUSCANY-1324DeserializationNoSchemaTestCase took a long time to run TUSCANY-1369EMF 2.2.2 Dependencies from ISU are Stale TUSCANY-1352NPE in SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema TUSCANY-1325Property value with xsd:QName type is not deserialized and serialized correctly TUSCANY-1250Static SDO generator generates an erroneous factory class, when inheritance and different Java packages are used TUSCANY-578Exceptions thrown by SDO runtime not the same as defined in the spec TUSCANY-1421XMLHelper.save on root object of DataGraph gives serialization of href=root.xml#/ TUSCANY-1436TypeHelper.getType(java.util.List.class) throws ClassCastException TUSCANY-1385Duplicate namespace was serialized when SDO QName property value containing existing namespace TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2 TUSCANY-1408Cannot programmatically define a SDO property matching to XSD element TUSCANY-1393ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:int TUSCANY-1305Changesummary of datagraph using static interfaces. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistence of Service Data Objects using OpenJPA now supports Tuscany SDO DAS API
Hey Pinaki Very good to hear that you also added initial support for the Tuscany DAS interfaces. BTW, let me ask you what are your plans to Fluid ? My personal opinion is that this might be a great addition to Tuscany, and we could have it as another DAS option in Tuscany. This could also promote a better integration between Tuscany and OpenJPA communities. Thoughts ? On 7/31/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Hi Luciano, In an earlier response to your question: if would be feasible to add a DAS interface[1] layer on top of Fluid [2]? My answer was: Yes. As backup of that answer, I just added the support for SDO DAS by implementing DASFactory/DAS/Command Using Fluid. These implementations are very thin-wrapper that delegates to Fluid's JPA API. From a usage model, there is conceptual shift though from a SQL-based DAS. Using Fluid based DAS, user code will look like: (there are some TestCases that details it) DataObject person = createPerson(ssn, Fluid, Guy, 17); DAS das = getDAS(); Command insert = das.getCommand(INSERT); insert.setParameter(0, person); insert.execute(); to persist a Person DataObject, or to query DAS das = getDAS(); Command query = das.getCommand(SELECT); String jpql = SELECT o FROM Person o WHERE o.firstName=?1 AND o.age=?2; query.setParameter(0, jpql); query.setParameter(1, Fluid); query.setParameter(2, 17); DataObject list = query.executeQuery(); List result = (List)list.get(0); Few notable points are: 1. There is no SQL. 2. All object level paramaters are set via Command.setParameter() method. Insert command acts on a Person DataObject (insert can be cascaded transitively, btw) which is passed to it as parameter. 3. Query is JPQL. This is a powerful contribution of JPA. The namespace of the query tokens are Object Domain tokens i.e. SDO Type and Property names; not database Table or Column names. Join is navigation across a SDO DataGraph. OpenJPA will take care of creating the appropriate SQL. User can see/monitor what SQL is being generated by OpenJPA. 4. DAS defined return of Command.executeQuery() as a DataObject. One would prefer it to be a ListDataObject but to confirm to the API, I just return a dynamic DataObject whose 0-th Property is a ListDataObject And, last but not the least, applyChanges(): dataObject.setString(firstName, Solid); das.applyChanges(dataObject); Will make an UPDATE to the database. How does user application gets a DAS? DASFactory dasFactory = new FluidDASFactory(SDO-DAS); DAS dasFactory = dasfactory.createDAS(); 1. Everything about persistence service (from database connections to ~200 configurable parameters supported by OpenJPA) is configured in a single file: META-INF/persistence.xml. The unit name in this file should be persistence-unit unitName=SDO-DAS. 2. The overloaded DASFactory.createDAS() that takes org.apache.tuscany.sdo.das.rdb.Config and other parameters are supported simply by ignoring the argument :). Regards Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 3:25 PM To: tuscany-dev@ws.apache.org Subject: Re: Persistence of Service Data Objects using OpenJPA I haven't looked into this with any great detail, but I'd like to ask if would be feasible to add a DAS interface[1] layer on top of Fluid [2]. Thoughts ? [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/main /java/org/apache/tuscany/das/rdb/DAS.java [2] http://people.apache.org/~ppoddar/fluid/site/welcome.html On 7/27/07, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Pinaki, I think your project has a lot of potential. Another related aspect is that there is interest in the SDO specification charter to discuss the possibility of converging/supporting JAXB with static SDO in version 3. JAXB2, as you may know, has a similar objective to support standard POJOs. If that happens, then I see even more synergy with your approach. At Tuscany, we'd also be very interested in the bytecode generation that you mentioned you've prototyped in Fluid. Tuscany has done a little bit of sandbox prototyping in that area as well, but nobody has had enough time to really pursue it. Given this work, I think you should consider getting involved with the DAS specification effort, if you haven't already. Frank. Pinaki Poddar [EMAIL PROTECTED] 07/27/2007 12:32 PM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc [EMAIL PROTECTED] Subject Persistence of Service Data Objects using OpenJPA
Re: Tuscany Subproject News Bulletin? Would it be useful?
interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java DAS beta1 (RC3)
All the maven artifacts are now signed. On 8/6/07, Venkata Krishnan [EMAIL PROTECTED] wrote: I've verified the signatures for the src and bin distros and they seem fine. The License file mentions 'Apache Jackarta'... while I think it is 'Apache Jakarta'. Maybe this very minor thing could be fixed for the next release. So over all, here is my +1 for this release. Thanks - Venkat On 7/30/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in RC1 and RC2 should now be fixed. The Release Candidate RC3 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Propose to create a new Tuscany malling list
Currently we have couple places that can generate e-mail notification : - Apache Continuum build notifications (sucess/failure) - Traffic stats for Apache Tuscany Blog (daily/weekly) - Traffic stats for Apache Tuscany website (daily/weekly) - etc I don't want to pollute the dev or committ list with these notifications, and thus would like to propose creation of a notification list to forward all these e-mails, and the interested people would subscribe (or look into the archives) and have access to these information. If people are OK with this, I'd contact infra@ and ask for the creation of the new notification list. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: August Reports - deadline tomorrow
Just a friendly reminder, tomorrow is the deadline for the Board Reports, please add any updates to the draft report [1], and I'll post it tomorrow. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 On 8/1/07, Luciano Resende [EMAIL PROTECTED] wrote: It's that time again for us, I have started a draft report on our wiki [1], let's get it updated asap. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 -- Forwarded message -- From: Noel J. Bergman [EMAIL PROTECTED] Date: Aug 1, 2007 7:52 PM Subject: August Reports To: [EMAIL PROTECTED] Just getting the reminder in early --- those projects reporting in August, please start working on and posting your reports. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy Attachments Resolution in the Assembly Model
Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
+1 for Ant On 8/8/07, Simon Nash [EMAIL PROTECTED] wrote: +1 for Ant. He did a great job with 0.90. Simon Venkata Krishnan wrote: +1 for Ant taking doing the RM since his seasoned hand will help up get things our quickly given the little time we have. Ant, if you are OK with this count me in for any help you might require in this. Thanks. - Venkat On 8/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Ant, Thanks for reminding us that time is ticking if we want to get another release out this month :) I'd like to nominate you as release manager, if you're ok with it. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy Attachments Resolution in the Assembly Model
Cool, if you can wait a day, i can take a look at that... Sebastien suggestion seems ok: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml But I guess we also need to change the logic on the algorithm that checks for the right processor to be used, as it's now just checking the file extension. On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Luciano, that's what I am suggesting. - Venkat On 8/8/07, Luciano Resende [EMAIL PROTECTED] wrote: Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- Jean-Sebastien - 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: New itest folder: guidelines
You could use some of the other project existing pom[1] as guidelines. The poms are all inheriting the necessary configuration to run the tests from the parent pom [2] and it looks like below : !-- surefire plugin configuration -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.3/version configuration includes include**/*TestCase.java/include /includes reportFormatbrief/reportFormat useFilefalse/useFile forkModeonce/forkMode argLine-ea -Xmx128m/argLine /configuration /plugin [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/contribution/pom.xml [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml On 8/9/07, venu reddy [EMAIL PROTECTED] wrote: Folks, I am planing to create my own folder (venu) in java/sca/itests and write few sample tests. Can any one please post if you have any guidelines on writing pom.xml (\java\sca\itests\venu\pom.xml) to include my sample tests for maven to build and execute. Thanks, Venu. - A 'wish' changes nothing. A 'decision' changes everything! Anon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build problem in binding-ws-axis2
Could you try moving to maven 2.0.5 on the one that does not work ? On 8/9/07, ant elder [EMAIL PROTECTED] wrote: This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribution URLs
I think your current directory, during the execution of the code, will not be mapped to the root of you project, but probably to target/classes or target/test-classes. Could you check that please ? On 8/10/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Simon, Could you please send the exact URL you are passing to the contribution service ? I have added a test case for what I understood your problem is, and that is working fine, but note that in the test case, I'm calling getClass().getResource(/deployables), and that gives me a url like : file://deployables, and that would pass the logic to correct identify a folder. On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: I've just noticed that if I have a contribution directory as follows /my/contribution/dir/mycomposite.composite And I pass the source URL /my/contribution/dir to the contribution service it complains that it can't find /my/contribution/mycomposite.composite. If I pass the source URL /my/contribution/dir/ it works (note slash on end). Is this a fault? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano This was the piece of code that was causing me problems... contributionURL = new URL(file:/ + currentDirectory.getCanonicalPath() + /src/main/resources/ + nodeName + /); // Contribute the SCA application Contribution contribution = contributionService.contribute( http://calculator;, contributionURL, resolver, false); Composite composite = contribution.getDeployables().get(0); // Add the deployable composite to the domain domain.getDomainComposite().getIncludes().add(composite); domain.getCompositeBuilder().build(composite); Where the directory structure is. src/ main/ resources/ nodeA/ META-INF/ sca-contribution.xml wsdl mutiply.wsdl calculator.composite And I want to read the contribution from the nodeA directory. Maybe you can spot something from this. But if nothing comes to mind immediately don't worry. I'll check this test in over the next few days and we can look at it directly. Regards Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
Simon Laws wrote: +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. We could probably get a stable distribution available on the 20th, and we would check that. On 8/12/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: I guess early the following week still leaves time for an August release. It will be real tight though so we'll all need to be quick and thorough with our RC reviews as one problem once we get to the IPMC voting and it could easily slip it into September. So does taking the branch on the 21st sound ok to everyone? ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: Ant talked about cutting the branch very early next week. I'd prefer that to doing it on August 18th. I will be away for a few days, returning home late on the 18th, and I could take advantage of the extra couple of days to help with last-minute things. Simon Venkata Krishnan wrote: Hi, Theres been lots of discussion. So let me summarize my understanding / imaginiation : - - We will cut a branch around Aug 18th for Release 0.95. As always, once the branch is cut we need to be watchful on the commits (including getting the RMs nod to significant ones) to the branch and also ensure the trunk is always in sync. - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Is that all right ? - Venkat On 8/9/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...ant - 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] +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
Memory: 52M/63M [INFO] Figures it would stop on Supply Chain (I'm in the process of of launching mydemandchain.com). Maybe someone is trying to tell me something :-) I ran the build 3 times to make sure that it was not just maven failing to download something...Although that could still be a possibility. I tried building it with 1.6 after the 1.5 run, and it still fails in the same place as before. Strange. Please let me know if you want me to try something else. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: itests: There are no tests to run
Surefire is configure to run test based on the following criteria : include**/*TestCase.java/include The test case java file must match the criteria above, and to take a concrete example (java/sca/itest/callback-api), you can see that the test case is named as CallBackApiTest.java and will not be picked up by surefire, that's why you see the message of no tests to run : --- T E S T S --- There are no tests to run. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 On 8/12/07, venu reddy [EMAIL PROTECTED] wrote: I am trying to execute itests from itest folder with mvn. Everything went fine without any errors including the sample itest that we are trying to write. However I have observed that, while trying to execute itests from each itest folder, for few folders it says There are no tests to run. What does this mean, are those tests incomplete?, or am I missing something here?. Thanks, Venu. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I think Tuscany needs a graph generator for composite layouts
Take a look at this post on Tuscany blog : http://apache-tuscany.blogspot.com/2007/07/sca-tooling.html Looks like the tooling project mentioned there has the ability to introspect components from your workspace, and give you a visual representation of your composite On 8/12/07, shaoguang geng [EMAIL PROTECTED] wrote: as the title, when composite contents comes more and more complicated, a layout graph generator would do greate help to developers. Or did some one see commercial providers of such a grapher? Good day. - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Calling XSD2JavaGenerator from ANT
I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Calling XSD2JavaGenerator from ANT
I was expecting the non-recommended approach to work...but the SDO generator code explicitly interpret and expects the key/value as two separate command line args. The non-recommended approach to emulate the two-argument behavior is arg line=key1 value1/ If this is the expected behavior, we should at least have it documented. Thoughts ? On 8/12/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Hi, The observed behaviour is the documented behavior of Ant arg value=key1/ arg value=value1 means there are two separate command-line arguments i.e. args.length=2 Is different from arg value=key1 value1/ Which means there is one command-line argument of value key1 value1. The non-recommended approach to emulate the two-argument behaviour is arg line=key1 value1/ Pinaki Poddar 972.834.2865 -Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 1:51 AM To: tuscany-dev Subject: Calling XSD2JavaGenerator from ANT I was playing with XSD2JavaGenerator to generate static sdo objects for some SCA samples, and realized it has some strange behavior with regards to command line argument processing. Basically, it treat the a command line option and it's value as two separate arguments, so, instead of being able to pass an argument like arg value=-targetDirectory target/sdo-source/, you actually MUST pass the arguments like two separate arguments arg value=-targetDirectory/ arg value=target/sdo-source/. Is this the expected behavior ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Tuscany Java DAS beta1 (RC4)
Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
Comments inline
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Below is what is happening today:-
managedtx(default-true) - config attribute in ConnectionInfo element to
control transactions
managedtx database conn. supplied effect on transaction
--
1)true from caller each DAS command undergoes
commit/rollback
2)false from within DAS this is not handled in any way
3)true from within DAS each DAS command undergoes
commit/rollback
4)false from caller DAS does not issue
commit/rollback, external caller manages
So what is lacking is
a ability to issue commit/rollback on group of commands where connection is
managed by DAS (managedtx=true).(case 3)). this will be essential to handle
any business unit work. otherwise DAS is ending up today in mimicking
autocommit behavior of Database which is not so useful when business
transactions need to handle a group of operations as one atomic unit
So, the test case below is an example of multiple commands under one
transaction. On this scenario, connection is supplied by client, and I
think this gives you the same results as if the connection was created
by DAS and exposed to client code, and also gives more flexibility to
how the client will aquire the connection, or re-use some other
connection to be part of the same transaction.
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java
b what is the reason behind providing case 1)? when client/container
provides connection, it can be controlled by client/container. and even if
DAS tries to controll it, as user has handle to connection,
commits/rollbacks can be issued by client async with what DAS is trying to
control. So there will be no meaning in DAS controlling the connection
supplied by client. And so there is no meaning to managedtx either.
c case 2), as of today there is no way to expose connection to client when
it is created by DAS. so neither DAS nor client manages transaction. For
this case exposing connection thru getConnection() will be useful (for other
cases, it can be banned)
In the case where client code requires access to the connection, is
there any issue with supplying it to DAS ?
d as DAS is heterogeneous API, is the DAS config going to be
heterogeneous too? If yes, then it will be advantageousto support the
transactional nature of RDB using such semantics. If the backend (non RDB)
does not support transaction, this semantics will be of no use, but
in this case the DAS config can be different (more tuned to that particular
backend)
So, it all depends on whether we are following the path to support DAS with
heterogeneous APIs or not. Will you please elaborate meaning of
heterogeneous API in context of different flavors of DAS?
Yes, the idea is that each impl would define it's own model,
inheriting from a common root class (xsd element)
e {If you already defined the transaction demarcation flags...}Where are we
doing that at present? What is there is only issue commit/rollback at the
end of each DAS Command. Am I missing some other transaction demarcation
mechanism already available in DAS?
Regards,
Amita
On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote:
I think that the main goal of DAS, is to be an heterogeneous API that
could be used to implement support for various backends (rdb, ldap,
xml etc). Starting to add various semantics that might be specific to
RDB might take us out of this direction.
So, for this issue, let's take a step back and think around the
scenarios where this new enhancement might be useful, could you please
list a couple here ? It would be great if you could also mention the
deficiencies you found from managedtx parameter on each scenario.
Also, couple questions :
- Could you please elaborate more on why you need to expose
DAS.getConnection() ?
- If you already defined the transaction demarcation flags, why you
still ask the client code to handle start/endTransaction? Why is that
different from passing managedtx = false ?
On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
-When connection is provider by caller(say container), there is no
meaning
of managedtx attribute, and it is better to let the caller handle the
transactionality of the operations. So, when DAS is instantiated using
external connection - mandate managedtx = false. Also, expose
getConnection() from DAS to give a ref. of the connection (User already
owns
it, DAS is just providing ref.). DAS will not issue any commit/rollback
-When connection is created internally, managedtx has a meaning.
1When false, DAS.getConnection() should be exposed and user should be
allowed to handle
Updating SCA Distributions
Is there any documentation on how to update the SCA Distributions ? Maybe a quick readme on java/sca/distribution describing how to add dependencies... should new dependencies always go in both bundle and manifest ? what about webapp ? BTW, I have added sdo-tools dependencies under revision #565631, it would be great if someone could review it and let me know if I didn't forget any other place. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
So, let me try to understand this. We are going to remove the -webapp samples from the release binary distribution (due to size constrains), but we are still going to continue supporting the -webapp story. Users can still see these samples on the source distributions, right ? I'm asking this because I think that our users DO use Tuscany in the scenario of a -webapp, and if we are going to remove the -webapp samples, users that are evaluating the new release might think we removed the webapp support, so we need to be clear. If the webapp story is changing, then we should document (wiki) and test so our users can migrate to the new story. If this requires implementation.web I'd think we should implement these changes when it's ready. As an alternative approach, what about creating a samples-webapp distro ? On 8/14/07, ant elder [EMAIL PROTECTED] wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Anderson, Jeff T (CA - Toronto) wrote: I like having the samples, in the absence of extensive documentation these are key to understanding Tuscany... I like the idea of packaging the samples as simple SCA contribution jar's. I think keeping the footprint as little as possible is important, both in terms of optics and managing the complexity and understanding. Just my humble opinion... Jeff +1 to keep the samples as simple SCA contribution JARs. The current webapp packaging is not quite right anyway as it's introducing a half baked mix of J2EE and SCA programming model inside the webapp. I'd suggest the following: - Package SCA sample components as simple SCA contribution JARs, stay away from webapps. - To allow JSP and servlets to invoke SCA service component, support implementation.web Web components as described in [1]. [1] http://www.osoa.org/pages/viewpage.action?pageId=3980 (now back on the dev list) Just to make sure I understand, as an example right now we have sample-helloworld-ws-service and sample-helloworld-ws-service-webapp, do we just delete the -webapp one? Yes And then you can use the jar built by the sample-helloworld-ws-service with either the the Geronimo/Tuscany integration or our webapp runtime or with the standalone runtime we already use it with today? That sounds like the way to go to me but that seems like quite a big change, do we want to try to get this done in time for the upcoming release or wait till after that and just make the changes for 1.0? ...ant I prefer to do it now. I'm not quite sure why it's a big change? Isn't it just about deleting Maven modules? we have equivalent samples already working with the standalone runtime right? Is the Geronimo integration ready to be included in the the release? -- Jean-Sebastien I also think sooner would be better so happy to help go for it. The list of current webapps is: demo-alert-aggregator demo-mortgage-creditcheck sample-calculator-webapp sample-chat-webapp sample-helloworld-dojo sample-helloworld-jsonrpc sample-helloworld-ws-sdo-webapp sample-helloworld-ws-service-webapp Not sure we do have equivalent non-webapp samples for all those, i'll have a go at and seeing if they all those sample- ones run ok out side of a webapp. ..ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error while executing the compiler - Java heap space
You can also increase the memory options in the sca pom, in the surefire plugin configuration section. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml On 8/15/07, ant elder [EMAIL PROTECTED] wrote: On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/15/07, ant elder [EMAIL PROTECTED] wrote: I always get a Java heap space error during the build while the itests are running these days. Runs fine if i build from within the itests folder but building from the top sca folder always fails. Does anyone else ever see this? Anyone know if there's something i can fiddle with in the mvn config to try to fix it? ...ant Hi ant I don't know if this is exactly the same issue that Luciano was seeing in the Continuum build but I remember he was playing about with MAVEN_OPTS=-Xmx1024m -Xms512m things. I looked back at the mails and see him trying to find out how to set these on the the Continuum machine. Simon Thanks, that does the trick. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can RSS Feed be enabled for Tuscany blog?
You can definetly get Atom feeds using the following URL : http://apache-tuscany.blogspot.com/feeds/posts/default As for RSS, there is some documentation here [1], but that seems not working anymore. As a tip, I also use iGoogle [2] as my homepage, and customized it to give me access to all related Tuscany blog feeds on one page, it's useful to see what's going on... and keep you updated. [1] http://help.blogger.com/bin/answer.py?answer=42662query=rss%20urltopic=type=f [2] http://www.google.com/ig On 8/15/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, There is no RSS Feed on Tuscany blog[1]. Any one knows how to enable this? [1]: http://apache-tuscany.blogspot.com/ Haleh -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build failure in java2wsdl
Are you using IBM JDK ? Looks like my latest changes have some issues with that JDK. On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: Just doing a clean build so that I can publish module snapshots and I get the following. Anyone any ideas? Simon java2wsdl\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package com. sun.org.apache.xml.internal.serialize does not exist C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot find symbol symbol : class OutputFormat location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot find symbol symbol : class XMLSerializer location: class org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm pl -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just looked more at the code and found something more interesting - :) When there is no connectionInfo in DAS Config, managedtx defaults to true, so when connection is passed by user (as in TransactionTests), managedtx is true. So, with the current code case 4) can not occur (which is actually useful) 4)false from caller DAS does not issue commit/rollback, external caller manages TransactionTests - if you look closely, there is just one DAS.applyChanges(root) command which has 2 INSERT statements using same PK. So, 2nd INSERT gives JDBC Exception and DAS uses it to issue rollback. So, TransactionTests is succedding in getting exception and avoiding both INSERTs due to the fact that both INSERTs are under same applyChanges() Command. What will happen in case when there is a client code like das.applyChanges (root1); das.applyChanges(root2); and the client wants both applyChanges() to be part of the same transaction? Is it possible with current DAS? Based on the current code, there will be autocommits for each applyChanges() which may not be desirable. Or is DAS forcing clients to grab all changes somehow in one call to das.applyChanges () to ensure transactional integrity? Is this convenient? ___ I could not understand the below statement - please elaborate. [In the case where client code requires access to the connection, is there any issue with supplying it to DAS ?'} ___ Regards, Amita On 8/14/07, Luciano Resende [EMAIL PROTECTED] wrote: Comments inline On 8/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below is what is happening today:- managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages So what is lacking is a ability to issue commit/rollback on group of commands where connection is managed by DAS (managedtx=true).(case 3)). this will be essential to handle any business unit work. otherwise DAS is ending up today in mimicking autocommit behavior of Database which is not so useful when business transactions need to handle a group of operations as one atomic unit So, the test case below is an example of multiple commands under one transaction. On this scenario, connection is supplied by client, and I think this gives you the same results as if the connection was created by DAS and exposed to client code, and also gives more flexibility to how the client will aquire the connection, or re-use some other connection to be part of the same transaction. [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java b what is the reason behind providing case 1)? when client/container provides connection, it can be controlled by client/container. and even if DAS tries to controll it, as user has handle to connection, commits/rollbacks can be issued by client async with what DAS
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Sebastien wrote : IMO application developers shouldn't have to suffer from the complexity of XML... How about supporting composites without namespace declarations at all? I'm trying to understand all the proposals here, what would be the side effects of going with your proposal ? This seems like simple, and simple is good... On 8/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: The last comments have been in favour of keeping things as-is so how about just doing nothing and letting this thread die. ...ant Here are the last comments from the different people who contributed to this thread: - Mike, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21059.html - Luciano, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21068.html - Simon, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21106.html - Sebastien, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21113.html - Ant, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21117.html I don't see a consensus in favor of keeping things as-is in these comments. This has a significant impact on the programming model so IMO this JIRA issue needs a clear resolution. On 8/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/3/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Taking that line of thought and you hit the long thread associated with: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] which is what I was hoping to quietly ignore by just keeping everything in the one SCA namespace. ...ant On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: Wouldn't this cause breakage in the scenario that I described, where foo from Tuscany later turns into foo as part of SCA but with some differences? Any SCDLs written to just use plain foo would break when Tuscany steps up to support the SCA foo. Simon ant elder wrote: How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) I didn't really want to reopen this debate either but I didn't understand both of your last comments so I guess I'm going to have to ask some questions... Ant, what did you mean by having the Tuscany namespace extend the SCA one? I'm not actually sure, my xsd is a bit rusty, i vaguely thought there was a way to say something extend another namespace inheriting all the things from it, but a quick search for it now i cant find how to do that, is it not possible? snip And also give my opinion: +0.5 if people want to keep Tuscany extensions in the SCA namespace for now, hoping that they make it to the SCA spec XSDs at some point I'd be +1 on doing that. The easier we can make things for people trying out Tuscany the better IHMO. ...ant What's the conclusion here? I've seen different opinions from Mike, Simon, Luciano, Ant, myself. Do we need a vote to decide the next step? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Looks like option B is more spec compliant and more aligned to the XML namespaces usage rules. Should I give it a try ? On 8/19/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my opinion about the three options: 1) -0.5 on A) 2) +1 on B) 3) -0.5 on C) A) violates the SCA assembly spec. 2535 ... New interface types, implementation types and binding types that are defined using 2536 this extensibility model, which are not part of these SCA specifications must be defined in 2537 namespaces other than the SCA namespace. C) IMO, the composite file should conform to the XSD defined by the SCA spec. The example listed under C) is not a valid SCA composite definition. We can make the http://www.osoa.org/xmlns/sca/1.0; as the default namespace to avoid the repeating prefixes. B) is right usage of XML namespaces. Hopefully, the SCA tooling can help ease the XML namespace declarations. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, August 19, 2007 5:07 PM Subject: Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions Luciano Resende wrote: Sebastien wrote : IMO application developers shouldn't have to suffer from the complexity of XML... How about supporting composites without namespace declarations at all? I'm trying to understand all the proposals here, what would be the side effects of going with your proposal ? This seems like simple, and simple is good... Before getting into the side effects, here are three examples: [A] What we have right now, standard SCA extensions and tuscany extensions sharing the standard SCA namespace composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:bb=http://bigbank; name=BigBank component name=AccountServiceComponent service name=AccountService binding.jsonrpc uri=/AccountJSONService/ binding.ws wsdlElement=http://bigbank#wsdl.port(AccountService/AccountServiceSoap)/ binding.sca/ /service implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ reference name=calculatorService binding.rmi host=localhost port=8099 serviceName=CalculatorRMIService/ /reference reference name=stockQuoteService binding.ws wsdlElement=http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference property name=currencyEURO/property /component component name=AccountFeedComponent service name=Collection binding.rss uri=/rss/ binding.atom uri=/atom/ /service implementation.java class=bigbank.account.feed.AccountFeedImpl/ reference name=accountService target=AccountServiceComponent/ /component component name=AccountDataServiceComponent implementation.composite name=bb:AccountData/ /component component name=WebResourceComponent service name=Resource binding.resource uri=// /service implementation.resource location=web/ /component /composite (B) What IMO is a more correct use of XML namespaces, standard SCA extensions in the standard SCA namespace, and Tuscany extensions in a Tuscany namespace composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://incubator.apache.org/xmlns/tuscany/1.0; targetNamespace=http://bigbank; xmlns:bb=http://bigbank; name=BigBank component name=AccountServiceComponent service name=AccountService t:binding.jsonrpc uri=/AccountJSONService/ binding.ws wsdlElement=http://bigbank#wsdl.port(AccountService/AccountServiceSoap)/ binding.sca/ /service implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ reference name=calculatorService t:binding.rmi host=localhost port=8099 serviceName=CalculatorRMIService/ /reference reference name=stockQuoteService binding.ws wsdlElement=http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)/ /reference property name=currencyEURO/property /component component name=AccountFeedComponent service name=Collection t:binding.rss uri=/rss/ t:binding.atom uri=/atom/ /service implementation.java class=bigbank.account.feed.AccountFeedImpl/ reference name=accountService target=AccountServiceComponent/ /component component name=AccountDataServiceComponent
Tuscany SCA and SDO plugins attempt to generate code on incorrect goals
Looking at TUSCANY-313, I was thinking about the use cases and expected behavior. case 1 - I'm a developer, building an application and I have some broken XSD. I probably just want to get my eclipse project generated so I can continue to work on my application. case 2 - I'm generating my eclipse project, and my application depend on the generated SDO, otherwise I'll get lot's of red x on eclipse and my code won't compile and work. So, in case1, i guess the developer won't really want the broken xsd to be processed, and a quick workaround would be to remove the broken xsd from the list of files to be processed on the project pom, but in case2, I guess the developer would benefit from having the static sdo generated when the eclipse:eclipse phase is processed. Based on this, I was thinking if we really want to change the current behavior. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release Tuscany Java DAS beta1 (RC4)
Release to vote Tuscany Java DAS beta1 has passed with 5 binding +1, 1 non-binding +1 and no -1s. Luciano Resende, Kevin Williams, Ant Elder, Adriano Crestani, Simon Laws, Amita Vadhavkar (non-binding) On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/16/07, Adriano Crestani [EMAIL PROTECTED] wrote: It seems ok for me, everything ran fine ; ) +1 Adriano Crestani On 8/15/07, ant elder [EMAIL PROTECTED] wrote: +1 ...ant On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in previous RC should now be fixed, and the only change from RC3 is a fix to file permission issues on the distribution as described in TUSCANY-1524. The Release Candidate RC4 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc4/das-beta1-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc4/ Seems OK to me, here is my +1 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano, I thought I would set up the DAS tests from the binary distro to make sure they play nice as I go through testing SCA samples. So this is very late +1 from me. The odd thing I found was that the sample urls in companyweb/readme.htm sample-ajax-das/readme.htm Don't work. So something for next time. I haven't gone in and fixed them as the url (http://localhost:8080/sample-companyweb-%7bversion%20tag%7d) looks strangely important. Are these htm pages generated from somewhere? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nullp when running binding-echo sample
I get an exception either from inside Eclipse IDE or from distribution using ant. Could you please create a jira for tracking this issue. On 8/20/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, I am running this sample from the distribution that I built based on the latest code. When I ran the sample following ant instructions, I get the following: C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo ant run Buildfile: build.xml run: [java] Returned message: foo [java] Echo reference = foo [java] Exception in thread main java.lang.NullPointerException [java] at echo.server.EchoServer.sendReceive(EchoServer.java:75) [java] at echo.EchoBindingClient.main(EchoBindingClient.java:44) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 1 second C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo I this a known problem that is being worked on? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nullp when running binding-echo sample
I fixed first :) You sent e-mail first :) On 8/20/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, It was fixed by Luciano a few minutes ago before I tried to check in the same fix :-). Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, August 20, 2007 9:44 PM Subject: Re: nullp when running binding-echo sample I get an exception either from inside Eclipse IDE or from distribution using ant. Could you please create a jira for tracking this issue. On 8/20/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, I am running this sample from the distribution that I built based on the latest code. When I ran the sample following ant instructions, I get the following: C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo ant run Buildfile: build.xml run: [java] Returned message: foo [java] Echo reference = foo [java] Exception in thread main java.lang.NullPointerException [java] at echo.server.EchoServer.sendReceive(EchoServer.java:75) [java] at echo.EchoBindingClient.main(EchoBindingClient.java:44) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 1 second C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\binding-echo I this a known problem that is being worked on? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Welcome Brady !!! On 8/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, Welcome Brady! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
a namespace since I think it is not extensible, unlike SCA which allows all kinds of extension. PS 2 If anyone can think of a better way for SCA to handle its extensibility, that will allow us to drop namespaces, the spec team will be all ears. The spec group debated the use of namespaces at some length before adopting the current spec definition (and I was one of those trying to keep namespaces out of it). No more technical comments on this thread today... So here's a summary of what people have said so far. - Ant: A) +1 B) -1 on only doing B C) - Luciano: A) B) more spec compliant C) - Mike: A) -1, B) +1 C) +0.5 if we do B - Raymond: A) -0.5 B) +1 C) -0.5 - Sebastien: A) +0.5 B) +1 C) proposed in addition to B - Simon: A) -1 B) +1 C) -1 if alone, -0.9 if we do B - Venkat: A) B) +1 C) Looks like option (B) is the most preferred option with: - one -1 - five +1 - one more spec compliant Do we need more technical discussion? or a new [VOTE] thread to close this issue? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache Tuscany Java DAS 1.0-incubating-beta1 released
August 21st 2007 - Apache Tuscany is pleased to announce the 1.0-incubating-beta1 release of the Java DAS project. Data Access Services (DAS) works together with Service Data Objects (SDO) simplifying handling of data when interacting with the back-end data source and frees application developers from dealing with tedious and error-prone transformation between end source types and SDO Data Object Types/properties. Key features of 1.0-incubating-beta1 release are : - Support for J2SE connections in DAS config using Driver Manager. - Added support for multiple database schemas in queries - Enhanced Optimistic Concurrency Control with overqualified updates - Multiple enhancements around ApplyChanges API - Enhanced Documentation : User, Developer and Architect guides as well as javadocs - Enhanced and new sample applications For a complete list of changes on this release, please view the release notes. https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1/distribution/binary/RELEASE_NOTES To download Java DAS please follow the link to http://incubator.apache.org/tuscany/das-downloads.html Apache Tuscany welcomes your help. Any contribution, including code, testing, improving the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany. Thank you for your interest in Apache Tuscany! The Apache Tuscany Team. --- Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] What's next for Tuscany DAS ?
With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question on extension-helper and how to register extensions with specific QNames
I'm updating all Tuscany extensions that are non-spec'd to use a Tuscany namespace, and with this, some bindings or component types will be registered with the SCA 1.0 namespace (e.g binding-ejb) but others will use the Tuscany extension namespace (e.g binding-dwr). In this case, and mainly when they are both implemented using Tuscany extension-helper, how I can use a specific QName for a tuscany binding or component type, and avoid using the default one ? Do we have any support for this today ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on extension-helper and how to register extensions with specific QNames
Well, i gave it a try, and I was able to get further by creating and registering a new module activator that extended BindingsActivator and overriding the getBindingQName method. On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm updating all Tuscany extensions that are non-spec'd to use a Tuscany namespace, and with this, some bindings or component types will be registered with the SCA 1.0 namespace (e.g binding-ejb) but others will use the Tuscany extension namespace (e.g binding-dwr). In this case, and mainly when they are both implemented using Tuscany extension-helper, how I can use a specific QName for a tuscany binding or component type, and avoid using the default one ? Do we have any support for this today ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Done under revision #568830 On 8/22/07, Mike Edwards [EMAIL PROTECTED] wrote: Jean-Sebastien, Jean-Sebastien Delfino wrote: snip Looks like option (B) is the most preferred option with: - one -1 - five +1 - one more spec compliant Do we need more technical discussion? or a new [VOTE] thread to close this issue? Thanks for a great summary. I'm happy with the conclusion. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
Simon Nash wrote: I think option 1 for 0.99 is the best (and safest) that we can do in the time available. +1 On 8/23/07, Simon Nash [EMAIL PROTECTED] wrote: I think option 1 for 0.99 is the best (and safest) that we can do in the time available. So +1 for the 0.99 part. I need to give more thought to 1.0. Simon Simon Laws wrote: On 8/23/07, ant elder [EMAIL PROTECTED] wrote: On 8/23/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/23/07, haleh mahbod [EMAIL PROTECTED] wrote: I moved all the jars from calculator-webapp to tomcat/lib. calculator-webapp runs fine. What else is there that might cause a problem? Haleh On 8/23/07, ant elder [EMAIL PROTECTED] wrote: On 8/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'll start a different thread to discuss the more long term support for implementation.web. For now, comments inline to cover the immediate WAR size issue for the 0.99 release. Simon Laws wrote: [snip] 1 - what is in the war that is build from these samples - currently all of the tuscany jars required [snip] Doing 1 is a relatively straightforward exercise of refactoring the current war into a slimmed down version. I'm still not convinced that it's a good idea to remove the webapp samples and compress everything into a small number of samples I think we should just document how to copy the required JARs to the Tomcat lib folder and run the stripped down WARs this way, assuming that it works. The problem is likely to be the assuming that it works as last time i tried this it didn't - there's various classloader issues. Changing to use deep integration like we used to also seems like quite a big change to be doing just moments before we cut a release so could we at least postpone looking at that till after this release? For this release I think I'm in favour of just picking a few samples and demos to not ship pre-built and documenting that in their README's as it seems like the most minimal change. ...ant I've been having a bit of a play with this and it's not straighforward to get this to happen in a nice way at the moment. What I was trying to do was knock all of the tuscany jars out of the war and have the deployment of the tuscany jar be a manual step. For some (classloader) reason the it seems to be a bit of an all or nothing, i.e. you have to have all of jars that were orignally in WEB-INF/lib in tomcat/lib or have them all in the web itself. What I wanted to do was package the non tuscany dependencies in the war to reduce the amount of manual picking required when applying tuscany jars to tomcat, i.e. I was prepared to go with copy all of the modules knocking out jetty, tomcat etc. Some options at the moment given where we are 1/ Just fix build.xml for each sample so that the wars can be built as is and we don;t have to ship them. 2/ Variation on 1 - Fix and change the build.xml to build a minimal war and alongside that build either a directory or a zip of all the jars that need to be dropped into tomcat/lib to get the sample to work. 2/ create the minimal war and give detailed manual instructions about which jars to pick out of the distro Anyone else have any other ideas. I worry we'd not get anything other than 1/ done by tomorrow and even then the READMEs etc would have bugs. So my preference would be for 0.99 do 1/ for the big webapps but keep the small prebuilt ones. The big ones are: demo-allert-aggregator.war demo-mortgage-creditcheck.war sample-helloworld-ws-sdo-webapp.war sample-helloworld-ws-service-webapp.war sample-calculator-webapp-ws.war Thats minimum changes to what we have today, just 5 readme updates, and gives a distro size of less the 60Meg. For 1.0 do: - change samples to be simple contribution jar's that can work in all of standalone, webapp distro, Geronimo - maybe keep one existing webapp sample to demonstrate that style of packaging - fix the ClassLoader issues so that Tomcat deep integration works well and have a sample/documentation for deep integration That should give a 1.0 distro size of less than 50Meg. Note also, i'd like to cut the 0.99 branch and create RC1 in about 9 hours so if anyone wants to go for something other than this for 0.99 thats fine by me but it needs to start getting done pretty smartly :) ...ant Ok, +1 for 1 given the time we have. I have to go and get some sleep. But can do some of this first thing. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com
Re: 0.99 RC distributions available for review
Sebastien wrote: I think that there's two issues: 1. In the pom.xml relativePath../pom.xml/relativePath should be changed to relativePath../../pom.xml/relativePath ../pom.xml references the parent pom.xml, and I guess that is right, as /demos have a pom.xml. Maybe you have found an issue with the other demo projects. As for Haleh's issue, I was having similar issue when trying to build the 0.99 branch with maven 2.0.7, so maybe we could check what's her maven version. On 8/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: haleh mahbod wrote: demo\alert-aggregator mvn is failing. Anyone else sees this? C:\tuscany-new\sca-dist\tuscany- sca-0.99-incubating-SNAPSHOT\demos\alert-aggrega tormvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 0.99-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:0.99-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) I think that there's two issues: 1. In the pom.xml relativePath../pom.xml/relativePath should be changed to relativePath../../pom.xml/relativePath I'm taking care of this fix. 2. The 0.99-incubating-SNAPSHOT artifacts probably have not been published yet -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.99-incubating RC2
Below is a list of things I found while evaluating the RC2. I played with samples built with maven in jetty app server I'll give a positive vote after the maven artifact issues are addressed, as for the other issues, I guess we could document them. - Maven repo needs signing - Invalid MD5 and SHA1 signatures e.g : D:\temp\0.99-RC2\maven\org\apache\tuscany\sca\sca-api\maven-metadata.xml Generated : 2d664e0f89c8ff79e8006e8fb99ed757 compared to md5 file 897dcee76e120aeb5461219a652258bf Generated : 4DE81991FB4A4825FE337D86038CE7663F095131 compared to SHA1 594302002ec7d9a5f3656984a0380bc5805c2abc - Snapshot references modules\binding-osgi\pom.xml parent groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-modules/artifactId version0.99-incubating-SNAPSHOT/version relativePath../pom.xml/relativePath /parent dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-host-embedded/artifactId version0.99-incubating-SNAPSHOT/version /dependency - sample-helloworld-ws-sdo-webapp.war built with ant can't find SDO dependency - demo alert agregator fails when trying to update feeds to display, logs are showing date parser error Exception java.text.ParseException: Unparseable date: 10-Jun-2007 16:34:03 Exception java.text.ParseException: Unparseable date: 10-Jun-2007 16:34:03 On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Omitted to vote myself ... +1 from me. ...ant On 8/25/07, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the 0.99 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/0.99-RC2/ http://people.apache.org/%7Eantelder/tuscany/0.99-RC2/ This includes the signed binary and source distributions, the RAT reports, and the Maven staging repository. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.99-incubating/ Many thanks, ...ant (note, the artifacts are still uploading so if it looks like something's missing please just wait a bit) -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.99-incubating RC2
Just a quick correction : I played with samples built with maven in jetty app server Should have been played with samples built using ant scripts. On 8/26/07, Luciano Resende [EMAIL PROTECTED] wrote: Below is a list of things I found while evaluating the RC2. I played with samples built with maven in jetty app server I'll give a positive vote after the maven artifact issues are addressed, as for the other issues, I guess we could document them. - Maven repo needs signing - Invalid MD5 and SHA1 signatures e.g : D:\temp\0.99-RC2\maven\org\apache\tuscany\sca\sca-api\maven-metadata.xml Generated : 2d664e0f89c8ff79e8006e8fb99ed757 compared to md5 file 897dcee76e120aeb5461219a652258bf Generated : 4DE81991FB4A4825FE337D86038CE7663F095131 compared to SHA1 594302002ec7d9a5f3656984a0380bc5805c2abc - Snapshot references modules\binding-osgi\pom.xml parent groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-modules/artifactId version0.99-incubating-SNAPSHOT/version relativePath../pom.xml/relativePath /parent dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-host-embedded/artifactId version0.99-incubating-SNAPSHOT/version /dependency - sample-helloworld-ws-sdo-webapp.war built with ant can't find SDO dependency - demo alert agregator fails when trying to update feeds to display, logs are showing date parser error Exception java.text.ParseException: Unparseable date: 10-Jun-2007 16:34:03 Exception java.text.ParseException: Unparseable date: 10-Jun-2007 16:34:03 On 8/26/07, ant elder [EMAIL PROTECTED] wrote: Omitted to vote myself ... +1 from me. ...ant On 8/25/07, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the 0.99 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/0.99-RC2/ http://people.apache.org/%7Eantelder/tuscany/0.99-RC2/ This includes the signed binary and source distributions, the RAT reports, and the Maven staging repository. The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.99-incubating/ Many thanks, ...ant (note, the artifacts are still uploading so if it looks like something's missing please just wait a bit) -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.99-incubating RC2
The maven-metadata.xml wasn't signed, but checking other projects, I realized some do and some don't, so it should be ok for us. +1 for releasing the 0.99 RC2 On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: snip - Maven repo needs signing It is isn't it? Eg: http://people.apache.org/~antelder/tuscany/0.99-RC2/maven/org/apache/tuscany/sca/sca-api/0.99-incubating/sca-api-0.99-incubating.jar.asc ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? On 8/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. [snip] Amita Vadhavkar wrote: I have not worked on the latest DAS-SCA integration so far, and am quite sure Lucinao will have good pointers in this area. But looking at the current tuscany-implementation-das, can see the following possible. Yes, I guess the idea is to: - access Data inside an SCA component declared with implementation-das - let the application developer annotate the component implementation and services with transaction policy intents to indicate what he wants in terms of transaction So take this as my attempt to understand intents/policySets and DAS-SCA integration :) DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand contains org.apache.tuscany.sca.assembly.Service dasService. Using dasService, requiredIntents on the Service can be found. There are two categories of policy intents in SCA: - implementation policy intents - used to indicate requirements of the component implementation (authorization for example, i.e. you must be authorized to execute my implementation) - interaction policy intents - used to configure how a component will interact with others (confidentiality for example, i.e. messages exchanged with my component must be encrypted) I think that the same will have to apply to transactions as well, the DAS implementation will probably have to deal with intents specified on both services and the implementation itself. org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these intents. DAS internally can configure DASConfig reflecting the intents specified , so that DAS instance construction happens with correct attributes. Based on these attributes DAS transaction control will occur (if intent is TransactionControl). Intent TransactionControl can be qualified as say, 1) Container Transaction Control, 2) DAS Transaction Control. Can you describe this a bit more to help me understand what you mean by Container transaction control vs DAS transaction control? Advantage of having intent attached to a service will be, using different intents for different services of same component. Yes, different services - different interaction policies Questions: What will be the policySets here? Say, if policySet/intent Container Transaction Control mandates that the implementation should expose getConnection() so that container Runtime can use it, how this mandate can be achieved? Not sure at all yet. A PolicySet translates an Intent to the corresponding configuration of the underlying runtime, so it really depends on what the DAS + SCA runtime will expect. [snip] On 8/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, Sorry to cut across the discussion about Transaction support in DAS, but are folks aware of the proposal for Transaction support in SCA? which leads to the entertaining question of how the DAS transaction support relates to the SCA transaction support. The problem at the moment is that the SCA spec group only has an unpublished draft of the Transaction support spec. The intention is to publish an updated draft in the near future. However, I can say that the SCA spec mechanism is based on the use of Intents to apply transactional characteristics to SCA components. I've seen several exchanges on the list already from people interested in some support for transactions... So since the spec is not ready yet, how about starting now with something really simple like an implementation policy intent that would just say: - transaction - i.e. my implementation must run as part of a transaction - noTransaction - i.e. I don't want to run as part of a transaction It may look simplistic, but will help us understand the end to end story, work on the necessary plumbing and integration with a transaction manager etc. and we can always add more later and adjust the details of the intents and policySets when the spec is ready. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TUSCANY-1343 - Resolving XSD imports inside WSDL
I was revisiting TUSCANY-1343 [1], and looks like we are still creating the URL for the imported XSD directly in the WSDLModelResolver unless the XSD import is defined as /, this would still make the scenario on TUSCANY-1343 fail. xsd:import namespace=http://priceQuoteSession; schemaLocation=PriceQuoteService_schema1.xsd/ I was wondering if a better approach would be to try to resolve the schemaLocation to a valid DeployedArtifact simmilar to the code below : DeployedArtifact proxyArtifact = contributionFactory.createDeployedArtifact(); proxyArtifact.setURI(importLocation); DeployedArtifact importedArtifact = contribution.getModelResolver().resolveModel(DeployedArtifact.class, proxyArtifact); and only try to create the URL (as we are doing today) if that can't be resolved : url = new URL(new URL(parentLocation), importLocation); I think this might help us on the TUSCANY-1343, Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-1343 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TUSCANY-1343 - Resolving XSD imports inside WSDL
So, in summary you are saying that, the scenario described in TUSCANY-1343 is invalid, and to make it valid, the schemaLocation should be set as : xsd:import namespace=http://priceQuoteSession; schemaLocation=/PriceQuoteService_schema1.xsd/ On 8/28/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, By the SCA assembly spec, if an explict resolving mechanism such as schemaLocation is present, we should honor it. To be consistent with all the existing WSDL/XSD editors/loaders, I think it's better to keep the current behavior. In the case that the uri starts '/'. You proposal sounds good to me. We can use the prxoy artifact to find the corresponding artifact in the contributions. Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, August 28, 2007 2:13 PM Subject: TUSCANY-1343 - Resolving XSD imports inside WSDL I was revisiting TUSCANY-1343 [1], and looks like we are still creating the URL for the imported XSD directly in the WSDLModelResolver unless the XSD import is defined as /, this would still make the scenario on TUSCANY-1343 fail. xsd:import namespace=http://priceQuoteSession; schemaLocation=PriceQuoteService_schema1.xsd/ I was wondering if a better approach would be to try to resolve the schemaLocation to a valid DeployedArtifact simmilar to the code below : DeployedArtifact proxyArtifact = contributionFactory.createDeployedArtifact(); proxyArtifact.setURI(importLocation); DeployedArtifact importedArtifact = contribution.getModelResolver().resolveModel(DeployedArtifact.class, proxyArtifact); and only try to create the URL (as we are doing today) if that can't be resolved : url = new URL(new URL(parentLocation), importLocation); I think this might help us on the TUSCANY-1343, Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-1343 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changes to ScriptInvoker not compatible with JDK 5, was Re: svn commit: r570495 - in /incubator/tuscany/java/sca/modules: assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/ binding-n
().getContextClassLoader(); String xqExpression = null; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Naming webapp samples *-webapp
+1 On 8/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Some of our webapp samples are missing a webapp suffix, I'm going to rename them as follows: - helloworld-jsonrpc - helloworld-jsonrpc-webapp - helloworld-dojo - helloworld-dojo-webapp - calculator-webapp-ws - calculator-ws-webapp If there's no objection I'll do that sometime tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there value in keeping download links for old releases?
A suggestion would be to have the most recent release, and the previous one, and then a link to archive that would point to the root folder of where our releases are stored. We could even just have the latest and the pointer to the archived releases. Thoughts ? On 8/29/07, haleh mahbod [EMAIL PROTECTED] wrote: I'd like to bring this message back to life. A few users posted to the ML recently and asked about M2. Immediate response has been to use the latest since M2 is very old (IMHO makes sense). This email thread was suggesting to remove the download link of very old releases to avoid confusion. We can leave the release history in place to show that there was a release, but remove the link for download to avoid confusion. If everyone agrees, when does a link get removed, in other words, how old the release should be? For starter, M2 is based on an older version of the spec. Should we remove the download link? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh I think yes we should keep them. One of the first things I look at when coming across an open source project is the release history as it gives you a good indication of how much life there is in the project. Maybe from that we don't need actual links to the download artifacts, but something clearly showing we do regular releases and have been doing so for years is a Good Thing IMHO. Another reason is if someone is debugging some old system with a back level release they may need access to the source distro to debug the code. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Renaming DAS samples
Amita wrote: We can rename sample-ajax-das to ''Advanced DAS Web Sample, any better name? +1, so this would make it advancedweb - Advanced DAS Web Sample Also, I'd like to take the opportunity and rename our samples to the same naming convention being used in SCA, so we would have it like : companyweb -- company-webapp advancedweb -- advanced-webapp -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Some issues trying to bringup the Interop-Soap iTests
I'm trying to bring up our soap interop tests under /java/sca/itest/interop-soap-*, and looks like we have two issues that I'm going to try to describe below : One, probably not so important and looks like behaving like this for a long time, is related to SDO databinding, where it looks like XSD2Java is not using the same order to generate the related types when an element and complexType have the same name. Looks like sometimes it uses Element-class, Type-class1, and other times it generates Element-class1, Type-class, and you will see generated java files like this : public org.soapinterop.SimpleDocument1 SimpleDocument( org.soapinterop.SimpleDocument1 simpleDocument) ; public org.soapinterop.ComplexDocument ComplexDocument( org.soapinterop.ComplexDocument complexDocument) ; Another issue that I noticed wrong generation of method signatures, where we are generating : public org.soapinterop.SimpleDocumentResponse SimpleDocument( org.soapinterop.SimpleDocument1 simpleDocument) ; instead of : public org.soapinterop.SimpleDocument1 SimpleDocument( org.soapinterop.SimpleDocument1 simpleDocument) ; This might be related to TUSCANY-1142, I'll keep investigating the issue above, but if anyone have some suggestions, please let me know. Note that, for the issues above, the WSDL used as reference can be found at [1] [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/interop-soap-client/src/main/resources/wsdl/interopdoc.wsdl -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build failure in binding-echo-extension
I'm seeing the following issue under revision #572386 [INFO] Compilation failure D:\dev\Opensource\Apache\Tuscany\source\java\sca\samples\binding-echo-extension\src\main\java\echo\impl\EchoBindingProcessor.java:[51,12] cannot find symbol symbol : class PolicyAttachPointProcessor location: class echo.impl.EchoBindingProcessor D:\dev\Opensource\Apache\Tuscany\source\java\sca\samples\binding-echo-extension\src\main\java\echo\impl\EchoBindingProcessor.java:[55,35] cannot find symbol symbol : class PolicyAttachPointProcessor location: class echo.impl.EchoBindingProcessor -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
Great, so looks like we would need a DAS release compatible with SDO 1.0 in order to include any SCA/DAS integration in the SCA 1.0 release. I'll try to get that done, by cutting a branch and working on a DAS release sometime this week. Please let me know if there is any changes in plan. On 8/28/07, kelvin goodson [EMAIL PROTECTED] wrote: There are no plans in place yet for the next SDO release. 1.0-incubating would seem the obvious choice. Kelvin. On 28/08/07, ant elder [EMAIL PROTECTED] wrote: That would be my guess unless there's a newer SDO release by then but i've not seen any mention of that in the SDO emails. ...ant On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: What are you guys thinking about SDO requirements for SCA 1.0 release ? SDO 1.0-incubating ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Aug 27, 2007 2:58 AM Subject: Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release? To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED] On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the XQuery sample in the next release?
Can't we publish it in maven ourselves or with help from the maven team ? does that violates the licensing ? On 9/3/07, Raymond Feng [EMAIL PROTECTED] wrote: If SAXON 8.9 is required, I can write an ant script to download SAXON 8.9 and install the jars into the local maven repo as part of the build. We already do that for the DOJO stuff. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, September 03, 2007 10:36 AM Subject: Re: Including the XQuery sample in the next release? Vasil Vasilev wrote: Hi, Isn't in the official repository some older version of Saxon. May be we could try to run the prototype with this older version. Bye, Vasil If the Saxon project really doesn't want to publish newer JARs then I guess we're going to have to use the 8.7 version already on ibiblio.org. In the longer term, this also gives us a good opportunity to think about making XQuery processor implementations pluggable, as you already suggested :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Removing @deprecated artifacts from Contribution related modules
Contribution modules have couple of @deprecated artifacts today, such as ContributionPostProcessor and ContributionMetadataDocumentProcessor interfaces. As preparation for SCA 1.0 release, I'd like to remove these classes. If nobody have objections, I'll take care of it in the next couple days. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Changes from Tuscany-1466, was Re: svn commit: r572735 - in /incubator/tuscany/java/das/rdb/src: main/java/org/apache/tuscany/das/rdb/ main/java/org/apache/tuscany/das/rdb/impl/ test/java/org/ap
/ + /ConnectionInfo + + Command name=SelectEmployeesFromDepartment1 + SQL=select * from DEPARTMENTS left outer join EMPLOYEES on DEPARTMENTS.ID = EMPLOYEES.DEPARTMENTID where DEPARTMENTS.ID = 1 + kind=Select/ + Command name=SelectEmployeesFromDepartment2 + SQL=select * from DEPARTMENTS left outer join EMPLOYEES on DEPARTMENTS.ID = EMPLOYEES.DEPARTMENTID where DEPARTMENTS.ID = 2 + kind=Select/ + + Relationship name=employed primaryKeyTable=DEPARTMENTS foreignKeyTable=EMPLOYEES many=true + KeyPair primaryKeyColumn=ID foreignKeyColumn=DEPARTMENTID / + /Relationship +/Config Added: incubator/tuscany/java/das/rdb/src/test/resources/extTxnIntConnectionRollback.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/das/rdb/src/test/resources/extTxnIntConnectionRollback.xml?rev=572735view=auto == --- incubator/tuscany/java/das/rdb/src/test/resources/extTxnIntConnectionRollback.xml (added) +++ incubator/tuscany/java/das/rdb/src/test/resources/extTxnIntConnectionRollback.xml Tue Sep 4 09:50:19 2007 @@ -0,0 +1,34 @@ +?xml version=1.0 encoding=ASCII? +!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + License); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + -- +Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd; + ConnectionInfo managedtx=false + ConnectionProperties + driverClass=org.apache.derby.jdbc.EmbeddedDriver + databaseURL=jdbc:derby:target/dastest; create = true + loginTimeout=60/ + /ConnectionInfo + + Command name=SelectBalanceFromAccount1 + SQL=select * from BANKACCOUNT where SSN = 564026354 and ID=1 + kind=Select/ + Command name=SelectBalanceFromAccount2 + SQL=select * from BANKACCOUNT where SSN = 564026354 and ID=2 + kind=Select/ +/Config - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapper style test in WSDL processing?
Note that we have a similar issue that I'm looking at under the wsdl2java tooling, described in this post [1] [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html On 9/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Laws wrote: I've done a bit more investigation now. For the signature String foo() Axis2 Java2WSDL generates wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; attributeFormDefault=qualified elementFormDefault=qualified targetNamespace=http://test/xsd; xs:element name=fooResponse xs:complexType xs:sequence xs:element name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=fooMessage / wsdl:message name=fooResponseMessage wsdl:part name=part1 element=ns:fooResponse / /wsdl:message I'm trying to understand the overall picture before choosing a side: - tolerate what Axis2 generates in our isWrapped() algorithm? - or fix the WSDL after it's generated by Axis2? I have the following two questions: 1) Is it true that the above WSDL has no chance to work at all as it doesn't allow the foo operation to be sent at all (since there is no foo element to carry it)? 2) Could you please paste the entire WSDL? including the generated binding and service+port? I believe that it'll help answer question (1). Thanks OK, looks like the answer to your question was already in your post, I should have read it better. In this case, it works with SOAP action. I think it's better to tolerate that (incorrect) behavior from Axis2 for now, as: (a) I don't think we'll be able to patch all WSDLs that may be generated by users with the Axis2 tools out of our control (b) this is a workaround anyway, and a tolerating workaround is not worse than a patching workaround, actually it is probably better as it won't introduce any other side effects I also think that we need to open an Axis2 JIRA to report and track this bug. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapper style test in WSDL processing?
In the case I'm investigating, the issue is around checking if the wrapper style is in use for the wsdl, but the problem is that wsdl2java generates wrong interfaces for the wsdl in question. On 9/5/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Note that we have a similar issue that I'm looking at under the wsdl2java tooling, described in this post [1] [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html On 9/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Laws wrote: I've done a bit more investigation now. For the signature String foo() Axis2 Java2WSDL generates wsdl:types xs:schema xmlns:xs= http://www.w3.org/2001/XMLSchema; attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://test/xsd; xs:element name=fooResponse xs:complexType xs:sequence xs:element name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=fooMessage / wsdl:message name=fooResponseMessage wsdl:part name=part1 element=ns:fooResponse / /wsdl:message I'm trying to understand the overall picture before choosing a side: - tolerate what Axis2 generates in our isWrapped() algorithm? - or fix the WSDL after it's generated by Axis2? I have the following two questions: 1) Is it true that the above WSDL has no chance to work at all as it doesn't allow the foo operation to be sent at all (since there is no foo element to carry it)? 2) Could you please paste the entire WSDL? including the generated binding and service+port? I believe that it'll help answer question (1). Thanks OK, looks like the answer to your question was already in your post, I should have read it better. In this case, it works with SOAP action. I think it's better to tolerate that (incorrect) behavior from Axis2 for now, as: (a) I don't think we'll be able to patch all WSDLs that may be generated by users with the Axis2 tools out of our control (b) this is a workaround anyway, and a tolerating workaround is not worse than a patching workaround, actually it is probably better as it won't introduce any other side effects I also think that we need to open an Axis2 JIRA to report and track this bug. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] So several points coming out here. Let me try and catch them (in no particular order) Issue1 - we have more than one piece of code in Tuscany that generates WSDL (using underlying Axis2 tools but possibly in different ways) Solution Do WSDL generation in one place. Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of wrapped which we have set out to support Solution1 get Axis to fix it Solution2 (stop gap) post process the generated WSDL to correct it for Tuscany Issue3 - Service providers and consumer outside of Tuscany may generate broken WSDL and reasonably expect their messages to work with Tuscany Solution There is a fix available to make inbound Axis2 processing lax to the extent that it handlse Axis2 version of a null parameter operation A fix is required for void return values It sounds like We could address Issue1 if it's possible - need Luciano/Ant to say if this is possible and/or worth it We should address Issue2 Solution 1 - well get it moving at least We could address Issue2 Solution2 - I quite like the idea of producing the correct WSDL as we see it but there is concern that we don't know if it we will break someone who relies on the WSDL the way axis produces it. This makes the assumption that it works for more people in its current form that it does in it's fixed up form. Which in turn is based on people being happy using Axis2. Warrants a bit of investigation. We should address Issue3 Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com
Re: Removing @deprecated artifacts from Contribution related modules
Done under revision #573040 On 9/3/07, Luciano Resende [EMAIL PROTECTED] wrote: Contribution modules have couple of @deprecated artifacts today, such as ContributionPostProcessor and ContributionMetadataDocumentProcessor interfaces. As preparation for SCA 1.0 release, I'd like to remove these classes. If nobody have objections, I'll take care of it in the next couple days. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] What's next for Tuscany DAS ?
Good, looks like we have most (if not all) the updates necessary to support SDO 2.1 specification and to be compatible with SDO 1.0 release. I'd like to start to work on a new release in the next couple days, and if we make it on time, we could still have a chance to include DAS in the SCA 1.0 release (planned for middle of September). As for naming, I was thinking to make this a beta2 release. Thoughts ? On 8/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: I have attached patch for TUSCANY-961+ TUSCANY-986 combined in TUSCANY-961. One observation here - Generated code shows usage of deprecated method FactoryBase.getProperty(Type, int) and needs to be replaced by getLocalProperty(), any changes needed in xsdtojava generator in SDO? Any suggestions? Regards, Amita On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the XQuery sample in the next release?
Here is some info around how to publish artifacts to maven repo... http://maven.apache.org/guides/mini/guide-central-repository-upload.html On 9/3/07, Luciano Resende [EMAIL PROTECTED] wrote: Can't we publish it in maven ourselves or with help from the maven team ? does that violates the licensing ? On 9/3/07, Raymond Feng [EMAIL PROTECTED] wrote: If SAXON 8.9 is required, I can write an ant script to download SAXON 8.9 and install the jars into the local maven repo as part of the build. We already do that for the DOJO stuff. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, September 03, 2007 10:36 AM Subject: Re: Including the XQuery sample in the next release? Vasil Vasilev wrote: Hi, Isn't in the official repository some older version of Saxon. May be we could try to run the prototype with this older version. Bye, Vasil If the Saxon project really doesn't want to publish newer JARs then I guess we're going to have to use the 8.7 version already on ibiblio.org. In the longer term, this also gives us a good opportunity to think about making XQuery processor implementations pluggable, as you already suggested :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remove hardcoded BASE_URI from Axis2ServiceProvider
On 9/7/07, Simon Nash [EMAIL PROTECTED] wrote: I'm a bit concerned with this default as it would cause conflicts if I have a Web app server active on port 8080 while I'm running a test that uses either of these environments. Yes, using 8080 would conflict with existing web app servers running locally and on the build environment. So I'd prefer some different default, like 8085 Is there any problem with changing this default setting for our embedded ServletHost from 8080 to 8085? This should allow all the existing tests to continue to run without change. If they don't run with this setup, I'd like to understand why. Simon ant elder wrote: Right now that would be down to the ServletHost impl that you use, currently our Jetty and Tomcat ServletHost impls both have port 8080 as the default. ...ant On 9/7/07, Simon Nash [EMAIL PROTECTED] wrote: What is the default for the environment? For a webapp deployment this seems meaningful, but I'm not sure what this would be for host-embedded with http-jetty or http-tomcat. Simon ant elder wrote: I'd like to remove the hard coded BASE_URI constant from the Axis2 WS binding Axis2ServiceProvider so that the default for the environment is used instead of always using port 8085 unless its explicitly stated in the binding uri. Can anyone see any problems with doing this? A quick try shows removing it makes some of the distributed and callback tests fail, asking here before i debug in case someone knows reasons why its required. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Changes from Tuscany-1466, was Re: svn commit: r572735 - in /incubator/tuscany/java/das/rdb/src: main/java/org/apache/tuscany/das/rdb/ main/java/org/apache/tuscany/das/rdb/impl/ test/java/or
Great, I think the wiki page will be very helpful. There is no need
for a web sample... I'll have to double check the license of the code
in your patch before committing it.
On 9/7/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
JIRA-1665 is there with a sample patch. Please see
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22828.html
and the readme.htm from patch for rest of the details.
In summary, DAS works well when connection is passed from caller and txn is
managed
by caller. I am trying to put a new wiki page for DAS Transaction support.
Please advise if there is a need of web sample or JIRA-1665 will suffice.
Regards,
Amita
On 9/4/07, Luciano Resende [EMAIL PROTECTED] wrote:
I don't think it's a good idea to expose the Connection trough DAS API
as I already mentioned in previous discussions. First, in a managed
environment, there is no need for DAS to expose the connection, as
there is transaction manager handling the transactions and JDBC knows
how to participate on them. Also, exposing the Connection on the DAS
API also makes it RDB centric, and I would like to avoid it.
Amita is doing some tests with a real managed transaction env (using
JOTM and Tomcat) and I'd like to hold any changes on this area untill
she comes up with concrete results from the proper env.So, could you
please revert these changes until we hear back from Amita.
Thanks, and sorry for the inconvenience.
On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: adrianocrestani
Date: Tue Sep 4 09:50:19 2007
New Revision: 572735
URL: http://svn.apache.org/viewvc?rev=572735view=rev
Log:
applying patch from JIRA-1466
Added:
incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/data/BankAccountData.java
incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/data/DepartmentsData.java
incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/data/EmployeesData.java
incubator/tuscany/java/das/rdb/src/test/resources/extTxWithExtConnection.xml
incubator/tuscany/java/das/rdb/src/test/resources/extTxWithIntConnection.xml
incubator/tuscany/java/das/rdb/src/test/resources/extTxnIntConnectionRollback.xml
Modified:
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/DAS.java
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/impl/DASImpl.java
incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/TransactionTests.java
incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/framework/DatabaseSetup.java
Modified:
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/DAS.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/DAS.java?rev=572735r1=572734r2=572735view=diff
==
---
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/DAS.java
(original)
+++
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/DAS.java
Tue Sep 4 09:50:19 2007
@@ -18,6 +18,8 @@
*/
package org.apache.tuscany.das.rdb;
+import java.sql.Connection;
+
import org.apache.tuscany.das.rdb.impl.DASFactoryImpl;
import commonj.sdo.DataObject;
@@ -64,4 +66,9 @@
*/
Command createCommand(String sql);
+/**
+ * Make connection available for user to control transaction
externally
+ * @return
+ */
+Connection getConnection();
}
Modified:
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/impl/DASImpl.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/impl/DASImpl.java?rev=572735r1=572734r2=572735view=diff
==
---
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/impl/DASImpl.java
(original)
+++
incubator/tuscany/java/das/rdb/src/main/java/org/apache/tuscany/das/rdb/impl/DASImpl.java
Tue Sep 4 09:50:19 2007
@@ -87,8 +87,7 @@
throw new RuntimeException(Invalid kind of command:
+ kind);
}
-}
-
+}
}
public DASImpl(Config inConfig, Connection inConnection) {
@@ -111,7 +110,7 @@
* @see
org.apache.tuscany.das.rdb.CommandGroup#getApplyChangesCommand()
*/
public ApplyChangesCommandImpl getApplyChangesCommand() {
-ApplyChangesCommandImpl cmd = new
ApplyChangesCommandImpl(configWrapper, getConnection());
+ApplyChangesCommandImpl cmd = new
ApplyChangesCommandImpl(configWrapper, getConnectionFromConfig());
return cmd;
}
@@ -125,7
Re: SCA build with an empty local maven repository only works with maven 2.0.5 not 2.0.6 or 2.0.7
Here is the explanation for the issue we are having : http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20844.html On 9/7/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/7/07, ant elder [EMAIL PROTECTED] wrote: Right now the SCA build with an empty local maven repository only works with Maven 2.0.5 not with Maven 2.0.6 or 2.0.7. I've raised TUSCANY-1676 for this, we've talked before about fixing this for 1.0 but not sure if we've time now so i've set the Fix level to Java-SCA-Next, please say if you think it needs to get done for 1.0. ...ant Is it just me or is it particulaly bad at the moment? I've been having the usual odd things happening with increasing frequency and I'm on 2.0.5. . Did someone suggest a specific fix other than going back to earlier versions. Looking back through the mail list I can't see it. If it gets much wors for me then I'm going to have to investgate. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Base interface
Any particular reason for us to have two copies of Base ? import org.apache.tuscany.sca.assembly.Base; import org.apache.tuscany.sca.interfacedef.Base; They seem identical, and making the change in interface-wsdl to use the Base class from assembly seems to cause no harm and the module seems to compile ok. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Base interface
I just changed the import and compiled the module with mvn clean install, no erros... but i didn't do a full build... i can try that later on... On 9/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Any particular reason for us to have two copies of Base ? import org.apache.tuscany.sca.assembly.Base; import org.apache.tuscany.sca.interfacedef.Base; They seem identical, and making the change in interface-wsdl to use the Base class from assembly seems to cause no harm and the module seems to compile ok. How are you changing the module dependencies for this to compile? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What's new with Apache Tuscany Data Access Services
I have posted this entry in my blog, but i guess it's a worthwhile reading for the DAS users on this community. http://lresende.blogspot.com/2007/09/whats-new-with-apache-tuscany-data.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Das beta2 stable distributions
I have posted stable distributions in preparation for DAS beta2 release [1]. I still have to fix-up the release notes, but it would be great if people could take a quick look on these distributions and provide some feedback. [1] http://people.apache.org/~lresende/tuscany/das-beta2-distribution/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA-1673 and SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
We have found an issue on the SDO Tools, described in JIRA-1673 [1] that is affecting the proper generation of java interfaces from a given wsdl. What's the plan to get this fix, when available, in SCA 1.0 release ? This might require a new SDO release ? [1] http://issues.apache.org/jira/browse/TUSCANY-1673 On 9/3/07, Luciano Resende [EMAIL PROTECTED] wrote: Great, so looks like we would need a DAS release compatible with SDO 1.0 in order to include any SCA/DAS integration in the SCA 1.0 release. I'll try to get that done, by cutting a branch and working on a DAS release sometime this week. Please let me know if there is any changes in plan. On 8/28/07, kelvin goodson [EMAIL PROTECTED] wrote: There are no plans in place yet for the next SDO release. 1.0-incubating would seem the obvious choice. Kelvin. On 28/08/07, ant elder [EMAIL PROTECTED] wrote: That would be my guess unless there's a newer SDO release by then but i've not seen any mention of that in the SDO emails. ...ant On 8/27/07, Luciano Resende [EMAIL PROTECTED] wrote: What are you guys thinking about SDO requirements for SCA 1.0 release ? SDO 1.0-incubating ? -- Forwarded message -- From: Simon Laws [EMAIL PROTECTED] Date: Aug 27, 2007 2:58 AM Subject: Re: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release? To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED] On 8/27/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. This seems like a really good idea to me. The 0.99 release has again shown that it always takes at least a couple of RCs to discover and resolve regressions caused by last minute changes and to polish up the samples, and for 1.0 we're all likely to be a bit more pedantic about readme and sample problems. How about aiming for a 1.0 branch and RC1 around the 14th of September? That gives 3 weeks from now for getting things ready and then two weeks which should enough for 2 or 3 RCs and voting and still get a 1.0in September. I've created a 1.0 JIRA version and started moving into there JIRAs i'd like to try to get done for 1.0 : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310210fixfor=12312698 One thing that would be good to do now while they're fresh in our minds is for people to commit fixes to trunk for all the sample and readme issues they reported in the 0.99 review so they don't get forgotten till 1.0review. ...ant +1 from me. I think we are going to need the extra time to fix the many small things we found this time round. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for 1.0 release, was: Release management for next release, was: SCA 0.92 release?
Couldn't say better about Ant as Release Manager, here is my +1 On 9/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Ant has been doing a great job as Release Manager for several releases. I'd like to nominate him as Release Manager for release 1.0, as it's going to be a pretty important milestone release for the project, and I'm sure he'll make it a successful release again! Thoughts? [snip] ant elder wrote: Taking the branch on the 14th and making an RC1 on the 14th is possible, just the RC is likely to be a little rough as there won't be much time at all to do checking. But as we're talking about RC1 not expected to be _the_ RC then i guess that could be fine. ...ant -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle business exceptions not easily serializable to XML
Are you talking about the same issue described in TUSCANY-1558 [1] ? If so, looks like the issue is fixed in Axis 2.1.3. [1] https://issues.apache.org/jira/browse/TUSCANY-1558 On 9/11/07, Scott Kurz [EMAIL PROTECTED] wrote: There are some particular issues relating to dealing with, alternately the exception DataType and the fault DataType, and getting these through the Tuscany databinding framework. Some of these I've worked around already and am working to post a more detailed update myself (for example I modified DataTransformationInterceptor to match element names of XMLType fault logicals rather than using an equals() comparison). Scott On 9/11/07, Simon Nash [EMAIL PROTECTED] wrote: Yes, I think this should work. I'm trying to get a simple case through the Web Service binding and the databinding transformers at the moment and I'm running into various issues. I'll post a more detailed update later. Simon Scott Kurz wrote: Say I wanted to have a remotable Java interface with a method like: int myMethod() throws java.sql.SQLException; Should I be able to throw this exception, say, across the web service binding? I don't see why not.JAX-WS Sec 3.7 describes how to build a fault bean out of an exception like SQLException which doesn't conform to the pattern in JAX-WS Sec 2.5. A tool like wsgen should be able to generate a WSDL with a corresponding fault element, typed by the default mapping obtained by viewing SQLException as a JavaBean (Sec 3.7) per JAXB. (For a complicated data type the default JAXB mapping isn't enough without annotations, but for simpler examples it might be OK.) Do we view this as a valid remote interface? I'm not asking whether it works today.. just whether it seems like it should work. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: is this a dead link on Tuscany wiki? Manual+Copy+Of+The+Tuscany+Website
This was a copy of the website wiki when we separated the Website from the public wiki. This copy, AFAIK, has not been updated, and is totally separate from the current website. And I believe nobody is using it. So, should I remove it ? On 9/11/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, Is http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Manual+Copy+Of+The+Tuscany+Website used any more? Would updates to this get replicated to the website? Haleh -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
Completely +1 for both proposals, as Simon Nash said, I'd like to see Tuscany graduate from the incubator, and I think we're ready to take this step. On 9/12/07, Raymond Feng [EMAIL PROTECTED] wrote: Finally :-). +1 on both proposals. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, September 11, 2007 4:50 PM Subject: Graduation So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for OSGi bundle contributions
Some comments online... On 9/12/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, Graham and I have been looking at supporting OSGi bundles as contributions in Tuscany. This is the packaging of SCA contributions as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). Unfortunately in the current Tuscany implementation, there doesn't seem to be a neat way of plugging in support for OSGi contributions. While implementation.osgi/ is a completely independent module, support for OSGi contributions would require changes to other processors. I would like to add a new module modules/contribution-osgi which provides all the code needed for supporting OSGi contribution bundles. But the code will have to be explicitly invoked from outside this module. OSGi bundles are jar files. Since there is only one processor for each contribution file type, the Jar processor will have to call OSGi bundle processor to do any special processing for OSGi bundles - the OSGi bundle processor installs the bundle into an OSGi runtime (starting a new runtime if necessary). So, isn't this the case where you could identify that the jar being processed is a OSGI bundle, and call a OSGI processor directly, instead of making the jar processor delegating ? Since class resolution for OSGi bundles should be done using OSGi resolution mechanisms rather than directly using a classloader, and there is only one resolver called by ExtensibleModelResolver for each model type, ClassReferenceModelResolver will need to call OSGiClassReferenceModelResolver to load the class using the OSGi bundle if the contribution is an OSGi bundle. Maybe we need to extend the packageProcessor to influence more what type of resolution and loading mechanisms to be used The changes to JarContributionProcessor and ClassReferenceModelResolver are fairly minimal - in both cases they try to dynamically load the corresponding OSGi processor and call a method on it. All the OSGi specific code is in modules/contribution-osgi. A better solution would have been to allow multiple processors for each contribution file type and multiple resolvers for each model type, where they are called in some order until the processing is complete. But that would require more extensive changes to Tuscany. I'll wait to see a patch to better comment on your proposal. I would like your feedback on the approach to follow, and would also like to know if I should wait till 1.0 is released before submitting a patch. Thank you... Regards, Rajini -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: use of datasource
Right now, you can either consider the data-source an implementation detail of your component, and initialize it as you would in a regular application, or you could use other aproaches, like what we have in implementation.das and implementation.data, where you can define it together with your component definition : component name=DASServiceComponent tuscany:implementation.das config=/CompanyConfig.xml dataAccessType=rdb tuscany:connectionInfo dataSource=java:comp/env/jdbc/dastest/ /tuscany:implementation.das /component In this case, DAS will take care of initializing the data-sources and you could use DAS to access your RDB data. Please let me know if you have more questions. On 9/12/07, mayank sharma [EMAIL PROTECTED] wrote: hi, How can we use datasources in SCA? I mean how can we create and initialise data-sources in SCA and use them. Regards Mayank Sharma -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some issues trying to bringup the Interop-Soap iTests
I'm still having some issues trying to bring-up the Interop-soap iTests, and the current one might be related to TUSCANY-1686. So I'm going to wait for Simon's patch and re-evaluate these iTests. On 9/3/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to bring up our soap interop tests under /java/sca/itest/interop-soap-*, and looks like we have two issues that I'm going to try to describe below : One, probably not so important and looks like behaving like this for a long time, is related to SDO databinding, where it looks like XSD2Java is not using the same order to generate the related types when an element and complexType have the same name. Looks like sometimes it uses Element-class, Type-class1, and other times it generates Element-class1, Type-class, and you will see generated java files like this : public org.soapinterop.SimpleDocument1 SimpleDocument( org.soapinterop.SimpleDocument1 simpleDocument) ; public org.soapinterop.ComplexDocument ComplexDocument( org.soapinterop.ComplexDocument complexDocument) ; Another issue that I noticed wrong generation of method signatures, where we are generating : public org.soapinterop.SimpleDocumentResponse SimpleDocument( org.soapinterop.SimpleDocument1 simpleDocument) ; instead of : public org.soapinterop.SimpleDocument1 SimpleDocument( org.soapinterop.SimpleDocument1 simpleDocument) ; This might be related to TUSCANY-1142, I'll keep investigating the issue above, but if anyone have some suggestions, please let me know. Note that, for the issues above, the WSDL used as reference can be found at [1] [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/interop-soap-client/src/main/resources/wsdl/interopdoc.wsdl -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
Hey, very good, some comments inline One question that I have is regarding the Transaction Manager, who is responsible for creating the transaction manager ? The SCA runtime, or implementations ? In the case of SCA runtime, we need to investigate that part, but I guess we can start by having it under the implementation as a proof of concept for now. On 9/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have given this a try based on what I tried in JIRA-1665 (Sample Using JOTM with DAS) Here also I am using JOTM with SCA+DAS. Currently played with 2 simple intents: I think we are going to use geronimo transaction manager with SCA integration, and there is a sample on implementation.bepel on how to use it, it's very simple, could you try using that one ? a transaction (Tx management from External TM), b noTransaction (Tx management from DAS) The only changes needed are as below:- A tuscany-data-engine-helper:- 1)DataAccessEngineManager new method getDAS(String config, ConnectionInfo connectionInfo, ListIntent intents, ListPolicySet policySets) Here if intent atransaction is detected, ConnectionInfo.setManagedTx(false) will be called. This modified connnectionInfo will be passed through configHelper to the new DAS instance. This way if external TM is going to manage Tx, DAS is signaled for it. Great... I'll leave comments on the policy side to Venkat or Sebastien or others that have been playing on this area... And logic to support this method 2) ConnectionInfo new attribute managedtx with setter/getter Ok B tuscany-implementation-das 1) DASImplementation implements PolicyAttachPoint 2) DASImplementationProcessor read(reader) - will read policies and intents on DASImplementation from .composite Who should read here, implementation.das or we should delegate to the policy artifact processors ? 3) DASImplementationProvider createInvoker() will call getDAS(passing config, connectioninfo, intents, policies) same will be for createCallbackInvoker() What other information you will need from intents and policies when creating DAS ? you already passed the managed transaction flag inside the connectionInfo, right ? Note that there is still support for a das config file, how are you going to manage that ? We probably need to throw an exception if DAS config file sets does NOT set the managed transaction flag, but transaction policy is set. With these above changes and with setup similar to JIRA-1665 sample, I could see that the external connection is being used by DAS (naming service is resolving datasource properly). The point I am stuck at is, in RDB-DAS, when we use external DS, we do not pass userName, password. But MYSQL (which with InnoDB supports Txn and works well with JOTM) does need id, pwd in ds.getConnection(). This can be case with other DBs as well. So, it looks like DAS config.xsd needs to allow passing userName, password in ConnectionInfo too ( and not just for ConnectionProperties). Thus below will be the changed DAS config portion:- xsd:complexType name=ConnectionInfo xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=ConnectionProperties type=config:ConnectionProperties/ /xsd:sequence xsd:attribute name=dataSource type=xsd:string/ xsd:attribute name=managedtx type=xsd:boolean default=true/ xsd:attribute name=userName type=xsd:string default=/ xsd:attribute name=password type=xsd:string default=/ /xsd:complexType xsd:complexType name=ConnectionProperties xsd:attribute name=driverClass type=xsd:string/ xsd:attribute name=databaseURL type=xsd:string/ xsd:attribute name=loginTimeout type=xsd:int default=0/ /xsd:complexType Create a DAS jira for this, and we can investigate further... Suggestion? If this looks OK, I would like to make the above changes and create a sample in tuscany-implementation-das demoing use of intent and ext TM. I have a demo in progress, probably is good to have a test case for now, and we could incorporate transaction support on the demo. Will give a try with geronimo as well. Regards, Amita On 9/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Luciano Resende wrote: I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? Two suggestions: - in a standalone environment, use JOTM [1] - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo plugin at [2] [1] http://jotm.objectweb.org/ [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany -- Jean-Sebastien
EchoBinding sample extension failing with NPE in isPolicySetApplicable
Looks like the CompositeWireBuilder is getting a NPE in isPolicySetApplicable due to bindingType is not set. I have added a check to see if bindingType is null (svn revision #575419), and in that case, isPolicySetApplicable will return false to this scenario. Could someone review this issue to see if we have a bigger issue of not properly populating the bindingType ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with policy/binding-ws-axis2/IBM JDK
The validation warnings might be related to Sebastien's latest changes to validate the composite files (revision #575532 : Fix for TUSCANY-1276, validate SCA assembly XML files against the SCA XML schemas when we load them.) On 9/14/07, Simon Laws [EMAIL PROTECTED] wrote: My build is failing the binding-ws-axis2 tests WSSecurityConfidentialityTestCase.java WSSecurityIntegrityTestCase.java I pinged Venkat to find out what the state of play is here and he is working this as he had already noticed the issue which apparently is something to do with using an IBM JDK (i'll let Venkat raise a JIRA is that's necessary) On the latest version from svn I'm getting lots of warnings from binding-ws-axis along the lines of 14-Sep-2007 08:51:22 org.apache.tuscany.sca.contribution.processor.ValidatingXML StreamReader$1 error WARNING: cvc-complex-type.4: Attribute 'targetNamespace' must appear on element 'composite'. Doesn't make tests fail. Is this just me? Anyone know why these are appearing now? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EchoBinding sample extension failing with NPE in isPolicySetApplicable
Shouldn't this be more like a compilation error typed by interfaces, instead of a NPE ? On 9/14/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Sorry.. should have mentioned 'bindings that implement PolicySetAttachPoint'. On 9/14/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Luciano. I'd view that bindings must implement the 'getType' method. I'll go and fix the echo-binding-extension for this. - Venkat On 9/14/07, Luciano Resende [EMAIL PROTECTED] wrote: Looks like the CompositeWireBuilder is getting a NPE in isPolicySetApplicable due to bindingType is not set. I have added a check to see if bindingType is null (svn revision #575419), and in that case, isPolicySetApplicable will return false to this scenario. Could someone review this issue to see if we have a bigger issue of not properly populating the bindingType ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCA WS-BPEL - Initial support available
This is a quick note to let the community know that I managed to get initial WS-BPEL component implementation ready just in time for our SCA 1.0 release. As described in [1] and [2], we can now invoke executables WS-BPEL process from an SCA runtime. As for a WS-BPEL engine, we are using Apache ODE [3][4].The current implementation.bpel is available in trunk at [5] and you can see a simple helloWorld BPEL process being invoked. I'm working on a new sample to better demonstrate the usage of this new component type, I'll also look into references as well. I'd also like to Thank all the help from the ODE community, especially Matthieu Riou. [1] http://osoa.org/display/Main/SCA+BPEL+White+Paper [2] http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1 [3] http://ode.apache.org [4] http://www.infoq.com/articles/paul-brown-ode [5] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build issue with implementation-bpel module
Hey Ray
This seems something with surefire, not sure exactly what yet
I'll get back to this in the morning...
On 9/15/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I ran into an issue in the implementation-bpel module from the top-down
build. The error message is as follows. But if I run the build for the
module only, everything works fine.
Any clue?
Thanks,
Raymond
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
C:\Tuscany\java\sca\modules\implementation-bp
el\target\test-classes
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact: org.apache.ode:ode-dao-jpa-ojpa-derby:1.1:zip
[INFO] Expanding: C:\Documents and
Settings\Administrator\.m2\repository\org\apa
che\ode\ode-dao-jpa-ojpa-derby\1.1\ode-dao-jpa-ojpa-derby-1.1.zip into
C:\Tuscan
y\java\sca\modules\implementation-bpel\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\Tuscany\java\sca\modules\implementation-bpe
l\target\surefire-reports
[INFO] Building jar:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\surefirebooter57948.jar
java.net.MalformedURLException: unknown protocol: c
at java.net.URL.init(URL.java:608)
at java.net.URL.init(URL.java:498)
at
sun.misc.URLClassPath$JarLoader.parseClassPath(URLClassPath.java:1118
)
at
sun.misc.URLClassPath$JarLoader.getClassPath(URLClassPath.java:1091)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:476)
at sun.misc.URLClassPath.getResource(URLClassPath.java:322)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:960)
at
java.security.AccessController.doPrivileged(AccessController.java:275
)
at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
at java.lang.ClassLoader.loadClass(ClassLoader.java:607)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:327)
at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
The java class is not found:
org.apache.maven.surefire.booter.SurefireBooter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build issue with implementation-bpel module (related to OPENJPA-256)
Let me try to give a little background here. Initially I was having
the same issue as the one described in OPENJPA-256 [1] and to
workaround the issue, we started configuring surefire to use System
Class loader. Looks like this solves the problem building the module
itself, but building the parent module give us some errors as
described in this thread [2].
So, this raises couple questions
- Any workaround or help for this issue, so we can get this BPEL SCA
integration in our SCA 1.0 release (this needs to happen very soon, as
we are targeting to cut a new RC tomorrow)
- Have ODE moved to JPA JPA 1.0 on it's latest trunk code ? If not,
any plans ? I tried to use the ODE 1.1 with JPA 1.0 but I was running
into some issues...
Well, any help is appreciated...
[1] http://issues.apache.org/jira/browse/OPENJPA-256
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg23439.html
On 9/16/07, ant elder [EMAIL PROTECTED] wrote:
I'm get a similar build failure related to surefire in the 1.0 branch:
[INFO] Configured Artifact: org.apache.ode:ode-dao-jpa-ojpa-derby:1.1:zip
[INFO] Expanding: C:\Documents and
Settings\Administrator\.m2\repository\org\apache\ode\ode-dao-jpa-ojpa-derby\1.1\ode-dao-jpa-ojpa-derby-1.
1.zip into
C:\Tuscany\SVN\1.0-BRN\modules\implementation-bpel\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\Tuscany\SVN\1.0-BRN\modules\implementation-bpel\target\surefire-reports
[INFO] Building jar:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\surefirebooter15021.jar
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/booter/SurefireBooter
Exception in thread main
[INFO]
[ERROR] BUILD FAILURE
...ant
On 9/16/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I ran into an issue in the implementation-bpel module from the top-down
build. The error message is as follows. But if I run the build for the
module only, everything works fine.
Any clue?
Thanks,
Raymond
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
C:\Tuscany\java\sca\modules\implementation-bp
el\target\test-classes
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact: org.apache.ode:ode-dao-jpa-ojpa-derby:1.1:zip
[INFO] Expanding: C:\Documents and
Settings\Administrator\.m2\repository\org\apa
che\ode\ode-dao-jpa-ojpa-derby\1.1\ode-dao-jpa-ojpa-derby-1.1.zip into
C:\Tuscan
y\java\sca\modules\implementation-bpel\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\Tuscany\java\sca\modules\implementation-bpe
l\target\surefire-reports
[INFO] Building jar:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\surefirebooter57948.jar
java.net.MalformedURLException: unknown protocol: c
at java.net.URL.init(URL.java:608)
at java.net.URL.init(URL.java:498)
at
sun.misc.URLClassPath$JarLoader.parseClassPath(URLClassPath.java:1118
)
at
sun.misc.URLClassPath$JarLoader.getClassPath(URLClassPath.java:1091)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:476)
at sun.misc.URLClassPath.getResource(URLClassPath.java:322)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java
:960)
at
java.security.AccessController.doPrivileged(AccessController.java:275
)
at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
at java.lang.ClassLoader.loadClass(ClassLoader.java:607)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:327)
at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
The java class is not found:
org.apache.maven.surefire.booter.SurefireBooter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sample implementation-composite fails in a top-down build of 1.0 branch, but it's passing in the module-only build
) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.contribute(ContributionServiceImpl.java:152) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(Def aultSCADomain.java:125) ... 21 more Caused by: java.lang.ClassNotFoundException: org.apache.tuscany.sca.node.impl.No deManagerServiceImpl ... 36 more Results : Tests in error: test(composite.CompositeTestCase) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-1716) implementation.bpel build issue
Could you apply to trunk at least ? Then we could verify we are not seeing the issue anymore, as it looks like your stackTrace and the one from Ant and myself are different. On 9/16/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I found a fix for this problem: using surefire plugin version 2.3.1-SNAPSHOT which fixes http://jira.codehaus.org/browse/SUREFIRE-322. It's not perfect to reference SNAPSHOT versions but I think it's OK as a workaround to run the test case. I'll check in the fix if there is no objections. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Sunday, September 16, 2007 4:32 PM Subject: Fwd: [jira] Created: (TUSCANY-1716) implementation.bpel build issue This is raised as a blocker so whats peoples feelings on it? I'd like bpel to get in 1.0 as well but what should i do tomorrow morning if this is still unresolved? Defer the JIRA or hold the RC vote till tomorrow evening in the hope that will be time to find a resolution? ...ant -- Forwarded message -- From: Luciano Resende (JIRA) tuscany-dev@ws.apache.org Date: Sep 17, 2007 12:13 AM Subject: [jira] Created: (TUSCANY-1716) implementation.bpel build issue To: tuscany-dev@ws.apache.org implementation.bpel build issue --- Key: TUSCANY-1716 URL: https://issues.apache.org/jira/browse/TUSCANY-1716 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.0 Reporter: Luciano Resende Priority: Blocker Fix For: Java-SCA-1.0 See threads for more information : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg23507.html and http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg23439.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change freeze in the 1.0 branch
I have added the implementation-bpel back to build with test cases disabled. This should avoid any of the issues we are seeing due to TUSCANY-1716. I have a sample for implementation-bpel in trunk, but the ant script need a little more work, depending on how things are, I'll try to work on it in the morning, and try to get it in if I make it in time... On 9/17/07, ant elder [EMAIL PROTECTED] wrote: Can we have a change freeze in the branch please while we take stock of where we are. There's so many changes going on still everytime i update to get the final thing to review by the time i've checked out there's new commits :( Could everyone who has more to do please reply now saying what changes they still want to make and when they think they'll be done by so we can asses whats important enough to still go in 1.0. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
