Re: Saxon versions - was: Release 1.1 - what will be ready for next week?

[Simon Laws]

On Jan 2, 2008 7:04 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

> [snip]
> Simon Laws wrote:
> >
> > Looking at what we have at the moment the main issue I'm having is with
> > Saxon. implementation-bpel depends on 8.7 and other parts of Tuscany,
> e.g.
> > xml-bigbank, have a dependency on 9.0.0.2. I tried bringing
> > implementation-bpel up to 9.0.0.2 with no luck. Is there someone who has
> > been working on these areas that can advise how we can rationalize.
> >
> > The result at the moment is that we end up with a mixed set of jar
> versions
> > added to the distribution and hence some of the samples/demos can't find
> the
> > jars they require. I can't determine exactly how the jars are chosen. It
> > could be the first or last module to specify a dependency or something
> else
> > as we get some jars at 8.7 and some at 9.0.0.2. Can someone tell me how
> the
> > distribution build chooses which jar version to ship.
> >
> > Thanks
> >
> > Simon
> >
>
> The ODE runtime used by Tuscany's implementation-bpel is built with
> saxon 8.7 (look for saxon in [1]).
>
> In Tuscany v1.0.1 implementation-xquery and databinding-saxon worked
> with saxon 8.7.
>
> I'd suggest to try saxon 8.7, implementation-xquery from trunk or
> v1.0.1, databinding-saxon from Tuscany v1.0.1.
>
> [1] https://svn.apache.org/repos/asf/ode/trunk/Rakefile
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> OK, thanks for the reply Sebastien. Sounds like I need to mess about with
the databinding-saxon version one I've taken the branch

Simon

Re: Using contributions in the tutorial, was: Improving the store tutorial module structure

[Jean-Sebastien Delfino]

Rajini Sivaram wrote:

Sebastien,

When I was implementing OSGi bundle contributions, I was very frustrated
about the fact that even though bundles can have cyclic dependencies,
bundles with cyclic dependencies could not be added to SCA, if the bundles
contained SCA artifacts (composites/componentType files). OSGi copes with
cyclic dependencies because bundles have separate install and start methods.
So classes need to get resolved only before the start method is called. The
bundle is moved to resolved state by the OSGi runtime when its dependencies
are satisfied, and only resolved bundles can be started. With SCA
contributions, when would the composites/componentType files in a
contribution get processed, if it is not done when the contribution is
added? Class resolution for contributions is lazy, and hence the ordering of
contributions is only relevant when there are multiple contributions
containing the same class. But classes used in SCA composites and
componentType files get resolved when those files are processed, and at the
moment addContribution is the trigger, requiring all dependent contributions
containing classes referred to in composites/componentType files to be
installed first. If addContribution is not the trigger to process
composites, I am not sure what the trigger would be. node.start() for the
node? What about the domain? Wouldn't it have been much simpler if Tuscany
had a better lifecycle layer (like OSGi :-))?



Thank you...

Regards,

Rajini



Short answer to a long question :) when a composite is assigned to a 
node: node.setComposite(composite).


--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using contributions in the tutorial, was: Improving the store tutorial module structure

[Jean-Sebastien Delfino]

Rajini Sivaram wrote:

Sebastien,

Sorry, ignore my previous note (the one below). Even with assets not in the
classpath, I can run launch.LaunchCloud as long as the assets contribution
is added first. The code in svn does:


currencyNode.addContribution("http://cloud";, cloudContribution);

catalogsNode.addContribution("http://assets";, assetsContribution);

assets should be aded to currencyNode before cloud (at least with the
current code). With that change, it runs without throwing any exceptions.




With the latest code and after fixing the addContribution calls 
LaunchCloud now works for me too. Thanks.


However, after starting LaunchCloud, starting LaunchStore throws the 
exception below, as o.a.t.implementation.data.api.collection.Collection 
is required by services.ShoppingCart but not on the contribution path.


Adding implementation-data-api.jar and derby.jar as contributions (as I 
 did in SVN r608288) is not sufficient as these JARs don't have an 
sca-contribution.xml exporting their classes.


Summary: classes that depend on existing JARs (likely to happen in many 
component implementation classes) cannot be loaded from SCA 
contributions, as the existing JARs are not properly handled by the 
contribution processor.


I'll try to fix the contribution processor, the contribution ClassLoader 
and the import/export machinery later this week.


P.S. Simon, I don't think that you need to wait for the fix for the 1.1 
release.


Here's the exception:
Exception in thread "main" java.lang.NoClassDefFoundError: 
org.apache.tuscany.sca.implementation.data.collection.Collection

at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
at 
java.security.AccessController.doPrivileged(AccessController.java:275)
at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution(ContributionClassLoader.java:281)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass(ContributionClassLoader.java:85)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass(ContributionClassLoader.java:142)

at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:228)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:557)
at java.net.URLClassLoader.access$400(URLClassLoader.java:120)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:962)
at 
java.security.AccessController.doPrivileged(AccessController.java:275)
at java.net.URLClassLoader.findClass(URLClassLoader.java:488)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClassFromContribution(ContributionClassLoader.java:281)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass(ContributionClassLoader.java:85)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.findClass(ContributionClassLoader.java:98)
	at 
org.apache.tuscany.sca.contribution.impl.ContributionClassLoader.loadClass(ContributionClassLoader.java:142)

at java.lang.ClassLoader.loadClass(ClassLoader.java:573)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:163)
	at 
org.apache.tuscany.sca.contribution.java.impl.ClassReferenceModelResolver.resolveModel(ClassReferenceModelResolver.java:95)
	at 
org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:127)
	at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:145)
	at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:1)
	at 
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
	at 
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
	at 
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:241)
	at 
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:794)
	at 
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1)
	at 
org.apache.tuscany.sca

[Fwd: Commit r608213 breaks exceptions-cross-binding itest]

[Simon Nash]

I ran the test again (standalone, not from the itest directory)
and it works OK now.  I can't understand what changed since the
earlier failure.  See below for the error message and stack trace
that I got earlier.  Any insights into this?

  Simon

 Original Message 
Subject: Commit r608213 breaks exceptions-cross-binding itest
Date: Wed, 02 Jan 2008 22:16:44 +
From: Simon Nash <[EMAIL PROTECTED]>
Organization: IBM
To: tuscany-dev@ws.apache.org

It looks like my commit r608213 has broken the exceptions-cross-binding
itest.  My apologies for this.  I am looking into this now.  My first
impression is that I need to refine the code for matching exception types
to data bindings in DefaultDataBindingExtensionPoint.introspectType() so
that the new java:exception data binding is not selected for exceptions
generated by JAXB.  I will send another update as soon as I have more news.

  Simon

- - - - - - - - errors from first run are below - - - - - - - -

