[jira] Commented: (TUSCANY-3708) SDO created with wrong type errors on deserialization
[
https://issues.apache.org/jira/browse/TUSCANY-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921304#action_12921304
]
Simon Laws commented on TUSCANY-3708:
-
I'm told that SDO generates different things depending on what types you
register and how. I may be over simplifying but this is what I think happens...
register an XSD = SDO generates DynamicDataObjectImpl
register a static factory = SDO generates static types
register nothing = SDO generates AnyTypeDataObject
I note that in the sample DataServiceImpl registers the static factory as
follows
helperContext = HelperProvider.getDefaultContext();
CatalogBaseTypeFactory.INSTANCE.register( helperContext );
The composite file registers the XSD as follows
dbsdo:import.sdo location=SDOTypes/catalogBaseType.xsd/
I'm guessing that the XSD wins. If I comment out the xsd registration the
static type is returned.
SDO created with wrong type errors on deserialization
---
Key: TUSCANY-3708
URL: https://issues.apache.org/jira/browse/TUSCANY-3708
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.1
Environment: Tuscany 1.6 resp 1.7 snapshot, JDK 1.6.0_21, Eclipse
Helios, Windows XP
Reporter: Sebastian Millies
Attachments: test.zip
Creation of static SDOs for which classes have been generated from XSD does
not work as expected.
In particular, I created a data object for a type which has a statically
generated class, but unexpectedly
got back an instance of DynamicDataObjectImpl.
A trelated error maybe that even when I create the static SDO directly from
the factory, when I later
try to return it over an XMI binding, I get a PackageNotFoundException.
Here are the details:
I created the types using XSD2JavaGenerator from this XSD:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://psp.softwareag.com/catalogBaseType;
xmlns:catalogBaseType=http://psp.softwareag.com/catalogBaseType;
complexType name=CatalogBaseType
attribute name=id type=string/attribute
attribute name=catalogID type=string/attribute
attribute name=fileName type=string/attribute
attribute name=catalogName type=string/attribute
attribute name=catalogStatus type=string/attribute
attribute name=supplierID type=string/attribute
attribute name=eclassVersion type=string/attribute
/complexType
element name=catalogBaseType
type=catalogBaseType:CatalogBaseType/element
/schema
The classes get generated in package com.softwareag.psp.catalog.base.type. I
generated no interfaces ( I
ran XSD2JavaGenerator with the following options: -noInterfaces
-noNotification -noUnsettable -prefix).
I have called the generated factory CatalogBaseTypeFactory.
Then in my coding (SCA service implementation) I do the following:
a)statically register the factory with the default context
static {
helperContext = HelperProvider.getDefaultContext();
CatalogBaseTypeFactory.INSTANCE.register( helperContext );
}
b)create a data object from the targetNamespace of the XSD and the type
name
DataObject obj = helperContext.getDataFactory().create(
http://psp.softwareag.com/catalogBaseType;, CatalogBaseType);
Unexpectedly obj is an instance of DynamicDataObjectImpl, where I would have
expected an instance
of CatalogBaseType instead.
When I call the service that returns this SDO using a Java RMI client, I also
get an exception when trying to
deserialize the dynamic data object:
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri
'http://psp.softwareag.com/catalogBaseType' not found. (http:///temp.xml, 5,
24)
which is caused by an underlying
org.eclipse.emf.ecore.xmi.PackageNotFoundException.
(see also my previous post with subject SDO deserialization error)
This exception also occurs when I use a SDO of the correct type created with
a call to the CatalogBaseTypeFactory.
Frank Budinsky commented on this on the mailing list:
From: Frank Budinsky [mailto:fra...@ca.ibm.com]
Sent: Thursday, October 07, 2010 3:30 PM
To: u...@tuscany.apache.org
Subject: Re: SDO instance creation and deserialization error
I think that should work, so my only guess is that maybe the SCA component
and runtime are not using the same classLoader and/or HelperContext
(scope). Maybe someone with more SCA knowledge can help.
Frank.
However, I suppose that the first problem (wrong type of SDO created)
probably is not connected to SCA,
because there is no SCA code involved. It doesn't matter for this problem
what context the SCA runtime
uses, because I use
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
I note that the dependencies in the helloworld impl-web samples were changed earlier and don't reference a valid artifact at the moment. Is is safe to assume that this is a work in progress? I have to admit i've not looked in any detail at the samples recently, once we've got the basic structure of the dependencies and builds which the samples should be using (which seems like its getting close now) i'll start going through them all again. ...ant It seems to be OK now. I got a clean linux build this morning. I'll go back an check a little later. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Build failed in Hudson: Tuscany-2x #888
On Fri, Oct 15, 2010 at 3:03 PM, ant elder ant.el...@gmail.com wrote: On Fri, Oct 15, 2010 at 2:39 PM, Apache Hudson Server hud...@hudson.apache.org wrote: snip Deploying the main artifact sample-binding-comet-1.0.war ERROR: Error deploying artifact: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/sample-binding-comet/1.0/sample-binding-comet-1.0.war. Return code is: 400 org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/sample-binding-comet/1.0/sample-binding-comet-1.0.war. Return code is: 400 at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94) at hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:119) at hudson.maven.reporters.MavenAggregatedArtifactRecord.deploy(MavenAggregatedArtifactRecord.java:79) at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:118) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:580) at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:595) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) at hudson.model.Run.run(Run.java:1303) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:293) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:140) Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/sample-binding-comet/1.0/sample-binding-comet-1.0.war. Return code is: 400 at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:172) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) ... 12 more It is very odd that the hudson deploy of this one sample keeps failing. I've taken out of the main build and kicked off another hudson to see if that now completes or if other things fail with similar issues. I've also setup a separate hudson build just of that one sample and it fails with the same issue - https://hudson.apache.org/hudson/job/tuscany-comet-sample/1/console ...ant Something slightly odd is that it thinks its deploying v1.0? Although it is trying to deploy to snapshots. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Commented: (TUSCANY-3727) which-jars files in distribution should not include jars from base runtime
[ https://issues.apache.org/jira/browse/TUSCANY-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921406#action_12921406 ] Simon Laws commented on TUSCANY-3727: - There's a human readable file, called which-jars, that can be generated by our maven-bundle-plugin which lists the jars that are contained in any particular collection whether that be a feature or any other kind of pom described collection, e.g. one of the *-runtime poms from modules or one of the features that collects together dependencies required to run a binding or implementation extension. The contents of the binding-rmi which-jars file is, for example, tuscany-binding-rmi-2.0-SNAPSHOT.jar tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar tuscany-host-rmi-2.0-SNAPSHOT.jar This clarity depends on being careful how the binding-rmi-runtime pom is configured. It's dependencies are specified as follows... dependencies dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-core-runtime/artifactId version2.0-SNAPSHOT/version typepom/type scopeprovided/scope /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-rmi/artifactId version2.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-host-rmi/artifactId version2.0-SNAPSHOT/version /dependency . Which clearly says that I need all the core Tuscany dependencies but that they will be provided elsewhere by the runtime. This means that the code that generates the which-jars file doesn't see these dependencies and hence generates the short list above. Now there isn't actually a which-jars list for the core dependencies, because you can't run anything with it on its own (although maybe we should provide it for completeness in case people want to know what provides the SPI). Current the core is wrapped up in the base runtime which adds on top of the core the minimal base runtime artifacts required to run Tuscany. Currently the base-runtime which-jars looks like... XmlSchema-1.4.3.jar activation-1.1/activation-1.1.jar asm-3.1/asm-3.1.jar cglib-2.2/cglib-2.2.jar commons-cli-1.2.jar geronimo-stax-api_1.0_spec-1.0.1.jar jaxb-api-2.1/jaxb-api-2.1.jar jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar jaxws-api-2.1/jaxws-api-2.1.jar jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar jsr250-api-1.0/jsr250-api-1.0.jar servlet-api-2.5/servlet-api-2.5.jar tuscany-assembly-2.0-SNAPSHOT.jar tuscany-assembly-xml-2.0-SNAPSHOT.jar tuscany-assembly-xsd-2.0-SNAPSHOT.jar tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar tuscany-binding-ws-2.0-SNAPSHOT.jar tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar tuscany-builder-2.0-SNAPSHOT.jar tuscany-common-java-2.0-SNAPSHOT.jar tuscany-common-xml-2.0-SNAPSHOT.jar tuscany-contribution-2.0-SNAPSHOT.jar tuscany-core-2.0-SNAPSHOT.jar tuscany-core-databinding-2.0-SNAPSHOT.jar tuscany-core-spi-2.0-SNAPSHOT.jar tuscany-databinding-2.0-SNAPSHOT.jar tuscany-databinding-jaxb-2.0-SNAPSHOT.jar tuscany-deployment-2.0-SNAPSHOT.jar tuscany-extensibility-2.0-SNAPSHOT.jar tuscany-host-http-2.0-SNAPSHOT.jar tuscany-host-webapp-2.0-SNAPSHOT.jar tuscany-implementation-java-2.0-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar tuscany-implementation-web-2.0-SNAPSHOT.jar tuscany-implementation-web-runtime-2.0-SNAPSHOT.jar tuscany-interface-java-2.0-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar tuscany-interface-wsdl-2.0-SNAPSHOT.jar tuscany-monitor-2.0-SNAPSHOT.jar tuscany-node-api-2.0-SNAPSHOT.jar tuscany-node-impl-2.0-SNAPSHOT.jar tuscany-node-launcher-2.0-SNAPSHOT.jar tuscany-policy-security-2.0-SNAPSHOT.jar tuscany-sca-api-2.0-SNAPSHOT.jar tuscany-sca-client-impl-2.0-SNAPSHOT.jar tuscany-xsd-2.0-SNAPSHOT.jar wsdl4j-1.6.2/wsdl4j-1.6.2.jar wstx-asl-3.2.4/wstx-asl-3.2.4.jar Not sure that's precisely the right list but we'll increment on it. Now, having said all this, most of the runtime module poms are not so carefully constructed or haven't been converted over to base + extensions at all. This is not really a problem in that it doesn't stop anything working but It's not very neat for our users. For example, I started converting binding-ws-runtime-axis2 as follows... dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-core-runtime/artifactId version2.0-SNAPSHOT/version typepom/type scopeprovided/scope /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-ws-wsdlgen/artifactId version2.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.tuscany.sca/groupId
[jira] Created: (TUSCANY-3728) Getting EPR bind error when running the async sample
Getting EPR bind error when running the async sample Key: TUSCANY-3728 URL: https://issues.apache.org/jira/browse/TUSCANY-3728 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta1 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0-Beta1 The epr bind fails because the runtime isn't able to properly match reference async operations with service operations (either sync or async). Am looking at the details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-3728) Getting EPR bind error when running the async sample
[ https://issues.apache.org/jira/browse/TUSCANY-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3728. --- Resolution: Fixed It was a test case error. The poll operation returned a Future rather than a Response. Getting EPR bind error when running the async sample Key: TUSCANY-3728 URL: https://issues.apache.org/jira/browse/TUSCANY-3728 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta1 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0-Beta1 The epr bind fails because the runtime isn't able to properly match reference async operations with service operations (either sync or async). Am looking at the details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (TUSCANY-3722) Tuscany SCA Java 1.x binary distribution could include an incorrect jaxws-api-2.1.jar
On Thu, Oct 14, 2010 at 9:12 AM, Simon Nash (JIRA) dev@tuscany.apache.org wrote: Tuscany SCA Java 1.x binary distribution could include an incorrect jaxws-api-2.1.jar - Key: TUSCANY-3722 URL: https://issues.apache.org/jira/browse/TUSCANY-3722 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-1.6 Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-1.6.1 Because of the problem described in [1], the Tuscany SCA Java binary distribution lib directory could contain the wrong version of jaxws-api-2.1.jar if it so happens that the local maven repository of the person building the distribution contains the wrong version of this jar and pom. The incorrect version of the jar is missing some classes such as javax.xml.ws.soap.Addressing. It's very undesirable that Tuscany binary distributions built by different people could have different contents. It's also very undesirable that Tuscany could propagate the bad version of this jar to users who might experience problems because they don't realise that the version of this jar that they got from Tuscany is bad. [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg06182.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. Does the bad version cause Tuscany tests to fail such that the person building the distro would notice when the do mvn to build the tree. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
On Thu, Oct 14, 2010 at 9:29 AM, ant elder ant.el...@gmail.com wrote: On Thu, Oct 14, 2010 at 8:56 AM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Oct 14, 2010 at 8:27 AM, ant elder (JIRA) dev@tuscany.apache.org wrote: Aggregate JARs don't work with Maven Key: TUSCANY-3721 URL: https://issues.apache.org/jira/browse/TUSCANY-3721 Project: Tuscany Issue Type: Bug Reporter: ant elder Fix For: Java-SCA-2.0-Beta1 The new aggregate JARs don't work with Maven because the shade plugin isn't configured to promote transitive dependencies which that means all the individual module jars are still included as transitive dependencies and added to the classpath. Updating the shade config to promote transitive dependencies also doesn't work as the shade plugin doesn't work with pom type dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. I've yet to try this out and really understand what the issue is here so my next comment may be rubbish but I wonder whether this really matters. We have other poms that describe the contents of aggregate jars so do we need the user to be able to depend on the aggregated jar itself from Maven? I'd like to fix it as i prefer the aggregate jars to the pom type approach. If they are fixed then that question could be flipped around to be: if we have the aggregate jars do users really need to use the pom type dependencies? To put this in (my) perspective look at whats common practice in other projects. I can point at lots of projects that aggregate small modules into easier to manage and use aggregate jars. On the other hand i don't know of a single other project in the world that you use with a pom type dependency. Take the Tuscany build as an example - it uses zillions of dependencies but not a single one is a pom type dependency. What ever the pros and cons the pom type approach is much less common, and that makes sense to me as fewer jars and dependencies is simpler. I think its good to try to have Tuscany work in as normal a way as possible because that makes it easier for people getting started with Tuscany. This is why i keep on trying have things be normal in Tuscany - the Maven build to use the standard build commands, the IDE setup to use standard IDE set up, the Tuscany APIs to match what the SCA specs describe, etc, the aggregate base jar is just more of that. Fine if people also want to experiment with other approaches too but i think we should strive have the more commonly understood approaches work as well where possible. ...ant I'll give it a go as I'm still not clear what the actual problem is. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
The problem is that the shade plugin doesn't work with pom type dependencies, so when the dependency reduced pom.xml is created it still contains the pom type dependency so all the individual Tuscany modules are still included as transitive dependencies, so everything is duplicated and both the shaded jar and individual module jars get included on the classpath and included in things like the webapp lib directory. The only easy way around this i can see is to duplicate what the pom type module does and include the actual module dependencies in the aggregate jar pom.xml. I guess the shade plugin could be fixed but i have had a look but it wasn't immediately obvious where its going wrong, and we'd have to wait for the fixed version to be released. This is similar to the dependency plugin also not working with pom type dependencies (and is probably just another symptom of the fact that pom type dependencies are a little uncommon). ...ant I apologize for being slow and I expect it's because I don't understand how the shades plugin work but I still don't understand what's going on here. More specifically I don't understand... - what a reduced dependency pom is (it's not something that google knows about) - why the shades plugin doesn't work with pom type poms. It seems to be generating working aggregate jars to me - why the appearance of transitive dependencies in projects that depend on the aggregate jar is the shade plugin's fault. Surely this is our fault for not marking the dependency on the base pom as optional in the aggregate jar pom. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
- why the appearance of transitive dependencies in projects that depend on the aggregate jar is the shade plugin's fault. Surely this is our fault for not marking the dependency on the base pom as optional in the aggregate jar pom. I may be missing what you're suggesting but if they're optional or provided then they wont get included in the aggregate jar which isn't what we want. ...ant Is that really true for optional dependencies? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
On Thu, Oct 14, 2010 at 11:22 AM, Simon Laws simonsl...@googlemail.com wrote: - why the appearance of transitive dependencies in projects that depend on the aggregate jar is the shade plugin's fault. Surely this is our fault for not marking the dependency on the base pom as optional in the aggregate jar pom. I may be missing what you're suggesting but if they're optional or provided then they wont get included in the aggregate jar which isn't what we want. ...ant Is that really true for optional dependencies? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com And I mean to say I'll give it a go and see if I can make it work. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
On Thu, Oct 14, 2010 at 11:22 AM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Oct 14, 2010 at 11:22 AM, Simon Laws simonsl...@googlemail.com wrote: - why the appearance of transitive dependencies in projects that depend on the aggregate jar is the shade plugin's fault. Surely this is our fault for not marking the dependency on the base pom as optional in the aggregate jar pom. I may be missing what you're suggesting but if they're optional or provided then they wont get included in the aggregate jar which isn't what we want. ...ant Is that really true for optional dependencies? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com And I mean to say I'll give it a go and see if I can make it work. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com Well I may of course be missing something important but it seems to work to me. I've done enough local changes to make this work... - add host-webapp and implementation-web-runtime to the base runtime (not sure this is the right place for these but it was convenient) - made the pom dependencies in the aggregation jars optional - added and exclusion to the base aggregation to remove the servlet api from the base runtime aggregation This creates a war not far off the same size as the war created using the base shade dependency. The war has one entry in the lib directory (tuscany-base-runtime-aggregation-2.0-SNAPSHOT.jar) and it works in the unit test and when deployed to tomcat. I'll check in these changes once I've done a build. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3721) Aggregate JARs don't work with Maven
Well I may of course be missing something important but it seems to work to me. I've done enough local changes to make this work... - add host-webapp and implementation-web-runtime to the base runtime (not sure this is the right place for these but it was convenient) - made the pom dependencies in the aggregation jars optional - added and exclusion to the base aggregation to remove the servlet api from the base runtime aggregation This creates a war not far off the same size as the war created using the base shade dependency. The war has one entry in the lib directory (tuscany-base-runtime-aggregation-2.0-SNAPSHOT.jar) and it works in the unit test and when deployed to tomcat. I'll check in these changes once I've done a build. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com I just committed the changes to add enough to tuscany-base-runtime to allow the helloworld-jsp project work with a dependency on the tuscany-base-runtime-aggregation jar. This aggregation jar is of, what we have previously called, the -nodep variety. It contains the tuscany jars and all their dependencies. I note that the dependencies in the helloworld impl-web samples were changed earlier and don't reference a valid artifact at the moment. Is is safe to assume that this is a work in progress? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Assigned: (TUSCANY-3717) Samples use other samples but without declaring the dependency causing fails due to build order
[ https://issues.apache.org/jira/browse/TUSCANY-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-3717: --- Assignee: Simon Laws Samples use other samples but without declaring the dependency causing fails due to build order --- Key: TUSCANY-3717 URL: https://issues.apache.org/jira/browse/TUSCANY-3717 Project: Tuscany Issue Type: Bug Reporter: ant elder Assignee: Simon Laws Fix For: Java-SCA-2.0-Beta1 Some samples use other samples but without declaring the dependency causing fails due to build order. Eg embedded-jse uses samples in gettibg-started/learniong-more. Can easily recreate by doing mvn clean before doing a build and for some other issues clearing out you local repo before a build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-3717) Samples use other samples but without declaring the dependency causing fails due to build order
[ https://issues.apache.org/jira/browse/TUSCANY-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws resolved TUSCANY-3717. - Resolution: Fixed Various fixes made and I now get a build on Linux following mvn clean. Samples use other samples but without declaring the dependency causing fails due to build order --- Key: TUSCANY-3717 URL: https://issues.apache.org/jira/browse/TUSCANY-3717 Project: Tuscany Issue Type: Bug Reporter: ant elder Assignee: Simon Laws Fix For: Java-SCA-2.0-Beta1 Some samples use other samples but without declaring the dependency causing fails due to build order. Eg embedded-jse uses samples in gettibg-started/learniong-more. Can easily recreate by doing mvn clean before doing a build and for some other issues clearing out you local repo before a build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build failed in Hudson: Tuscany-2x #886
Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: https://repository.apache.org/content/repositories/snapshots/org/apache/tuscany/sca/sample-binding-comet/1.0/sample-binding-comet-1.0.war. Return code is: 400 at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:172) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) ... 12 more Oh so close. Everything worked but it failed to deploy an artifact for some reason! Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Dependency on jaxws-rt-2.1.7.jar
A difference in 2.x is that we require JDK6 and use the xml dependencies that are included in that, and they don't necessarily work with other versions of things. So for example changing to use the jaxws-api dependency as used in 1.6.1 gives me the following exception: Caused by: java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.internal.bind.api .JAXBRIContext Looking at the dependency tree the Tuscany module databinding-jaxb is using com.sun.xml.bind:jaxb-impl:jar:2.1.12 so i guess we have to have dependencies that are compatible with that, or change databinding-jaxb to use just the base JDK classes. ...ant ...ant And I guess we don't know yet whether we actually need the 2.1.12 version if jaxb-impl. I note from playing with it yesterday that jaxb-impl 2.1.4 is a dependency of the wink server. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Commented: (TUSCANY-3708) SDO created with wrong type errors on deserialization
[
https://issues.apache.org/jira/browse/TUSCANY-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920497#action_12920497
]
Simon Laws commented on TUSCANY-3708:
-
thanks for the example Sebastien
I note that you set the HelpContext up in the component impl but not in the
DataServiceRMITest. I copied the following lines to the setUpBeforeClass
method...
HelperContext helperContext =
HelperProvider.getDefaultContext();
CatalogBaseTypeFactory.INSTANCE.register( helperContext );
With this the output is...
SDO
com.softwareag.psp.catalog.base.type.CatalogBaseType
SDO
com.softwareag.psp.catalog.base.type.CatalogBaseType
Is that what was expected?
SDO created with wrong type errors on deserialization
---
Key: TUSCANY-3708
URL: https://issues.apache.org/jira/browse/TUSCANY-3708
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.1
Environment: Tuscany 1.6 resp 1.7 snapshot, JDK 1.6.0_21, Eclipse
Helios, Windows XP
Reporter: Sebastian Millies
Attachments: test.zip
Creation of static SDOs for which classes have been generated from XSD does
not work as expected.
In particular, I created a data object for a type which has a statically
generated class, but unexpectedly
got back an instance of DynamicDataObjectImpl.
A trelated error maybe that even when I create the static SDO directly from
the factory, when I later
try to return it over an XMI binding, I get a PackageNotFoundException.
Here are the details:
I created the types using XSD2JavaGenerator from this XSD:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://psp.softwareag.com/catalogBaseType;
xmlns:catalogBaseType=http://psp.softwareag.com/catalogBaseType;
complexType name=CatalogBaseType
attribute name=id type=string/attribute
attribute name=catalogID type=string/attribute
attribute name=fileName type=string/attribute
attribute name=catalogName type=string/attribute
attribute name=catalogStatus type=string/attribute
attribute name=supplierID type=string/attribute
attribute name=eclassVersion type=string/attribute
/complexType
element name=catalogBaseType
type=catalogBaseType:CatalogBaseType/element
/schema
The classes get generated in package com.softwareag.psp.catalog.base.type. I
generated no interfaces ( I
ran XSD2JavaGenerator with the following options: -noInterfaces
-noNotification -noUnsettable -prefix).
I have called the generated factory CatalogBaseTypeFactory.
Then in my coding (SCA service implementation) I do the following:
a)statically register the factory with the default context
static {
helperContext = HelperProvider.getDefaultContext();
CatalogBaseTypeFactory.INSTANCE.register( helperContext );
}
b)create a data object from the targetNamespace of the XSD and the type
name
DataObject obj = helperContext.getDataFactory().create(
http://psp.softwareag.com/catalogBaseType;, CatalogBaseType);
Unexpectedly obj is an instance of DynamicDataObjectImpl, where I would have
expected an instance
of CatalogBaseType instead.
When I call the service that returns this SDO using a Java RMI client, I also
get an exception when trying to
deserialize the dynamic data object:
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri
'http://psp.softwareag.com/catalogBaseType' not found. (http:///temp.xml, 5,
24)
which is caused by an underlying
org.eclipse.emf.ecore.xmi.PackageNotFoundException.
(see also my previous post with subject SDO deserialization error)
This exception also occurs when I use a SDO of the correct type created with
a call to the CatalogBaseTypeFactory.
Frank Budinsky commented on this on the mailing list:
From: Frank Budinsky [mailto:fra...@ca.ibm.com]
Sent: Thursday, October 07, 2010 3:30 PM
To: u...@tuscany.apache.org
Subject: Re: SDO instance creation and deserialization error
I think that should work, so my only guess is that maybe the SCA component
and runtime are not using the same classLoader and/or HelperContext
(scope). Maybe someone with more SCA knowledge can help.
Frank.
However, I suppose that the first problem (wrong type of SDO created)
probably is not connected to SCA,
because there is no SCA code involved. It doesn't matter for this problem
what context the SCA runtime
uses, because I use the default SDO context directly when registering the
Factory and creating
the SDO.
The second problem (the PackageNotFoundException upon deserialization) may
have to do with SCA,
because there is a mediating SCA
Re: testing/compliance-tests status?
On Wed, Oct 13, 2010 at 12:31 PM, ant elder ant.el...@gmail.com wrote: Whats the status of the compliance tests in trunk? I've managed to get a build through all the way to the java-ci tests without failing which is further than its got for ages, that fails with missing dependencies and compile errors and looking at the pom.xml its still using the old feature (which doesn't exist) not the base-runtime but updating to that gets compile errors and looking in tuscany-otests-sca-j-ci-tests it looks like its missing a lot of things. Has that got extra changes that need to be published? ...ant Not as far as I know. I've getting a clean build at the moment. I see what you mean about the feature. I didn't spot that so I must be running of a version cached in my local repo. I'll change it here also and see what happens. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: testing/compliance-tests status?
On Wed, Oct 13, 2010 at 12:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Wed, Oct 13, 2010 at 12:31 PM, ant elder ant.el...@gmail.com wrote: Whats the status of the compliance tests in trunk? I've managed to get a build through all the way to the java-ci tests without failing which is further than its got for ages, that fails with missing dependencies and compile errors and looking at the pom.xml its still using the old feature (which doesn't exist) not the base-runtime but updating to that gets compile errors and looking in tuscany-otests-sca-j-ci-tests it looks like its missing a lot of things. Has that got extra changes that need to be published? ...ant Not as far as I know. I've getting a clean build at the moment. I see what you mean about the feature. I didn't spot that so I must be running of a version cached in my local repo. I'll change it here also and see what happens. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com I committed an updated pom. Can you give that a spin and see what happens for you before I fix the rest of them. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3717) Samples use other samples but without declaring the dependency causing fails due to build order
On Wed, Oct 13, 2010 at 2:12 PM, ant elder (JIRA) dev@tuscany.apache.org wrote: Samples use other samples but without declaring the dependency causing fails due to build order --- Key: TUSCANY-3717 URL: https://issues.apache.org/jira/browse/TUSCANY-3717 Project: Tuscany Issue Type: Bug Reporter: ant elder Fix For: Java-SCA-2.x Some samples use other samples but without declaring the dependency causing fails due to build order. Eg embedded-jse uses samples in gettibg-started/learniong-more. Can easily recreate by doing mvn clean before doing a build and for some other issues clearing out you local repo before a build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. Hi I tried to solve this with a dependency at the running tuscany level as all the running tuscany samples should depend on contributions elsewhere (this is not completely true atm). I though that this had done the job but maybe not. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Resolved: (TUSCANY-3713) Issue on ExtensibleStAXArtifactProcessor.read
[
https://issues.apache.org/jira/browse/TUSCANY-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws resolved TUSCANY-3713.
-
Resolution: Fixed
Fix Version/s: Java-SCA-2.0-Beta1
Thanks for the patch Yang, Committed at r1021805
Issue on ExtensibleStAXArtifactProcessor.read
-
Key: TUSCANY-3713
URL: https://issues.apache.org/jira/browse/TUSCANY-3713
Project: Tuscany
Issue Type: Bug
Reporter: Yang Lei
Assignee: Simon Laws
Fix For: Java-SCA-2.0-Beta1
Attachments: patch_StAXAP.txt
I am running OASIS spec compliance test in another hosting environment. When
I run the test that includs DTD definition in composite, (e.g. JCA_9016), the
parser in my hosting environement will throw the following exception.
javax.xml.stream.XMLStreamException: A non-whitespace event found while
calling nextTag.
... parser code
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:155)
To bypass the issue, I commented the ExtensibleStAXArtifactProcessor code
with mine new code:
//if (event == XMLStreamConstants.START_DOCUMENT) {
//source.nextTag();
//}
if (event == XMLStreamConstants.START_DOCUMENT) {
while (source.next() != XMLStreamReader.START_ELEMENT);
}
Here is the java doc for the nextTag:
nextTag
public int nextTag()
throws XMLStreamExceptionSkips any insignificant events (COMMENT
and PROCESSING_INSTRUCTION) until a START_ELEMENT or END_ELEMENT is reached.
If other than space characters are encountered, an exception is thrown. This
method should be used when processing element-only content because the parser
is not able to recognize ignorable whitespace if then DTD is missing or not
interpreted.
Returns:
the event type of the element read
Throws:
XMLStreamException - if the current event is not white space
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3674) Review/consolidate 2.x distribution structure
[ https://issues.apache.org/jira/browse/TUSCANY-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-3674: Fix Version/s: Java-SCA-2.0-Beta1 Move to Beta category Review/consolidate 2.x distribution structure - Key: TUSCANY-3674 URL: https://issues.apache.org/jira/browse/TUSCANY-3674 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0-Beta1 We currently have a number of mechanisms for packaging distributed artifacts. Primarily: - Modules are grouped together into features (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/features/) - Modules are grouped together into shaded jars (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/shades/) It's not clear why these grouped functions have to be specified in different pom.xml files in different places in the code base. Also the resulting 2.x distributions have both a features directory (from the features) and a lib director (containing jars from the shades directory) alongside the modules directory. This is at best confusing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [1.6.1] Updated proposal for release content packaging
On Wed, Oct 13, 2010 at 6:17 PM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Oct 12, 2010 at 5:17 AM, Simon Nash n...@apache.org wrote: Based on feedback to my previous proposal [1] and further investigations I have made, here's a revised proposal for the 1.6.1 release content and packaging. Anything not listed below is unchanged from 1.6. Add to binary distro: modules/binding-erlang modules/binding-erlang-runtime samples/helloworld-erlang-reference samples/helloworld-erlang-service samples/store-dojo Add to binary distro but not to tuscany-sca-all and tuscany-sca-manifest: modules/binding-atom-js-dojo modules/binding-jsonrpc-js-dojo modules/implementation-widget-runtime-dojo modules/web-javascript-dojo Release as updatesite package: tools/eclipse/site/updatesite Release to maven repo only: modules/binding-sca-corba (conflict with binding-sca) modules/binding-sca-jms (conflict with binding-sca) modules/host-corba-jee (conflict with host-corba-jse) modules/host-tomcat (conflict with host-jetty) modules/node-launcher-osgi (needs dependencies not in binary distro lib directory) modules/policy-transaction (dependency conflicts with binary distro lib directory) tools/contrib2wsdl tools/eclipse/features/core tools/eclipse/plugins/core tools/java2wsdl tools/maven/maven-ant-generator tools/maven/maven-bundle-plugin tools/maven/maven-dependency-lister tools/maven/maven-incremental-build tools/maven/maven-java2wsdl tools/maven/maven-wsdl2java Exclude from the 1.6.1 release: modules/binding-hessian modules/contribution-jee-impl (pending resolution of TUSCANY-3165) modules/databinding-fastinfoset modules/databinding-xstream modules/extensibility-equinox modules/host-ejb modules/host-openejb modules/workspace-manager tools/maven/maven-osgi-junit samples/calculator-lean samples/calculator-ws-secure-webapp samples/customer-dojo (needs more work before release) samples/customer-dojo-webapp (needs more work before release) samples/domain-webapp samples/helloworld-jms-webapp (should be released in 1.7) samples/helloworld-ws-reference-lean samples/loanapplication samples/zipcode-jaxws Please check the above lists, especially the items marked for exclusion. Is there anything there that should be part of the 1.6.1 release? Simon [1] http://mail-archives.apache.org/mod_mbox/tuscany-dev/201010.mbox/%3c4cb1ed9e.7000...@apache.org%3e From high level look, it seems fine. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ Looks OK to me too. The only detailed comment is that I don't think samples/domain-webapp does anything useful so could be removed from 1.x. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [1.6.1] erlang modules and samples, was: Re: trunk structure - trunk/contrib folder
On Mon, Oct 11, 2010 at 11:44 PM, Raymond Feng cyberf...@gmail.com wrote: +1 to add it. Raymond Feng rf...@apache.org Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com On Oct 11, 2010, at 2:58 PM, Simon Nash wrote: Luciano Resende wrote: On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash n...@apache.org wrote: I've looked at the modules, samples and tools directories as released in 1.6, and I've also looked at the contents of the maven repo. (cut) The earlang extensions have an issue that you have to install earlang first, before you can do much with it. But other then that, it should be good to stay. I installed erlang and ran the erlang samples. The only problem I found was that the README instructions for these samples mention using ant but there aren't any build.xml files. I added code to the poms to generate the build.xml files and everything worked OK. If erlang isn't installed, the samples produce a message saying this. Based on this I see no reason for excluding modules/binding-erlang-* and samples/helloworld-erlang-* from the 1.x and 1.6.1 binary distros, and I would like to add them. Does anyone disagree with this? Simon +1 if they work I think they should be added. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Assigned: (TUSCANY-3713) Issue on ExtensibleStAXArtifactProcessor.read
[
https://issues.apache.org/jira/browse/TUSCANY-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-3713:
---
Assignee: Simon Laws
Issue on ExtensibleStAXArtifactProcessor.read
-
Key: TUSCANY-3713
URL: https://issues.apache.org/jira/browse/TUSCANY-3713
Project: Tuscany
Issue Type: Bug
Reporter: Yang Lei
Assignee: Simon Laws
Attachments: patch_StAXAP.txt
I am running OASIS spec compliance test in another hosting environment. When
I run the test that includs DTD definition in composite, (e.g. JCA_9016), the
parser in my hosting environement will throw the following exception.
javax.xml.stream.XMLStreamException: A non-whitespace event found while
calling nextTag.
... parser code
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:155)
To bypass the issue, I commented the ExtensibleStAXArtifactProcessor code
with mine new code:
//if (event == XMLStreamConstants.START_DOCUMENT) {
//source.nextTag();
//}
if (event == XMLStreamConstants.START_DOCUMENT) {
while (source.next() != XMLStreamReader.START_ELEMENT);
}
Here is the java doc for the nextTag:
nextTag
public int nextTag()
throws XMLStreamExceptionSkips any insignificant events (COMMENT
and PROCESSING_INSTRUCTION) until a START_ELEMENT or END_ELEMENT is reached.
If other than space characters are encountered, an exception is thrown. This
method should be used when processing element-only content because the parser
is not able to recognize ignorable whitespace if then DTD is missing or not
interpreted.
Returns:
the event type of the element read
Throws:
XMLStreamException - if the current event is not white space
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Dependency on jaxws-rt-2.1.7.jar
On Tue, Oct 12, 2010 at 5:43 PM, Simon Nash n...@apache.org wrote: Raymond Feng wrote: Are there any newer versions in public repos? / Raymond Feng rf...@apache.org mailto:rf...@apache.org /Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com / / On Oct 12, 2010, at 6:36 AM, ant elder wrote: The Tuscany runtime seems to now require jaxws-rt-2.1.7.jar or you get various ws or xml failures but that jar isn't easily available in any repo now, the only one i can find it in is the old java.net http://java.net Maven 1.x legacy repo but thats so slow the download always times out. Does anyone know why we need this or if theres a different version that we can use which is more easily available? ...ant Where does this dependency come from? I recently went through 1.6.1 checking for this and I was able to change all these dependencies to jaxws-api except for a couple with test scope. Simon In 2.x it appears in a number of places where native JAX-WS endpoints are used. testing/compliance-tests/assembly/pom.xml:artifactIdjaxws-rt/arti factId testing/compliance-tests/assembly/target/test-classes/META-INF/maven/org.apache. tuscany.sca/tuscany-otests-asm-tests/pom.xml:artifactIdjaxws-rt/a rtifactId testing/compliance-tests/binding-ws/target/test-classes/META-INF/maven/org.apach e.tuscany.sca/tuscany-otests-sca-ws-tests/pom.xml:artifactIdjaxws- rt/artifactId testing/compliance-tests/java-caa/target/test-classes/META-INF/maven/org.apache. tuscany.sca/tuscany-otests-sca-j-caa-tests/pom.xml:artifactIdjaxws -rt/artifactId testing/compliance-tests/java-ci/target/test-classes/META-INF/maven/org.apache.t uscany.sca/tuscany-otests-sca-j-ci-tests/pom.xml:artifactIdjaxws-r t/artifactId testing/compliance-tests/policy/target/test-classes/META-INF/maven/org.apache.tu scany.sca/tuscany-otests-policy-tests/pom.xml:artifactIdjaxws-rt/ artifactId testing/itest/databindings/jaxb-bottom-up/pom.xml:artifactIdjaxws- rt/artifactId testing/itest/databindings/jaxb-top-down/pom.xml:artifactIdjaxws-r t/artifactId testing/itest/ws/external-client/pom.xml:artifactIdjaxws-rt/artif actId I can't speak directly to the otests but I don't see why we can't look to get rid of it from the Tuscany specific ones to start with. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Created: (TUSCANY-3710) ASM_9004 - Default binding exposes remote endpoints in nested composites.
ASM_9004 - Default binding exposes remote endpoints in nested composites. -- Key: TUSCANY-3710 URL: https://issues.apache.org/jira/browse/TUSCANY-3710 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws When a service is configured with the default binding in a nested composite, for example, in ASM_9004 see the following endpoint INFO: Add endpoint - (@4537813)Endpoint: URI = TestComponent1/TestComposite1Component1#service-binding(Service1/Service1) It seems that a remote endpoint will be made available there. In a nested composite service only the local endpoint should be made available -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3711) ASM_9004
ASM_9004 Key: TUSCANY-3711 URL: https://issues.apache.org/jira/browse/TUSCANY-3711 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - OASIS Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws For generated WSDL the WS binding spec describes a mapping (Appendix D - non-normative). We need to check that we follow this suggested mapping where possible . In particular check that the port name is generated correctly 729 • wsdl:port/@name = binding name + SOAP version + Port -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3712) JCA_11003 Endpoints being created for each @WebService annotation
JCA_11003 Endpoints being created for each @WebService annotation - Key: TUSCANY-3712 URL: https://issues.apache.org/jira/browse/TUSCANY-3712 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - OASIS Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws This otest defines a component implementation with @WebService annotation in both the service interface and the service implementation class. It looks like an endpoint is exposed bot both INFO: Added Servlet mapping: http://9.20.188.155:8080/TEST_JCA_11003Component1/Service1WS 11-Oct-2010 08:59:10 org.apache.tuscany.sca.core.assembly.impl.EndpointRegistryImpl addEndpoint INFO: Add endpoint - (@28442439)Endpoint: URI = TEST_JCA_11003Component1#service-binding(Service1WS/Service1WS) 11-Oct-2010 08:59:10 org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://9.20.188.155:8080/TEST_JCA_11003Component1/service1ImplWS 11-Oct-2010 08:59:10 org.apache.tuscany.sca.core.assembly.impl.EndpointRegistryImpl addEndpoint INFO: Add endpoint - (@4365289)Endpoint: URI = TEST_JCA_11003Component1#service-binding(service1ImplWS/service1ImplWS) Is this correct? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Tuscany SCA 2.0-M5.1 RC2
On Sat, Oct 9, 2010 at 6:54 PM, Luciano Resende luckbr1...@gmail.com wrote: Please review and vote on RC2 of the SCA 2.0-M5.1 release. This is a minor relese based on 2.0-M5 and provides fixes to running Tuscany applications in Google AppEngine environment and other minor fixes to remove compliance tests run from part of the source distro build. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~lresende/tuscany/2.0-M5.1-RC2/ The release tag is at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-M5.1-RC2/ Here is my +1 -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ +1 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0-M5.1 RC1
On Fri, Oct 8, 2010 at 4:43 AM, Luciano Resende luckbr1...@gmail.com wrote: On Thu, Oct 7, 2010 at 2:05 AM, Simon Laws simonsl...@googlemail.com wrote: On Wed, Oct 6, 2010 at 5:50 PM, Simon Laws simonsl...@googlemail.com wrote: On Wed, Oct 6, 2010 at 7:48 AM, ant elder ant.el...@gmail.com wrote: On Wed, Oct 6, 2010 at 5:55 AM, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Oct 4, 2010 at 7:59 AM, Luciano Resende luckbr1...@gmail.com wrote: Please review and vote on RC1 of the SCA 2.0-M5.1 release. This is a minor relese based on 2.0-M5 and provides fixes to running Tuscany applications in Google AppEngine environment and other minor fixes to remove compliance tests run from part of the source distro build. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~lresende/tuscany/2.0-M5.1-RC1/ The release tag is at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-M5.1-RC1/ Here is my +1 Ping ? The M5.1 has a very small delta from M5 and should be a easy review. I will try to get to this today, just have been too busy to spend time on it so far sorry. ...ant Sorry Luciano. Only just got to this. Will take a look now. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com - Rat looks OK - Build of source with clean repo initially failed with... Reason: POM 'org.apache.maven.plugins:maven-assembly-plugin' not found in reposi tory: Unable to download the artifact from any repository org.apache.maven.plugins:maven-assembly-plugin:pom:2.2-beta-3 But it worked this morning when I retried. - Key signatures look good - I tried some samples. The READMEs still leave a lot to be desired. This isn't any worse than M5 however. We know we have to make a better fist of this, hence the re-org in trunk. - The samples build against the staged maven artifacts - In the bin distro LICENCE file we refer to tuscany-assembly-xsd.jar and tuscany-sca-api.jar without explicit version numbers. This has always been the case but I wonder if we should. I also note that we refer to tuscany-assembly-xsd-osoa in the LICENSE which is not present any more. - There are some odd things in the src distro LICENSE file (they were like this in M5 but I for one didn't spot them). The module itest/databindings/common isn't in the src distro The module definitions-xml isn't in the src distro The last section which starts with... = The module assembly-xsd includes XSD files under the following license: The modules binding-ws-xml databinding databinding-axiom databinding-jaxb databinding-json databinding-sdo databinding-sdo-axiom databinding-xmlbeans interface-wsdl-xml Include the ipo.xsd and address.xsd information from the XML Schema Primer = It looks like the The module assembly-xsd includes XSD files under the following license: is just a cut and paste as this appears in front of the previous license. Some of the listed modules have been removed or merged with other modules. Some modules are missing. I believe the list should read. binding-ws databinding databinding-axiom databinding-jaxb databinding-jaxb-axiom databinding-json databinding-sdo databinding-sdo-axiom interface-wsdl I'd like to get the license files fixed before I vote to release. Regards As these are all present in 2.0-M5, do you really think this is a MUST before we release 2.0-M5.1 ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ Well the informal rule I've tried to apply so far in these kinds of cases is 1 - if we mention things that aren't in the distro then it's not great but I could live with it until the next distro 2 - if we don't mention things that are in the distro then that's not so good. There are several things that come under category 1 but I could live with them binding-ws, databinding-jaxb-axiom, interface-wsdl come under category 2 w.r.t that last license. The problem with this is where do you stop. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Created: (TUSCANY-3709) XSD defined in WSDL is leaking out into global scope
XSD defined in WSDL is leaking out into global scope Key: TUSCANY-3709 URL: https://issues.apache.org/jira/browse/TUSCANY-3709 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws The otests define many WSDL and some of then re-define the same XSD elements in different ways. This causes Tuscany problems as we aggregate WSDL together and hence sometimes, depending on which way the wind's blowing, we pick up the the wrong schema. This is evident in the following tests. Failed tests: testDummy(client.ASM_12007_TestCase) * testDummy(client.ASM_5016_TestCase) testDummy(client.ASM_6004_TestCase) testDummy(client.ASM_6007_TestCase) testDummy(client.ASM_12008_TestCase) * testDummy(client.ASM_6014_TestCase) testDummy(client.ASM_6008_TestCase) testDummy(client.ASM_6034_TestCase) I note that the two tests marked with * actually have incorrect expected error messages recorded because of this fault. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
After much messing about with compliance tests thinking that the reorg had broken them (only to find that there's a real issue there TUSCANY-3709) I've checked in the mods to demonstrate a structure which I think has most of the things different people have said they want in the distro. Here are the highlights... Source = distribution/ all/ pom.xml - uses our maven bundle plugin to general modules and to generate meta-data in features *.aggregation - aggregate jars for JSE user convenience b asically Ant's shade jars but without the detailed selection of content yet. Ant's done this before so is more likely to get it right - no manifests at the moment. Potentially difficult to add and don't know if we want to make these work in OSGi - based on either *-runtime collections in features/ or *-runtime in modules/ - I don't mind if these live here or somewhere else features/ all/ - modified to list all dependencies explicitly as I wanted to understand what was in it *-runtime - incremental function supporting the base + extension pattern - this is different from the features in that the features are really stand along collections. - I don't know whether these belong in features The remaining features - haven't changed them modules/ binding-rmi-runtime (+dependencies) pom.xml - have changed to refer to *-runtime as an example binding-ws-runtime-axis2 pom.xml - started to change to refere to *-runtime but couldn't complete as it mean changing too many other things itest/ builder pom.xml - changed to refer to *-runtime as an example compliance assembly pom.xml - changed to refer to *-runtime as an example Distro == modules/ - as before features/ all meta-data at the root level (would quite like to put this under an all diretory) *-runtime - meta data for bae + extension patern. Includes, for example, for base runtime... build-path.xml tuscany-base-runtime-manifest.jar which-jars lib/ tuscany-base-runtime-aggregation-2.0-SNAPSHOT.jar tuscany-binding-rmi-runtime-aggregation-2.0-SNAPSHOT.jar tuscany-binding-ws-runtime-axis2-aggregation-2.0-SNAPSHOT.jar tuscany-sca-api-2.0-SNAPSHOT.jar etc. - aggregate jars including all you need to do to run base extensions can be added as required - The ws jar is bigger than required as the ws runtime pom is not sorted properly yet. - I left the api jar here as something referred to it but don't think we really need it? So effectively we support several approaches to using the runtime in one distribution OSGI - load all the jars from modules JSE - Ant paths, manifest, standalone jars. I don't think we also need to provide standalone jars that don't include dependencies as if people want to pick and choose they can fall back to the modules directory and the what-jars list. There is necessarily duplication between the standalone jars and modules. I can live with this for the beta (I'm assuming that we're not going to produce a full set of standalone jars as a limited set probably reaches 80% of the users). This hopefully keeps people who what to see one solution or the other happy. We can stand back from the beta and decide whether this works. We may decide to go with one approach or the other, have multiple binary releases or push forward with something like this. As it's checked in now you can build it yourself. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0-M5.1 RC1
On Fri, Oct 8, 2010 at 6:44 PM, Luciano Resende luckbr1...@gmail.com wrote: On Fri, Oct 8, 2010 at 4:23 AM, Simon Laws simonsl...@googlemail.com wrote: Well the informal rule I've tried to apply so far in these kinds of cases is 1 - if we mention things that aren't in the distro then it's not great but I could live with it until the next distro 2 - if we don't mention things that are in the distro then that's not so good. There are several things that come under category 1 but I could live with them binding-ws, databinding-jaxb-axiom, interface-wsdl come under category 2 w.r.t that last license. The problem with this is where do you stop. Ok, I'll look into this over the weekend and provide a new RC -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ Hi Luciano I was looking at this and have a couple of LICENSE changes I'll commit shortly for review. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0-M5.1 RC1
Ok, I made some changes based on what I reported previously in this thread. Please take a look as see if this is correct. The artifacts in question are test only, shouldn't appear in the binary distro and hence I don't believe the LICENSE/NOTICE files shipped with the maven modules are affected. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0-M5.1 RC1
On Wed, Oct 6, 2010 at 5:50 PM, Simon Laws simonsl...@googlemail.com wrote: On Wed, Oct 6, 2010 at 7:48 AM, ant elder ant.el...@gmail.com wrote: On Wed, Oct 6, 2010 at 5:55 AM, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Oct 4, 2010 at 7:59 AM, Luciano Resende luckbr1...@gmail.com wrote: Please review and vote on RC1 of the SCA 2.0-M5.1 release. This is a minor relese based on 2.0-M5 and provides fixes to running Tuscany applications in Google AppEngine environment and other minor fixes to remove compliance tests run from part of the source distro build. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~lresende/tuscany/2.0-M5.1-RC1/ The release tag is at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-M5.1-RC1/ Here is my +1 Ping ? The M5.1 has a very small delta from M5 and should be a easy review. I will try to get to this today, just have been too busy to spend time on it so far sorry. ...ant Sorry Luciano. Only just got to this. Will take a look now. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com - Rat looks OK - Build of source with clean repo initially failed with... Reason: POM 'org.apache.maven.plugins:maven-assembly-plugin' not found in reposi tory: Unable to download the artifact from any repository org.apache.maven.plugins:maven-assembly-plugin:pom:2.2-beta-3 But it worked this morning when I retried. - Key signatures look good - I tried some samples. The READMEs still leave a lot to be desired. This isn't any worse than M5 however. We know we have to make a better fist of this, hence the re-org in trunk. - The samples build against the staged maven artifacts - In the bin distro LICENCE file we refer to tuscany-assembly-xsd.jar and tuscany-sca-api.jar without explicit version numbers. This has always been the case but I wonder if we should. I also note that we refer to tuscany-assembly-xsd-osoa in the LICENSE which is not present any more. - There are some odd things in the src distro LICENSE file (they were like this in M5 but I for one didn't spot them). The module itest/databindings/common isn't in the src distro The module definitions-xml isn't in the src distro The last section which starts with... = The module assembly-xsd includes XSD files under the following license: The modules binding-ws-xml databinding databinding-axiom databinding-jaxb databinding-json databinding-sdo databinding-sdo-axiom databinding-xmlbeans interface-wsdl-xml Include the ipo.xsd and address.xsd information from the XML Schema Primer = It looks like the The module assembly-xsd includes XSD files under the following license: is just a cut and paste as this appears in front of the previous license. Some of the listed modules have been removed or merged with other modules. Some modules are missing. I believe the list should read. binding-ws databinding databinding-axiom databinding-jaxb databinding-jaxb-axiom databinding-json databinding-sdo databinding-sdo-axiom interface-wsdl I'd like to get the license files fixed before I vote to release. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Trunk directory structure
On Thu, Oct 7, 2010 at 11:06 AM, ant elder ant.el...@gmail.com wrote: Hasn't most of the work been done now, and all thats left is how to group the shades, features and distribution folders, is there anything else? Don't think so. For those I think it would be fine to initially just move features and shades to be under distribution, that way the trunk top level is about as clean as its going to get and we can try moving about things in distribution/ as we go and people are less likely to mind about whats going on in there. ...ant Works for me. But I have some outstanding changes I'd like to commit in features before we move it. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples - build failing
On Thu, Oct 7, 2010 at 11:19 AM, Florian MOGA moga@gmail.com wrote: How much of this is this solved? Is this still an issue? I've pretty much got it working now. Still fails on Hudson with the artifact copy timeout that I posted about yesterday. I had my first clean build on Linux for a long time yesterday (I saw a couple of off compliance failures and also had to disable the enpoint-tribes test) so still a little work to do. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples - single pom.xml
On Thu, Oct 7, 2010 at 11:19 AM, Florian MOGA moga@gmail.com wrote: There were no negative comments on this topic. Can we proceed with the required changes for this? Remind me, was this was about having a single pom at the top level and poms in each of the leaf directories. Hence removing poms in between. If so I'm +0 on it. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples - async
On Thu, Oct 7, 2010 at 11:19 AM, Florian MOGA moga@gmail.com wrote: Should embedded-jse-async-sample-launcher/ be moved to running-tuscany/? sample-contribution-implementation-java-calculator-async/ would remain where it is now. We don't need a separate launcher for the asynch samples. It should just per part of the other launchers we already have. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples - launching samples
On Thu, Oct 7, 2010 at 11:18 AM, Florian MOGA moga@gmail.com wrote: Is everybody fine with using the shell for launching the samples? What's the current state of the shell? My concern here is that we have two shell implementations and the one in running tuscany is no the one, AFAIUI, that has been used to date. If we can't bring these together maybe we stick with two ways of doing things. Would be useful to have two subdirectories of running tuscany that describe the two approaches and why they are different. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples - osgi samples
On Thu, Oct 7, 2010 at 11:18 AM, Florian MOGA moga@gmail.com wrote: There are a number of samples which are not marked either as contributions or webapps: maven-osgi-junit, distributed-osgi, implementation-composite folder. Should these samples have -contribution appended at the end? would that make the names unnecessarily long? The OSGi ones are a bit tricky as they don't really match the new samples structure, maybe there should be a separate folder for OSGi in samples. I think they are OK where they are at the moment. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples - async
On Thu, Oct 7, 2010 at 11:32 AM, Florian MOGA moga@gmail.com wrote: Then what's the embedded-jse-async-sample-launcher/? Isn't it another type of launcher? On Thu, Oct 7, 2010 at 1:28 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Oct 7, 2010 at 11:19 AM, Florian MOGA moga@gmail.com wrote: Should embedded-jse-async-sample-launcher/ be moved to running-tuscany/? sample-contribution-implementation-java-calculator-async/ would remain where it is now. We don't need a separate launcher for the asynch samples. It should just per part of the other launchers we already have. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com IIUC it's the same as the embedded-jse launcher but just happens to launch the asynch samples. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Great. I don't think the base-runtime should include OSGi or Jetty as that drags in dependencies not needed in many environments. It also shouldn't include all those dependencies that are included as standard in Java 1.6. I still think base-runtime should include most things that can be included without draging in extra dependencies as well as things where it makes sense to have the transitive dependencies be provided or optional scope. So implementation-web could be included as implementation-java is. Another example is http host support, there's host-jetty and host-webapp, both of those need the servlet api and host-jetty needs jetty, the servlet api can be provided scope as that will work for both cases and jetty could be optional so its not included by default. ..ant I don't necessarily disagree with any of this. I think we just need to get the moving parts in the right place to build the distribution and then tune the content accordingly. I do wonder it there should be a separate minimal aggregation that meets the needs of 80% of users that is separate from the base + extension approach. Just a thought and something we can mull over later. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Trunk directory structure
I do say development should happen in trunk, thats a fundamental part of the Apache Way. I guess the point is that whats in trunk/contrib (now unreleased) is that its not being actively developed, most of its not been changed for months, its not included in any build, the pom.xmls are out of date so that it doesn't build, there is no doc, and there are no tests. Other than to the individuals who added the bits its just cruft that we're making everyone who checks out Tuscany download. Anyway, we've got trunk/unreleased now and as so many of you seem keen on it i guess that will stay but IMHO you should regularly consider why what you have put in there is there and either move it to contrib out of trunk or if its work to be continued move it to trunk proper. In 1.x quite a few (but not all) of the unreleased modules are in the build. I'm not sure what their status is in terms of tests and documentation. I agree that things shouldn't stay in trunk/unreleased as a long-term state of affairs. Its purpose should be as a staging post toward becoming part of a release. I think the first step for 1.x should be to move the unreleased modules and samples to trunk/unreleased and see what ends up there. The second step would be to see whether anyone wants to put in the work to get these things into a releasable state. If not, they can be moved out of trunk and archived. Simon +1 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: trunk structure - trunk/contrib folder
There are other advantages of having the unreleased code in trunk and in the default top-level trunk build. 1. Having it in trunk makes it clear that it's part of trunk and that people making changes to trunk need to take account of any impact that their changes have on this code. 2. Having it in the default build (not just the Hudson build) makes it immediately obvious if something is broken and requires people to take positive action to correct or work around the problem. Simon +1 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
New article SCA revisited: Helios and Eclipse SCA tools
Just a FYI. The following link was pointed out to me. It talks about using Tuscany with the Eclipse STP project. http://www.ibm.com/developerworks/web/library/wa-scatools/index.html Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
I've now checked in two new modules in the features directory... tuscany-core-runtime tuscany-base-runtime The core-runtime is the set modules required to implement extensions (exact set still TBD as there's probably too much in there now) The base-runtime is core-runtime + the modules required for a minimum runtime, i.e impl.java + local wiring. (this includes OSGi runtime stuff at the moment. We may want a base specifically targetting OSGi). I've made some changes to binding-rmi and binding-ws to demonstrate how these would be used in the runtime. E.g. the binding-rmi model pom dependencies are now dependencies dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-core-runtime/artifactId version2.0-SNAPSHOT/version typepom/type scopeprovided/scope /dependency /dependencies While the binding-rmi-runtime dependencies are... dependencies dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-core-runtime/artifactId version2.0-SNAPSHOT/version typepom/type scopeprovided/scope /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-rmi/artifactId version2.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-host-rmi/artifactId version2.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-base-runtime/artifactId version2.0-SNAPSHOT/version typepom/type scopetest/scope /dependency /dependencies This leads to the following collections of jars core-runtime not shipped independently as the user can't do anything with it base-runtime XmlSchema-1.4.3.jar activation-1.1/activation-1.1.jar asm-3.1/asm-3.1.jar cglib-2.2/cglib-2.2.jar commons-cli-1.2.jar geronimo-stax-api_1.0_spec-1.0.1.jar jaxb-api-2.1/jaxb-api-2.1.jar jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar jaxws-api-2.1/jaxws-api-2.1.jar jetty-6.1.19.jar jetty-util-6.1.19.jar jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar jsr250-api-1.0/jsr250-api-1.0.jar osgi-3.5.0-v20090520.jar services-3.2.0-v20090520-1800.jar servlet-api-2.5/servlet-api-2.5.jar tuscany-assembly-2.0-SNAPSHOT.jar tuscany-assembly-xml-2.0-SNAPSHOT.jar tuscany-assembly-xsd-2.0-SNAPSHOT.jar tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar tuscany-binding-ws-2.0-SNAPSHOT.jar tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar tuscany-builder-2.0-SNAPSHOT.jar tuscany-common-java-2.0-SNAPSHOT.jar tuscany-common-xml-2.0-SNAPSHOT.jar tuscany-contribution-2.0-SNAPSHOT.jar tuscany-contribution-osgi-2.0-SNAPSHOT.jar tuscany-core-2.0-SNAPSHOT.jar tuscany-core-databinding-2.0-SNAPSHOT.jar tuscany-core-spi-2.0-SNAPSHOT.jar tuscany-databinding-2.0-SNAPSHOT.jar tuscany-databinding-jaxb-2.0-SNAPSHOT.jar tuscany-deployment-2.0-SNAPSHOT.jar tuscany-extensibility-2.0-SNAPSHOT.jar tuscany-extensibility-equinox-2.0-SNAPSHOT.jar tuscany-host-http-2.0-SNAPSHOT.jar tuscany-host-jetty-2.0-SNAPSHOT.jar tuscany-implementation-java-2.0-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar tuscany-implementation-osgi-2.0-SNAPSHOT.jar tuscany-interface-java-2.0-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar tuscany-interface-wsdl-2.0-SNAPSHOT.jar tuscany-monitor-2.0-SNAPSHOT.jar tuscany-node-api-2.0-SNAPSHOT.jar tuscany-node-impl-2.0-SNAPSHOT.jar tuscany-node-impl-osgi-2.0-SNAPSHOT.jar tuscany-node-launcher-2.0-SNAPSHOT.jar tuscany-node-launcher-equinox-2.0-SNAPSHOT.jar tuscany-policy-security-2.0-SNAPSHOT.jar tuscany-sca-api-2.0-SNAPSHOT.jar tuscany-xsd-2.0-SNAPSHOT.jar wsdl4j-1.6.2/wsdl4j-1.6.2.jar wstx-asl-3.2.6/wstx-asl-3.2.6.jar binding-rmi-runtime tuscany-binding-rmi-2.0-SNAPSHOT.jar tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar tuscany-host-rmi-2.0-SNAPSHOT.jar The binding-ws-runtime-axis dependency list is not as clean yet as I had to leave the wsdlgen dependency in lest I break the majority of the itests. The fix is to have the itests refer to base-runtime as well. Here's an example of the builder itest converted to use base-runtime. dependencies dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-base-runtime/artifactId version2.0-SNAPSHOT/version typepom/type /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-ws-runtime-axis2/artifactId version2.0-SNAPSHOT/version /dependency dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.1/version scopetest/scope /dependency /dependencies However I didn't want to do it all at once. I will make
Re: Trunk directory structure
On Wed, Oct 6, 2010 at 10:54 AM, Florian MOGA moga@gmail.com wrote: I've seen you guys started committing things related to the distribution structure. Could you as well make the agreed adjustments on the trunk directory structure as they are two tightly related operations? Are we sticking to the features + distribution + shades folders? I think the new distro structure enables us to reduce all that to a single directory. I think we can have a single folder. What should it be called? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Trunk directory structure
On Wed, Oct 6, 2010 at 11:30 AM, Florian MOGA moga@gmail.com wrote: distribution sounds good to me... In the distribution folder we already have all and tomcat. What directory should we use to collect together the projects that describe collections of jars but which are not, in their own right, distributions, e.g. core-runtime, base-runtime etc. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Trying to get build through Hudson
After some tidying our build is now consistently failing in Hudson when it tries to archive the artifacts that the distro build produces. The archive step takes ages for all of the artifacts for some reason but it times out with the large zips that we produce for the distro. [INFO] Installing /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/pom.xml to /export/home/hudson/.m2/repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT.pom [INFO] Installing /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/target/apache-tuscany-sca-all-2.0-SNAPSHOT.tar.gz to /export/home/hudson/.m2/repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT.tar.gz [INFO] Installing /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/target/apache-tuscany-sca-all-2.0-SNAPSHOT.zip to /export/home/hudson/.m2/repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT.zip [INFO] Installing /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/target/apache-tuscany-sca-all-2.0-SNAPSHOT-src.tar.gz to /export/home/hudson/.m2/repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT-src.tar.gz [INFO] Installing /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/target/apache-tuscany-sca-all-2.0-SNAPSHOT-src.zip to /export/home/hudson/.m2/repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT-src.zip [HUDSON] Archiving /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/pom.xml to /home/hudson/hudson/jobs/Tuscany-2x/modules/org.apache.tuscany.sca$tuscany-distribution-all/builds/2010-10-06_08-20-11/archive/org.apache.tuscany.sca/tuscany-distribution-all/2.0-SNAPSHOT/pom.xml [HUDSON] Archiving /export/home/hudson/.m2/repository/org/apache/tuscany/sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT.pom to /home/hudson/hudson/jobs/Tuscany-2x/modules/org.apache.tuscany.sca$tuscany-distribution-all/builds/2010-10-06_08-20-11/archive/org.apache.tuscany.sca/tuscany-distribution-all/2.0-SNAPSHOT/tuscany-distribution-all-2.0-SNAPSHOT.pom [HUDSON] Archiving /export/home/hudson/hudson-slave/workspace/Tuscany-2x/sca-2x/distribution/all/target/apache-tuscany-sca-all-2.0-SNAPSHOT.tar.gz to /home/hudson/hudson/jobs/Tuscany-2x/modules/org.apache.tuscany.sca$tuscany-distribution-all/builds/2010-10-06_08-20-11/archive/org.apache.tuscany.sca/tuscany-distribution-all/2.0-SNAPSHOT/apache-tuscany-sca-all-2.0-SNAPSHOT.tar.gz Build timed out. Aborting The odd thing is that looking at the build configuration we haven't got the archive artifacts check box selected. Before I ask on the build list has someone configured some other magic that's causing this archive step to take place? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0-M5.1 RC1
On Wed, Oct 6, 2010 at 7:48 AM, ant elder ant.el...@gmail.com wrote: On Wed, Oct 6, 2010 at 5:55 AM, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Oct 4, 2010 at 7:59 AM, Luciano Resende luckbr1...@gmail.com wrote: Please review and vote on RC1 of the SCA 2.0-M5.1 release. This is a minor relese based on 2.0-M5 and provides fixes to running Tuscany applications in Google AppEngine environment and other minor fixes to remove compliance tests run from part of the source distro build. The distribution artifacts, RAT reports, and Maven staging repository are available for review at: http://people.apache.org/~lresende/tuscany/2.0-M5.1-RC1/ The release tag is at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-M5.1-RC1/ Here is my +1 Ping ? The M5.1 has a very small delta from M5 and should be a easy review. I will try to get to this today, just have been too busy to spend time on it so far sorry. ...ant Sorry Luciano. Only just got to this. Will take a look now. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Build issue?
On Sat, Sep 18, 2010 at 9:41 AM, Simon Laws simonsl...@googlemail.com wrote:
On Fri, Sep 17, 2010 at 7:27 PM, Raymond Feng enjoyj...@gmail.com wrote:
Hi,
I'm running into some build issues for Tuscany 2.x trunk. Do any of you see
the same problem.
I use git svn to check out the code and it doesn't support svn:externals. Do
we need to have the OASIS test cases checked out?
Thanks,
Raymond
[INFO]
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests
Assembly (during install)
[INFO]
[INFO] Compilation failure
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[34,17]
package testClient does not exist
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[35,13]
package client does not exist
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[41,45]
cannot find symbol
symbol: class RuntimeBridge
public class TuscanyRuntimeBridge implements RuntimeBridge {
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[208,26]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[209,12]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[209,42]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
[INFO]
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests
Java CAA (during install)
[INFO]
[INFO] Compilation failure
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/java-caa/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[34,17]
package testClient does not exist
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/java-caa/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[35,13]
package client does not exist
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/java-caa/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[41,45]
cannot find symbol
symbol: class RuntimeBridge
public class TuscanyRuntimeBridge implements RuntimeBridge {
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/java-caa/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[208,26]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/java-caa/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[209,12]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
/Users/rfeng/Projects/tuscany-git/tuscany-sca-2.x/compliance-tests/java-caa/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[209,42]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
Raymond Feng
rf...@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
H Raymond,
No need to have the OASIS stuff checked out. It should just work but
obviously I've messed something up. Let me take a look
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Hi Raymond
I just spotted a problem when building on linux that may have been
causing a problem in your environment. Firstly their was a lurking
dependency on an OASIS maven artifact that isn't available in the
maven repos. Secondly one of the tests zips that we've published
temporarily had it name changed erroneously to be all caps. I've
believe I've fixed both of these now
Simon
--
Apache Tuscany committer: tuscany.apache.org
Re: [jira] Created: (TUSCANY-3703) implmentation.composite not working in 1.6
On Tue, Oct 5, 2010 at 4:04 PM, antony (JIRA) dev@tuscany.apache.org wrote: implmentation.composite not working in 1.6 -- Key: TUSCANY-3703 URL: https://issues.apache.org/jira/browse/TUSCANY-3703 Project: Tuscany Issue Type: Test Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.6 Environment: SCA 1.6, JSF, Hibernate Web Application Reporter: antony Fix For: Java-SCA-1.6.1 I have two composite under web-inf directory. web.compoiste, test.composite. where one of the component implementation in web.composite is implemented in test.composite. web.composite: - Component name=XXXComponent implementation.java class=com.test../ reference name=userService target=TargetComponent interface.java interface=com.test.IUser / /reference /Component component name=TargetComponent implementation.composite name=sample:test/ /component test.composite: -- component name=UserComponent implementation.java class=com.test.impl.UserImpl/ /component service name=userService promote=UserComponent interface.java interface=com.test.IUser / /service But this throws a warning while starting the serverComponent reference userService does not have a binding which matches the bindings of service $promoted$TargetComponent$slash$userService. While running my application, it throws below error. Unable to create SCA binding invoker for local target XXXComponent reference userService (bindingURI=TargetComponent operation=methodxxx) But the same code works in sca 2.0M5. I am migrating my code to 1.6. can u please tell what is missing/wrong here? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. Hi Antony Which bindings do you have defined on the services and references? Or are there no bindings defined as you've indicated here? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
logging-scribe sample errors
When I run the logging-scribe sample I get... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.thrift:libthrift:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.thrift -DartifactId=libthrif t -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.thrift -DartifactId=libthrift -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -Dreposi toryId=[id] Path to dependency: 1) org.apache.tuscany.sca:sample-logging-scribe:jar:2.0-SNAPSHOT 2) org.apache.thrift:libthrift:jar:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-logging-scribe:jar:2.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/), java.net (http://download.java.net/maven/1), ibiblio.org (http://mirrors.ibiblio.org/pub/mirrors/maven2), intalio.org (http://www.intalio.org/public/maven2), tuscany.repo (http://svn.apache.org/repos/asf/tuscany/maven), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), java.net2 (http://download.java.net/maven/2), apache.ws.zone (http://ws.zones.apache.org/repository2), osuosl.org (http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2) So firstly this sample depends on a snapshot which isn't great. Thrift isn't represented in the new snapshot repo hence the build can't find it. The sample is commented out at the moment so I guess someone who knows about it could fix it or we could move it to contrib if it's not ready for release? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Compliance tests and Releases
On Sat, Oct 2, 2010 at 4:44 PM, Luciano Resende luckbr1...@gmail.com wrote: While trying to build the M5 branch, I remembered we were depending on the OASIS test runners deployed to our own repositories and it looks like we didn't produce a release of those artifacts. I noticed we already move into the direction of using tuscany internal maven repo instead of the one in ant's people account, which is good, but are we planning to release these artifacts as part of our official releases ? Or are we going to disable the compliance tests in our official releases ? AFAIK, users probably care if we are compliant or not, but they don't need/want to run the compliance tests themselves. Thoughts ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ I don't think we should ship the compliance tests or encourage people to use the compliance zips that are currently in out svn repo. We should though encourage OASIS to hosts versions of the jars which they don't do yet. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
On Fri, Oct 1, 2010 at 9:15 AM, Florian MOGA moga@gmail.com wrote: dosgi-dynamic-calculator-operations fails as well... I've committed the poms with the failing samples commented out. Do you think it's worth checking them out now or wait until we implement the new build structure as we'll need to get through all of the samples again? On Fri, Oct 1, 2010 at 10:49 AM, Florian MOGA moga@gmail.com wrote: All the samples were building successfully in maven relatively recently. I think we should make them work regardless of the new structure otherwise we won't know if the sample is failing or if the structure is causing it to fail. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Doing another 2.x release in a few weeks?
On Fri, Oct 1, 2010 at 9:19 AM, Florian MOGA moga@gmail.com wrote: Simon, are you suggesting to cut down a branch prior to doing the build structure modifications and make them on the branch? What's the procedure you are following when doing a release? No, I'm suggesting we get trunk into shape and then cut the branch. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [1.6.1] Replacing download.java.net by mirrors.ibiblio.org
I'm very surprised to hear about these failures. I haven't seen anything like this, so there must be some difference in your environment from mine. Can anyone else try this and report their results? Simon I'll give it a go but it'll take a little while. Doing svn up now. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [1.6.1] Replacing download.java.net by mirrors.ibiblio.org
On Fri, Oct 1, 2010 at 9:34 AM, Simon Laws simonsl...@googlemail.com wrote: I'm very surprised to hear about these failures. I haven't seen anything like this, so there must be some difference in your environment from mine. Can anyone else try this and report their results? Simon I'll give it a go but it'll take a little while. Doing svn up now. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com OK looks good to me [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 29 minutes 53 seconds [INFO] Finished at: Fri Oct 01 01:56:25 PDT 2010 [INFO] Final Memory: 654M/986M [INFO] [simon_l...@tuscany sca-java-1.6.1]$ That was on Linux Java = java version 1.6.0_07 Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) Maven = 2.1.0 Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
snip... what's the async folder? it's got modules-like pom and seems to include a launcher... shouldn't the launcher get into running-tuscany and the other one into getting-started as comments say it demonstrates synchronous/asynchronous invocation? I'm going to defer commenting on this one to others for now as i'd need to go work out what its really trying to show an dhow best to do that It's just showing asyn operations. There's no need for a launcher in here as it should work with any of the other lauchers (need to be tests of course). there are a number of samples which are not marked either as contributions or webapps: maven-osgi-junit, distributed-osgi, implementation-composite folder. Should these samples have -contribution appended at the end? would that make the names unnecessarily long? I think the things in implementation-composite should be moved to getting started Moving one would be fine. Don't need both in getting started. I suggest we leave the ws version in learning-more. I.e. you don't need to show the user every combination in getting started. That's what learning-more gives us the the opportunity to do. The OSGi ones are a bit tricky as they don't really match the new samples structure, maybe there should be a separate folder for OSGi in samples. Why do you say that they don't match the structure? They are contributions that can we started with (OSGi) launchers. ...ant Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Trunk directory structure
On Fri, Oct 1, 2010 at 12:29 PM, ant elder ant.el...@gmail.com wrote: On Fri, Oct 1, 2010 at 12:24 PM, Simon Nash n...@apache.org wrote: ant elder wrote: On Fri, Oct 1, 2010 at 10:56 AM, Luciano Resende luckbr1...@gmail.com wrote: What should we do with contrib? From previous long discussion, contrib should in trunk, and can be excluded from a release. I think we should revisit trunk/contrib. The suggested purpose was that it was a place to put things that were to be built with the trunk build to ensure that they don't get broken. I don't think that happens, for one most of the contrib stuff isn't finished so doesn't have any tests so we've no idea if it actually does work or not, and secondly AFAICT no one, and i mean no one, actually builds trunk/contrib regularly anyway. I agree with Florian and think we should get rid of it and just use the other contrib folder. ...ant I think trunk/contrib is a good idea and I'd like to put this structure into 1.x after 1.6.1 is done. It would be used for the thiungs currently in trunk but not included in releases. Whats the problem with instead just putting those things in the existing contrib folders at tuscany/sca-java-1.x/contrib/ and tuscany/sca-java-2.x/contrib/? ...ant It's more convenient for me personally to have them under trunk/contrib which means that I can check trunk out and get the contrib stuff too. At the higher level I have to check two separate trees out or pull down all the tags and branches also. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Created: (TUSCANY-3701) Error on Geronimo Transaction Manager start sometimes when running in OSGi
Error on Geronimo Transaction Manager start sometimes when running in OSGi -- Key: TUSCANY-3701 URL: https://issues.apache.org/jira/browse/TUSCANY-3701 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-M5 Environment: OSGi Reporter: Simon Laws Seeing the following error when starting from OSGi. I'm going to prevent the transaction manager starting in the OSGi envrionment by commenting out the start in the TransactionModuleActivator SEVERE: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory at org.slf4j.LoggerFactory.clinit(LoggerFactory.java:60) at org.apache.geronimo.transaction.log.HOWLLog.clinit(HOWLLog.java:60) at org.apache.tuscany.sca.policy.transaction.runtime.geronimo.TransactionManagerWrapper.start(TransactionManagerWrapper.java:61) at org.apache.tuscany.sca.policy.transaction.runtime.geronimo.TransactionModuleActivator.start(TransactionModuleActivator.java:57) at org.apache.tuscany.sca.core.DefaultModuleActivatorExtensionPoint.start(DefaultModuleActivatorExtensionPoint.java:130) at org.apache.tuscany.sca.extensibility.ServiceHelper.start(ServiceHelper.java:46) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.addExtensionPoint(DefaultExtensionPointRegistry.java:75) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:110) at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.init(NodeFactoryImpl.java:268) at org.apache.tuscany.sca.node.osgi.impl.OSGiNodeFactoryImpl.init(OSGiNodeFactoryImpl.java:107) at org.apache.tuscany.sca.osgi.remoteserviceadmin.impl.AbstractOSGiServiceHandler.init(AbstractOSGiServiceHandler.java:67) at org.apache.tuscany.sca.osgi.remoteserviceadmin.impl.OSGiServiceExporter.start(OSGiServiceExporter.java:73) at org.apache.tuscany.sca.osgi.remoteserviceadmin.impl.RemoteServiceAdminImpl.start(RemoteServiceAdminImpl.java:78) at org.apache.tuscany.sca.node.osgi.impl.NodeActivator.start(NodeActivator.java:69) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tuscany 2.x trunk build has been broken for a while
On Fri, Oct 1, 2010 at 4:45 PM, Raymond Feng enjoyj...@gmail.com wrote:
Hi,
I'm struggling to get a clean build of the latest Tuscany 2.x trunk these
days. There are a tons of errors/failures. There are even compilation errors
such as:
[INFO] Error for project: Apache Tuscany SCA Specification Compliance Tests
Assembly (during install)
[INFO]
[INFO] Compilation failure
/Users/rfeng/Projects/tuscany/sca-java-2.x/trunk/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[34,17]
package testClient does not exist
/Users/rfeng/Projects/tuscany/sca-java-2.x/trunk/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[35,13]
package client does not exist
/Users/rfeng/Projects/tuscany/sca-java-2.x/trunk/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[41,45]
cannot find symbol
symbol: class RuntimeBridge
public class TuscanyRuntimeBridge implements RuntimeBridge {
/Users/rfeng/Projects/tuscany/sca-java-2.x/trunk/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[208,26]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
/Users/rfeng/Projects/tuscany/sca-java-2.x/trunk/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[209,12]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
/Users/rfeng/Projects/tuscany/sca-java-2.x/trunk/compliance-tests/assembly/src/test/java/org/apache/tuscany/sca/otest/TuscanyRuntimeBridge.java:[209,42]
cannot find symbol
symbol : class TestException_Exception
location: class org.apache.tuscany.sca.otest.TuscanyRuntimeBridge
Any clue what's going on? We need to get the build working again!
Thanks,
Raymond
Raymond Feng
rf...@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
There are quite a few failures due to the sample tidying. I have some
fixes but svn is down.
I don't remember seeing this compilation failure but I'll double check.
The thing I've been seeing for a little while is the rat failures in
the source distro. Haven't got to that yet.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Issue with InterfaceContract under reference target
On Fri, Oct 1, 2010 at 4:49 PM, Raymond Feng enjoyj...@gmail.com wrote: That sounds right. Raymond Feng Sent from my iPhone On Oct 1, 2010, at 7:33 AM, Yang Lei yl.yangle...@gmail.com wrote: I have my own webservices binding implementation in my OASIS hosting environment. I noticed when reference target is defined, service and reference side will share the share InterfaceContract instance. My service side and reference side are using (forced to use) different databinding. This object sharing cased me trouble running some of the OASIS spec compliance test as the databinding on the service side messed up, as reference side will be configured later than service side. I fixed the issue by making my reference side of binding clone the InterfaceContract before reset the databinding. However I would like to understand if it is correct behavior to share the same interfaceContact instance between service side and reference side... Appreciate thoughts and comments. I encountered the issue on JCA_11003 and a couple of other test cases under JCA and POJO. -- Thanks. Yang. Agreed. In OASIS, for references with targets, we copy the binding model from the service and I expect this is where the same interface contract gets pulled across. I'll check but we need the fix in Tuscany if you're happy to create a JIRA/patch? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Created: (TUSCANY-3702) Many failures due to sample moves
Many failures due to sample moves - Key: TUSCANY-3702 URL: https://issues.apache.org/jira/browse/TUSCANY-3702 Project: Tuscany Issue Type: Bug Environment: All Reporter: Simon Laws Recent sample moves have left lots of things failing (can we try and not checking in moved things without first testing that nothing is broken as a result - the svn move is the easy bit!). I have fixes but svn is down. I'm attaching a patch as I have to go now and it would be a shame to have someone else spend another day trying to fix this up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3702) Many failures due to sample moves
[ https://issues.apache.org/jira/browse/TUSCANY-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-3702: Attachment: 3702-1.patch May not give a completely clean build but gets closer. I'll commit all this if I see Apache svn come back to life. Many failures due to sample moves - Key: TUSCANY-3702 URL: https://issues.apache.org/jira/browse/TUSCANY-3702 Project: Tuscany Issue Type: Bug Environment: All Reporter: Simon Laws Attachments: 3702-1.patch Recent sample moves have left lots of things failing (can we try and not checking in moved things without first testing that nothing is broken as a result - the svn move is the easy bit!). I have fixes but svn is down. I'm attaching a patch as I have to go now and it would be a shame to have someone else spend another day trying to fix this up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Doing another 2.x release in a few weeks?
On Fri, Oct 1, 2010 at 6:03 PM, Luciano Resende luckbr1...@gmail.com wrote: On Fri, Oct 1, 2010 at 1:26 AM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Oct 1, 2010 at 9:19 AM, Florian MOGA moga@gmail.com wrote: Simon, are you suggesting to cut down a branch prior to doing the build structure modifications and make them on the branch? What's the procedure you are following when doing a release? No, I'm suggesting we get trunk into shape and then cut the branch. Guys, I'm really in need of a new release, and it seems that we are spending too much time on structuring the source/samples instead. Do you guys think we are going to have a release in the next two weeks ? Otherwise I'll try to cut a M5.1 or M6 (based on m5) in the next couple days with the fixes I need. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ Hi Luciano I'd very much like to get the release out ASAP. I think we've done enough thinking about restructuring to do the beta release. The beta will give us the chance to stand back and see if we like it or not. There is still lots to do in terms of fixing sample build scripts/READMEs/docs etc. but I hope that won't take too long and we *can* do this within two weeks. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Doing another 2.x release in a few weeks?
On Thu, Sep 30, 2010 at 8:29 AM, ant elder ant.el...@gmail.com wrote: On Wed, Sep 29, 2010 at 6:27 PM, Simon Laws simonsl...@googlemail.com wrote: How about we start to making progress on the Beta release again... Things are looking ok I believe from an otest point of view. We've had discussion about the samples and that looks to be shaping up. We've also had disscussion about the distro structure and there are lots of ideas. I think we need a release to review and to focus the mind. Big +1 from me, it would be great to get a release done and then get into the habit again of much more regular releases. ...ant Yep agreed. Needs to be a straightforward process. I think quite a bit of the pain has been taken out with some of the automation and testing that's in 2.x now. Re. the beta release. I suggest we cut the branch again rather than trying to use the existing one. There is though quite a bit of tidying we can do in trunk, e.g. there was more sample name tidying suggested and we need to tidy the sample poms and build.xml files and make sure classes and wars etc are excluded. How about we cut the branch tomorrow or Monday? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng enjoyj...@gmail.com wrote: To me, the extension is just a feature that contains only the modules that make up the extension :-). For example, I can model the binding.ws extension as feature-binding-ws (a pom project that list feature-base, binding-ws, binding-ws-runtime-axis2, etc.). Absolutely you could do that and still can in fact. I was thinking of the extensions slightly differently though in that the extension dependencies should exclude the dependencies for base. I.e. you always need base and then add whatever extensions you want. So, for example, if I wanted to run Tuscany with binding.ws and binding.rmi I don't need a bindingws+rmi feature I just use base + ws + rmi. Now you may very well have a feature caled banana that happens to contain base, ws and rmi. Nothing wrong with that, it's just that that's a slightly different world view. So what I've found with this exercise is that different people have different ways of looking at the problem. And as is the way with these things it seems that reaching absolute agreement may be tricky. However with the beta we have the opportunity to actually try them out and see what value the different approaches bring. We may decide we want them all, one of them or something different. I don't know a way to combine more than one config.ini. But if we generate the config.ini per feature, it will contain the bundles from the base. Isn't that good enough? I understand it doesn't support the case where you start Equinox with base and then try to add the extension. k, thanks. I'd concluded the same so maybe this is a restriction and we don't generate the config.ini for extensions. So maybe this is the real difference between extensions and features. Features can be installed directly into OSGi extensions don't have config.ini support and manual configuration is required. This doesn't mean that I believe extensions have any less value. In fact recent experience of this suggests that setting up an OSGi environment for Tuscany in combination with other products isn't a carefree as just dumping all the Tuscany jars in there. Care and attention is required to avoid nasty wiring conflicts. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Thu, Sep 30, 2010 at 9:04 AM, ant elder ant.el...@gmail.com wrote: On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng enjoyj...@gmail.com wrote: To me, the extension is just a feature that contains only the modules that make up the extension :-). What is the point in that? We call them extensions everywhere else (doc, spec, code, website etc), so it seems simpler to not obfuscate things but bringing in the feature term. ...ant It's not clear to me that it's an either or. Features and extensions seem different to me. my 2c. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Thu, Sep 30, 2010 at 9:06 AM, ant elder ant.el...@gmail.com wrote: On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws simonsl...@googlemail.com wrote: There is an issue though. The extension meta-data repeats all the dependencies that base provides. This actually doesn't make a difference because the duplicates don't have a material impact on the classpath (other than we might generate a classpath that is too long). Aesthetically, and possibly for classpath length reasons, though it's not that pleasing and so it could be useful to know when we're dealing with extensions to filter our base dependencies from their meta data. I agree, it would be much nicer if we can get them to only include their own dependencies so i think we should try to fix that. ...ant Y, two ways come to mind initially... 1/ We create a pom for each extension and use Maven dependency mechanisms to exclude base dependencies. Is there a way to do that simply? I.e. do an exclude for base and all it's transitive dependencies without having to be explicit. For example, make base a provided dependency. However I presume that means we need to change things across the poms in modules to follow this pattern also. 2/ Alternatively we could rely on bundle plugin like logic which knows internally what the dependencies are and can filter. 2 is initially attractive as it would be straightforward to implement however I don't think its the right ways as it hides the process inside the plugin. Using a pom (1) would seem the most appropriate/obvious way if we can make it work. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
I think this will be difficult if the base is made up of a large number of jars and poms. AIUI the exlude list would have to name all the poms in the base. If the list of poms in the base ever changes then all the exclude lists would have to change as well. A simple solution would be to create a single jar in the maven repository called tuscany-sca-base. This could be made up of the contents of a number of other maven jars but this relationship wouldn't be exposed via maven. A further thought on this: to make it work, extensions would have to be built with poms that include tuscany-sca-base and not with poms that include all the different base components individually. This could be inconvenient for developers of base components as it would be necessary to rebuild tuscany-sca-base every time an individual base component changes. Simon Hi Simon Well it would work ok if the base remained as an pom type pom which just groups together other modules. The only time this would need rebuilding would be when the set of dependency jars change. Which isn't very often. The question then remains whether you can exclude the dependencies without unnecessarily arduous exclude editing. The other drawback of this is that Ant found problems when depending on this pom type pom in order to build aggregate jars. I can't remember precisely what the problem was off the top of my head. So it needs some experimentation to see what really can be made to work. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: BarCamp - Session1 - JIRA cleanup discussion notes
On Thu, Sep 30, 2010 at 4:50 PM, Florian MOGA moga@gmail.com wrote: What about a Samples category as well? On Thu, Sep 30, 2010 at 4:57 PM, Florian MOGA moga@gmail.com wrote: Hi Brent, The idea for the User folder is that it would help us avoid issues being assigned to the wrong category (might not be the case for such general categories) but most important user reported issues will go through a triage phase and become official issues after we take a look at them. It will also be a measure for us to monitor how much user activity we have and the common problems they are facing. The Ideas section would be destined for things like How about having an implementation.jpa?. Google Summer of Code project ideas would fit in too. As a high level view it would contain ideas that also need some research or it is not sure that something like that is possible. It would basically be a place where to store the ideas you have and don't have time to expoit in order not to forget them. At some point I saw a page on the tuscany website trying to do this but I can't find it at the moment... The main idea is that user issues might be so many that they would make the list verbose and the ideas issues would be such a small number that it will be hard to find them. I don't know exactly but I'm expecting that from the current opened issues a big part are user reported issues which most of them are out dated, not affecting them or we don't have any clue about them anymore. Does this make sense? Florian On Thu, Sep 30, 2010 at 3:38 PM, Brent Daniel brenthdan...@gmail.com wrote: +1 on the shortened list of JIRA categories. The current granularity doesn't seem to be all that helpful. I'm not sure if there needs to be a separate section for user questions -- with the shortened list it should be possible for even the newest of users to find a home for a JIRA. Similarly for Ideas, it seems like most issues would fit into one of the other categories. Are there current examples of JIRAs that would fit best in a separate Ideas section? Brent On Thu, Sep 30, 2010 at 4:48 AM, Florian MOGA moga@gmail.com wrote: Since we're cleaning up things I took a look again at the JIRA Categories. I propose simply having: Java SCA Java SDO Java DAS C++ SCA C++ SDO C++ DAS OASIS Tools (including Hudson, Maven, SVN issues) Website/Documentation User Questions Ideas instead of having ~30 categories which nobody uses... It seems simpler and gives us the functionality we need out of it. Regarding the User Questions section we can let users report issues in there and only after an investigation from our side we can promote them to the appropriate category. Seems fair enough... SDO and DAS sections seem to have some a considerable number of issues opened (~20%). How can we clean those up? On Sat, Sep 18, 2010 at 9:20 PM, Luciano Resende luckbr1...@gmail.com wrote: On Sat, Sep 18, 2010 at 4:36 AM, Simon Laws simonsl...@googlemail.com wrote: Current status 1500 closed 1560 resolved 500 Open (365 SCA) Each person, for those that you've opened Close resolved ones Close open JIRA that no longer apply Can do this without sending email although the check box seems to have been removed I'm not seeing the option to transition jiras without sending e-mails, do I need to be admin to do that ? otherwise I don't think we want 200 more e-mails just to move from fixed to close :) For JIRA that fall out of this process Take it to the list Mail back to the user? We can try and group correctly - Feature request vs Bug Use will not fix if we really think we're not going to do anything Categories general dissatisfaction with JIRA categories we have as they are not really used Try to convert to a shorter list (should try and match distribution structure?) base runtime binding.ws binding.jms etc for the main extensions Look at this list when we've talked about release artifacts Encourage people to use unknown rather than guessing SCA Java is default so would need SCA Native, SDO Java etc There are several uncategorized ones, should we handle those as well ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ I'd like to maintain the two OASIS categories as it distinguishes between those issues Tuscany has to do something about and those issues that OASIS have to do something about. Other than that I'm +1 on reducing the granularity. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Well it would work ok if the base remained as an pom type pom
which just groups together other modules. The only time this would
need rebuilding would be when the set of dependency jars change. Which
isn't very often.
The question then remains whether you can exclude the dependencies
without unnecessarily arduous exclude editing.
The other drawback of this is that Ant found problems when depending
on this pom type pom in order to build aggregate jars. I can't
remember precisely what the problem was off the top of my head.
So it needs some experimentation to see what really can be made to work.
I've looked at this before and I don't think there is an easy
non-arduous way to do the excludes. The simplest solution to me is to
have the extensions use provided scope for the base dependencies.
...ant
This approach seems OK to me.
Simon
So to be more concrete what were looking at is having
tuscany-base-runtime defined something like
artifactIdtuscany-base-runtime/artifactId
nameApache Tuscany SCA Base Runtime/name
packagingpom/packaging
!--
The dependencies required to run the Assembly otests minus
the web service
binding (which is only required by the otest framework).
Provides a minimum
set of function for running composites using
implementation.java and local
wiring. Other extensions can be added to this base when required
--
dependencies
dependency
groupIdorg.apache.tuscany.sca/groupId
artifactIdtuscany-assembly/artifactId
version${pom.version}/version
/dependency
dependency
groupIdorg.apache.tuscany.sca/groupId
artifactIdtuscany-assembly-xml/artifactId
version${pom.version}/version
/dependency
etc.
Then an extension, for example, binding-rmi, would be defined like
project
modelVersion4.0.0/modelVersion
parent
groupIdorg.apache.tuscany.sca/groupId
artifactIdtuscany-modules/artifactId
version2.0-SNAPSHOT/version
relativePath../pom.xml/relativePath
/parent
artifactIdtuscany-binding-rmi/artifactId
nameApache Tuscany SCA RMI Binding Model/name
dependencies
dependency
groupIdorg.apache.tuscany.sca/groupId
artifactIdtuscany-base-runtime/artifactId
version2.0-SNAPSHOT/version
typepom/type
scopeprovided/scope
/dependency
/dependencies
/project
It's then very easy to tweak the bundle plugin to take notice of the
provided dependency and omit it from the meta-data, e.g. the
tuscany-base-runtime which-jars list is...
jaxb-api-2.1/jaxb-api-2.1.jar
tuscany-policy-security-2.0-SNAPSHOT.jar
tuscany-assembly-xml-2.0-SNAPSHOT.jar
jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar
tuscany-common-xml-2.0-SNAPSHOT.jar
tuscany-interface-wsdl-2.0-SNAPSHOT.jar
tuscany-databinding-jaxb-2.0-SNAPSHOT.jar
tuscany-node-impl-osgi-2.0-SNAPSHOT.jar
tuscany-node-launcher-equinox-2.0-SNAPSHOT.jar
activation-1.1/activation-1.1.jar
tuscany-core-spi-2.0-SNAPSHOT.jar
tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar
jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar
tuscany-binding-ws-2.0-SNAPSHOT.jar
tuscany-builder-2.0-SNAPSHOT.jar
XmlSchema-1.4.3.jar
tuscany-sca-api-2.0-SNAPSHOT.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
jetty-6.1.19.jar
services-3.2.0-v20090520-1800.jar
tuscany-monitor-2.0-SNAPSHOT.jar
tuscany-host-http-2.0-SNAPSHOT.jar
jsr250-api-1.0/jsr250-api-1.0.jar
jetty-util-6.1.19.jar
tuscany-databinding-2.0-SNAPSHOT.jar
asm-3.1/asm-3.1.jar
tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar
tuscany-node-launcher-2.0-SNAPSHOT.jar
tuscany-implementation-java-2.0-SNAPSHOT.jar
tuscany-deployment-2.0-SNAPSHOT.jar
tuscany-contribution-2.0-SNAPSHOT.jar
tuscany-core-2.0-SNAPSHOT.jar
tuscany-node-impl-2.0-SNAPSHOT.jar
tuscany-xsd-2.0-SNAPSHOT.jar
cglib-2.2/cglib-2.2.jar
wstx-asl-3.2.6/wstx-asl-3.2.6.jar
tuscany-extensibility-2.0-SNAPSHOT.jar
tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar
tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar
tuscany-node-api-2.0-SNAPSHOT.jar
tuscany-extensibility-equinox-2.0-SNAPSHOT.jar
jaxws-api-2.1/jaxws-api-2.1.jar
servlet-api-2.5/servlet-api-2.5.jar
tuscany-core-databinding-2.0-SNAPSHOT.jar
tuscany-contribution-osgi-2.0-SNAPSHOT.jar
tuscany-assembly-2.0-SNAPSHOT.jar
tuscany-assembly-xsd-2.0-SNAPSHOT.jar
wsdl4j-1.6.2/wsdl4j-1.6.2.jar
tuscany-implementation-osgi-2.0-SNAPSHOT.jar
osgi-3.5.0-v20090520.jar
tuscany-host-jetty-2.0-SNAPSHOT.jar
tuscany-common-java-2.0-SNAPSHOT.jar
commons-cli-1.2.jar
tuscany-interface-java-2.0-SNAPSHOT.jar
while the binding-rmi-runtime which-jars list is
Jars required to enable extension: tuscany-binding-rmi-runtime
tuscany-host-rmi-2.0-SNAPSHOT.jar
tuscany-binding-rmi-2.0-SNAPSHOT.jar
tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar
Which is a bit shorter than it was (and not very interesting for rmi).
Now I don't really know yet what issues are lurking in modules by
Re: samples again
On Wed, Sep 29, 2010 at 9:26 AM, ant elder ant.el...@gmail.com wrote: On Wed, Sep 29, 2010 at 8:52 AM, Florian MOGA moga@gmail.com wrote: One detail that I've noticed is that we're having a lack for naming consistency for the samples (e.g. contribution-helloworld / helloworld-webapp). IMHO using a consistent naming (like helloworld-contribution / helloworld-webapp) is much more readable. If we all agree with this I can make the necessary changes during the morning as we've got the time difference and there won't be any overlapping commits. I find helloworld-contribution reads better too. It is different from how a lot of the others were done though so does anyone feel strongly for the other way? ...ant +1 for... *-contribution = a stand-alone contribution *-webapp = a webapp packaging a contribution Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Created: (TUSCANY-3696) JSONP binding doesn't work with arrays
JSONP binding doesn't work with arrays
--
Key: TUSCANY-3696
URL: https://issues.apache.org/jira/browse/TUSCANY-3696
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.0-M5, Java-SCA-1.6, Java-SCA-1.4
Environment: All
Reporter: Simon Laws
The JSONP binding doesn't apply the JSON conversion correctly when an operation
parameter is of array type. This is because the data type model is set
incorrectly in the array case.
Both service and reference providers for the JSONP binding reset the binding
interface contract databinding in order to enable JSON conversion using the
JSON databinding using a line like
contract.getInterface().resetDataBinding(JSON2x);
This works fine for ordinary parameters. What I didn't realize when I added
this was that arrays are treated specially for some reason. There's code in
InterfaceImpl which reads...
private void setDataBinding(DataType dataType, String dataBinding) {
if (java:array.equals(dataType.getDataBinding())) {
setDataBinding((DataType)dataType.getLogical(), dataBinding);
} else {
dataType.setDataBinding(dataBinding);
}
}
When you then reset a databinding on an operation that has a parameter of an
array type you get something like
Contract
Interface
Operation
InputDataType
Logical - databinding = java:array
Logical - databinding = JSON2x
This lead to the databinding code using the following transformations
Input2InputTransformer
Array2ArrayTransformer
Object2JSONTransformer
Where I would have expected
Contract
Interface
Operation
InputDataType
Logical - databinding = JSON2x
Logical - databinding = JSON2x
Input2InputTransformer
Object2JSONTransformer
I don't know what the advantage of keeping the array databinding in place. I
guess the point is that the databinding code may not be able to cope with array
transfomation but it can in the JSON case. So I need to extend the databinding
resetting code to read...
contract.getInterface().resetDataBinding(JSON2x);
// force array types to map to JSON also
for (Operation operation : contract.getInterface().getOperations()){
DataTypeListDataType inputTypes = operation.getInputType();
for (DataType inputType : inputTypes.getLogical()){
if (java:array.equals(inputType.getDataBinding())){
inputType.setDataBinding(JSON2x);
}
}
DataType outputType = operation.getOutputType();
if (java:array.equals(outputType.getDataBinding())){
outputType.setDataBinding(JSON2x);
}
}
I may of course be missing something obvious to those who know about
databinding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Databinding and arrays question
Hi I just raised TUSCANY-3696 [1] as I realize that it's not clear how bindings should deal with arrays. It seems that the databinding layer is set up at the moment to transform the contents of an array parameter and leave the array in place for binding code to deal with. To put it another way when you reset a databinding in an interface, DataTypes with databinding set to java:array are left as-is but their child DataType databinding is reset. It seems relatively straightforward to reset the appropriate java:array databindings and let the databinding layer do it's thing. Alternatively the binding could do some of the work and transform the arrays itself. There must be a good reason why the latter seems to be the intention. Anyone remember what the original thinking was? [1] https://issues.apache.org/jira/browse/TUSCANY-3696 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
On Wed, Sep 29, 2010 at 11:09 AM, Florian MOGA moga@gmail.com wrote: I personally like the shell and the shell idea very much and I agree it would be the way to go (no Maven/Ant discrimination). The major problem in using the shell is that it implies a decent amount of knowledge with terms like domain, node, contribution which (we all know) aren't very well defined in our documentation on the website and the specs. I remember the early days of getting familiar with Tuscany when I had a hard time running the samples as they implied various launchers which were running tuscany embedded and didn't help very much in understanding the runtime as I had no low level control over it. All I wanted to see were jars which I could run and wars which i could deploy manually (things that i was already familiar with). I find Ant's suggestion for the save feature very good and it solves this problem. However, the user still needs to configure his contributions manually at the moment. My proposal is to also have a feature for the shell that can run tuscany shell script files. This will make things nice and easy. This is also a feature i suggest we need to have as it makes complex domain configurations to be started up very easy. I've listed more advantages here [1]. I see these tuscany shell script files as files containing shell commands on each line. This way, the user can either start the runtime using the shell scripts we'd provide either export or save it to a standalone jar and run it manually. Thoughts? [1] http://www.mail-archive.com/dev@tuscany.apache.org/msg13683.html Shell scripting is an interesting idea and certainly something that could be added. However, to me, it sounds more like a power user convenience. Here's another approach. Why not simply imagine a directory structure that lays out the various parts of the problem, e..g domain1 contributions contribution1.zip (contributions don't need to be here physically if they are accessible from elsewhere via a URL) nodes node1config.xml Then run a shell (I put it in speach marks as we seem to have several shells at the moment and I'm not sure what is actually being discussed here) over it and have it start the available node config (or indeed create a new node config and start that). Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: tutorial - using binding.rest with non-jaxrs service?
On Wed, Sep 29, 2010 at 11:20 AM, Florian MOGA moga@gmail.com wrote: I've seen Simon started fixing things on the json databinding and I would like to update the jsonp sample as well to also use arrays and BigDecimal. Are we keeping the current format for the scdl or switch to the wire declaration? I can't estimate how much such a change would take but if it needs some time I propose to deffer it as it looks like a nice enhancement for the next releases after 2.0. 1.x is a little odd at the moment in that I have JSONP working there with the JSON databinding from 2.x. Other binding that use this databinding, e.g. JSON-RPC don't work with the 2.x version but I'm not of a mind to fix that in 1.x as it should all work in 2.x. I 'm yet to port the array fix over to 2.x. I'll do that this week some time. Also I have a few local BigDecimal changes that I'm thinking about. I'll decide if they need committing this week if I get time. Having said this any samples in 2.x to test this stuff are very much appreciated. Even better if you want to help out porting the fixes. Re. the SCDL format. I'd like to try the HTTP wire format varient but haven't had time yet. I'd like to get the 2.0 beta out first. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
Shell scripting is an interesting idea and certainly something that could be added. However, to me, it sounds more like a power user convenience. Here's another approach. Why not simply imagine a directory structure that lays out the various parts of the problem, e..g domain1 contributions contribution1.zip (contributions don't need to be here physically if they are accessible from elsewhere via a URL) nodes node1config.xml Then run a shell (I put it in speach marks as we seem to have several shells at the moment and I'm not sure what is actually being discussed here) over it and have it start the available node config (or indeed create a new node config and start that). The tuscany shell script files as files containing shell commands on each line and the node1config.xml approaches seem pretty similar. You can actually use files of shell commands right now by just redirecting sysin from a file (eg java -jar tuscany-base-nodep-2.0-20100929.095517-1.jar fileOfCmds) but ther doesn't seem to be any way to switch back to read from the console afterwards so it might be better to add an extra startup parameter for the command file, and that way you can run the script commands and then use the shell command line to continue using commands to display the state and make updates. I like the idea of supporting node xml as well though so think we should add shell commands like load and save that read and write the xml files. And then you can have something like helloworld.xml and in the shell do load helloworld.xml to run the helloworld sample. And for each of the samples provide the xml file to configure everything for the sample. ...ant Adding/removing contributions/nodeconfig.xml to the appropriate directories could have the same effect a. la. Tomcat. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Databinding and arrays question
On Wed, Sep 29, 2010 at 12:30 PM, Scott Kurz scottk...@gmail.com wrote: Simon, like you mentioned, the original thinking must simply be that in most cases, the right thing to do is transform the contents of one array into the contents of the resulting array. I just wanted to chime in and ask if it might be worth trying to use the transformer weight mechanism to make a direct array-JSON conversion a higher-priority transform than a transformer chain which includes Array2Array. I admit I'm a little fuzzy as to precisely how to do that. Also, I think this would have to make sense for array-JSON conversions, in general, not just from this particular binding... not sure if this is the case or not. Still, I wonder if this avenue is worth a try? Scott Certainly worth thinking about Scott. I am a little concerned though that I'm missed something obvious in the array-JSON conversion. I'm just trying to avoid having JSON conversion code in the binding if I can avoid it and it works OK for JSONP. So I can certainly try to see if it works for others like JSONRPC. What this does point out is that we don't have a good cross binding test for all the various types that that can be transferred as this issue was only just pointed out to me. We need to look at extending the reach of itest/databinding in 2.x. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Ok well I've published a snapshot of our maven-bundle-plugin that
allows us to generate some more meta-data for the binary distro. The
snapshot is not synched yet to the Nexus repo so I haven't committed
the distro poms that allow you to build for yourself. I've posted the
resulting zip to my p.o.a. space [1]. I notice that this is rather
large, mostly due to cruft in the samples I believe, so you probably
won't want to actually download it so here are the interesting (?)
changes...
bin/
haven't changed
modules/
haven't changed
lib/
haven't changed
features/
tuscany-base-runtime
tuscany-binding-atom-runtime
tuscany-binding-corba-runtime
tuscany-binding-ejb-runtime
tuscany-binding-jms-runtime
tuscany-binding-jsonp-runtime
tuscany-binding-jsonrpc-runtime
tuscany-binding-rest-runtime
tuscany-binding-rmi-runtime
tuscany-binding-rss-runtime
tuscany-binding-ws-runtime-axis2
tuscany-implementation-bpel-runtime
tuscany-implementation-osgi-runtime
tuscany-implementation-script-runtime
tuscany-implementation-spring-runtime
tuscany-implementation-web-runtime
tuscany-implementation-widget-runtime
samples
mostly unchanged except...
running-tuscany
embedded-jse
build.xml - updated to use different ways to ref base + ext
all manifest
ant filesets
separate manifests
would like to add aggregate jars here also
The top level feature dir still has the all info in it though I'd
like to move
it to a sub directory. All sub-directories have meta-data referring to modules
for example,
features/
tuscany-binding-rmi-runtime/
build-path.xml
tuscany-binding-rmi-runtime-manifest.jar
which-jars
The sample build.xml file that uses this meta-data includes
appropriate ant filesets
include
file=${tuscany.home}/features/tuscany-base-runtime/build-path.xml/
include
file=${tuscany.home}/features/tuscany-binding-ws-runtime-axis2/build-path.xml/
include
file=${tuscany.home}/features/tuscany-binding-rmi-runtime/build-path.xml/
and then uses various different mechanisms
target name=binding-sca-calculator depends=compile
java classname=launcher.JSELauncherBindingSCACalculator
fork=true
failonerror=true
classpath
pathelement location=target/${jar.name}/
fileset dir=${tuscany.home}/features
include name=tuscany-sca-manifest.jar /
/fileset
/classpath
/java
/target
target name=binding-ws-calculator depends=compile
java classname=launcher.JSELauncherBindingWSCalculator
fork=true
failonerror=true
classpath
pathelement location=target/${jar.name}/
path refid=tuscany-base-runtime.path/
path refid=tuscany-binding-ws-runtime-axis2.path/
/classpath
/java
/target
target name=binding-rmi-calculator depends=compile
java classname=launcher.JSELauncherBindingRMICalculator
fork=true
failonerror=true
classpath
pathelement location=target/${jar.name}/
fileset dir=${tuscany.home}/features/tuscany-base-runtime
include name=tuscany-base-runtime-manifest.jar /
/fileset
fileset
dir=${tuscany.home}/features/tuscany-binding-rmi-runtime
include name=tuscany-binding-rmi-runtime-manifest.jar /
/fileset
/classpath
/java
/target
!-- TODO - I'd like this to be running with aggregate JARs --
target name=implementation-java-calculator depends=compile
java classname=launcher.JSELauncherImplementationJavaCalculator
fork=true
failonerror=true
classpath
pathelement location=target/${jar.name}/
fileset dir=${tuscany.home}/features
include name=tuscany-sca-manifest.jar /
/fileset
/classpath
/java
/target
The base meta-data is defined in the base feature and just refers to
the modules required to
run the ASM otests less the ws binding. All the extensions are
referenced directly in the
modules dir. There is a new mojo in the bundles plugin that does the
generation with the
following configuration.
execution
idextensions-build/id
phaseprocess-resources/phase
goals
goalgenerate-meta-data/goal
/goals
configuration
generateModulesfalse/generateModules
useDistributionNamefalse/useDistributionName
Re: samples again
snip... Being able to export the full application with all the dependencies included sounds like a must-have to me. I would add that being able to start up from a full configuration without the need to run separate commands seems similarly important. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Doing another 2.x release in a few weeks?
How about we start to making progress on the Beta release again... Things are looking ok I believe from an otest point of view. We've had discussion about the samples and that looks to be shaping up. We've also had disscussion about the distro structure and there are lots of ideas. I think we need a release to review and to focus the mind. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 6:25 PM, Raymond Feng enjoyj...@gmail.com wrote: Hi, What's the difference between feature and extension? Thanks, Raymond In the bundle plugin config you mean? In reality in the code nothing at the moment. I had looked on features as being a somewhat arbitrary but functional collection of jars from the modules directory. Extensions though have a special meaning in SCA and Tuscany in that they relate to binding.?, implementation.?, policy.? etc and extend the base SCA function that the Assembly spec defines. So I kept them separate. From a tuscany point of view an extension will typically be made up of a model, a runtime and any associated dependencies. As you see from the listing they currently end up generating the same sort of output and all end up under features at the moment. The meta data that's generated is consistent on purpose of course as demonstrated by the examples I included. The idea being that you can specify base + extension using the same approach for both (whatever the approach happens to be). There is an issue though. The extension meta-data repeats all the dependencies that base provides. This actually doesn't make a difference because the duplicates don't have a material impact on the classpath (other than we might generate a classpath that is too long). Aesthetically, and possibly for classpath length reasons, though it's not that pleasing and so it could be useful to know when we're dealing with extensions to filter our base dependencies from their meta data. Another thing this reminds me to ask... You'll note that I don't generate config.ini for extensions as I don't know of a way of loading more than one into Exquinox (other than possibly a manual merge). Any ideas? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [1.6.1] Replacing download.java.net by mirrors.ibiblio.org
On Tue, Sep 28, 2010 at 5:13 PM, Simon Nash n...@apache.org wrote:
I'm trying to build 1.6.1 from a clean maven repo. Things were going
steadily
until the build reached the following:
[INFO]
[INFO] Building Apache Tuscany SCA WSDL2Java Tool
[INFO] task-segment: [install]
[INFO]
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory:
E:\td\sca161\sca-java-1.6.1\tools\wsdl2java\target
\sdo-source added.
[INFO] [resources:resources]
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. b
uild is platform dependent!
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources,
i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] Copying 2 resources to META-INF
Downloading:
http://download.java.net/maven/1/com.sun.xml.bind/poms/jaxb-xjc-2.1
.7.pom
343b downloaded
Downloading:
http://download.java.net/maven/1/com.sun.xml.bind/jars/jaxb-xjc-2.1
.7.jar
440/3053K
At the current rate of progress (3K per minute) it will take about 15 hours
to
finish getting this one file!
It appears there's an alternative source for this file at
http://mirrors.ibiblio.org/pub/mirrors/maven2/com/sun/xml/bind/jaxb-xjc/2.1.7/
I just tried downloading it from there and it completed quickly with no
problems.
For the sake of users trying to build 1.6.1 from the source distro (as well
as
for my own sanity) I'd like to change those 1.6.1 poms that currently use
download.java.net/maven/1 to use mirrors.ibiblio.org/pub/mirrors/maven2
instead.
Is there any possible reason why I shouldn't make this change?
Simon
I thought we already included the Ibiblio mirror in the top level pom?
Is it just that because the download.java.net works (but very slowly)
that it's choosing that one but not completing. I don't believe there
is an issue with using Ibiblio. Especially as we already include it as
a mirror. There would be a problem if there are things at
download.java.net that are not at Ibiblio.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
On Mon, Sep 27, 2010 at 8:49 AM, ant elder ant.el...@gmail.com wrote: On Sat, Sep 25, 2010 at 6:27 PM, Florian MOGA moga@gmail.com wrote: Hi Kelvin, Given the agreed directory structure, I'd also include in the getting-started directory the samples illustrating callbacks and scopes which we were thinking to promote from the itest folder. Thoughts? Which of them do you think would be most suitable? Yes i think that would be good, I'd envisaged getting-started including enough to get a bit of a taste of what SCA is about, so the concepts we think are important. I was thinking things like using contributions and the sca-contribution.xml file, composites with some implementation and binding types along with the basic assembly constructs like components, services and references. Scopes and callbacks come up a lot on the user list so it would be good if they could fit in too, though i can see we do need to find a balance and have things to go in the learning more folder. ...ant Sounds good. I think the balance would be that in getting started we can show the user how to use a binding or an implementation type but that we don't have to show them how to use all the different bindings or implementation types. Similarly for other sca features such as callbacks and scopes, we should show them what they do but leave demonstration of the combination/extent of configuration options to the learning more section. As Ant says, demonstrate the important features that allow a user to get started. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: NPE in binding-jsonp-runtime test
Another issue that's cropped up with this JSONP refactoring is that the JSONP model now depends on the implementation class for the HTTP model. This isn't reflected in the OSGi manisfests. For now I'll add them in but it's not great to be exposing the impl classes of a binding model as an SPI. JSONP should be a fragment of the HTTP model unless there is another OSGi way to get round this. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
Hi Kelvin I just edited the new samples doc page you created [1] to make some suggestions about 1/ locating some of the helloworld samples 2/ removing launcher from the front of the running-tuscany samples 3/ moving the implementation-osgi sample up one level and hence loosing the sub-directory under distributed OSGi Haven't made any changes in the code. [1] https://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Samples Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] Created: (TUSCANY-3686) Impl classes in OSGi exports
Impl classes in OSGi exports Key: TUSCANY-3686 URL: https://issues.apache.org/jira/browse/TUSCANY-3686 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Affects Versions: Java-SCA-2.0-M5 Environment: OSGi Reporter: Simon Laws There are a couple of changes I've made recently that introduce Impl classes into OSGi exports which is not ideal. The JSONP model implementation extends the HTTP model implementation The Tribes endpoint registry (and I presume the hazelcast one also) needs to be able to de-serialize RuntimeEnpointImpl classes but the core bundle doesn't export the impl package For now I've put in the appropriate imports/exports but we could do with a neater way of addressing this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3687) Can we get rid of ranking on endpoint registry implementations?
Can we get rid of ranking on endpoint registry implementations? --- Key: TUSCANY-3687 URL: https://issues.apache.org/jira/browse/TUSCANY-3687 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws I believe that the endpoint registry implementation is selected based on the domain scheme. Is the ranking of the extensions required any more? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3688) The sample webapp helloworld-js-client fails
The sample webapp helloworld-js-client fails Key: TUSCANY-3688 URL: https://issues.apache.org/jira/browse/TUSCANY-3688 Project: Tuscany Issue Type: Bug Components: Java SDO Samples Environment: WinXP SP2 Sun JDK 1.6.20 Reporter: Simon Laws helloworld-js-client fails with... --- Test set: itest.HelloworldTestCase --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.203 sec FAILURE! testA(itest.HelloworldTestCase) Time elapsed: 0.172 sec ERROR! java.io.IOException: Server returned HTTP response code: 503 for URL: http://localhost:8085/helloworld-js-client/org.oasisopen.sca.componentContext.js/foo/call/plaincall/service.sayHello.dwr at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1313) at itest.HelloworldTestCase.testA(HelloworldTestCase.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Can someone who knows how this hangs together take a look? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: samples again
On Wed, Sep 22, 2010 at 11:12 PM, Kelvin Goodson kelvingood...@gmail.com wrote: That would mean getting started would be hidden away in a sub folder. Maybe the folder could have a more meaningful name in relation to the getting started folder. Something like going deeper. Kelvin On 22 Sep 2010, at 22:33, ant elder ant.el...@gmail.com wrote: On Wed, Sep 22, 2010 at 5:20 PM, kelvin goodson kelvingood...@apache.org wrote: be good. There seems to be consensus that a flatter structure would be preferable, so I plan to move the contents of tuscany-features into the directory If thats what happens do we even need the sca-features directory at all and instead just have everything in there be in the top samples folder. That might be closer to what Luciano was asking for, and i have to say the folder name sca-features doesn't mean much to me. ...ant Yeah, I don't think it makes sense to have some things in sub directories and some things at the top level. The things in sca-features are contributions. So going-deeper works for me or contributions or sca-contributions or extension-contributions or any other name that indicates that it contains contributions demonstrating point features of the Tuscany runtime. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Added page on importing projects into Eclipse
On Thu, Sep 23, 2010 at 8:37 AM, Simon Nash n...@apache.org wrote: Simon Laws wrote: I was talking offline to the other Simon about how to import existing projects into Eclipse. Looking at the docs I realized that we talk about how to use Eclipse when starting from scratch but don't say much about how to use Eclipse with existing projects. I had a go at putting some instructions together in 1.x [1]. If anyone has any suggesting for improvements please feel free. Once they settle down we can add/link similar info to the 2.x site. [1] http://tuscany.apache.org/import-existing-tuscany-sca-projects-into-eclipse.html Simon The maven-based instructions on this web page work fine for importing the Tuscany SCA samples into Eclipse. However I'm finding it difficult to debug the Tuscany runtime with this setup. The problem is that each imported sample project has a list of dependencies pointing to tuscany-xxx jar files in my local maven repository (M2_REPO). Eclipse doesn't know the location of the source code for these jar files, so I can't view the source and set debug breakpoints within Tuscany runtime code. I found a very painful workaround by selecting one particular dependent jar that I wanted to debug and doing an Eclipse source attachment for that specific jar only. This worked but I shudder at the thought of having to repeat this manual source attachment for dozens of dependent jars in dozens of samples. Is there a simple convenient way to tell Eclipse that all the dependent jars in the M2_REPO/org/apache/tuscany/sca/xxx path have their source in the Tuscany source distribution zip file? Simon This may not be that helpful in the context of using the Tuscany source distribution but here's what I know about finding source in the context of the Tuscany svn based source environment. - Source jars. Our build produces source jars (with the sources profile) and when you build with maven (without -o) they are downloaded to your local repo automatically. Eclipse will pick them up from there and show the source for you. There is a *big* downside here though. The source jars are out of date all of the time. This is made even worse as the Hudson build is not completing and so the source jars are getting further and further out of sync. The problem is so bad that I physically delete the source jars from my local repo whenever they get downloaded as it makes it impossible to debug. - Inclusion of Tuscany in the workspace. If you do mvn eclipse:eclipse for all the Tuscany modules and you do this from the top level of the Tuscany build then the inter module references will be to projects in the workspace rather than to jars in the local repo. This is not the case if you run mvn eclipse:eclipse in individual modules. - Manual assignment of source. As I run in the PDE and am often running samples outside the context of the Tuscany directory structure I'm nearly always faced with the prospect of telling eclipse where the Tuscany source is. It's seemingly random when and how eclipse asks for this information, i.e. it has a selection of different dialogs that it uses but I can't detect a pattern. Anyhow I find this mechanism pretty convenient and, more important, predictable in terms of allowing me to debug the Tuscany source at the right level. It's very easy to waste a lot of time in Eclipse trying to work out why the lines you are stepping through don't apparently match what's going on. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Added page on importing projects into Eclipse
On Thu, Sep 23, 2010 at 8:56 AM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Sep 23, 2010 at 8:37 AM, Simon Nash n...@apache.org wrote: Simon Laws wrote: I was talking offline to the other Simon about how to import existing projects into Eclipse. Looking at the docs I realized that we talk about how to use Eclipse when starting from scratch but don't say much about how to use Eclipse with existing projects. I had a go at putting some instructions together in 1.x [1]. If anyone has any suggesting for improvements please feel free. Once they settle down we can add/link similar info to the 2.x site. [1] http://tuscany.apache.org/import-existing-tuscany-sca-projects-into-eclipse.html Simon The maven-based instructions on this web page work fine for importing the Tuscany SCA samples into Eclipse. However I'm finding it difficult to debug the Tuscany runtime with this setup. The problem is that each imported sample project has a list of dependencies pointing to tuscany-xxx jar files in my local maven repository (M2_REPO). Eclipse doesn't know the location of the source code for these jar files, so I can't view the source and set debug breakpoints within Tuscany runtime code. I found a very painful workaround by selecting one particular dependent jar that I wanted to debug and doing an Eclipse source attachment for that specific jar only. This worked but I shudder at the thought of having to repeat this manual source attachment for dozens of dependent jars in dozens of samples. Is there a simple convenient way to tell Eclipse that all the dependent jars in the M2_REPO/org/apache/tuscany/sca/xxx path have their source in the Tuscany source distribution zip file? Simon This may not be that helpful in the context of using the Tuscany source distribution but here's what I know about finding source in the context of the Tuscany svn based source environment. - Source jars. Our build produces source jars (with the sources profile) and when you build with maven (without -o) they are downloaded to your local repo automatically. Eclipse will pick them up from there and show the source for you. There is a *big* downside here though. The source jars are out of date all of the time. This is made even worse as the Hudson build is not completing and so the source jars are getting further and further out of sync. The problem is so bad that I physically delete the source jars from my local repo whenever they get downloaded as it makes it impossible to debug. - Inclusion of Tuscany in the workspace. If you do mvn eclipse:eclipse for all the Tuscany modules and you do this from the top level of the Tuscany build then the inter module references will be to projects in the workspace rather than to jars in the local repo. This is not the case if you run mvn eclipse:eclipse in individual modules. - Manual assignment of source. As I run in the PDE and am often running samples outside the context of the Tuscany directory structure I'm nearly always faced with the prospect of telling eclipse where the Tuscany source is. It's seemingly random when and how eclipse asks for this information, i.e. it has a selection of different dialogs that it uses but I can't detect a pattern. Anyhow I find this mechanism pretty convenient and, more important, predictable in terms of allowing me to debug the Tuscany source at the right level. It's very easy to waste a lot of time in Eclipse trying to work out why the lines you are stepping through don't apparently match what's going on. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com b.t.w my source Jar comments refer to 2.x Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: samples again
On Thu, Sep 23, 2010 at 9:29 AM, kelvin goodson kelvingood...@apache.org wrote: OK, so if going deeper or the like works, then I'll go with something like that. It occurs to me that there might not be the same turn of phrase in olther languages, so I'm going to avoid the potential ambuiguity for members of the community whose first language is not English and use learning-more. Kelvin. Ok, makes sense. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Added page on importing projects into Eclipse
On Thu, Sep 23, 2010 at 12:08 PM, Simon Nash n...@apache.org wrote: kelvin goodson wrote: I share your pain! I have lost a lot of time trying to influence my eclipse workspace to pay heed to the source in my workspace rather than requiring source jars. I too see a variety of eclipse dialogs to locate source, and recently it seems to prefer only letting me point to source jars, so it is impossible to get the debugger to show my local mods. Kelvin. I found a way to do this that works for me. It was based on Simon's suggestion to run mvn eclipse:eclipse from the top level so that the Tuscany modules are included in the reactor when generating the eclipse project files for the samples. I had to adapt this slightly because I am generating Eclipse projects from the contents of the binary distribution, which doesn't include source for the Tuscany modules. I copied a hacked pom.xml into the root directory of the binary distribution which I had built within the distribution folder of my svn working copy. The relevant section of the hacked pom.xml is: modules module../../../../modules/module modulesamples/module moduletutorials/module moduledemos/module /modules The relative path ../../../../modules picks up the modules directory from my working copy and combines that with the samples, tutorials and demos directories in the binary distribution. Running mvn eclipse:eclipse against this pom generates all the Eclipse projects I need, with the correct cross-dependencies and with live source code in the right place (not taken from jar or zip files). I can import these projects into Eclipse and everything works as it should. If I then update some Tuscany source code in my svn working copy to fix a bug that I found when running a sample, Eclipse will automatically pick up the updated Tuscany source code. Simon neat! Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Building features in the distribution
I seem to remember a while back that there was a way to generate the separate feature meta data files into the distribution. I'm blowed if I can either remember how that used to work or find any mention of it in the code base. Am I imagining it? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