[INFO] -
---
[INFO] Building Apache Tuscany SCA Cross-Binding Exceptions Integration Tests
[INFO]task-segment: [install]
[INFO] -
---
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: javax.xml.ws:jaxws-api:2.1:jar
[INFO] Configured Artifact: javax.xml.bind:jaxb-api:2.1:jar
[INFO] Copying jaxws-api-2.1.jar to H:\tuscany59\sca\itest\exceptions-cross-bind
ing\target\endorsed\jaxws-api-2.1.jar
[INFO] Copying jaxb-api-2.1.jar to H:\tuscany59\sca\itest\exceptions-cross-bindi
ng\target\endorsed\jaxb-api-2.1.jar
[INFO] [tuscany-sdo:generate {execution: default}]
[INFO] Generating SDO interfaces from H:\tuscany59\sca\itest\exceptions-cross-bi
nding\src\main\resources\wsdl.sdo\StockExceptionTest.wsdl
>>  Generating code
>>  Generating packages
>>  Generating package ScatesttoolPackageImpl
>>  Generating Java interface stockexceptiontestservice.scatesttool.ScatesttoolF
actory
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/ScatesttoolF
actory.java
>>  Generating Java class stockexceptiontestservice.scatesttool.impl.Scatesttool
FactoryImpl
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/impl/Scatest
toolFactoryImpl.java
>>  Generating Invalid Symbol Fault
>>  Generating Java interface stockexceptiontestservice.scatesttool.InvalidSymbo
lFault
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/InvalidSymbo
lFault.java
>>  Generating Java class stockexceptiontestservice.scatesttool.impl.InvalidSymb
olFaultImpl
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/impl/Invalid
SymbolFaultImpl.java
>>  Generating Market Closed Fault
>>  Generating Java interface stockexceptiontestservice.scatesttool.MarketClosed
Fault
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/MarketClosed
Fault.java
>>  Generating Java class stockexceptiontestservice.scatesttool.impl.MarketClose
dFaultImpl
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/impl/MarketC
losedFaultImpl.java
>>  Generating Stock Offer
>>  Generating Java interface stockexceptiontestservice.scatesttool.StockOffer
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/StockOffer.j
ava
>>  Generating Java class stockexceptiontestservice.scatesttool.impl.StockOfferI
mpl
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/impl/StockOf
ferImpl.java
>>  Generating stock Quote Offer
>>  Generating Java interface stockexceptiontestservice.scatesttool.stockQuoteOf
fer
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/stockQuoteOf
fer.java
>>  Generating Java class stockexceptiontestservice.scatesttool.impl.stockQuoteO
fferImpl
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/impl/stockQu
oteOfferImpl.java
>>  Generating stock Quote Offer Response
>>  Generating Java interface stockexceptiontestservice.scatesttool.stockQuoteOf
ferResponse
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/stockQuoteOf
ferResponse.java
>>  Generating Java class stockexceptiontestservice.scatesttool.impl.stockQuoteO
fferResponseImpl
>>  Generating /TargetProject/stockexceptiontestservice/scatesttool/impl/stockQu
oteOfferResponseImpl.java
Downloading: http://people.apache.org/repo/m2-incubating-repository/woodstox/wst
x-asl/3.2.1/wstx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository a
pache.incubator (http://people.apache.org/repo/m2-incubating-repository)
Downloading: http://snapshots.repository.codehaus.org/woodstox/wstx-asl/3.2.1/ws
tx-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom:3.2.1' from repository c
odehaus-snapshot (http://snapshots.repository.codehaus.org)
Downloading: http://ws.zones.apache.org/repository2/woodstox/wstx-asl/3.2.1/wstx
-asl-3.2.1.pom
[WARNING] Unable to get resource 'woodstox:wstx-asl:pom

Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[Jean-Sebastien Delfino]

Simon Laws wrote:

On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:


As an experiment I looked down the first page of the outstanding bug list
[1] allocating to release 1.1 those bugs that I believed should be fixed.
I was looking for the sort of thing which showed a failure of some feature
of Tuscany, didn't obviously have a work round and that wasn't obviously
some kind of enhancement from what we have already. Difficult to apply this
consistently and I'm sure we would all come up with different lists. Non the
less I came up with 9 JIRA on the page of 50 (I moved some others as I'm
trying to address as many of the release build related bugs as I can. I'm
not counting them for this purpose). Just be multiplying that up for the
remaining pages that gives us over 30 must fixes before 1.1.  So if you
are planning to work on the release during the rest of the year please use
this as a guide.

In reality I know we won't get these all done but we need to ensure 1.1.
is of suitable quality. Perhaps a more realistic way of looking at this is
if we we had to do 2 each before we start voting on a release candidate in
January which two would they be? I'm working my way though the (hopefully)
straightforward release related JIRA but I expect the RC process will raise
more of these so experience tells us we will have these to deal with also.

Any thoughts about how we approach this?

Regards

Simon

[1] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC




As you may have noticed I've just moved over the rest of the easy JIRA that
relate to samples for 1.1 and that mostly got deferred last time round.
These are primarily README type fixes and take little effort to either fix
or discount so I'll get on with them. I've still not had any feedback on how
people feel about the harder technical JIRA that remain outstanding.

Currently I'm waiting for a few things before I can potentially cut the
branch. In particular,

JMS
Venkat's last policy changes (he's committed but there may be a few
adjustments to make)
Some help with the Saxon dependency

This means the formal branch won't happen for a couple of days yet. However,


Should we get some more of the outstanding JIRA fixed for 1.1?
If so which ones (I moved some of the likely candidates to 1.1 before
Christmas but not all), i.e. who is going to do what ?

Personally there are a couple of domain related JIRAs I want to fix but I
need to know from everyone whether I should go ahead and cut the branch
(once I'm in a position to do so) or whether we are going to spend some time
fixing JIRA.

Thanks

Simon



+1 to go ahead and cut a branch as soon as possible, there are JIRAs 
open, but there will be more releases too. I want to do minor clean up 
of the getting started sample for 1.1 but I guess that can miss the branch.


--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Commit r608213 breaks exceptions-cross-binding itest

[Simon Nash]

It looks like my commit r608213 has broken the exceptions-cross-binding
itest.  My apologies for this.  I am looking into this now.  My first
impression is that I need to refine the code for matching exception types
to data bindings in DefaultDataBindingExtensionPoint.introspectType() so
that the new java:exception data binding is not selected for exceptions
generated by JAXB.  I will send another update as soon as I have more news.

  Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1939) Can't pass business exceptions across Web services when using Sun JDK

[Simon Nash (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Nash resolved TUSCANY-1939.
-

Resolution: Fixed

Fixed under r608213.

> Can't pass business exceptions across Web services when using Sun JDK
> -
>
> Key: TUSCANY-1939
> URL: https://issues.apache.org/jira/browse/TUSCANY-1939
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1
> Environment: Sun JDK, Windows XP
>Reporter: Simon Nash
>Assignee: Simon Nash
>Priority: Blocker
> Fix For: Java-SCA-1.1
>
>
> The changes in commit r601501 prevent business exceptions from being passed 
> over Web services when using the Sun JDK.  This is because Tuscany's POJO 
> serialization to XML now uses JAXB, and JAXB cannot handle Java exception 
> objects.  This problem causes the exceptions-simple-ws itest to fail with the 
> following exception:
> ---
>  T E S T S
> ---
> Running com.example.ExampleTestCase
> 17-Dec-2007 21:40:27 org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
> 17-Dec-2007 21:40:27 org.apache.catalina.startup.ContextConfig 
> defaultWebConfig
> INFO: No default web.xml
> 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register
> WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd
> 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register
> WARNING: Could not get url for 
> /javax/servlet/jsp/resources/web-jsptaglibrary_1_
> 1.dtd
> 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register
> WARNING: Could not get url for 
> /javax/servlet/jsp/resources/web-jsptaglibrary_1_
> 2.dtd
> 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register
> WARNING: Could not get url for 
> /javax/servlet/jsp/resources/web-jsptaglibrary_2_
> 0.xsd
> 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register
> WARNING: Could not get url for 
> /javax/servlet/resources/j2ee_web_services_1_1.xs
> d
> 17-Dec-2007 21:40:27 org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-8085
> 17-Dec-2007 21:40:27 org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-8085
> 17-Dec-2007 21:40:27 org.apache.tuscany.sca.http.tomcat.TomcatServer 
> addServletM
> apping
> INFO: Added Servlet mapping: http://EUREKA:8085/axis2/services/ExampleService
> 17-Dec-2007 21:40:28 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSy
> ncMessageReceiver invokeBusinessLogic
> SEVERE: org.apache.tuscany.sca.databinding.TransformationException: 
> com.sun.xml.
> bind.v2.runtime.IllegalAnnotationsException: 1 counts of 
> IllegalAnnotationExcept
> ions
> java.lang.StackTraceElement does not have a no-arg default constructor.
> this problem is related to the following location:
> at java.lang.StackTraceElement
> at public java.lang.StackTraceElement[] 
> java.lang.Throwable.getS
> tackTrace()
> at java.lang.Throwable
> at java.lang.Exception
> at com.example.BusinessException
> org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.databinding.Transfo
> rmationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 
> cou
> nts of IllegalAnnotationExceptions
> java.lang.StackTraceElement does not have a no-arg default constructor.
> this problem is related to the following location:
> at java.lang.StackTraceElement
> at public java.lang.StackTraceElement[] 
> java.lang.Throwable.getS
> tackTrace()
> at java.lang.Throwable
> at java.lang.Exception
> at com.example.BusinessException
> at 
> org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt
> imeWireInvoker.java:127)
> at 
> org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt
> imeWireInvoker.java:89)
> at 
> org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt
> imeWireInvoker.java:83)
> at 
> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWi
> reImpl.java:127)
> at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTa
> rget(Axis2ServiceProvider.java:572)
> at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageR
> eceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:59)
> at 
> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBus
> inessLogic(AbstractInOutSyncMessa

Re: Saxon versions - was: Release 1.1 - what will be ready for next week?

[Jean-Sebastien Delfino]

[snip]
Simon Laws wrote:


Looking at what we have at the moment the main issue I'm having is with
Saxon. implementation-bpel depends on 8.7 and other parts of Tuscany, e.g.
xml-bigbank, have a dependency on 9.0.0.2. I tried bringing
implementation-bpel up to 9.0.0.2 with no luck. Is there someone who has
been working on these areas that can advise how we can rationalize.

The result at the moment is that we end up with a mixed set of jar versions
added to the distribution and hence some of the samples/demos can't find the
jars they require. I can't determine exactly how the jars are chosen. It
could be the first or last module to specify a dependency or something else
as we get some jars at 8.7 and some at 9.0.0.2. Can someone tell me how the
distribution build chooses which jar version to ship.

Thanks

Simon



The ODE runtime used by Tuscany's implementation-bpel is built with 
saxon 8.7 (look for saxon in [1]).


In Tuscany v1.0.1 implementation-xquery and databinding-saxon worked 
with saxon 8.7.


I'd suggest to try saxon 8.7, implementation-xquery from trunk or 
v1.0.1, databinding-saxon from Tuscany v1.0.1.


[1] https://svn.apache.org/repos/asf/ode/trunk/Rakefile
--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[ant elder]

On Jan 2, 2008 5:04 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> On Jan 2, 2008 2:20 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Jan 2, 2008 2:11 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > As an experiment I looked down the first page of the outstanding bug
> > > list
> > > > [1] allocating to release 1.1 those bugs that I believed should be
> > > fixed.
> > > > I was looking for the sort of thing which showed a failure of some
> > > feature
> > > > of Tuscany, didn't obviously have a work round and that wasn't
> > obviously
> > > > some kind of enhancement from what we have already. Difficult to
> apply
> > > this
> > > > consistently and I'm sure we would all come up with different lists.
> > Non
> > > the
> > > > less I came up with 9 JIRA on the page of 50 (I moved some others as
> > I'm
> > > > trying to address as many of the release build related bugs as I
> can.
> > > I'm
> > > > not counting them for this purpose). Just be multiplying that up for
> > the
> > > > remaining pages that gives us over 30 must fixes before 1.1.  So if
> > you
> > > > are planning to work on the release during the rest of the year
> please
> > > use
> > > > this as a guide.
> > > >
> > > > In reality I know we won't get these all done but we need to ensure
> > 1.1.
> > > > is of suitable quality. Perhaps a more realistic way of looking at
> > this
> > > is
> > > > if we we had to do 2 each before we start voting on a release
> > candidate
> > > in
> > > > January which two would they be? I'm working my way though the
> > > (hopefully)
> > > > straightforward release related JIRA but I expect the RC process
> will
> > > raise
> > > > more of these so experience tells us we will have these to deal with
> > > also.
> > > >
> > > > Any thoughts about how we approach this?
> > > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > > > [1]
> > >
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC
> > > >
> > > >
> > >
> > > As you may have noticed I've just moved over the rest of the easy JIRA
> > > that
> > > relate to samples for 1.1 and that mostly got deferred last time
> round.
> > > These are primarily README type fixes and take little effort to either
> > fix
> > > or discount so I'll get on with them. I've still not had any feedback
> on
> > > how
> > > people feel about the harder technical JIRA that remain outstanding.
> > >
> > > Currently I'm waiting for a few things before I can potentially cut
> the
> > > branch. In particular,
> > >
> > > JMS
> > > Venkat's last policy changes (he's committed but there may be a few
> > > adjustments to make)
> > > Some help with the Saxon dependency
> > >
> > > This means the formal branch won't happen for a couple of days yet.
> > > However,
> > >
> > >
> > > Should we get some more of the outstanding JIRA fixed for 1.1?
> > > If so which ones (I moved some of the likely candidates to 1.1 before
> > > Christmas but not all), i.e. who is going to do what ?
> > >
> > > Personally there are a couple of domain related JIRAs I want to fix
> but
> > I
> > > need to know from everyone whether I should go ahead and cut the
> branch
> > > (once I'm in a position to do so) or whether we are going to spend
> some
> > > time
> > > fixing JIRA.
> > >
> > > Thanks
> > >
> > > Simon
> > >
> >
> > Does taking the branch have to wait for JMS? I'm a little behind so it
> may
> > be a day or two before the binding is in a releasable state but the
> branch
> > could still happen now and I'll can just copy over any changes.
> >
> >   ...ant
> >
> Ant
>
> Can I ask what version of Active MQ the new code will be using?
>
> Simon
>


Its on 4.1.1 presently but as 5.0 is the latest i'd been thinking about
moving up to that.

   ...ant

Re: Release dependency management

[Jean-Sebastien Delfino]

Simon Laws wrote:

On Dec 21, 2007 5:25 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:


Does the ant file generator support projects that depend on wsdl
generation or sdo type generation? If not, some samples, that have
working ant scripts, might get broken...

On Dec 21, 2007 9:21 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

I'm putting Sebastien's ant file generator into the build. The snag is

that

it builds ant files based on dependencies it finds at the module level.

We

ship a release excluding all but the latest level of dependencies. Hence

the

ant file may be looking for dependencies that we don't ship. My first

port

of call here is to look across the project and see if we can rationalize

our

dependencies so that the modules are looking for the latest version.

Failing

that we will have to have some kind of lookup that maps to the latest
version for each jar. I'm raising it here in the off chance that someone

has

already thought about this and knows a neat solution.

Regards

Simon




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende 
http://lresende.blogspot.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Yes, you're right. What I was thinking of doing there is have the ant

generator just generate the required classpath into a separate file and
include that into a static ant file so we have the option of writing custom
ant files that can just include the generated bit if needs be

Simon



I can add code to the plugin to detect wsdl2java and gen the 
corresponding ant script. It'll be simpler than a mix of generated and 
custom ant scripts.


--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release dependency management

[Jean-Sebastien Delfino]

Simon Laws wrote:

I'm putting Sebastien's ant file generator into the build. The snag is that
it builds ant files based on dependencies it finds at the module level. We
ship a release excluding all but the latest level of dependencies. Hence the
ant file may be looking for dependencies that we don't ship. My first port
of call here is to look across the project and see if we can rationalize our
dependencies so that the modules are looking for the latest version. Failing
that we will have to have some kind of lookup that maps to the latest
version for each jar. I'm raising it here in the off chance that someone has
already thought about this and knows a neat solution.

Regards

Simon



Happy new year.

I can try to help fix the problem, once I understand it. Can you point 
me to a module and steps to reproduce it?


Thanks.
--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: R1.1 - Sample/demo ant builds

[Simon Nash]

Comments inline.

  Simon

Simon Laws wrote:


On Jan 2, 2008 1:23 PM, ant elder <[EMAIL PROTECTED]> wrote:



On Jan 2, 2008 12:00 PM, Simon Laws <[EMAIL PROTECTED]> wrote:



On Jan 2, 2008 10:53 AM, Mike Edwards <[EMAIL PROTECTED]>
wrote:



Folks,

Some comments

Yours,  Mike.

ant elder wrote:


On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]>


wrote:


For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
change,
based on the ant generator plugin, to bring some automation to the


process


of building the ant files for the samples and demos. For any sample


or


demo
that requires explicit dependencies, e.g. the webapp samples, I've
replaced
the static ant file with and automatically generated one. In the


case


that


some hand crafted ant script is needed, for example, to generate


SDOs,


then
I have the ant generator just build build-dependency.xml which has


the


dependencies listed and which can then be included in the manually
generated
build.xml script.

I haven't applied this change to all of the samples but it could be


done.


If
we did have all of the dependencies explicitly described for all of


the


samples can we get rid of the "all" and "manifest" jars?

Simon




I think its better if applications don't have to know or care about


Tuscany


internals, that includes knowing all the different Tuscany module


names


and


all the dependencies they use.


+1 - applications should ideally have ZERO dependence on Tuscany
internals.  They should be deployed to an "SCA capable runtime"


without


having to know anything about that runtime.



We haven't got this right yet so each time we
release our sample Ant builds break as the build.xml files get out


of


date -


this will be happening for any Ant builds our users have as well.


The


"all"


jar is an attempt to fix this, its a better way IMHO than having
applications specify every Tuscany module but theres a bit of work


still


to


do to make it work better for webapps. We've also talked before


about


changing all the samples to be simple sca contributions that don't


need


any


mention of the Tuscany internals, this is something I think we


really


need


to do. Both of those things seem better to me than messing about


trying


to


generate build scripts.


I agree with this sentiment.  We should be building:

a) runtimes of various kinds (SCA standalone, embedded within Tomcat,


etc)


b) applications, containing only the code and other artifacts required
for the application itself

and then have some regular means of deploying the applications to
appropriate runtimes - some applications could be deployed to "almost
any" SCA runtime while others need specific runtime capabilities such


as


a Web server and Servlet support.



  ...ant



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

We are describing configuration scenarios in this thread that are not


currently well covered in the samples that ship with Tuscany. Take the
following steps as an example,

1 - choose a runtime
2 - configure the runtime
3 - start the runtime
4 - assemble application(s)
5 - contribute the application(s)
6 - make top level contributed composites available

90% of our samples currently assume that

1-3 means start a standalone runtime with all features enabled by using
the
"all" jar
4-6 means add a single contribution with a single composite

The ant scripts we have target step 2 and have no impact on 4,5,6. The


ant


scripts do not imply that the "applications have to know or care about
Tuscany internals". I think you are confusing the act of starting the
runtime with that of contributing the application. It just so happens


that


in our samples these steps all happen in close proximity, I.e. our


samples


generally include a runtime and the application itself. In the


particular


case of webapps the ant scripts configure the runtime (the war in this
case)
so that it contains just enough to run and no more in order to reduce


the


size of the war.



Maybe if we had a way to say "Tuscany standalone with all extensions" or
"Tuscany Tomcat with BPEL, WS and JavaScript" then ok but if the
application
build process has to mention tuscany-assembly, tuscany-core,
tuscany-definitions, tuscany-databinding and all the other dozens of
required jars then that does seems like "knowing and caring about Tuscany
internals" to me.



This is the case as at some point someone decided to package our samples
along with the runtime that will run them. So to configure the runtime you
need to configure the sample build. There is no hardwired relationship
though between the runtime build and the application build.

The case where we do need to build the two together is when we package the
runtime within the WAR that holds the application. There have been numerous
posts during previous releases

Build failure from contribution-multiple itest

[Simon Nash]

I just did an svn up and full build.  All was OK until I got to the
itests and contribution-multiple.  Here's the failure.  It looks like
null was returned from domain.getCompositeBuilder().  Any ideas?

  Simon

[INFO] -
---
[INFO] Building Apache Tuscany SCA Multiple Contribution Integration Tests
[INFO]task-segment: [install]
[INFO] -
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 5 source files to H:\tuscany59\sca\itest\contribution-multiple\
target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: H:\tuscany59\sca\itest\contribution-multiple\t
arget\surefire-reports

---
 T E S T S
---
Running test.ContributionTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.941 sec <<< FA
ILURE!
testServiceCall(test.ContributionTestCase)  Time elapsed: 0.901 sec  <<< ERROR!
java.lang.NullPointerException
at test.ContributionTestCase.setUp(ContributionTestCase.java:66)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.
java:35)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)


Results :

Tests in error:
  testServiceCall(test.ContributionTestCase)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[Simon Laws]

On Jan 2, 2008 2:20 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Jan 2, 2008 2:11 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> > On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > > As an experiment I looked down the first page of the outstanding bug
> > list
> > > [1] allocating to release 1.1 those bugs that I believed should be
> > fixed.
> > > I was looking for the sort of thing which showed a failure of some
> > feature
> > > of Tuscany, didn't obviously have a work round and that wasn't
> obviously
> > > some kind of enhancement from what we have already. Difficult to apply
> > this
> > > consistently and I'm sure we would all come up with different lists.
> Non
> > the
> > > less I came up with 9 JIRA on the page of 50 (I moved some others as
> I'm
> > > trying to address as many of the release build related bugs as I can.
> > I'm
> > > not counting them for this purpose). Just be multiplying that up for
> the
> > > remaining pages that gives us over 30 must fixes before 1.1.  So if
> you
> > > are planning to work on the release during the rest of the year please
> > use
> > > this as a guide.
> > >
> > > In reality I know we won't get these all done but we need to ensure
> 1.1.
> > > is of suitable quality. Perhaps a more realistic way of looking at
> this
> > is
> > > if we we had to do 2 each before we start voting on a release
> candidate
> > in
> > > January which two would they be? I'm working my way though the
> > (hopefully)
> > > straightforward release related JIRA but I expect the RC process will
> > raise
> > > more of these so experience tells us we will have these to deal with
> > also.
> > >
> > > Any thoughts about how we approach this?
> > >
> > > Regards
> > >
> > > Simon
> > >
> > > [1]
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC
> > >
> > >
> >
> > As you may have noticed I've just moved over the rest of the easy JIRA
> > that
> > relate to samples for 1.1 and that mostly got deferred last time round.
> > These are primarily README type fixes and take little effort to either
> fix
> > or discount so I'll get on with them. I've still not had any feedback on
> > how
> > people feel about the harder technical JIRA that remain outstanding.
> >
> > Currently I'm waiting for a few things before I can potentially cut the
> > branch. In particular,
> >
> > JMS
> > Venkat's last policy changes (he's committed but there may be a few
> > adjustments to make)
> > Some help with the Saxon dependency
> >
> > This means the formal branch won't happen for a couple of days yet.
> > However,
> >
> >
> > Should we get some more of the outstanding JIRA fixed for 1.1?
> > If so which ones (I moved some of the likely candidates to 1.1 before
> > Christmas but not all), i.e. who is going to do what ?
> >
> > Personally there are a couple of domain related JIRAs I want to fix but
> I
> > need to know from everyone whether I should go ahead and cut the branch
> > (once I'm in a position to do so) or whether we are going to spend some
> > time
> > fixing JIRA.
> >
> > Thanks
> >
> > Simon
> >
>
> Does taking the branch have to wait for JMS? I'm a little behind so it may
> be a day or two before the binding is in a releasable state but the branch
> could still happen now and I'll can just copy over any changes.
>
>   ...ant
>
Ant

Can I ask what version of Active MQ the new code will be using?

Simon

Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[Simon Laws]

On Jan 2, 2008 4:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Apologies for the long delay in responding to this.
>
> I am concerned about the number of significant JIRAs that are open
> against the current trunk code.  I have been working on two of these
> that I consider to be "must fix" for 1.1.  They are TUSCANY-1849 and
> TUSCANY-1939.  I have a fix for TUSCANY-1939 that is ready to commit
> today, and I will then turn my attention to TUSCANY-1849.  After I
> have committed a fix for this, I will look at Simon's list and resolve
> as many of the others as I can before 1.1 is frozen.
>
>   Simon
>
> ant elder wrote:
>
> > On Jan 2, 2008 2:11 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >
> >>On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>As an experiment I looked down the first page of the outstanding bug
> >>
> >>list
> >>
> >>>[1] allocating to release 1.1 those bugs that I believed should be
> >>
> >>fixed.
> >>
> >>>I was looking for the sort of thing which showed a failure of some
> >>
> >>feature
> >>
> >>>of Tuscany, didn't obviously have a work round and that wasn't
> obviously
> >>>some kind of enhancement from what we have already. Difficult to apply
> >>
> >>this
> >>
> >>>consistently and I'm sure we would all come up with different lists.
> Non
> >>
> >>the
> >>
> >>>less I came up with 9 JIRA on the page of 50 (I moved some others as
> I'm
> >>>trying to address as many of the release build related bugs as I can.
> >>
> >>I'm
> >>
> >>>not counting them for this purpose). Just be multiplying that up for
> the
> >>>remaining pages that gives us over 30 must fixes before 1.1.  So if you
> >>>are planning to work on the release during the rest of the year please
> >>
> >>use
> >>
> >>>this as a guide.
> >>>
> >>>In reality I know we won't get these all done but we need to ensure 1.1
> .
> >>>is of suitable quality. Perhaps a more realistic way of looking at this
> >>
> >>is
> >>
> >>>if we we had to do 2 each before we start voting on a release candidate
> >>
> >>in
> >>
> >>>January which two would they be? I'm working my way though the
> >>
> >>(hopefully)
> >>
> >>>straightforward release related JIRA but I expect the RC process will
> >>
> >>raise
> >>
> >>>more of these so experience tells us we will have these to deal with
> >>
> >>also.
> >>
> >>>Any thoughts about how we approach this?
> >>>
> >>>Regards
> >>>
> >>>Simon
> >>>
> >>>[1]
> >>
> >>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC
> >>
> >>>
> >>As you may have noticed I've just moved over the rest of the easy JIRA
> >>that
> >>relate to samples for 1.1 and that mostly got deferred last time round.
> >>These are primarily README type fixes and take little effort to either
> fix
> >>or discount so I'll get on with them. I've still not had any feedback on
> >>how
> >>people feel about the harder technical JIRA that remain outstanding.
> >>
> >>Currently I'm waiting for a few things before I can potentially cut the
> >>branch. In particular,
> >>
> >>JMS
> >>Venkat's last policy changes (he's committed but there may be a few
> >>adjustments to make)
> >>Some help with the Saxon dependency
> >>
> >>This means the formal branch won't happen for a couple of days yet.
> >>However,
> >>
> >>
> >>Should we get some more of the outstanding JIRA fixed for 1.1?
> >>If so which ones (I moved some of the likely candidates to 1.1 before
> >>Christmas but not all), i.e. who is going to do what ?
> >>
> >>Personally there are a couple of domain related JIRAs I want to fix but
> I
> >>need to know from everyone whether I should go ahead and cut the branch
> >>(once I'm in a position to do so) or whether we are going to spend some
> >>time
> >>fixing JIRA.
> >>
> >>Thanks
> >>
> >>Simon
> >>
> >
> >
> > Does taking the branch have to wait for JMS? I'm a little behind so it
> may
> > be a day or two before the binding is in a releasable state but the
> branch
> > could still happen now and I'll can just copy over any changes.
> >
> >...ant
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

Re: Code updates for passing service references around as XML instead of base64 binary

[Simon Laws]

On Jan 2, 2008 3:44 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> I just committed r608125 which changes the serialization format of the
> CallableReference and ServiceReference signature types from base64 binary
> to XML strings (see TUSCANY-1943).
>
> There are some method signatures that pass around service references
> using the Externalizable type.  I did not change these in r608125.
> For consistency I would like to change these signatures to use the
> ServiceReference type so that they will be serialized to XML instead
> of to base64 binary.  Does anyone object to this change?
>
> I have identified the following signatures that would be affected:
>
>  
> sca\modules\domain\src\main\java\org\apache\tuscany\sca\domain\SCADomainEventService.java
>registerNode()
>
>  
> sca\modules\domain\src\main\java\org\apache\tuscany\sca\domain\model\NodeModel.java
>getNodeManagerReference()
>setNodeManagerReference()
>
>  
> sca\modules\domain-impl\src\main\java\org\apache\tuscany\sca\domain\impl\SCADomainImpl.java
>registerNode()
>
>  
> sca\modules\domain-impl\src\main\java\org\apache\tuscany\sca\domain\management\impl\SCADomainManagerServiceImpl.java
>registerNode()
>
>  
> sca\modules\domain-impl\src\main\java\org\apache\tuscany\sca\domain\model\impl\NodeModelImpl.java
>getNodeManagerReference()
>setNodeManagerReference()
>
>  
> sca\modules\node-impl\src\main\java\org\apache\tuscany\sca\node\impl\SCADomainEventServiceProxyImpl.java
>registerNode()
>
>  
> sca\modules\binding-sca-axis2\src\test\java\org\apache\tuscany\sca\binding\sca\axis2\TestDomain.java
>registerNode()
>
> Code updates would also be needed to the following files:
>
>  
> sca\modules\domain-impl\src\test\java\org\apache\tuscany\sca\domain\impl\DomainImplTestCase.java
>
>  
> sca\modules\domain-impl\src\test\java\org\apache\tuscany\sca\domain\impl\TestCallableReferenceImpl.java
>
>   Simon
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Simon

I have no objections. Would be great if you could do the fixes.

Regards

Simon

Re: How to set a specific data binding to be used by a binding?

[ant elder]

I've also abandoned this approach for now as after many many hours I just
couldn't get the XML data binding to produce wrapped style XML even with
WSDL interfaces. So instead of using the XML databinding I'll use the Axiom
databinding and just convert the XML strings from/to OMElements myself.

   ...ant

On Dec 15, 2007 10:23 AM, ant elder <[EMAIL PROTECTED]> wrote:

> Hopefully I'm just missing something but it doesn't look at all easy to
> create a correctly configured WrapperInfo object.
>
> I'm going to give up on this for now and just generate a WSDL interface
> from the Java interface and use that. This will drag in all sorts of Axis2
> and WSDL guff which seems quite far from ideal.
>
> Maybe I'm just not being clear about what I want to do and all JMS and rpc
> vs messaging style stuff is confusing the issue - Lets say I want to copy
> the sample implementation-pojo-extension and change that so instead of using
> Java objects for the argument and return values it uses a String containing
> wrapped style XML. Is it possible to do that without having to generate a
> wsdl (and thus avoid dragging in all the dependencies that requires)?
>
>...ant
>
>
> On Dec 14, 2007 7:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > Ok thanks, i'll go explore that for a little while...probably I'll be
> > having more questions while doing that :)
> >
> >...ant
> >
> >
> > On Dec 14, 2007 7:20 PM, Raymond Feng < [EMAIL PROTECTED]> wrote:
> >
> > > Yes, creating the WrapperInfo manually is an alternative to generating
> > > a
> > > wrapper style WSDL (in which case the WSDL interface introspection
> > > produces
> > > the WrapperInfo).
> > >
> > > Thanks,
> > > Raymond
> > >
> > > - Original Message -
> > > From: "ant elder" < [EMAIL PROTECTED]>
> > > To: "tuscany-dev" 
> > > Sent: Friday, December 14, 2007 11:09 AM
> > > Subject: Re: How to set a specific data binding to be used by a
> > > binding?
> > >
> > >
> > > > Ok, so from "unless the binding interface contract is a wrapper
> > > style WSDL
> > > > portType" does that mean it really must have a WSDL portType and
> > > thats
> > > > baked
> > > > deep into the design or is it more "unless the binding interface
> > > contract
> > > > is
> > > > a wrapper style" and it would be possible to just set that up with a
> > > Java
> > > > interface? Something like setting a WrapperInfo with
> > > > o.a.t.s.interfacedef.Operation.setWrapper? Which I guess is assuming
> > > its
> > > > straightforward to create a WrapperInfo object?
> > > >
> > > >   ...ant
> > > >
> > > > On Dec 14, 2007 5:39 PM, Raymond Feng < [EMAIL PROTECTED]> wrote:
> > > >
> > > >>  Hi,
> > > >>
> > > >> I just use JMS as an example for bindings that are not naturally
> > > >> RPC-style.
> > > >>
> > > >> Using AXIOM as the databinding will only give you an array of
> > > OMElements
> > > >> representing the parameters unless the binding interface contract
> > > is a
> > > >> wrapper style WSDL portType (then you'll receive the wrapper
> > > OMElement).
> > > >> We
> > > >> can enhance the XMLStringDataBinding to handle wrappers but we
> > > still need
> > > >> to
> > > >> express that the binding interface contract is wrapper style in the
> > > first
> > > >> place.
> > > >>
> > > >> Thanks,
> > > >> Raymond
> > > >>
> > > >> - Original Message -
> > > >> *From:* ant elder < [EMAIL PROTECTED]>
> > > >> *To:* Raymond Feng <[EMAIL PROTECTED]>
> > > >> *Cc:* tuscany-dev@ws.apache.org
> > > >> *Sent:* Friday, December 14, 2007 9:12 AM
> > > >> *Subject:* Re: How to set a specific data binding to be used by a
> > > >> binding?
> > > >>
> > > >> I'm completely missing the point sorry and I'm not sure I
> > > understand why
> > > >> JMS comes into this? I've a binding and I want the wrapped XML. I
> > > want it
> > > >> as
> > > >> a String but I could use DOM or OMElement or what ever else. Right
> > > now I
> > > >> (think?) it would work if I just use the Axiom data binding which
> > > gives
> > > >> the
> > > >> wrapped style of XML and then I'd receive OMElements as the payload
> > > which
> > > >> I
> > > >> could call toString on to get a String, but I'd prefer not to have
> > > the
> > > >> dependency on Axiom.
> > > >>
> > > >> I still don't understand why there couldn't be a version of
> > > >> XMLStringDataBinding that returns wrapped style XML?
> > > >>
> > > >>...ant
> > > >>
> > > >> On Dec 14, 2007 4:55 PM, Raymond Feng < [EMAIL PROTECTED]> wrote:
> > > >>
> > > >> > There are two independent factors in the operation-level data
> > > >> > transformation
> > > >> > ( i.e., converting the payload from one structure to another). In
> > > the
> > > >> > JMSBinding case, if a java interface is used, it's from Object[]
> > > to
> > > >> > JMSMessage (or the text for JMS TextMessage).
> > > >> >
> > > >> > 1) The data conversion (from example, a Customer SDO to String)
> > > >> > 2) The wrapping/unwrapping process. Wrapper style is just a
> > > special
> > > >> > patte

Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[Simon Nash]

Apologies for the long delay in responding to this.

I am concerned about the number of significant JIRAs that are open
against the current trunk code.  I have been working on two of these
that I consider to be "must fix" for 1.1.  They are TUSCANY-1849 and
TUSCANY-1939.  I have a fix for TUSCANY-1939 that is ready to commit
today, and I will then turn my attention to TUSCANY-1849.  After I
have committed a fix for this, I will look at Simon's list and resolve
as many of the others as I can before 1.1 is frozen.

  Simon

ant elder wrote:


On Jan 2, 2008 2:11 PM, Simon Laws <[EMAIL PROTECTED]> wrote:



On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:



As an experiment I looked down the first page of the outstanding bug


list


[1] allocating to release 1.1 those bugs that I believed should be


fixed.


I was looking for the sort of thing which showed a failure of some


feature


of Tuscany, didn't obviously have a work round and that wasn't obviously
some kind of enhancement from what we have already. Difficult to apply


this


consistently and I'm sure we would all come up with different lists. Non


the


less I came up with 9 JIRA on the page of 50 (I moved some others as I'm
trying to address as many of the release build related bugs as I can.


I'm


not counting them for this purpose). Just be multiplying that up for the
remaining pages that gives us over 30 must fixes before 1.1.  So if you
are planning to work on the release during the rest of the year please


use


this as a guide.

In reality I know we won't get these all done but we need to ensure 1.1.
is of suitable quality. Perhaps a more realistic way of looking at this


is


if we we had to do 2 each before we start voting on a release candidate


in


January which two would they be? I'm working my way though the


(hopefully)


straightforward release related JIRA but I expect the RC process will


raise


more of these so experience tells us we will have these to deal with


also.


Any thoughts about how we approach this?

Regards

Simon

[1]


https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC




As you may have noticed I've just moved over the rest of the easy JIRA
that
relate to samples for 1.1 and that mostly got deferred last time round.
These are primarily README type fixes and take little effort to either fix
or discount so I'll get on with them. I've still not had any feedback on
how
people feel about the harder technical JIRA that remain outstanding.

Currently I'm waiting for a few things before I can potentially cut the
branch. In particular,

JMS
Venkat's last policy changes (he's committed but there may be a few
adjustments to make)
Some help with the Saxon dependency

This means the formal branch won't happen for a couple of days yet.
However,


Should we get some more of the outstanding JIRA fixed for 1.1?
If so which ones (I moved some of the likely candidates to 1.1 before
Christmas but not all), i.e. who is going to do what ?

Personally there are a couple of domain related JIRAs I want to fix but I
need to know from everyone whether I should go ahead and cut the branch
(once I'm in a position to do so) or whether we are going to spend some
time
fixing JIRA.

Thanks

Simon




Does taking the branch have to wait for JMS? I'm a little behind so it may
be a day or two before the binding is in a releasable state but the branch
could still happen now and I'll can just copy over any changes.

   ...ant





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Implementation Policies

[Simon Nash]

I took Venkat's post as expressing a need for some kind of validation
that would be performed before the composite is allowed to be used by
the runtime.  This seems to preclude a solution based on management
interfaces, as these would presumably not come into play until the
composite is actually running.

Managemant interfaces would be good for other reasons, but it's not
clear to me that they can be used for this purpose.

  Simon

Mike Edwards wrote:


Folks,

Perhaps this calls for something more general which will support other 
use cases.


How about some form of "management" interfaces which will allow an 
application to get information about entities inside the runtime in a 
controlled fashion?  So the idea would be to get some contribution(s) 
running in the SCA runtime and then have a client application issue 
queries about what is actually running, which would include information 
such as Venkat requires to check the intents and policySets applying to 
some componenet?


I realize that this is no trivial capability to add to the system, but 
it will satisfy a number of goals in the longer run.


Yours,  Mike.


Venkata Krishnan wrote:


Hi Simon,

What I need is a hook into the runtime startup and more specifically 
after
the build phase so that I can analyse the built composite to see if it 
has
the correctly computed intents and policysets.  Is that something we 
can do

in the node-runtime?

Thanks

-  Venkat




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1943) Use XML serialization for CallableReference instead of base64 binary

[Simon Nash (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Nash resolved TUSCANY-1943.
-

Resolution: Fixed

Committed as r608125.

> Use XML serialization for CallableReference instead of base64 binary
> 
>
> Key: TUSCANY-1943
> URL: https://issues.apache.org/jira/browse/TUSCANY-1943
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.0.1
> Environment: All
>Reporter: Simon Nash
>Assignee: Simon Nash
>Priority: Minor
> Fix For: Java-SCA-1.1
>
>
> The XML serialized form of a CallableReference is currently some XML wrapped 
> up in a Java ObjectOutputStream and converted to base64 binary.  This is very 
> implementation-specific, unreadable, and non-interoperable.  It would be 
> cleaner to serialize the same information as plain readable XML.  I have 
> written a transformer that does this. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Code updates for passing service references around as XML instead of base64 binary

[Simon Nash]

I just committed r608125 which changes the serialization format of the
CallableReference and ServiceReference signature types from base64 binary
to XML strings (see TUSCANY-1943).

There are some method signatures that pass around service references
using the Externalizable type.  I did not change these in r608125.
For consistency I would like to change these signatures to use the
ServiceReference type so that they will be serialized to XML instead
of to base64 binary.  Does anyone object to this change?

I have identified the following signatures that would be affected:
 
sca\modules\domain\src\main\java\org\apache\tuscany\sca\domain\SCADomainEventService.java
   registerNode()
 
sca\modules\domain\src\main\java\org\apache\tuscany\sca\domain\model\NodeModel.java
   getNodeManagerReference()
   setNodeManagerReference()
 
sca\modules\domain-impl\src\main\java\org\apache\tuscany\sca\domain\impl\SCADomainImpl.java
   registerNode()
 
sca\modules\domain-impl\src\main\java\org\apache\tuscany\sca\domain\management\impl\SCADomainManagerServiceImpl.java
   registerNode()
 
sca\modules\domain-impl\src\main\java\org\apache\tuscany\sca\domain\model\impl\NodeModelImpl.java
   getNodeManagerReference()
   setNodeManagerReference()
 
sca\modules\node-impl\src\main\java\org\apache\tuscany\sca\node\impl\SCADomainEventServiceProxyImpl.java
   registerNode()
 
sca\modules\binding-sca-axis2\src\test\java\org\apache\tuscany\sca\binding\sca\axis2\TestDomain.java
   registerNode()

Code updates would also be needed to the following files:
 
sca\modules\domain-impl\src\test\java\org\apache\tuscany\sca\domain\impl\DomainImplTestCase.java
 
sca\modules\domain-impl\src\test\java\org\apache\tuscany\sca\domain\impl\TestCallableReferenceImpl.java

  Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Implementation Policies

[Mike Edwards]

Folks,

Perhaps this calls for something more general which will support other 
use cases.


How about some form of "management" interfaces which will allow an 
application to get information about entities inside the runtime in a 
controlled fashion?  So the idea would be to get some contribution(s) 
running in the SCA runtime and then have a client application issue 
queries about what is actually running, which would include information 
such as Venkat requires to check the intents and policySets applying to 
some componenet?


I realize that this is no trivial capability to add to the system, but 
it will satisfy a number of goals in the longer run.


Yours,  Mike.


Venkata Krishnan wrote:

Hi Simon,

What I need is a hook into the runtime startup and more specifically after
the build phase so that I can analyse the built composite to see if it has
the correctly computed intents and policysets.  Is that something we can do
in the node-runtime?

Thanks

-  Venkat




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Build of calculator-implementation-policies sample is failing

[Mike Edwards]

Folks,

Looks like there are differences between the IBM JDK and Sun JDK on this 
point.  Certainly, the underlying security implementations within those 
JDKs are very different.  It is going to be necessary to double check 
any security related code against both of those JDKs.


Yours,  Mike.

Simon Laws wrote:

On Jan 2, 2008 11:56 AM, Simon Nash <[EMAIL PROTECTED]> wrote:


I did a full checkout of Java SCA and tried to build it.  I got the
following failure in samples/calculator-implementation-policies.
Looking at the messages, I see validation errors followed by a
problem with login configuration.  Does anyone have ideas on why
this sample is failing?





I'm assuming these are somehow connected to the recent policy related
changes. I'll have a poke around here in case I've messed up something
locally. Venkat, can you double check you clean build?

Thanks

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: R1.1 - Sample/demo ant builds

[Simon Laws]

On Jan 2, 2008 1:23 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Jan 2, 2008 12:00 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> > On Jan 2, 2008 10:53 AM, Mike Edwards <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Folks,
> > >
> > > Some comments
> > >
> > > Yours,  Mike.
> > >
> > > ant elder wrote:
> > > > On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
> > > >
> > > >> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> > > >> change,
> > > >> based on the ant generator plugin, to bring some automation to the
> > > process
> > > >> of building the ant files for the samples and demos. For any sample
> > or
> > > >> demo
> > > >> that requires explicit dependencies, e.g. the webapp samples, I've
> > > >> replaced
> > > >> the static ant file with and automatically generated one. In the
> case
> > > that
> > > >> some hand crafted ant script is needed, for example, to generate
> > SDOs,
> > > >> then
> > > >> I have the ant generator just build build-dependency.xml which has
> > the
> > > >> dependencies listed and which can then be included in the manually
> > > >> generated
> > > >> build.xml script.
> > > >>
> > > >> I haven't applied this change to all of the samples but it could be
> > > done.
> > > >> If
> > > >> we did have all of the dependencies explicitly described for all of
> > the
> > > >> samples can we get rid of the "all" and "manifest" jars?
> > > >>
> > > >> Simon
> > > >
> > > >
> > > >
> > > > I think its better if applications don't have to know or care about
> > > Tuscany
> > > > internals, that includes knowing all the different Tuscany module
> > names
> > > and
> > > > all the dependencies they use.
> > >
> > > +1 - applications should ideally have ZERO dependence on Tuscany
> > > internals.  They should be deployed to an "SCA capable runtime"
> without
> > > having to know anything about that runtime.
> > >
> > > > We haven't got this right yet so each time we
> > > > release our sample Ant builds break as the build.xml files get out
> of
> > > date -
> > > > this will be happening for any Ant builds our users have as well.
> The
> > > "all"
> > > > jar is an attempt to fix this, its a better way IMHO than having
> > > > applications specify every Tuscany module but theres a bit of work
> > still
> > > to
> > > > do to make it work better for webapps. We've also talked before
> about
> > > > changing all the samples to be simple sca contributions that don't
> > need
> > > any
> > > > mention of the Tuscany internals, this is something I think we
> really
> > > need
> > > > to do. Both of those things seem better to me than messing about
> > trying
> > > to
> > > > generate build scripts.
> > >
> > > I agree with this sentiment.  We should be building:
> > >
> > > a) runtimes of various kinds (SCA standalone, embedded within Tomcat,
> > etc)
> > >
> > > b) applications, containing only the code and other artifacts required
> > > for the application itself
> > >
> > > and then have some regular means of deploying the applications to
> > > appropriate runtimes - some applications could be deployed to "almost
> > > any" SCA runtime while others need specific runtime capabilities such
> as
> > > a Web server and Servlet support.
> > >
> > > >
> > > >...ant
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > We are describing configuration scenarios in this thread that are not
> > currently well covered in the samples that ship with Tuscany. Take the
> > following steps as an example,
> >
> > 1 - choose a runtime
> > 2 - configure the runtime
> > 3 - start the runtime
> > 4 - assemble application(s)
> > 5 - contribute the application(s)
> > 6 - make top level contributed composites available
> >
> > 90% of our samples currently assume that
> >
> > 1-3 means start a standalone runtime with all features enabled by using
> > the
> > "all" jar
> > 4-6 means add a single contribution with a single composite
> >
> > The ant scripts we have target step 2 and have no impact on 4,5,6. The
> ant
> > scripts do not imply that the "applications have to know or care about
> > Tuscany internals". I think you are confusing the act of starting the
> > runtime with that of contributing the application. It just so happens
> that
> > in our samples these steps all happen in close proximity, I.e. our
> samples
> > generally include a runtime and the application itself. In the
> particular
> > case of webapps the ant scripts configure the runtime (the war in this
> > case)
> > so that it contains just enough to run and no more in order to reduce
> the
> > size of the war.
> >
>
> Maybe if we had a way to say "Tuscany standalone with all extensions" or
> "Tuscany Tomcat with BPEL, WS and JavaScript" then ok but if the
> application
> build process has to mention tuscany-assembly, tuscany-core,
> tuscany-definitions, 

Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[ant elder]

On Jan 2, 2008 2:11 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> > As an experiment I looked down the first page of the outstanding bug
> list
> > [1] allocating to release 1.1 those bugs that I believed should be
> fixed.
> > I was looking for the sort of thing which showed a failure of some
> feature
> > of Tuscany, didn't obviously have a work round and that wasn't obviously
> > some kind of enhancement from what we have already. Difficult to apply
> this
> > consistently and I'm sure we would all come up with different lists. Non
> the
> > less I came up with 9 JIRA on the page of 50 (I moved some others as I'm
> > trying to address as many of the release build related bugs as I can.
> I'm
> > not counting them for this purpose). Just be multiplying that up for the
> > remaining pages that gives us over 30 must fixes before 1.1.  So if you
> > are planning to work on the release during the rest of the year please
> use
> > this as a guide.
> >
> > In reality I know we won't get these all done but we need to ensure 1.1.
> > is of suitable quality. Perhaps a more realistic way of looking at this
> is
> > if we we had to do 2 each before we start voting on a release candidate
> in
> > January which two would they be? I'm working my way though the
> (hopefully)
> > straightforward release related JIRA but I expect the RC process will
> raise
> > more of these so experience tells us we will have these to deal with
> also.
> >
> > Any thoughts about how we approach this?
> >
> > Regards
> >
> > Simon
> >
> > [1]
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC
> >
> >
>
> As you may have noticed I've just moved over the rest of the easy JIRA
> that
> relate to samples for 1.1 and that mostly got deferred last time round.
> These are primarily README type fixes and take little effort to either fix
> or discount so I'll get on with them. I've still not had any feedback on
> how
> people feel about the harder technical JIRA that remain outstanding.
>
> Currently I'm waiting for a few things before I can potentially cut the
> branch. In particular,
>
> JMS
> Venkat's last policy changes (he's committed but there may be a few
> adjustments to make)
> Some help with the Saxon dependency
>
> This means the formal branch won't happen for a couple of days yet.
> However,
>
>
> Should we get some more of the outstanding JIRA fixed for 1.1?
> If so which ones (I moved some of the likely candidates to 1.1 before
> Christmas but not all), i.e. who is going to do what ?
>
> Personally there are a couple of domain related JIRAs I want to fix but I
> need to know from everyone whether I should go ahead and cut the branch
> (once I'm in a position to do so) or whether we are going to spend some
> time
> fixing JIRA.
>
> Thanks
>
> Simon
>

Does taking the branch have to wait for JMS? I'm a little behind so it may
be a day or two before the binding is in a releasable state but the branch
could still happen now and I'll can just copy over any changes.

   ...ant

R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality

[Simon Laws]

On Dec 20, 2007 10:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> As an experiment I looked down the first page of the outstanding bug list
> [1] allocating to release 1.1 those bugs that I believed should be fixed.
> I was looking for the sort of thing which showed a failure of some feature
> of Tuscany, didn't obviously have a work round and that wasn't obviously
> some kind of enhancement from what we have already. Difficult to apply this
> consistently and I'm sure we would all come up with different lists. Non the
> less I came up with 9 JIRA on the page of 50 (I moved some others as I'm
> trying to address as many of the release build related bugs as I can. I'm
> not counting them for this purpose). Just be multiplying that up for the
> remaining pages that gives us over 30 must fixes before 1.1.  So if you
> are planning to work on the release during the rest of the year please use
> this as a guide.
>
> In reality I know we won't get these all done but we need to ensure 1.1.
> is of suitable quality. Perhaps a more realistic way of looking at this is
> if we we had to do 2 each before we start voting on a release candidate in
> January which two would they be? I'm working my way though the (hopefully)
> straightforward release related JIRA but I expect the RC process will raise
> more of these so experience tells us we will have these to deal with also.
>
> Any thoughts about how we approach this?
>
> Regards
>
> Simon
>
> [1] 
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC
>
>

As you may have noticed I've just moved over the rest of the easy JIRA that
relate to samples for 1.1 and that mostly got deferred last time round.
These are primarily README type fixes and take little effort to either fix
or discount so I'll get on with them. I've still not had any feedback on how
people feel about the harder technical JIRA that remain outstanding.

Currently I'm waiting for a few things before I can potentially cut the
branch. In particular,

JMS
Venkat's last policy changes (he's committed but there may be a few
adjustments to make)
Some help with the Saxon dependency

This means the formal branch won't happen for a couple of days yet. However,


Should we get some more of the outstanding JIRA fixed for 1.1?
If so which ones (I moved some of the likely candidates to 1.1 before
Christmas but not all), i.e. who is going to do what ?

Personally there are a couple of domain related JIRAs I want to fix but I
need to know from everyone whether I should go ahead and cut the branch
(once I'm in a position to do so) or whether we are going to spend some time
fixing JIRA.

Thanks

Simon

[jira] Closed: (TUSCANY-1265) Disitrbution build - tuscany-sca-all-1.0-incubating-SNAPSHOT.jar is empty

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-1265.
---

Resolution: Fixed

Am closing this as I think it is a JDK issue. Cleaning before doing the 
distribution build helps.

> Disitrbution build - tuscany-sca-all-1.0-incubating-SNAPSHOT.jar is empty
> -
>
> Key: TUSCANY-1265
> URL: https://issues.apache.org/jira/browse/TUSCANY-1265
> Project: Tuscany
>  Issue Type: Bug
>  Components: Build System
>Affects Versions: Java-SCA-0.90
> Environment: Windows XP
>Reporter: Simon Laws
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> cd sca/disitribution
> mvn
> The resulting bindary distribution (tuscany-sca-1.0-incubating-SNAPSHOT.zip) 
> contains the jar tuscany-sca-all-1.0-incubating-SNAPSHOT.jar but it is empty
> This seems to be a fault with the ways the shader maven plugin operates. The 
> maven compile indicates that the shaded bundle jar can't be copied over the 
> original jar that is picked up by the process that builds the binary 
> disitribution jar. 
> ...
> [INFO] Replacing original artifact with shaded artifact.
> [WARNING] Could not replace original artifact with shaded artifact!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1594) helloworld-ws-sdo-webapp - no README

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1594:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1

> helloworld-ws-sdo-webapp - no README
> 
>
> Key: TUSCANY-1594
> URL: https://issues.apache.org/jira/browse/TUSCANY-1594
> Project: Tuscany
>  Issue Type: Improvement
>Affects Versions: Java-SCA-0.99
>Reporter: Simon Laws
>Assignee: ant elder
> Fix For: Java-SCA-1.1
>
>
> README required

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1595) helloworld-ws-service-webapp - README needs content

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1595:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1

> helloworld-ws-service-webapp - README needs content
> ---
>
> Key: TUSCANY-1595
> URL: https://issues.apache.org/jira/browse/TUSCANY-1595
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.99
>Reporter: Simon Laws
>Assignee: ant elder
> Fix For: Java-SCA-1.1
>
>
> README at present only contains the URL you have to use

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1601) README for alert-aggregator demo does not explain how to build it using ant scripts

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1601:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1

> README for alert-aggregator demo does not explain how to build it using ant 
> scripts
> ---
>
> Key: TUSCANY-1601
> URL: https://issues.apache.org/jira/browse/TUSCANY-1601
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.99
> Environment: Windows XP
>Reporter: Simon Nash
>Priority: Minor
> Fix For: Java-SCA-1.1
>
>
> In the 0.99 binary distro, the README for the alert-aggregator demo does not 
> explain how to build it using the ant scripts that are part of the demo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1616) calculator-distributed sample doesn't shut down cleanly

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1616:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1

> calculator-distributed sample doesn't shut down cleanly
> ---
>
> Key: TUSCANY-1616
> URL: https://issues.apache.org/jira/browse/TUSCANY-1616
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.99
> Environment: Windows XP
>Reporter: Simon Nash
> Fix For: Java-SCA-1.1
>
>
> I ran the calculator-distributed sample with ant, using the insttuctions in 
> the README.  All the nodes started correctly and the sample ran OK.  I then 
> tried to shut down the nodes.  Nodes B and C would not shut down when Enter 
> was pressed.  DomainNode did shut down when Enter was pressed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1710) Get service by class's name will cause error when add a binding.ws

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1710:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1

> Get service by class's name will cause error when add a binding.ws
> --
>
> Key: TUSCANY-1710
> URL: https://issues.apache.org/jira/browse/TUSCANY-1710
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-Next
> Environment: win jdk1.6 eclipse tuscany svn 575578
>Reporter: gengshaoguang
> Fix For: Java-SCA-1.1
>
>
> I just found this:
> I finished a component with  and it 
> works with 
>getService(a.b.C.class,"[component's name]");
> Then I added a  to the above component, and 
> modified a.b.C to implements a @Remotable interface a.b.I, and I will have to 
> use:
>getService(a.b.I.class,"[component's name]");
> Otherwise(if I don't change the first parameter), I will get an will known 
> error: "Can't handle mixed payloads betweem OMElements and other types".
> This will bring a discomfort to a user: when they deside to expose an exist 
> resource to outside consumer, they need to change their own code!
> Did some one get into the same scenario? Of course, I myself might did some 
> incorrect.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1622) bigbank demo does not close down cleanly

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1622:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1

> bigbank demo does not close down cleanly
> 
>
> Key: TUSCANY-1622
> URL: https://issues.apache.org/jira/browse/TUSCANY-1622
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-0.99
> Environment: Windows XP
>Reporter: Simon Nash
> Fix For: Java-SCA-1.1
>
>
> I started bigbank-calculator, bigbank-stockquote, and bigbank-account in that 
> order.  I tried the bigbank-acoount demo, then closed down bigbank-account, 
> bigbank-stockquote, and bigbank-calculator iin that order (the reverse of 
> startup).  bigbank-account and bigbank-stockquote closed down OK, but 
> bigbank-calculator failed with the following error:
>  [java] Exception in thread "main" java.io.IOException: Stream closed
>  [java] at 
> java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
>  [java] at 
> java.io.BufferedInputStream.read(BufferedInputStream.java:239)
>  [java] at 
> calculator.demo.CalculatorServer.main(CalculatorServer.java:36)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1762) Intermittent failure of sample/implementation-composite build

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-1762.
---

   Resolution: Fixed
Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

The node implementation has been rewritten since this was reported so am 
closing this issue. 

> Intermittent failure of sample/implementation-composite build
> -
>
> Key: TUSCANY-1762
> URL: https://issues.apache.org/jira/browse/TUSCANY-1762
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.0
> Environment: All
>Reporter: Simon Laws
> Fix For: Java-SCA-1.1
>
>
> Sometimes I see
> ---
> Running composite.CompositeTestCase
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.296 sec <<< 
> FAILURE!
> test(composite.CompositeTestCase)  Time elapsed: 1.203 sec  <<< ERROR!
> org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.contribution.service.ContributionResolveE
> xception: java.lang.ClassNotFoundException: 
> org.apache.tuscany.sca.node.impl.NodeManagerServiceImpl
>at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance 
> (SCADomain.java:58)
> Intermittently.
> Looking at this output it seems that the test is trying to load the 
> node.composite from the node module and failing as it doesn't have the 
> classes that that composite requires. It should actually be loading the 
> composites under implementation-composite/src/main.resources.
> It's using the following to create the domain...
> scaDomain = SCADomain.newInstance();
> Which basically means it's going looking for
> sca-contribution.xml, sca-contribution-generated.xml (not sure this is the 
> exact name) or deployables/ on the classpath
> In some circumstances it's finding the node version and in others it's 
> finding the module version. I don't know what makes it do one or the other.
> The fix is the remove META-INF/sca-contribution from 
> modules/node/src/main/resources. 
> This is also the workround.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1742) tuscany-interface-wsdl-runtime module version 0.99-incubating missing

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1742:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

set as closed at 1.1

> tuscany-interface-wsdl-runtime module version 0.99-incubating missing
> -
>
> Key: TUSCANY-1742
> URL: https://issues.apache.org/jira/browse/TUSCANY-1742
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-0.99
>Reporter: Yan
> Fix For: Java-SCA-1.1
>
>
> I used the tuscany-interface-wsdl-runtime module in my service layer 
> implementation with java sca 0.91-incubating. However, when I upgraded 
> tuscany-sca to 0.99-incubating, the module is unavailable now. I am wondering 
> if it has been merged into some other module? Which artifact I should use 
> instead? Thanks a lot!
> 
> org.apache.tuscany.sca
> tuscany-interface-wsdl-runtime
> 0.99-incubating
> runtime
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1742) tuscany-interface-wsdl-runtime module version 0.99-incubating missing

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-1742.
---

Resolution: Fixed

module has now been removed

> tuscany-interface-wsdl-runtime module version 0.99-incubating missing
> -
>
> Key: TUSCANY-1742
> URL: https://issues.apache.org/jira/browse/TUSCANY-1742
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-0.99
>Reporter: Yan
> Fix For: Java-SCA-Next
>
>
> I used the tuscany-interface-wsdl-runtime module in my service layer 
> implementation with java sca 0.91-incubating. However, when I upgraded 
> tuscany-sca to 0.99-incubating, the module is unavailable now. I am wondering 
> if it has been merged into some other module? Which artifact I should use 
> instead? Thanks a lot!
> 
> org.apache.tuscany.sca
> tuscany-interface-wsdl-runtime
> 0.99-incubating
> runtime
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1789) Is binding-jms available?

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws updated TUSCANY-1789:


Fix Version/s: (was: Java-SCA-Next)
   Java-SCA-1.1

move to 1.1 as I expect better (but not complete) JMS support to be provided

> Is binding-jms available?
> -
>
> Key: TUSCANY-1789
> URL: https://issues.apache.org/jira/browse/TUSCANY-1789
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-0.99
>Reporter: Yan
> Fix For: Java-SCA-1.1
>
>
> I wish to expose service to JMS client through SCA's JMS binding component. 
> But I can't find the binding-jms module in the current tuscany sca 0.99 
> version or the future 1.0 version. I browsed the previous posts, it seems 
> that the JMS binding has ever been included in the tuscany sca 0.90 release. 
> I am wondering if it is available in the current release and how I should use 
> it. Thank you very much!!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Conversation from a non-SCA application

[Simon Nash]

Happy New Year to you as well!

This is a very interesting use case.  I could give you an answer
based on the current Tuscany implementation, or I could give you
an answer based on what the spec guarantees.  I'll do the latter
as this is the best way to ensure that the code you write will
continue to work on future releases of Tuscany.

The guaranteed approach would be to have a second client for the
same service and have both clients force the same globally unique
conversationID to be used when invoking the service.  If the
service is defined as having a callback, there's no way to avoid
passing in a callback reference from the second client's invocation.
However, the service can save away the original callback reference
when it is first invoked by the original client, and can then use
this callback reference to make the callback when it is invoked
the second time (ignoring the callback reference passed with the
second invocation).

Here's the entire sequence of steps:

1) Conversational client calls a SCA Service Operation, specifying
   an explicit application-generated globally unique conversationID.
   This invocation will also pass an implicit callback reference to
   the original client.
2) SCA Service gets its callback reference (from the RequestContext)
   and saves it in its conversational state.  The @Callback injection
   annotation should not be used.
3) SCA Service then makes a non-blocking call to the non-SCA operation,
   passing out the unique conversationID.  This can be obtained via
   RequestContext.getServiceReference().getConversation().getConversationID()
4) non-SCA operation does its processing, then invokes a second SCA
   client passing the unique conversationID.
5) This second SCA client invokes the same SCA Service as in step 1,
   specifying the unique conversationID so that the same service component
   instance is used as in step 2.  This invocation will also pass an
   implicit callback reference to the second client that is not useful
   and should be ignored by the SCA Service.
6) The SCA Service retrieves the callback reference that was saved
   in its conversational state in step 2, and uses this callback reference
   to return the updates to the original conversational client.

Some notes on the above:

a. Currently this would work in Tuscany even if step 5 invoked a different
   SCA Service in the same SCA Component.  However, I can't find words in
   the spec that guarantee this.
b. Currently this would work in Tuscany even if step 1 used a system-
   generated conversationID.  However, I can't find words in the spec
   that guarantee this.

  Simon

Dave Sowerby wrote:


Hi All,

Seasons Greetings :)

I've got a conversational service and it's client and it's all working great.

However I'd like to extend this service to make a call to a non-SCA
asynchronous application and I'm not sure as to how I should make the
call back from the non-SCA application back into the SCA "world".

Just to make sure this is all clear, the flow I'd like to achieve is:

1) Conversational client calls a SCA Service Operation.
2) SCA Service then makes a non-blocking call to the non-SCA operation.
3) non-SCA operation processes and notifies the originating Service
conversation-instance of updates.
4) Any updates are returned to the original conversational client.

Obviously the problem here is calling back into the originating
conversation-instance from the non-sca application.

Looking through the various specifications from osoa I can't see any
suggested solutions to this, though I'm trying to ascertain if any of
the following would work:

o invoke a second client (such as a Servlet) and force the
conversationID with no callback reference (to maintain the original
client callback reference).
o implement a second service through one component without callback
and once again force the conversationID to hopefully find the
originating service conversation-instance.

Are either of these recommended solutions, or is there a more
appropriate means of doing this?  I'd like to find a solution that
would continue to work between Tuscany releases.

Any help would be greatly appreciated.

Cheers,

Dave.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: R1.1 - Sample/demo ant builds

[ant elder]

On Jan 2, 2008 12:00 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> On Jan 2, 2008 10:53 AM, Mike Edwards <[EMAIL PROTECTED]>
> wrote:
>
> > Folks,
> >
> > Some comments
> >
> > Yours,  Mike.
> >
> > ant elder wrote:
> > > On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > >> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> > >> change,
> > >> based on the ant generator plugin, to bring some automation to the
> > process
> > >> of building the ant files for the samples and demos. For any sample
> or
> > >> demo
> > >> that requires explicit dependencies, e.g. the webapp samples, I've
> > >> replaced
> > >> the static ant file with and automatically generated one. In the case
> > that
> > >> some hand crafted ant script is needed, for example, to generate
> SDOs,
> > >> then
> > >> I have the ant generator just build build-dependency.xml which has
> the
> > >> dependencies listed and which can then be included in the manually
> > >> generated
> > >> build.xml script.
> > >>
> > >> I haven't applied this change to all of the samples but it could be
> > done.
> > >> If
> > >> we did have all of the dependencies explicitly described for all of
> the
> > >> samples can we get rid of the "all" and "manifest" jars?
> > >>
> > >> Simon
> > >
> > >
> > >
> > > I think its better if applications don't have to know or care about
> > Tuscany
> > > internals, that includes knowing all the different Tuscany module
> names
> > and
> > > all the dependencies they use.
> >
> > +1 - applications should ideally have ZERO dependence on Tuscany
> > internals.  They should be deployed to an "SCA capable runtime" without
> > having to know anything about that runtime.
> >
> > > We haven't got this right yet so each time we
> > > release our sample Ant builds break as the build.xml files get out of
> > date -
> > > this will be happening for any Ant builds our users have as well. The
> > "all"
> > > jar is an attempt to fix this, its a better way IMHO than having
> > > applications specify every Tuscany module but theres a bit of work
> still
> > to
> > > do to make it work better for webapps. We've also talked before about
> > > changing all the samples to be simple sca contributions that don't
> need
> > any
> > > mention of the Tuscany internals, this is something I think we really
> > need
> > > to do. Both of those things seem better to me than messing about
> trying
> > to
> > > generate build scripts.
> >
> > I agree with this sentiment.  We should be building:
> >
> > a) runtimes of various kinds (SCA standalone, embedded within Tomcat,
> etc)
> >
> > b) applications, containing only the code and other artifacts required
> > for the application itself
> >
> > and then have some regular means of deploying the applications to
> > appropriate runtimes - some applications could be deployed to "almost
> > any" SCA runtime while others need specific runtime capabilities such as
> > a Web server and Servlet support.
> >
> > >
> > >...ant
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > We are describing configuration scenarios in this thread that are not
> currently well covered in the samples that ship with Tuscany. Take the
> following steps as an example,
>
> 1 - choose a runtime
> 2 - configure the runtime
> 3 - start the runtime
> 4 - assemble application(s)
> 5 - contribute the application(s)
> 6 - make top level contributed composites available
>
> 90% of our samples currently assume that
>
> 1-3 means start a standalone runtime with all features enabled by using
> the
> "all" jar
> 4-6 means add a single contribution with a single composite
>
> The ant scripts we have target step 2 and have no impact on 4,5,6. The ant
> scripts do not imply that the "applications have to know or care about
> Tuscany internals". I think you are confusing the act of starting the
> runtime with that of contributing the application. It just so happens that
> in our samples these steps all happen in close proximity, I.e. our samples
> generally include a runtime and the application itself. In the particular
> case of webapps the ant scripts configure the runtime (the war in this
> case)
> so that it contains just enough to run and no more in order to reduce the
> size of the war.
>

Maybe if we had a way to say "Tuscany standalone with all extensions" or
"Tuscany Tomcat with BPEL, WS and JavaScript" then ok but if the application
build process has to mention tuscany-assembly, tuscany-core,
tuscany-definitions, tuscany-databinding and all the other dozens of
required jars then that does seems like "knowing and caring about Tuscany
internals" to me.


>
> Having said this I still agree that having the samples be just
> applications
> that are then contributed to a runnning runtime of your choice is a more
> well rounded target to aim for.  I note that ther

Re: Build of calculator-implementation-policies sample is failing

[Simon Laws]

On Jan 2, 2008 11:56 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> I did a full checkout of Java SCA and tried to build it.  I got the
> following failure in samples/calculator-implementation-policies.
> Looking at the messages, I see validation errors followed by a
> problem with login configuration.  Does anyone have ideas on why
> this sample is failing?
>
>   Simon
>
> [INFO]
> -
> ---
> [INFO] Building Apache Tuscany SCA Calculator Sample using Implementation
> Polici
> es
> [INFO]task-segment: [install]
> [INFO]
> -
> ---
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 13 source files to
> H:\tuscany59\sca\samples\calculator-implemen
> tation-policies\target\classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Compiling 1 source file to
> H:\tuscany59\sca\samples\calculator-implementa
> tion-policies\target\test-classes
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> H:\tuscany59\sca\samples\calculator-implementa
> tion-policies\target\surefire-reports
>
> ---
>  T E S T S
> ---
> Running calculator.CalculatorTestCase
> 02-Jan-2008 11:31:08
> org.apache.tuscany.sca.contribution.processor.ValidatingXML
> StreamReader$1 error
> WARNING: XMLSchema validation problem in:
> file:/H:/tuscany59/sca/samples/calcula
> tor-implementation-policies/target/classes/Calculator.composite, line: 28,
> colum
> n: 4
> cvc-complex-type.2.4.a: Invalid content was found starting with element
> 'operati
> on'. One of '{WC[##other:"http://www.osoa.org/xmlns/sca/1.0"]}' is
> expected.
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - add
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation add with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - add
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation add with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - add
> 02-Jan-2008 11:31:08
> FINER: Returning from operation add with return value 5
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - add
> 02-Jan-2008 11:31:08
> FINER: Returning from operation add with return value 5
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - subtract
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation subtract with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - subtract
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation subtract with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - subtract
> 02-Jan-2008 11:31:08
> FINER: Returning from operation subtract with return value 1
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - subtract
> 02-Jan-2008 11:31:08
> FINER: Returning from operation subtract with return value 1
> 02-Jan-2008 11:31:08
> org.apache.tuscany.sca.contribution.processor.ValidatingXML
> StreamReader$1 error
> WARNING: XMLSchema validation problem in:
> file:/H:/tuscany59/sca/samples/calcula
> tor-implementation-policies/target/classes/Calculator.composite, line: 28,
> colum
> n: 4
> cvc-complex-type.2.4.a: Invalid content was found starting with element
> 'operati
> on'. One of '{WC[##other:"http://www.osoa.org/xmlns/sca/1.0"]}' is
> expected.
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - add
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation add with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - add
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation add with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - add
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation add with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - add
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation add with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - add
> 02-Jan-2008 11:31:08
> FINER: Returning from operation add with return value 5
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - add
> 02-Jan-2008 11:31:08
> FINER: Returning from operation add with return value 5
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - add
> 02-Jan-2008 11:31:08
> FINER: Returning from operation add with return value 5
> 02-Jan-2008 11:31:08
> INFO:  Returned from operation - add
> 02-Jan-2008 11:31:08
> FINER: Returning from operation add with return value 5
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - subtract
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation subtract with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> INFO:  Invoking operation - subtract
> 02-Jan-2008 11:31:08
> FINER: Inovoking operation subtract with arguments 3.0, 2.0,
> 02-Jan-2008 11:31:08
> I

Re: R1.1 - Sample/demo ant builds

[ant elder]

On Jan 2, 2008 10:53 AM, Mike Edwards <[EMAIL PROTECTED]>
wrote:



We should be building:
>
> a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)
>
> b) applications, containing only the code and other artifacts required
> for the application itself
>
> and then have some regular means of deploying the applications to
> appropriate runtimes - some applications could be deployed to "almost
> any" SCA runtime while others need specific runtime capabilities such as
> a Web server and Servlet support.
>

Which incidentally is what I've been starting trying to do in
modules/runtime, modules/runtime-*, and distribution/tomcat and
distribution/webapp etc, its a ways from being ready though.

   ...ant

Re: R1.1 - Sample/demo ant builds

[Simon Laws]

On Jan 2, 2008 10:53 AM, Mike Edwards <[EMAIL PROTECTED]>
wrote:

> Folks,
>
> Some comments
>
> Yours,  Mike.
>
> ant elder wrote:
> > On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> >> change,
> >> based on the ant generator plugin, to bring some automation to the
> process
> >> of building the ant files for the samples and demos. For any sample or
> >> demo
> >> that requires explicit dependencies, e.g. the webapp samples, I've
> >> replaced
> >> the static ant file with and automatically generated one. In the case
> that
> >> some hand crafted ant script is needed, for example, to generate SDOs,
> >> then
> >> I have the ant generator just build build-dependency.xml which has the
> >> dependencies listed and which can then be included in the manually
> >> generated
> >> build.xml script.
> >>
> >> I haven't applied this change to all of the samples but it could be
> done.
> >> If
> >> we did have all of the dependencies explicitly described for all of the
> >> samples can we get rid of the "all" and "manifest" jars?
> >>
> >> Simon
> >
> >
> >
> > I think its better if applications don't have to know or care about
> Tuscany
> > internals, that includes knowing all the different Tuscany module names
> and
> > all the dependencies they use.
>
> +1 - applications should ideally have ZERO dependence on Tuscany
> internals.  They should be deployed to an "SCA capable runtime" without
> having to know anything about that runtime.
>
> > We haven't got this right yet so each time we
> > release our sample Ant builds break as the build.xml files get out of
> date -
> > this will be happening for any Ant builds our users have as well. The
> "all"
> > jar is an attempt to fix this, its a better way IMHO than having
> > applications specify every Tuscany module but theres a bit of work still
> to
> > do to make it work better for webapps. We've also talked before about
> > changing all the samples to be simple sca contributions that don't need
> any
> > mention of the Tuscany internals, this is something I think we really
> need
> > to do. Both of those things seem better to me than messing about trying
> to
> > generate build scripts.
>
> I agree with this sentiment.  We should be building:
>
> a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)
>
> b) applications, containing only the code and other artifacts required
> for the application itself
>
> and then have some regular means of deploying the applications to
> appropriate runtimes - some applications could be deployed to "almost
> any" SCA runtime while others need specific runtime capabilities such as
> a Web server and Servlet support.
>
> >
> >...ant
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> We are describing configuration scenarios in this thread that are not
currently well covered in the samples that ship with Tuscany. Take the
following steps as an example,

1 - choose a runtime
2 - configure the runtime
3 - start the runtime
4 - assemble application(s)
5 - contribute the application(s)
6 - make top level contributed composites available

90% of our samples currently assume that

1-3 means start a standalone runtime with all features enabled by using the
"all" jar
4-6 means add a single contribution with a single composite

The ant scripts we have target step 2 and have no impact on 4,5,6. The ant
scripts do not imply that the "applications have to know or care about
Tuscany internals". I think you are confusing the act of starting the
runtime with that of contributing the application. It just so happens that
in our samples these steps all happen in close proximity, I.e. our samples
generally include a runtime and the application itself. In the particular
case of webapps the ant scripts configure the runtime (the war in this case)
so that it contains just enough to run and no more in order to reduce the
size of the war.

Having said this I still agree that having the samples be just applications
that are then contributed to a runnning runtime of your choice is a more
well rounded target to aim for.  I note that there a series of modules under
construction.

tuscany-runtime
tuscany-runtime-tomcat
tuscany-runtime-war

which could be extended to include tuscany-runtime-standalone,
tuscany-runtime-jms or whatever else is required.

We still need a mechanism for configuring these runtimes. In particular we
have binding, databinding and implementation extensions that can be
included/excluded. Also some of these extensions may provided alternative
implementations that must be selected explicitly. It seems that steps 1, 2
and 3 resolve to

1 - choose hosting approach
2 - choose extensions
3 - build useable runtime

It may be that the "all" jar can satisfy many of the cases now as we don't
currently ha

Build of calculator-implementation-policies sample is failing

[Simon Nash]

I did a full checkout of Java SCA and tried to build it.  I got the
following failure in samples/calculator-implementation-policies.
Looking at the messages, I see validation errors followed by a
problem with login configuration.  Does anyone have ideas on why
this sample is failing?

  Simon

[INFO] -
---
[INFO] Building Apache Tuscany SCA Calculator Sample using Implementation Polici
es
[INFO]task-segment: [install]
[INFO] -
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 13 source files to H:\tuscany59\sca\samples\calculator-implemen
tation-policies\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to H:\tuscany59\sca\samples\calculator-implementa
tion-policies\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: H:\tuscany59\sca\samples\calculator-implementa
tion-policies\target\surefire-reports

---
 T E S T S
---
Running calculator.CalculatorTestCase
02-Jan-2008 11:31:08 org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in: file:/H:/tuscany59/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line: 28, colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with element 'operati
on'. One of '{WC[##other:"http://www.osoa.org/xmlns/sca/1.0"]}' is expected.
02-Jan-2008 11:31:08
INFO:  Invoking operation - add
02-Jan-2008 11:31:08
FINER: Inovoking operation add with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Invoking operation - add
02-Jan-2008 11:31:08
FINER: Inovoking operation add with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Returned from operation - add
02-Jan-2008 11:31:08
FINER: Returning from operation add with return value 5
02-Jan-2008 11:31:08
INFO:  Returned from operation - add
02-Jan-2008 11:31:08
FINER: Returning from operation add with return value 5
02-Jan-2008 11:31:08
INFO:  Invoking operation - subtract
02-Jan-2008 11:31:08
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Invoking operation - subtract
02-Jan-2008 11:31:08
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Returned from operation - subtract
02-Jan-2008 11:31:08
FINER: Returning from operation subtract with return value 1
02-Jan-2008 11:31:08
INFO:  Returned from operation - subtract
02-Jan-2008 11:31:08
FINER: Returning from operation subtract with return value 1
02-Jan-2008 11:31:08 org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in: file:/H:/tuscany59/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line: 28, colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with element 'operati
on'. One of '{WC[##other:"http://www.osoa.org/xmlns/sca/1.0"]}' is expected.
02-Jan-2008 11:31:08
INFO:  Invoking operation - add
02-Jan-2008 11:31:08
FINER: Inovoking operation add with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Invoking operation - add
02-Jan-2008 11:31:08
FINER: Inovoking operation add with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Invoking operation - add
02-Jan-2008 11:31:08
FINER: Inovoking operation add with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Invoking operation - add
02-Jan-2008 11:31:08
FINER: Inovoking operation add with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Returned from operation - add
02-Jan-2008 11:31:08
FINER: Returning from operation add with return value 5
02-Jan-2008 11:31:08
INFO:  Returned from operation - add
02-Jan-2008 11:31:08
FINER: Returning from operation add with return value 5
02-Jan-2008 11:31:08
INFO:  Returned from operation - add
02-Jan-2008 11:31:08
FINER: Returning from operation add with return value 5
02-Jan-2008 11:31:08
INFO:  Returned from operation - add
02-Jan-2008 11:31:08
FINER: Returning from operation add with return value 5
02-Jan-2008 11:31:08
INFO:  Invoking operation - subtract
02-Jan-2008 11:31:08
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Invoking operation - subtract
02-Jan-2008 11:31:08
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
02-Jan-2008 11:31:08
INFO:  Returned from operation - subtract
02-Jan-2008 11:31:08
FINER: Returning from operation subtract with return value 1
02-Jan-2008 11:31:08
INFO:  Returned from operation - subtract
02-Jan-2008 11:31:08
FINER: Returning from operation subtract with return value 1
02-Jan-2008 11:31:08
INFO:  Invoking operation - multiply
02-Jan-2

Re: R1.1 - Sample/demo ant builds

[Mike Edwards]

Folks,

Some comments

Yours,  Mike.

ant elder wrote:

On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]> wrote:


For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
change,
based on the ant generator plugin, to bring some automation to the process
of building the ant files for the samples and demos. For any sample or
demo
that requires explicit dependencies, e.g. the webapp samples, I've
replaced
the static ant file with and automatically generated one. In the case that
some hand crafted ant script is needed, for example, to generate SDOs,
then
I have the ant generator just build build-dependency.xml which has the
dependencies listed and which can then be included in the manually
generated
build.xml script.

I haven't applied this change to all of the samples but it could be done.
If
we did have all of the dependencies explicitly described for all of the
samples can we get rid of the "all" and "manifest" jars?

Simon




I think its better if applications don't have to know or care about Tuscany
internals, that includes knowing all the different Tuscany module names and
all the dependencies they use. 


+1 - applications should ideally have ZERO dependence on Tuscany 
internals.  They should be deployed to an "SCA capable runtime" without 
having to know anything about that runtime.



We haven't got this right yet so each time we
release our sample Ant builds break as the build.xml files get out of date -
this will be happening for any Ant builds our users have as well. The "all"
jar is an attempt to fix this, its a better way IMHO than having
applications specify every Tuscany module but theres a bit of work still to
do to make it work better for webapps. We've also talked before about
changing all the samples to be simple sca contributions that don't need any
mention of the Tuscany internals, this is something I think we really need
to do. Both of those things seem better to me than messing about trying to
generate build scripts.


I agree with this sentiment.  We should be building:

a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)

b) applications, containing only the code and other artifacts required 
for the application itself


and then have some regular means of deploying the applications to 
appropriate runtimes - some applications could be deployed to "almost 
any" SCA runtime while others need specific runtime capabilities such as 
a Web server and Servlet support.




   ...ant



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1852) Use static model to define DAS Config relationships

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar closed TUSCANY-1852.


Resolution: Fixed

can re-open based on new features in SDO in future.

> Use static model to define DAS Config relationships
> ---
>
> Key: TUSCANY-1852
> URL: https://issues.apache.org/jira/browse/TUSCANY-1852
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24861.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1929) generate xml from dataobject

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar closed TUSCANY-1929.


Resolution: Fixed

In case the prevision explanation is not applicable to the problem , please 
re-open the issue.

> generate xml from dataobject
> 
>
> Key: TUSCANY-1929
> URL: https://issues.apache.org/jira/browse/TUSCANY-1929
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-M2
> Environment: java ee 1.5, eclipse 3.3.1.1. , windows xp, das 1.0 beta 
> 2, access mdb - no access installed, sca 1.0
>Reporter: Kristina 
>Assignee: Amita Vadhavkar
> Attachments: XMLHelperSample.java
>
>
> hi all,
> not sure if this is a bug or is just me... bottom line i need help :)
> when trying to generate the xml from dataobject , i get an empty one 
> eventhough the dataobject is filled
> I am using: String generatedXml = XMLHelper.INSTANCE.save(root, 
> "http://helloworld2";, "MaterialListForTest"); where root is my dataobject
> what am i doing wrong?
> thanks,
> kristina

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1944) support update of PK

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-1944.
--

Resolution: Fixed

fixed at revision 608066

> support update of PK
> 
>
> Key: TUSCANY-1944
> URL: https://issues.apache.org/jira/browse/TUSCANY-1944
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
>Assignee: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26631.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1944) support update of PK

[Amita Vadhavkar (JIRA)]

support update of PK


 Key: TUSCANY-1944
 URL: https://issues.apache.org/jira/browse/TUSCANY-1944
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
 Fix For: Java-DAS-Next


http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26631.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: An update collision occurred when update the primary key property !

[Amita Vadhavkar]

UpdateGenerator forms update statement with "where" clause like this -
iterate over all PKs and include them in "where" clause. Then iterate
over all changed fields and include them in "where" clause with values
set to old values from change summary. In case the PK itself is being
changed, this results in something like below -

update tableX set idX=? where idX=? and idX=oldValueOfidX

Later in ChangeOperation.execute(), when the changed fields in DObj are
scanned
referring to propertyNames,for idX, the new value is found and set for both
idX
params above with "?", this is because the first "where" clause idX is not
marked as Collision param. This results in -

update tableX set idX=newValueOfIdx where idX=newValueOfIdx and
idX=oldValueOfidX

This results in 0 rows update in DB and seen by DAS as OCC Exception.

A simple fix will be - when changedFields includes a PK, avoid first
inclusion
in where clause in UpdateGenerator. For other cases (i.e. changedFields do
not
include PK), keep the logic as is.

There can be cases where the PK needs to be modified in the tables - like
data
migration, system upgrades etc. So the above simple fix will be useful in
supporting
update of PK.

Old discussion ref -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16310.html
Minor change on the top of the above discussion is making update efficient
by
avoiding duplicate inclusion of same column in "where" clause.

New test case - AliasTests.testModifyPK()

Submitting patch soon for this.

Regards,
Amita




On Dec 31, 2007 8:48 AM, <[EMAIL PROTECTED]> wrote:

> Hi All ,
>
>I  write a sample to test the DAS work with the DB , when execute a
> update operation on primary key ,
>
> an update collision occurred ,  how to deal with it if I need update the
> primary key value ?
>
>
> Best Regards
>
> Leo
>
>

Re: R1.1. - Host-jms-activemq

[ant elder]

On Jan 2, 2008 9:09 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

> Firstly, should this be included in 1.1?
>
> This new JMS host module can only be used once on any particular machine
> as
> it uses a specific port (61616?). This causes problems in our demos and
> samples unless we choose our dependencies carefully. If you use the
> manifest/all approach then you always get this jar and the second app you
> start, for example, where the sample comprises server and client apps,
> will
> fail to start.
>
> It feels like we need a more configurable way of connecting SCA
> applications
> to JMS providers that may already be running without forcing a new one to
> be
> started.
>
> I've got round this for now by auto generating the client application ant
> scripts that are affected which has the effect of explicitly listing the
> dependencies and hence misses out host-jms-activemq where it's not
> required.
>
>
> Thoughts?
>
> Simon
>

I'm not sure if we should include this or not yet, i'm still working on the
jms binding.

There's two issues - how to configure it, and how to control if its used or
not.

We don't yet seem to have any way for configuring things like default ports
in Tuscany. There is some mention in the JMS binding spec of using the
definitions.xml file for some configuration so maybe something could be done
in that. The default port configuration problem is worse for the JMS binding
than say the WS binding as there's not the option in JMS of specifying the
port in the binding uri as there is with the WS binding.

We need to change the JMS host so that it only starts the broker when
something actually uses a service with binding.jms, and that will help some
with the controlling if its used or not problem.

   ...ant

Re: R1.1 - Sample/demo ant builds

[ant elder]

On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> change,
> based on the ant generator plugin, to bring some automation to the process
> of building the ant files for the samples and demos. For any sample or
> demo
> that requires explicit dependencies, e.g. the webapp samples, I've
> replaced
> the static ant file with and automatically generated one. In the case that
> some hand crafted ant script is needed, for example, to generate SDOs,
> then
> I have the ant generator just build build-dependency.xml which has the
> dependencies listed and which can then be included in the manually
> generated
> build.xml script.
>
> I haven't applied this change to all of the samples but it could be done.
> If
> we did have all of the dependencies explicitly described for all of the
> samples can we get rid of the "all" and "manifest" jars?
>
> Simon



I think its better if applications don't have to know or care about Tuscany
internals, that includes knowing all the different Tuscany module names and
all the dependencies they use. We haven't got this right yet so each time we
release our sample Ant builds break as the build.xml files get out of date -
this will be happening for any Ant builds our users have as well. The "all"
jar is an attempt to fix this, its a better way IMHO than having
applications specify every Tuscany module but theres a bit of work still to
do to make it work better for webapps. We've also talked before about
changing all the samples to be simple sca contributions that don't need any
mention of the Tuscany internals, this is something I think we really need
to do. Both of those things seem better to me than messing about trying to
generate build scripts.

   ...ant

Saxon versions - was: Release 1.1 - what will be ready for next week?

[Simon Laws]

-- Forwarded message --
From: Simon Laws <[EMAIL PROTECTED]>
Date: Dec 29, 2007 11:01 AM
Subject: Re: Release 1.1 - what will be ready for next week?
To: tuscany-dev@ws.apache.org




On Dec 28, 2007 4:00 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:

> Implementation-bpel was OK. I have added implementation-widget and
> implementation-data-api.
>
> On Dec 28, 2007 4:59 AM, Luciano Resende < [EMAIL PROTECTED]> wrote:
> > Good point Haleh, implementation.bpel should not be excluded,
> > implementation-data-api should not either as it's being used in the
> > store tutorial scenario. Let me check if I can fix this on the
> > distribution files...
> >
> >
> > On Dec 27, 2007 7:51 PM, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > > Hi Simon,
> > > Thank you for trying to get a release candidate ready during the
> holidays.
> > > Why is implementation.bpel excluded?
> > >
> > > Haleh
> > >
> > >
> > > On 12/21/07, Simon Laws <[EMAIL PROTECTED] > wrote:
> > > >
> > > > On Dec 19, 2007 10:18 AM, Rajini Sivaram <
> [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Simon,
> > > > >
> > > > > No, I don't have an ID yet. Please do the update for me.
> > > > >
> > > > > Thank you...
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > > >
> > > > > On 12/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > On Dec 19, 2007 9:07 AM, Rajini Sivaram <
> [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > >
> > > > > > > Simon,
> > > > > > >
> > > > > > > There shouldn't be any visible effect because of the
> classloading
> > > > > > changes
> > > > > > > to
> > > > > > > the Tuscany runtime (at least that was the goal). It enables
> Tuscany
> > > > > to
> > > > > > be
> > > > > > > run in a multi-classloader environment including inside OSGi.
> By
> > > > > > default,
> > > > > > > Tuscany continues to run using a single CLASSPATH-based
> classloader.
> > > > > > >
> > > > > > > Contribution classloading was also modified. As a result,
> > > > > contributions
> > > > > > no
> > > > > > > longer need to be in the CLASSPATH. All import/export
> dependencies
> > > > > > across
> > > > > > > contributions should be explicitly specified (as described in
> the
> > > > > spec).
> > > > > > > Earlier, classes from contributions were loaded using the
> thread
> > > > > context
> > > > > > > classloader (typically using CLASSPATH), and import/export
> > > > statements
> > > > > > did
> > > > > > > not have any effect.
> > > > > > >
> > > > > > >
> > > > > > > Thank you...
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Rajini
> > > > > > >
> > > > > > >
> > > > > > > On 12/18/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > > On Dec 13, 2007 1:37 PM, Simon Laws <[EMAIL PROTECTED]
> >
> > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Dec 13, 2007 12:16 PM, ant elder < [EMAIL PROTECTED]>
> wrote:
> > > > > > > > >
> > > > > > > > > > On Dec 12, 2007 10:03 AM, Simon Laws <
> > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Dec 12, 2007 9:45 AM, Luciano Resende <
> > > > > [EMAIL PROTECTED]>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Following Ant's question, after you cut the first
> RC,
> > > > > > > development
> > > > > > > > > > > > would continue on trunk or on a branch ? Based on
> the
> > > > > > timeframe
> > > > > > > > and
> > > > > > > > > > > > considering we would still work on issues on the
> week of
> > > > Jan
> > > > > > > 7th,
> > > > > > > > > > I'd
> > > > > > > > > > > > recommend continue on trunk until sometime around
> end of
> > > > > year.
> > > > > > > > > > > >
> > > > > > > > > > > > On Dec 12, 2007 12:22 AM, ant elder <
> [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > > > > > > > I don't think the tomcat deep integration, JMS, or
> > > > > > > distribution
> > > > > > > > > > > > structure
> > > > > > > > > > > > > changes would all be done by next week. Haven't
> seen
> > > > much
> > > > > > > > > > happening
> > > > > > > > > > > with
> > > > > > > > > > > > > jsonrpc references recently either. We do have all
> of
> > > > the
> > > > > > rest
> > > > > > > > of
> > > > > > > > > > this
> > > > > > > > > > > > year
> > > > > > > > > > > > > to continue development though right?
> > > > > > > > > > > > >
> > > > > > > > > > > > >...ant
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Dec 11, 2007 10:59 PM, Simon Laws <
> > > > > > > [EMAIL PROTECTED]
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Following on from the JIRA tidy up note here are
> a few
> > > > > > high
> > > > > > > > > > level
> > > > > > > > > > > > areas
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > I've seen activity on over the last few weeks
> and so
> > > > may
> > > > > > be

R1.1. - Host-jms-activemq

[Simon Laws]

Firstly, should this be included in 1.1?

This new JMS host module can only be used once on any particular machine as
it uses a specific port (61616?). This causes problems in our demos and
samples unless we choose our dependencies carefully. If you use the
manifest/all approach then you always get this jar and the second app you
start, for example, where the sample comprises server and client apps, will
fail to start.

It feels like we need a more configurable way of connecting SCA applications
to JMS providers that may already be running without forcing a new one to be
started.

I've got round this for now by auto generating the client application ant
scripts that are affected which has the effect of explicitly listing the
dependencies and hence misses out host-jms-activemq where it's not required.


Thoughts?

Simon

R1.1 - Sample/demo ant builds

[Simon Laws]

For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a change,
based on the ant generator plugin, to bring some automation to the process
of building the ant files for the samples and demos. For any sample or demo
that requires explicit dependencies, e.g. the webapp samples, I've replaced
the static ant file with and automatically generated one. In the case that
some hand crafted ant script is needed, for example, to generate SDOs, then
I have the ant generator just build build-dependency.xml which has the
dependencies listed and which can then be included in the manually generated
build.xml script.

I haven't applied this change to all of the samples but it could be done. If
we did have all of the dependencies explicitly described for all of the
samples can we get rid of the "all" and "manifest" jars?

Simon

[jira] Resolved: (TUSCANY-1608) Rationalize sample and demo ant build and run scripts

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws resolved TUSCANY-1608.
-

Resolution: Fixed

For those sample and demos that require specific dependencies to be described 
the ant files are now generated by the maven ant generator plugin. This is used 
in one of two ways. If there is no requirement in the sample for hand crafted 
build script then the entire build.xml is generated. If some hand crafting is 
required, e.g. SDO generation, then just build-dependencies.xml is generated 
and can be included in the manually created build.xml file. 

> Rationalize sample and demo ant build and run scripts
> -
>
> Key: TUSCANY-1608
> URL: https://issues.apache.org/jira/browse/TUSCANY-1608
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-1.1
>
>
> The ant build scripts used in the samples are taking a lot of maintenance 
> each time we release. Here are some things that we need to look at
> fix web app packaging (not just restricted to ant builds but currently we are 
> relying on the ant build so we don;t have to ship large wars)
> factor out all of the common bits where possible so that they aren't in every 
> file
>   initialization
>   compiles
>   dojo dowload
>   jar packaging
>   war packaging
> Come up with a better way of doing dependencies
>   Allways use all of the jars 
>   or generate project specific dependencies
> How far can we go to running the samples in the main build (or a samples test 
> build) in the same way as they run as samples
>   
>   
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (TUSCANY-1608) Rationalize sample and demo ant build and run scripts

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws reassigned TUSCANY-1608:
---

Assignee: Simon Laws

> Rationalize sample and demo ant build and run scripts
> -
>
> Key: TUSCANY-1608
> URL: https://issues.apache.org/jira/browse/TUSCANY-1608
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-1.1
>
>
> The ant build scripts used in the samples are taking a lot of maintenance 
> each time we release. Here are some things that we need to look at
> fix web app packaging (not just restricted to ant builds but currently we are 
> relying on the ant build so we don;t have to ship large wars)
> factor out all of the common bits where possible so that they aren't in every 
> file
>   initialization
>   compiles
>   dojo dowload
>   jar packaging
>   war packaging
> Come up with a better way of doing dependencies
>   Allways use all of the jars 
>   or generate project specific dependencies
> How far can we go to running the samples in the main build (or a samples test 
> build) in the same way as they run as samples
>   
>   
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]