Re: Native M3 release status

[Simon Laws]

On 2/22/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 22/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Pete Robbins wrote:
> > On 22/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >>
> >> On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >> > On 21/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >> > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >> > > > On 21/02/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >> > > > >
> >> > > > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >> > > > > > I now have Ruby working on Mac. I will remove the ws
bindings
> >> and
> >> > > > > clients
> >> > > > > > from the *Calculator samples so we have a simple sample for
> >> each
> >> > > > > language.
> >> > > > > > $TUSCANY_SCACPP/extensions/ruby/lib needs to be added to
the
> >> > > > > LD_LIBRARY_PATH
> >> > > > > > (or PATH on windows) to run the Ruby clients. I've updated
> the
> >> runclient
> >> > > > > > scripts.
> >> > > > >
> >> > > > > Running a Linux build against the latest code gives me an
error
> >> with
> >> > > > > the new Ruby layout:
> >> > > > >
> >> > > > > make[5]: Entering directory
> >> > > > >
> >> > > > >
> >>
>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension/src'
> >>
> >> > > > > g++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> >> -fexceptions
> >> > > > > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
> >> > > > > -mtune=generic -fasynchronous-unwind-tables -Wall  -fPIC
-I.
> >> > > > > -I/usr/lib/ruby/1.8/i386-linux -I/usr/lib/ruby/1.8/i386-linux
> >> -I.   -c
> >> > > > > Extension.cpp
> >> > > > > Extension.cpp:28:35: error: tuscany/sca/ruby/Ruby.h: No such
> >> file
> >> or
> >> > > > > directory
> >> > > > > Extension.cpp:29:51: error:
> >> tuscany/sca/ruby/RubyCompositeContext.h:
> >> > > > > No such file or directory
> >> > > > >
> >> > > > > Did everything get checked in? Am I missing an env variable?
> >> > > >
> >> > > >
> >> > > > Everything is checked in. The extconf.rb RUby script generates
> the
> >> makefile.
> >> > > > It should add the lib and include paths nexessary. Are there
> >> messages before
> >> > > > the compile like:
> >> > > >
> >> > > > checking for #include 
> >> > > >
> >> > > > ?
> >> > > >
> >> > >
> >> > > Yep, the full build log for sca/runtime/extensions/ruby/extension
> >> is:
> >> > >
> >> > > Making install in extension
> >> > > make[4]: Entering directory
> >> > >
> >>
>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension'
> >>
> >> > > cd src; ruby extconf.rb; make
> >> > > checking for tuscany/sca/ruby/RubyCompositeContext.h... yes
> >> > > checking for main() in -ltuscany_sca_ruby_lang... yes
> >> > > creating Makefile
> >> > > make[5]: Entering directory
> >> > >
> >>
>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension/src'
> >>
> >> > > g++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> >> > > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
> >> > > -mtune=generic -fasynchronous-unwind-tables -Wall  -fPIC   -I.
> >> > > -I/usr/lib/ruby/1.8/i386-linux -I/usr/lib/ruby/1.8/i386-linux
> >> -I.   -c
> >> > > Extension.cpp
> >> > > Extension.cpp:28:35: error: tuscany/sca/ruby/Ruby.h: No such file
> or
> >> directory
> >> > > Extension.cpp:29:51: error:
> tuscany/sca/ruby/RubyCompositeContext.h:
> >> > > No such file or directory
> >> > > Extension.cpp:35: error: āVALUEā does not name a type
> >> > > Extension.cpp: In function āvoid Init_tuscany_sca_ruby()ā:
> >> > > Extension.cpp:47: error: āVALUEā was not declared in this scope
> >> > > Extension.cpp:47: error: expected `;' before āmoduleā
> >> > > Extension.cpp:48: error: āmoduleā was not declared in this scope
> >> > > Extension.cpp:48: error: expected primary-expression before ā)ā
> >> token
> >> > > Extension.cpp:48: error: āANYARGSā was not declared in this scope
> >> > > Extension.cpp:48: error: ārb_define_module_functionā was not
> >> declared
> >> > > in this scope
> >> > > make[5]: *** [Extension.o] Error 1
> >> > > make[5]: Leaving directory
> >> > >
> >>
>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension/src'
> >>
> >> > > make[4]: *** [extension_build] Error 2
> >> > > make[4]: Leaving directory
> >> > >
> >>
>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension'
> >>
> >> > > make[3]: *** [install-recursive] Error 1
> >> > > make[3]: Leaving directory
> >> > > `/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby'
> >> > > make[2]: *** [install-recursive] Error 1
> >> > > make[2]: Leaving directory
> >> > > `/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions'
> >> > > make[1]: *** [install-recursive] Error 1
> >> > > make[1]: Leaving directory
> >> `/home/ajborley/workspace/TuscanyCPP/sca/runtime'
> >> > > make: *** [install-recursive] Error 1
> >> > >
> >> > > So the check for tuscany/sca/ruby/RubyCompositeContext.h is there
> >> > > (although there isn't

Re: Native M3 release status

[Simon Laws]

On 2/28/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Pete Robbins wrote:
> On 22/02/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>  On 22/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >
>> > Pete Robbins wrote:
>> > > On 22/02/07, Andrew Borley <[EMAIL PROTECTED] > wrote:
>> > >>
>> > >> On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>> > >> > On 21/02/07, Andrew Borley < [EMAIL PROTECTED]> wrote:
>> > >> > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>> > >> > > > On 21/02/07, Andrew Borley < [EMAIL PROTECTED]> wrote:
>> > >> > > > >
>> > >> > > > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED] >
wrote:
>> > >> > > > > > I now have Ruby working on Mac. I will remove the ws
>> > bindings
>> > >> and
>> > >> > > > > clients
>> > >> > > > > > from the *Calculator samples so we have a simple
>> sample for
>> >
>> > >> each
>> > >> > > > > language.
>> > >> > > > > > $TUSCANY_SCACPP/extensions/ruby/lib needs to be added to
>> > the
>> > >> > > > > LD_LIBRARY_PATH
>> > >> > > > > > (or PATH on windows) to run the Ruby clients. I've
>> updated
>> > the
>> > >> runclient
>> > >> > > > > > scripts.
>> > >> > > > >
>> > >> > > > > Running a Linux build against the latest code gives me an
>> > error
>> > >> with
>> > >> > > > > the new Ruby layout:
>> > >> > > > >
>> > >> > > > > make[5]: Entering directory
>> > >> > > > >
>> > >> > > > >
>> > >>
>> >
>>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension/src'
>>
>> >
>> > >>
>> > >> > > > > g++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>> > >> -fexceptions
>> > >> > > > > -fstack-protector --param=ssp-buffer-size=4 -m32
>> -march=i386
>> > >> > > > > -mtune=generic -fasynchronous-unwind-tables -Wall  -fPIC
>> > -I.
>> > >> > > > > -I/usr/lib/ruby/1.8/i386-linux
>> -I/usr/lib/ruby/1.8/i386-linux
>> > >> -I.   -c
>> > >> > > > > Extension.cpp
>> > >> > > > > Extension.cpp:28:35: error: tuscany/sca/ruby/Ruby.h: No
>> such
>> > >> file
>> > >> or
>> > >> > > > > directory
>> > >> > > > > Extension.cpp:29:51: error:
>> > >> tuscany/sca/ruby/RubyCompositeContext.h:
>> > >> > > > > No such file or directory
>> > >> > > > >
>> > >> > > > > Did everything get checked in? Am I missing an env
>> variable?
>> > >> > > >
>> > >> > > >
>> > >> > > > Everything is checked in. The extconf.rb RUby script
>> generates
>> > the
>> > >> makefile.
>> > >> > > > It should add the lib and include paths nexessary. Are there
>> > >> messages before
>> > >> > > > the compile like:
>> > >> > > >
>> > >> > > > checking for #include
>> 
>> > >> > > >
>> > >> > > > ?
>> > >> > > >
>> > >> > >
>> > >> > > Yep, the full build log for
>> sca/runtime/extensions/ruby/extension
>> > >> is:
>> > >> > >
>> > >> > > Making install in extension
>> > >> > > make[4]: Entering directory
>> > >> > >
>> > >>
>> >
>>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension'
>>
>> > >>
>> > >> > > cd src; ruby extconf.rb; make
>> > >> > > checking for tuscany/sca/ruby/RubyCompositeContext.h... yes
>> > >> > > checking for main() in -ltuscany_sca_ruby_lang... yes
>> > >> > > creating Makefile
>> > >> > > make[5]: Entering directory
>> > >> > >
>> > >>
>> >
>>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension/src'
>>
>> >
>> > >>
>> > >> > > g++ -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>> -fexceptions
>> > >> > > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
>> > >> > > -mtune=generic -fasynchronous-unwind-tables -Wall  -fPIC   -I.
>> > >> > > -I/usr/lib/ruby/1.8/i386-linux -I/usr/lib/ruby/1.8/i386-linux
>> > >> -I.   -c
>> > >> > > Extension.cpp
>> > >> > > Extension.cpp:28:35: error: tuscany/sca/ruby/Ruby.h: No such
>> file
>> > or
>> > >> directory
>> > >> > > Extension.cpp:29:51: error:
>> > tuscany/sca/ruby/RubyCompositeContext.h:
>> > >> > > No such file or directory
>> > >> > > Extension.cpp:35: error: āVALUEā does not name a type
>> > >> > > Extension.cpp: In function āvoid Init_tuscany_sca_ruby()ā:
>> > >> > > Extension.cpp:47: error: āVALUEā was not declared in this
scope
>> > >> > > Extension.cpp:47: error: expected `;' before āmoduleā
>> > >> > > Extension.cpp:48: error: āmoduleā was not declared in this
>> scope
>> > >> > > Extension.cpp:48: error: expected primary-expression before
ā)ā
>> > >> token
>> > >> > > Extension.cpp :48: error: āANYARGSā was not declared in this
>> > scope
>> > >> > > Extension.cpp:48: error: ārb_define_module_functionā was not
>> > >> declared
>> > >> > > in this scope
>> > >> > > make[5]: *** [ Extension.o] Error 1
>> > >> > > make[5]: Leaving directory
>> > >> > >
>> > >>
>> >
>>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension/src'
>>
>> > >>
>> > >> > > make[4]: *** [extension_build] Error 2
>> > >> > > make[4]: Leaving directory
>> > >> > >
>> > >>
>> >
>>
`/home/ajborley/workspace/TuscanyCPP/sca/runtime/extensions/ruby/extension'
>>
>> > >>
>> > >> > > make[3]: *** [install-recursive] Error 1
>> > >> 

Running Java SCA Calculators sample?

[Simon Laws]

After talking a few  weeks ago about how best to build Java I got distracted
doing PHP SCA things. Anyhow I have actually got back to trying it out.

* I checked out head and the integration branch with the aim of running up
the calculator sample.
* I built Head using Raymond's splendid script [1] (maybe that should be in
svn somewhere ;-) and most of it seemed OK. I get the following error.

---
T E S T S
---
Running
org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyCon
tent
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.14 sec
Running
org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.657 sec
<<< F
AILURE!
testLauncherUsage(
org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL
auncher)  Time elapsed: 0.812 sec  <<< FAILURE!
junit.framework.ComparisonFailure: expected:<..> but was:<...
...>
   at junit.framework.Assert.assertEquals(Assert.java:81)
   at junit.framework.Assert.assertEquals (Assert.java:87)
   at
org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c
ompareOutput(CommandTestCase.java:37)
   at
org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
.testLauncherUsage(SmokeTestLauncher.java:40)

Not sure if this is significant.

I'm now not sure how to try the calculator sample. I cd to sca/core-samples
(from the mail list this seems to be the correct version of the calculator
sample [2]) and run
"mvn install" but it doesn't seem to do anything.  Playing with building
various modules this is what seemed to work for me.

cd sca/runtime/itest; mvn install
cd sca/core-samples/common; mvn install
cd sca/core-samples/standalone/calculator; mvn install

Seems to run the test successfully but I can't tell now how to run this test
from the command line. The instructions in the readme suggest using "mvn
dependency:unpack" but I don't see any dependency plugin configuration in
the pom files here abouts so I guess this isn't going to work.

Can someone confirm whether standalone operation works in the calculator
sample in head and if so how to do it?

By way of light relief I thought I would try the same on the integration
branch.

* I was able to build and run the sample in the integration branch in mvn
but the standalone runtime doesn't seem to be supported here either. Is that
correct?
* Anyhow I took the next step and pulled the project into eclipse and it was
happy to let me debug the test as a JUnit test so I'm set for a bit of
experimentation.

I'm assuming that this mode of debugging will also work for Head but I
haven't tried it yet. I'd be interested to know if there is a general mode
of operation for debugging samples that people have adopted, e.g. debug from

 standalone runtime
 JUnit tests
 With some clever mvn settings(?) and attach remotely
 System.out :-)
 Something else...

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg14659.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg14530.html

Re: Native M3 release status

[Simon Laws]

On 2/28/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


I think we have resolved the issues with the Python samples when mixed
with
Ruby and/or httpd so we have:

Windows/Linux : core, cpp, ruby, python, ws, rest, sca
Mac: core, cpp, ruby, python, rest

Tomorrow I will try and integrate the PHP extension into the distribution
and hopefully get a release candidate out this week.

Cheers,


Hi Pete,

What was the fix? I'm wondering whether it could also be applied to fix our
lingering PHP extension linux build problem.

Simon

Re: Native M3 release status

[Simon Laws]

On 2/28/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 28/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 2/28/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > I think we have resolved the issues with the Python samples when mixed
> > with
> > Ruby and/or httpd so we have:
> >
> > Windows/Linux : core, cpp, ruby, python, ws, rest, sca
> > Mac: core, cpp, ruby, python, rest
> >
> > Tomorrow I will try and integrate the PHP extension into the
> distribution
> > and hopefully get a release candidate out this week.
> >
> > Cheers,
> >
> Hi Pete,
>
> What was the fix? I'm wondering whether it could also be applied to fix
> our
> lingering PHP extension linux build problem.
>
> Simon
>

It was a mismatch in the expat library that Python includes and the one
that
Ruby or httpd use. To fix this we use LD_PRELOAD=
before invoking Ruby (or starting httpd). This pulls in the expat that
Python insists on and the other components are happy using that version.

Cheers,

--
Pete


Ok, thanks Pete. So maybe not a solution for PHP but interesting none the
less.

Regards

Simon

Re: Running Java SCA Calculators sample?

[Simon Laws]

On 2/28/07, Jim Marino <[EMAIL PROTECTED]> wrote:



On Feb 28, 2007, at 9:37 AM, Simon Laws wrote:

> After talking a few  weeks ago about how best to build Java I got
> distracted
> doing PHP SCA things. Anyhow I have actually got back to trying it
> out.
>
> * I checked out head and the integration branch with the aim of
> running up
> the calculator sample.
> * I built Head using Raymond's splendid script [1] (maybe that
> should be in
> svn somewhere ;-) and most of it seemed OK. I get the following error.
>
> ---
> T E S T S
> ---
> Running
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyC
> on
> tent
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.14 sec
> Running
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 11.657 sec
> <<< F
> AILURE!
> testLauncherUsage(
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL
> auncher)  Time elapsed: 0.812 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<..> but was:<...
> ...>
>at junit.framework.Assert.assertEquals(Assert.java:81)
>at junit.framework.Assert.assertEquals (Assert.java:87)
>at
> org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c
> ompareOutput(CommandTestCase.java:37)
>at
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
> .testLauncherUsage(SmokeTestLauncher.java:40)
>
> Not sure if this is significant.
This would be significant but I think this may be caused by the
script you are running as the trunk build system is significantly
different than the one in branch. The trunk has been stable for me.

To run the samples, as we have not cut a release yet, you will need
to manually create a distribution. This should be pretty
straightforward:

1. In /kernel do 'mvn'
2. In /runtime/standalone run 'mvn'
3. In /core-samples/common run 'mvn install'
4. In /core-samples/ run 'mvn install'
5. Run the calculator:

java -jar ../../../runtime/standalone/smoketest/target/assembly/bin/
launcher.jar target/calc.jar add 2 5

You should see 'result = 7.0'

The launcher syntax is java -jar  

The two parameters '2' and '5' are for the application.

You can also do the same with the loan application statefull
conversational sample except you will not need to build the common
module (Step 3) and instead build /core-samples/loanapplication. Then
run:

java -jar ../../../runtime/standalone/smoketest/target/assembly/bin/
launcher.jar target/loan-application.jar

If you want to remove debug, do (adjusting for your IDE, this works
with IDEA):

java -Xdebug -Xnoagent -Djava.compiler=NONE -
Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -
jar ../../../runtime/standalone/smoketest/target/assembly/bin/
launcher.jar target/loan-application.jar target/loan-application.jar

And start up remote debugging in your IDE. You can also run the
launcher directly in the IDE. If you need to run integration tests,
we have a JUnit component type that is part of the iTest pluging.
This makes righting tests easy as you just create a TestCase and
configure it as an SCA component.

Sorry for having to manually create the distro but once we have the
release set, things should be as simple as just using java -jar  .

Let me know how you get along.

Jim





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

Great, thanks Jim. Not a problem doing the manual steps. Now I know how to

do it (with all your info) it hangs together. It's just that first time when
you've not seen it before it's a little confusing :-)

Regards

Simon

Re: Running Java SCA Calculators sample?

[Simon Laws]

On 2/28/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Feb 28, 2007, at 9:37 AM, Simon Laws wrote:
> Running
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 11.657 sec
> <<< F
> AILURE!
> testLauncherUsage(
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL
> auncher)  Time elapsed: 0.812 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<..> but was:<...
> ...>
>at junit.framework.Assert.assertEquals(Assert.java:81)
>at junit.framework.Assert.assertEquals (Assert.java:87)
>at
> org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c
> ompareOutput(CommandTestCase.java:37)
>at
> org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
> .testLauncherUsage(SmokeTestLauncher.java:40)
>
> Not sure if this is significant.

Generally, yes - in this case it means that the rest of the build for
the "runtime" module failed (which would include the webapp and itest
plugins).

This might be a CRLF issue with the master copy for the test output
as it works for me on OSX (\n type line separators). If so, then
except for aborting the build, it's not significant. Is anyone else
on Windows seeing this as an issue?

> I'm now not sure how to try the calculator sample. I cd to sca/core-
> samples
> (from the mail list this seems to be the correct version of the
> calculator
> sample [2]) and run
> "mvn install" but it doesn't seem to do anything.  Playing with
> building
> various modules this is what seemed to work for me.
>
> cd sca/runtime/itest; mvn install
> cd sca/core-samples/common; mvn install
> cd sca/core-samples/standalone/calculator; mvn install

We need some updated doco there I think.

I don't think there's any point in building all the samples in one go
- that's not very useful for users :-) What we might do perhaps at
the root though is build the common modules, which is what you did
manually.

For the standlone sample, you don't need to install it, just "mvn
package" is OK - we should make that the default goal for that
module. This generates a simple jar that can be run with the launcher:

$ java -jar ${tuscany.installDir}/bin/launcher.jar target/calc.jar
add 2 5
result = 7.0

where tuscany.installDir points to the location where you installed
our distribution (remember, users generally won't be building from
source, they will be using a release). Given you did build the distro
from source, you can find versions in your maven repo
  ~/.m2/repository/org/apache/tuscany/sca/runtime/standalone/assembly/
1.0-alpha-incubating-SNAPSHOT/
  or in the build tree
  sca/runtime/standalone/assembly/target

Hope that helps
--
Jeremy



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



Hi Jeremy. As you say the LauncherUsage.txt file has \n alone. I'll give it
a spin tommorrow and see what it is checking against. Thanks for "how to
run" info, now I've done it that first time it's all a bit clearer.

Simon

Re: LauncherUsage.txt, was: Running Java SCA Calculators sample?

[Simon Laws]

On 2/28/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Feb 28, 2007, at 1:02 PM, Simon Laws wrote:

> On 2/28/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>>
>> This might be a CRLF issue with the master copy for the test output
>> as it works for me on OSX (\n type line separators). If so, then
>> except for aborting the build, it's not significant. Is anyone else
>> on Windows seeing this as an issue?
>>
> Hi Jeremy. As you say the LauncherUsage.txt file has \n alone. I'll
> give it
> a spin tommorrow and see what it is checking against. Thanks for
> "how to
> run" info, now I've done it that first time it's all a bit clearer.

If you are on Windows and that just has \n then we'll have problems.
The test code expects the file to have the same line endings as the
output from the command i.e. \n on Linux/OSX and \r\n on Windows. To
do that it sets svn:eol-style to "native" which should me \r\n on
checkout.

Are you using Cygwin? That might have an impact.
--
Jeremy


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

Apologies Jeremy. This is entirely my fault. I'm running with the svn

client native settings here (
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/etc/svn-config) rather
than the java setting here (
http://svn.apache.org/repos/asf/incubator/tuscany/java/). I'll look to see
if we can consolidate, or at least make them the same, as this gets
confusing for anyone who has the desire to look at both projects.

Regards

Simon

Re: Federating between Java and C++, was: Running Java SCA Calculators sample?

[Simon Laws]

On 2/28/07, Jim Marino <[EMAIL PROTECTED]> wrote:


> do it (with all your info) it hangs together. It's just that first
> time when
> you've not seen it before it's a little confusing :-)
>
> Regards
>
> Simon

I'm wondering if it would be a good time to start discussing
federation between the Java and C++ runtimes. On the Java side we
have been using an implementation based on JXTA which also has a C++
implementation. Would people be interested in starting to see how
some of the pieces might fit together?

Jim


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

Hi Jim


Yes we should get back to that at some point. I'm taking some vacation at
the moment so won't be that active until next week.When we discussed this
last time I was going to concentrate on the C++ side. In hindsight though
it's probably better to get a grounding generally in Java SCA (and it's
interesting :-) hence I'm taking some time out to get up to speed.

Regards

Simon

Re: LauncherUsage.txt, was: Running Java SCA Calculators sample?

[Simon Laws]

On 3/1/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 1, 2007, at 1:00 AM, Simon Laws wrote:
>> Apologies Jeremy. This is entirely my fault. I'm running with the svn
> client native settings here (
> http://svn.apache.org/repos/asf/incubator/tuscany/cpp/etc/svn-
> config) rather
> than the java setting here (
> http://svn.apache.org/repos/asf/incubator/tuscany/java/). I'll look
> to see
> if we can consolidate, or at least make them the same, as this gets
> confusing for anyone who has the desire to look at both projects.

We should probably consolidate the two but I'm not sure that this is
the problem here. Once the property is set then it should be
respected regardless of the auto-props setting.

For this file, I have:
$ svn propget svn:eol-style src/test/resources/org/apache/tuscany/sca/
runtime/standalone/smoketest/LauncherUsage.txt
native

which AIUI would mean \n on OSX for me and \r\n on Windows for you.

Two things I can think might mess this up:
* Cygwin's mount options which can give everything Unix still line
endings
* Some 'smart' tooling which is somehow overriding the property

Can you try removing this file and checking out again using command-
line svn client from a genuine Command box and see what you get?
--
Jeremy

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

Jeremy


You are correct. It was just cygwin messing things up. Checked out under
Tortoise and all is well.

Thanks for your help.

Simon

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 22/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 2/22/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >
> > > Thanks. The apache mailing list seems sensitive to attachments. The
> > > Jira is the right place for it anyway.
> > >
> > > Cheers,
> > >
> > > On 21/02/07, Caroline Maynard <[EMAIL PROTECTED] > wrote:
> > > > I had attached it to my post, and it appeared to get through OK
for
> > > me,  but
> > > > perhaps not for others.  So I've now raised
> > > > https://issues.apache.org/jira/browse/TUSCANY-1133 and attached it
> to
> > > that.
> > > >
> > > > On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > > I can't find the JIRA that you attached the patch to. Can you
> point
> > > me in
> > > > > the right direction?
> > > > >
> > > >
> > > > --
> > > > Caroline
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > Thanks Caroline
> >
> OK, the patch improves the situation on windows somewhat so it's checked
> in
> now. I need to get it out and re-run on linux.
>
> Regards
>
> Simon
>

I have been working on the PHP Extension on Linux and have got it into a
"working" state but not without some changes in the code from pecl. Here
is
what I have done (though this is not yet checked in to svn):

a) I have created a separate build for the extesnion with it's own
build.sh.
It can be packaged and released separately from the rest of Tuscany. This
is
an experiment to see if this model works and whether we should do this for
other Tuscany Native extensions. I have included PHPCalculator sample with
the extension rather than in the sca/samples.

b) I have simplified the PHPCalcualtor sample. Currently there is no way
for
a PHP client to locate and call a Tuscany service as this code in the
PHP_SCA code is not yet written. I have replaced the C++ client to a
simple
Python client. This cleans up the build process significantly!



My concern is that this may make life easier for us but still hides a
problem that I have experienced on linux which means that using a C++ client
doesn't work with the C++ SCA automake system. I just haven't had the time
to go back and work out why. I'm not suggesting you have the time either
btw.

Next I have

changed the sample so that it demonstrates:





1. Add and Subtract are simple services in Calculator.php that can be
  called from the client. They do not reference any other service.
  2. Multiply service can be called form the client and then uses
  a PHP_SCA injected reference to the multiply service (
  Multiply.php). The resolution and calling of this referenced
  service does not involve the Tuscany php extension (I think)


 3. Divide service can be called from the client and then uses an

  injected binding.tuscany that should go via a tuscany
  proxy/wrapper to invoke the method in Divide.php



Not sure without seeing what code you now have. The way it was set up in SVN
is demonstrated in the diagram.
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PHPCalculator/phpcalculator.png.
Only the CPP local client at the bottom was tested due, as you note, to PHP
clients not being implemented yet. So

1. Add.php
  A basic PHP script that implements the component's "add" function and
uses PHP SCA to find a PHP logging component. PHP SCA is running embedded
here so it should go out via the native runtime, and use the model built
from SCDL, to find the log comoponent.

2 Subtract.php
 A basic PHP script with a PHP funtion implementing the component's "sub"
function. Again finds a PHP logging components via the native runtime.

3 Multiple.php
  A PHP class which provides a class function to implement the component's
"mul" function. Again finds a PHP logging component  via the native runtime

4 Divide.php
  A PHP SCA service (uses @services annotation) and provides a class
function to implement the component's "div" function. Uses the native
runtime to find a C++ Divide component and passes the message on.

Because we don't have a PHP Client and because the C++ calculator component
does add/subtract/multiply operations inte

Re: [C++] SCA PHP Extension patches

[Simon Laws]

On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > On 22/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On 2/22/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Thanks. The apache mailing list seems sensitive to attachments.
> The
> > > > > Jira is the right place for it anyway.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > On 21/02/07, Caroline Maynard <[EMAIL PROTECTED] >
wrote:
> > > > > > I had attached it to my post, and it appeared to get through
OK
> > for
> > > > > me,  but
> > > > > > perhaps not for others.  So I've now raised
> > > > > > https://issues.apache.org/jira/browse/TUSCANY-1133 and
attached
> it
> > > to
> > > > > that.
> > > > > >
> > > > > > On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > I can't find the JIRA that you attached the patch to. Can
you
> > > point
> > > > > me in
> > > > > > > the right direction?
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Caroline
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Pete
> > > > >
> > > > >
> > -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > > Thanks Caroline
> > > >
> > > OK, the patch improves the situation on windows somewhat so it's
> checked
> > > in
> > > now. I need to get it out and re-run on linux.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> > I have been working on the PHP Extension on Linux and have got it into
a
> > "working" state but not without some changes in the code from pecl.
Here
> > is
> > what I have done (though this is not yet checked in to svn):
> >
> > a) I have created a separate build for the extesnion with it's own
> > build.sh.
> > It can be packaged and released separately from the rest of Tuscany.
> This
> > is
> > an experiment to see if this model works and whether we should do this
> for
> > other Tuscany Native extensions. I have included PHPCalculator sample
> with
> > the extension rather than in the sca/samples.
> >
> > b) I have simplified the PHPCalcualtor sample. Currently there is no
way
> > for
> > a PHP client to locate and call a Tuscany service as this code in the
> > PHP_SCA code is not yet written. I have replaced the C++ client to a
> > simple
> > Python client. This cleans up the build process significantly!
>
>
> My concern is that this may make life easier for us but still hides a
> problem that I have experienced on linux which means that using a C++
> client
> doesn't work with the C++ SCA automake system. I just haven't had the
time
> to go back and work out why. I'm not suggesting you have the time either
> btw.


I will go back and make this work someday! There should be nothing that a
C++ client will pull in to cause the problem you see. For this simple
sample
though I don't want to have to do all the scagen, compile stuff when I can
use a simple Python or Ruby client.


Next I have
> > changed the sample so that it demonstrates:
>
>
>
> > 1. Add and Subtract are simple services in Calculator.php that can
> be
> >   called from the client. They do not reference any other service.
> >   2. Multiply service can be called form the client and then uses
> >   a PHP_SCA injected reference to the multiply service (
> >   Multiply.php). The resolution and calling of this referenced
> >   service does not involve the Tuscany php extension (I think)
>
>  3. Divide service can be called from the client and then uses an
> >   injected binding.tuscany that should go via a tuscany
> >   proxy/wrapper to invoke the method in Divide.php
>

Databindings test status

[Simon Laws]

Hi Dan, I've just spent a couple of days stepping through the SCA code and
trying various tests to build up my knowledge a little. I note the
databinding tests are being updated and you are asking for some help (
https://issues.apache.org/jira/browse/TUSCANY-1149). I just updated from SVN
(for the integration branch) and ran up your tests and get the same result,
i.e. the JAXB/WS combination passes while the other three fails. By way of
education for me I'm  going to have a crack at debugging and see how I get
one. Have you already solved this problem?  Anything I should particularly
look out for in terms of configuring and debugging the tests?

Simon

Re: Databindings test status

[Simon Laws]

On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:


If you try with the very latest SVN code both the JAXB and SDO WS tests
should work now as Raymond made so fixes over night (works for me now).

I don't think the tests using the default binding will work right now as
there's no default binding implemented yet.

   ...ant

On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> Hi Dan, I've just spent a couple of days stepping through the SCA code
and
> trying various tests to build up my knowledge a little. I note the
> databinding tests are being updated and you are asking for some help (
> https://issues.apache.org/jira/browse/TUSCANY-1149). I just updated from
> SVN
> (for the integration branch) and ran up your tests and get the same
> result,
> i.e. the JAXB/WS combination passes while the other three fails. By way
of
> education for me I'm  going to have a crack at debugging and see how I
get
> one. Have you already solved this problem?  Anything I should
particularly
> look out for in terms of configuring and debugging the tests?
>
> Simon
>


Hi Ant

Yes, thanks, I just discovered that. I went back and did a mvn clean and a
rebuild and now I see both the sdo and jaxb ws tests working now.

Simon

Re: Databindings test status

[Simon Laws]

On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Seems like Raymond generates the SDO representation of the wsdl as well as
the data in the the XSDs. This seems to be due to the use of wrapped style
of ws binding (or is it always necessary ?). Interesting thought that this
is required, personally I'd not have guessed it would be needed as I'd
assumed the wsdl is the domain of (transport) bindings rather than
databindings.

Would like to make a couple of minor tweaks to what Raymond did (generate
the SDO objects in a non-default package) so we can do sdo<->jaxb between
client and service

Thanks for helping chaps,
Dan

On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > If you try with the very latest SVN code both the JAXB and SDO WS
tests
> > should work now as Raymond made so fixes over night (works for me
now).
> >
> > I don't think the tests using the default binding will work right now
as
> > there's no default binding implemented yet.
> >
> >...ant
> >
> > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Dan, I've just spent a couple of days stepping through the SCA
code
> > and
> > > trying various tests to build up my knowledge a little. I note the
> > > databinding tests are being updated and you are asking for some help
(
> > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just updated
> from
> > > SVN
> > > (for the integration branch) and ran up your tests and get the same
> > > result,
> > > i.e. the JAXB/WS combination passes while the other three fails. By
> way
> > of
> > > education for me I'm  going to have a crack at debugging and see how
I
> > get
> > > one. Have you already solved this problem?  Anything I should
> > particularly
> > > look out for in terms of configuring and debugging the tests?
> > >
> > > Simon
> > >
> >
> Hi Ant
>
> Yes, thanks, I just discovered that. I went back and did a mvn clean and
a
> rebuild and now I see both the sdo and jaxb ws tests working now.
>
> Simon
>


Dan

By way of education am just digging into what gets generated and used in
your sample so I will be back here with questions shortly:-)


From your comments you have tests in mind. Clearly there are various

combinations of message, databinding and binding that we could test. We did
some work a while back on interop schema that we could use and there is all
the work in CTS. Can you give me a quick run down on what you plan. I can
help write tests.

Regards

Simon

Re: Databindings test status

[Simon Laws]

On 3/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi Simon,

Essentually, as I see it, there are two main activities:

   - Increase the types of data. The sample is just a trivial complex
   type, we should also test more complex data strucutres using either (or
   both) the SDO schemas (in the CTS & SDO Impl) and the interop tests
(which I
   think you were one of the main authors of).
   - Add tests for interop between databindings

In doing so I think we now need to test different styles of ws bindings.
Since we need to generate the wrappers for doc/lit wrapped style ws
binding,
it means that we should also test rpc and straight doc/lit style as they
could effect the way databinding transformations behave.

I should be adding a patch for the first interop today (or tomorrow), so
if
you wanted add different ws binding styles to the current example that
would
be a good place to start.

Thanks for you offer of help,
Dan

On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> >
> > Seems like Raymond generates the SDO representation of the wsdl as
well
> as
> > the data in the the XSDs. This seems to be due to the use of wrapped
> style
> > of ws binding (or is it always necessary ?). Interesting thought that
> this
> > is required, personally I'd not have guessed it would be needed as I'd
> > assumed the wsdl is the domain of (transport) bindings rather than
> > databindings.
> >
> > Would like to make a couple of minor tweaks to what Raymond did
> (generate
> > the SDO objects in a non-default package) so we can do sdo<->jaxb
> between
> > client and service
> >
> > Thanks for helping chaps,
> > Dan
> >
> > On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > >
> > > > If you try with the very latest SVN code both the JAXB and SDO WS
> > tests
> > > > should work now as Raymond made so fixes over night (works for me
> > now).
> > > >
> > > > I don't think the tests using the default binding will work right
> now
> > as
> > > > there's no default binding implemented yet.
> > > >
> > > >...ant
> > > >
> > > > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Dan, I've just spent a couple of days stepping through the
SCA
> > code
> > > > and
> > > > > trying various tests to build up my knowledge a little. I note
the
> > > > > databinding tests are being updated and you are asking for some
> help
> > (
> > > > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just
> updated
> > > from
> > > > > SVN
> > > > > (for the integration branch) and ran up your tests and get the
> same
> > > > > result,
> > > > > i.e. the JAXB/WS combination passes while the other three fails.
> By
> > > way
> > > > of
> > > > > education for me I'm  going to have a crack at debugging and see
> how
> > I
> > > > get
> > > > > one. Have you already solved this problem?  Anything I should
> > > > particularly
> > > > > look out for in terms of configuring and debugging the tests?
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > Hi Ant
> > >
> > > Yes, thanks, I just discovered that. I went back and did a mvn clean
> and
> > a
> > > rebuild and now I see both the sdo and jaxb ws tests working now.
> > >
> > > Simon
> > >
> >
> Dan
>
> By way of education am just digging into what gets generated and used in
> your sample so I will be back here with questions shortly:-)
>
> From your comments you have tests in mind. Clearly there are various
> combinations of message, databinding and binding that we could test. We
> did
> some work a while back on interop schema that we could use and there is
> all
> the work in CTS. Can you give me a quick run down on what you plan. I
can
> help write tests.
>
> Regards
>
> Simon
>


So let's enumerate what you have in mind

Databindings
==
 SDO
 Static types - currently part of the test
 Dynamic types - are these supported?
 JAXB
 etc.

You have separated your tests according to databinding so there are separate
JAXB and SDO tests. I assume that for cross databinding interop the
intention is to instigate a new interop tests projec

Re: Legacy C App embedded in Tuscany C++

[Simon Laws]

On 3/8/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:


Kelvin,

Thanks a lot for your feedback!

As you said, these are still open questions to me. However, I am now
trying to answer the "How can we make an SCA C++ runtime interact with a
Java one?" question.  Therefore, I am deep diving in Tuscany's
architecture and reading through developer list's emails to get to
understand if such interaction can be currently achieved.

Any information/suggestions will be greatly appreciated.

BTW, you suggested me to pull the questions out into a post on this
list. What do you mean by that? You are talking about sending an email
to the tuscany-dev list asking for those questions?

Thanks and best regards,
Mario


-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 7:48 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Legacy C App embedded in Tuscany C++


Mario,
  thanks for that.  It's really great to see what people are doing with
Tuscany.  Are you still looking for answers to the questions you posed
at
the end of the document.  I'm not in a position to answer them,  but it
might be worth pulling them out into a post on this list.

Regards, Kelvin.


On 05/03/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I wrote a document that explains the way I exposed a legacy C
> application (called Jabon)  as  a Tuscany Service Component. I think
it
> could be useful for the community.
>
> The link to the post is:
>
http://cwiki.apache.org/confluence/display/TUSCANY/Building+an+Applicati
> on
>
> Best regards,
> Mario Antollini
>
> -
> 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]

Hi Mario


It depends what you mean by make an "SCA C++ runtime interact with a
Java one". Today components in the C++ runtime and Java runtimes can
interact through remote interfaces using protocols like SOPA/HTTP.  This
means that the runtimes are running in separate processes, possibly on
separate machines. There is no support for running Java components locally
in the C++ runtime or for running C++ components in the Java runtime. What
sort of integration are you looking for?

Regards

Simon

Re: FW: Legacy C App embedded in Tuscany C++

[Simon Laws]

On 3/8/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:



Simons,

What I mean by "How can we make an SCA C++ runtime interact with a Java
one?" is that I would like a service running in the C++ runtime can
reference a service running in the Java runtime, but without relying on
Web Services to achieve that. Therefore, I think that it could only be
achieved if there is some sort of communication among different runtimes
(something like a network of Tuscany runtimes)

Does anyone know if this is already doable nowadays?.

I hope it is clear now

Best regards,
Mario


-Original Message-----
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 11:28 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Legacy C App embedded in Tuscany C++

On 3/8/07, Antollini, Mario <[EMAIL PROTECTED] > wrote:
>
> Kelvin,
>
> Thanks a lot for your feedback!
>
> As you said, these are still open questions to me. However, I am now
> trying to answer the "How can we make an SCA C++ runtime interact with
a
> Java one?" question.  Therefore, I am deep diving in Tuscany's
> architecture and reading through developer list's emails to get to
> understand if such interaction can be currently achieved.
>
> Any information/suggestions will be greatly appreciated.
>
> BTW, you suggested me to pull the questions out into a post on this
> list. What do you mean by that? You are talking about sending an email
> to the tuscany-dev list asking for those questions?
>
> Thanks and best regards,
> Mario
>
>
> -Original Message-
> From: kelvin goodson [mailto: [EMAIL PROTECTED]
> Sent: Wednesday, March 07, 2007 7:48 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Legacy C App embedded in Tuscany C++
>
>
> Mario,
>   thanks for that.  It's really great to see what people are doing
with
> Tuscany.  Are you still looking for answers to the questions you posed
> at
> the end of the document.  I'm not in a position to answer them,  but
it
> might be worth pulling them out into a post on this list.
>
> Regards, Kelvin.
>
>
> On 05/03/07, Antollini, Mario <[EMAIL PROTECTED] > wrote:
> >
> > Hello,
> >
> > I wrote a document that explains the way I exposed a legacy C
> > application (called Jabon)  as  a Tuscany Service Component. I think
> it
> > could be useful for the community.
> >
> > The link to the post is:
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Building+an+Applicati
> > on
> >
> > Best regards,
> > Mario Antollini
> >
> >
-
> > 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]
>
> Hi Mario

It depends what you mean by make an "SCA C++ runtime interact with a
Java one". Today components in the C++ runtime and Java runtimes can
interact through remote interfaces using protocols like SOPA/HTTP.  This
means that the runtimes are running in separate processes, possibly on
separate machines. There is no support for running Java components
locally
in the C++ runtime or for running C++ components in the Java runtime.
What
sort of integration are you looking for?

Regards

Simon

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

Hi Mario, thanks for the clarification.


You can't do this easily at the moment unless you use one of the supported
remote protocols like WebServices. There has been discussion about
implementing a default binding between containers, e.g. Java and C++. The
objective would be to make the interaction of components running in Java and
C++ runtimes more efficient without having to re-implement all component
types in all runtimes. As you say this means having a network of Tuscany
runtimes up and supporting a composed set of components in a distributed
manner. Do you have other reasons for not using a remote protocol like
SOAP/HTTP?

On a related but orthogonal note, on the Java SCA side of things there is
work well under way to support the idea of starting up a composition in a
federated runtime, I.e. have a single SCA composition that makes sense
across multiple runtimes. This is restricted to java at the moment. Again we
have talked about extending this to C++ but haven't done anything about it
yet. This is independent of how the components in the distributed runtimes
talk to each other though so we would still have to implement some kind of
more basic binding

Re: Databindings test status

[Simon Laws]

On 3/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

FYI, we already have two cross-databinding integration tests added by Rick
for the purpose of business exception handling. They use the SDO, JAXB and
AXIOM databindings.

iTest-exceptions-crossBinding (component (SDO) to component (JAXB))
iTest-exceptions-crossBinding-ws (component (SDO) to reference w/ ws
binding
(AXIOM)... soap/http ... service w/ ws binding (AXIOM) --> component
(JAXB)

Hopefully they give you some ideas.

Thanks,
Raymond

- Original Message -
From: "Dan Murphy" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, March 08, 2007 3:32 AM
Subject: Re: Databindings test status


> Hi Simon,
>
> Essentually, as I see it, there are two main activities:
>
>   - Increase the types of data. The sample is just a trivial complex
>   type, we should also test more complex data strucutres using either
(or
>   both) the SDO schemas (in the CTS & SDO Impl) and the interop tests
> (which I
>   think you were one of the main authors of).
>   - Add tests for interop between databindings
>
> In doing so I think we now need to test different styles of ws bindings.
> Since we need to generate the wrappers for doc/lit wrapped style ws
> binding,
> it means that we should also test rpc and straight doc/lit style as they
> could effect the way databinding transformations behave.
>
> I should be adding a patch for the first interop today (or tomorrow), so
> if
> you wanted add different ws binding styles to the current example that
> would
> be a good place to start.
>
> Thanks for you offer of help,
> Dan
>
> On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>> On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>> >
>> > Seems like Raymond generates the SDO representation of the wsdl as
well
>> as
>> > the data in the the XSDs. This seems to be due to the use of wrapped
>> style
>> > of ws binding (or is it always necessary ?). Interesting thought that
>> this
>> > is required, personally I'd not have guessed it would be needed as
I'd
>> > assumed the wsdl is the domain of (transport) bindings rather than
>> > databindings.
>> >
>> > Would like to make a couple of minor tweaks to what Raymond did
>> (generate
>> > the SDO objects in a non-default package) so we can do sdo<->jaxb
>> between
>> > client and service
>> >
>> > Thanks for helping chaps,
>> > Dan
>> >
>> > On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > If you try with the very latest SVN code both the JAXB and SDO WS
>> > tests
>> > > > should work now as Raymond made so fixes over night (works for me
>> > now).
>> > > >
>> > > > I don't think the tests using the default binding will work right
>> now
>> > as
>> > > > there's no default binding implemented yet.
>> > > >
>> > > >...ant
>> > > >
>> > > > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > Hi Dan, I've just spent a couple of days stepping through the
SCA
>> > code
>> > > > and
>> > > > > trying various tests to build up my knowledge a little. I note
>> > > > > the
>> > > > > databinding tests are being updated and you are asking for some
>> help
>> > (
>> > > > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just
>> updated
>> > > from
>> > > > > SVN
>> > > > > (for the integration branch) and ran up your tests and get the
>> same
>> > > > > result,
>> > > > > i.e. the JAXB/WS combination passes while the other three
fails.
>> By
>> > > way
>> > > > of
>> > > > > education for me I'm  going to have a crack at debugging and
see
>> how
>> > I
>> > > > get
>> > > > > one. Have you already solved this problem?  Anything I should
>> > > > particularly
>> > > > > look out for in terms of configuring and debugging the tests?
>> > > > >
>> > > > > Simon
>> > > > >
>> > > >
>> > > Hi Ant
>> > >
>> > > Yes, thanks, I just discovered that. I went back and did a mvn
clean
>> and
>> > a
>> > > rebuild and now I see both the sdo and jaxb ws tests working now.
>> > >
>> > > Simon
>> > >
>> >
>> Dan
>>
>> By way of education am just digging into what gets generated and used
in
>> your sample so I will be back here with questions shortly:-)
>>
>> From your comments you have tests in mind. Clearly there are various
>> combinations of message, databinding and binding that we could test. We
>> did
>> some work a while back on interop schema that we could use and there is
>> all
>> the work in CTS. Can you give me a quick run down on what you plan. I
can
>> help write tests.
>>
>> Regards
>>
>> Simon
>>
>


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

Raymond, Thanks for pointing that out. These are good examples. We want to

do the same but with more data types:-)

Simon

Re: Databindings test status

[Simon Laws]

On 3/9/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi Simon,

Some comments in line...

On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 3/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> >
> > Hi Simon,
> >
> > Essentually, as I see it, there are two main activities:
> >
> >- Increase the types of data. The sample is just a trivial complex
> >type, we should also test more complex data strucutres using either
> (or
> >both) the SDO schemas (in the CTS & SDO Impl) and the interop tests
> > (which I
> >think you were one of the main authors of).
> >- Add tests for interop between databindings
> >
> > In doing so I think we now need to test different styles of ws
bindings.
> > Since we need to generate the wrappers for doc/lit wrapped style ws
> > binding,
> > it means that we should also test rpc and straight doc/lit style as
they
> > could effect the way databinding transformations behave.
> >
> > I should be adding a patch for the first interop today (or tomorrow),
so
> > if
> > you wanted add different ws binding styles to the current example that
> > would
> > be a good place to start.
> >
> > Thanks for you offer of help,
> > Dan
> >
> > On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Seems like Raymond generates the SDO representation of the wsdl as
> > well
> > > as
> > > > the data in the the XSDs. This seems to be due to the use of
wrapped
> > > style
> > > > of ws binding (or is it always necessary ?). Interesting thought
> that
> > > this
> > > > is required, personally I'd not have guessed it would be needed as
> I'd
> > > > assumed the wsdl is the domain of (transport) bindings rather than
> > > > databindings.
> > > >
> > > > Would like to make a couple of minor tweaks to what Raymond did
> > > (generate
> > > > the SDO objects in a non-default package) so we can do sdo<->jaxb
> > > between
> > > > client and service
> > > >
> > > > Thanks for helping chaps,
> > > > Dan
> > > >
> > > > On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > If you try with the very latest SVN code both the JAXB and SDO
> WS
> > > > tests
> > > > > > should work now as Raymond made so fixes over night (works for
> me
> > > > now).
> > > > > >
> > > > > > I don't think the tests using the default binding will work
> right
> > > now
> > > > as
> > > > > > there's no default binding implemented yet.
> > > > > >
> > > > > >...ant
> > > > > >
> > > > > > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Hi Dan, I've just spent a couple of days stepping through
the
> > SCA
> > > > code
> > > > > > and
> > > > > > > trying various tests to build up my knowledge a little. I
note
> > the
> > > > > > > databinding tests are being updated and you are asking for
> some
> > > help
> > > > (
> > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just
> > > updated
> > > > > from
> > > > > > > SVN
> > > > > > > (for the integration branch) and ran up your tests and get
the
> > > same
> > > > > > > result,
> > > > > > > i.e. the JAXB/WS combination passes while the other three
> fails.
> > > By
> > > > > way
> > > > > > of
> > > > > > > education for me I'm  going to have a crack at debugging and
> see
> > > how
> > > > I
> > > > > > get
> > > > > > > one. Have you already solved this problem?  Anything I
should
> > > > > > particularly
> > > > > > > look out for in terms of configuring and debugging the
tests?
> > > > > > >
> > > > > > > Simon
> > > > > > >
> > > > > >
> > 

Re: FW: Legacy C App embedded in Tuscany C++

[Simon Laws]

On 3/10/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:


Simon,

Thanks a lot for the detailed explanation. Furthermore, thanks a lot for
inviting me to join! I really appreciate this chance and I will
definitively take it in the near future. However, I am interested in
different aspects of Tuscany and not exactly on how different Tuscany
Runtimes can interact. I need to keep deep diving into Tuscany first and
understand where I can contribute the better, and I come back to you
afterwards.

Thanks for your time and best regards,
Mario


-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 3:07 PM
To: tuscany-dev@ws.apache.org
Subject: Re: FW: Legacy C App embedded in Tuscany C++

On 3/8/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:
>
>
> Simons,
>
> What I mean by "How can we make an SCA C++ runtime interact with a
Java
> one?" is that I would like a service running in the C++ runtime can
> reference a service running in the Java runtime, but without relying
on
> Web Services to achieve that. Therefore, I think that it could only be
> achieved if there is some sort of communication among different
runtimes
> (something like a network of Tuscany runtimes)
>
> Does anyone know if this is already doable nowadays?.
>
> I hope it is clear now
>
> Best regards,
> Mario
>
>
> -Original Message-
> From: Simon Laws [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2007 11:28 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Legacy C App embedded in Tuscany C++
>
> On 3/8/07, Antollini, Mario <[EMAIL PROTECTED] > wrote:
> >
> > Kelvin,
> >
> > Thanks a lot for your feedback!
> >
> > As you said, these are still open questions to me. However, I am now
> > trying to answer the "How can we make an SCA C++ runtime interact
with
> a
> > Java one?" question.  Therefore, I am deep diving in Tuscany's
> > architecture and reading through developer list's emails to get to
> > understand if such interaction can be currently achieved.
> >
> > Any information/suggestions will be greatly appreciated.
> >
> > BTW, you suggested me to pull the questions out into a post on this
> > list. What do you mean by that? You are talking about sending an
email
> > to the tuscany-dev list asking for those questions?
> >
> > Thanks and best regards,
> > Mario
> >
> >
> > -Original Message-
> > From: kelvin goodson [mailto: [EMAIL PROTECTED]
> > Sent: Wednesday, March 07, 2007 7:48 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Legacy C App embedded in Tuscany C++
> >
> >
> > Mario,
> >   thanks for that.  It's really great to see what people are doing
> with
> > Tuscany.  Are you still looking for answers to the questions you
posed
> > at
> > the end of the document.  I'm not in a position to answer them,  but
> it
> > might be worth pulling them out into a post on this list.
> >
> > Regards, Kelvin.
> >
> >
> > On 05/03/07, Antollini, Mario <[EMAIL PROTECTED] > wrote:
> > >
> > > Hello,
> > >
> > > I wrote a document that explains the way I exposed a legacy C
> > > application (called Jabon)  as  a Tuscany Service Component. I
think
> > it
> > > could be useful for the community.
> > >
> > > The link to the post is:
> > >
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Building+an+Applicati
> > > on
> > >
> > > Best regards,
> > > Mario Antollini
> > >
> > >
> -
> > > 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]
> >
> > Hi Mario
>
> It depends what you mean by make an "SCA C++ runtime interact with a
> Java one". Today components in the C++ runtime and Java runtimes can
> interact through remote interfaces using protocols like SOPA/HTTP.
This
> means that the runtimes are running in separate processes, possibly on
> separate machines. There is no support for running Java components
> locally
> in the C++ runtime or for running C++ components in the Java runtime.
> What
> sort of integration are you looking for?
>
> Regards
>
> Simon
>
> ---

Re: [SCA] WSDL2Java seems not generating SDO code

[Simon Laws]

On 3/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:
>
> Yang ZHONG wrote:
>> WSDL has schemas and portTypes.
>> WSDL2Java uses SDO CodeGen to compute classes names for schemas and
>> generates classes for portTypes.
>> SDO code seem not actually generated.
>> Is that desired?
>>
>> If not, I can look into how to fix.
>>
>> If yes, are users supposed to use SDO CodeGen themselves?
>> If so, what if users specify options causing different code from what
>> WSDL2Java expects?
>> How do we enable users to reflect the customization to WSDL2Java?
>>
>
> Yang,
>
> If I remember correctly, the current WSDL2Java tool does not
> automatically run XSD2Java for all the inline XSDs or all the XSDs
> referenced from the WSDL. Application developers are responsible to
> run the WSDL2Java tool or XSD2Java tool on each individual WSDL or XSD
> file.
>
> On one hand, it would be nice to support a top-down generation from a
> WSDL including the closure of all the referenced XSDs. On the other
> hand if multiple WSDLs  reference common XSDs you probably don't want
> to regenerate code for these XSDs multiple times. Also if an
> application developer starts to work on an XSD he'll probably want to
> generate SDOs from it even before writing a WSDL, then later when he
> generates a Java interface from that WSDL, the interface will have to
> point to these SDOs... As you noted things will break if incompatible
> codegen options are used in XSD2Java and WSDL2Java.
>
> These issues are actually not specific to WSDL, you can run into
> similar issues with a graph of XSDs...
>
> We should start a discussion to find the best strategy for this codegen:
> a) Handle generation on an SCA contribution basis (basically you don't
> gen from individual files but you handle in a single pass ALL relevant
> files in the contribution, with consistent codegen options and
> avoiding duplicate gen).
> b) Or continue with the current approach where the app developer
> specifies which files to gen from (including support for "*.wsdl" or
> "*.xsd").
> c) Or add support for top-down generation of a closure from a WSDL or
> an XSD.
> d) Or any other scheme...
>
> My preference would be for keeping option (b) and build option (a) on
> top of it, but I think it'll help to look at how existing similar
> tools are handling this:
> How does the current XSD2Java tool handle this? What does it do when
> you give it an a.xsd containing an  of another b.xsd? Does it
> generate code only for a.xsd? or for both a.xsd and b.xsd?
> What about the JAXWS tools?
>
> Thoughts?
>

One more thought, for option (a) we should be able to reuse the SCA
Contribution service to find all the WSDLs and XSDs used in an SCA
contribution (as well as the namespaces imported from other SCA
contributions) to automate the calls to the WSDL2Java and XSD2Java
codegen and generate everything the SCA contribution needs.


--
Jean-Sebastien


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

Hi, a couple of questions/comments


I'm for option a) if we can make it work.

It would be good to have some event call out though so that just before
parsing an XSD you get the chance to do some configuration, e.g. in the
databinding test work the same schema is used for SDO and JAXB tests but
their generators will both generate to the same location (package) if we let
them.

What happens today in the case of reading a remote WSDL. Is it the
developer's responsibility to download WSDL and associated XSDs and to build
the contribution and hence gen code from them? From your comments this would
seem to be the case. This sounds like it's harder than it should be. Would
be good if the generator tools were able to provide to the developer the
interfaces described by the contribution/SCDL . Does this tie up with your
option c)?

Regards

Simon

[sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour

[Simon Laws]

Hi

I remember Dan discussing this on the list before but I can't put my finger
on the thread

If I run the databinding WS tests without including the factory for the WSDL
XML types in the composite...

   

Then the web service call fails with the following:

java.lang.ClassCastException: org.apache.tuscany.sdo.util.BasicSequenceincompat
ible with org.apache.tuscany.sca.itest.databinding.types.PersonType
   at $Proxy26.greetPersonType(Unknown Source)
   at
org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl.
greetPersonType(GreeterServiceClientImpl.java:47)
...

In the case where I am getting the error Tuscany can't convert the wrapped
return type from the call back to the type expected in the client. This is
clearly something to do with Tuscany not having the correct types registered
(adding the above import fixes it). But the thing that confuses me is that
it only fails on processing the return message in the client. It has quite
happily

 1/ Converted the request message into a wrapped message on the client
 2/ Converted the wrapped message back into the required message on the
server
 3/ Converted the response message into a wrapped response on the server

only to fail at the final hurdle when trying to unwrap the response on the
client. So it seems to be able to do quite a lot without the imported
information. Why is it required for the last step.

I'm happy to look into this if there is not an obvious answer. If nothing
else we need better error messages here.

Regards

Simon

Re: [sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour

[Simon Laws]

On 3/13/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

The ClassCastException will only happen if we try to get the child element
out of the repsonse wrapper (which is an instance of AnyTypeDataObjectImpl
because the model is not registered with SDO runtime) and cast it to a
generated SDO interface. If the ServiceFactory is not registered, the data
(from the inline schema of the WSDL) are then represented by
"org.apache.tuscany.sdo.impl.AnyTypeDataObjectImpl" which doesn't have
problems to convert to XML or vice versa. But now the child of
AnyTypeDataObjectImpl is BasicSequence instead of the real PersonType
since
the types are not known.

It's very common that we define XSD elements and types in the inline
schemas
of WSDL. These need to be registered so SDO runtime can work correctly. I
could try to make your special case working (your wsdl only has element
definitions) and I don't see much value.

Thanks,
Raymond

- Original Message -
From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" 
Sent: Tuesday, March 13, 2007 2:51 PM
Subject: [sca-java-integration-branch] Missing WSDL type imports causes
aymetrical behviour


> Hi
>
> I remember Dan discussing this on the list before but I can't put my
> finger
> on the thread
>
> If I run the databinding WS tests without including the factory for the
> WSDL
> XML types in the composite...
>
>
>
> Then the web service call fails with the following:
>
> java.lang.ClassCastException:
> org.apache.tuscany.sdo.util.BasicSequenceincompat
> ible with org.apache.tuscany.sca.itest.databinding.types.PersonType
>at $Proxy26.greetPersonType(Unknown Source)
>at
> org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl.
> greetPersonType(GreeterServiceClientImpl.java:47)
> ...
>
> In the case where I am getting the error Tuscany can't convert the
wrapped
> return type from the call back to the type expected in the client. This
is
> clearly something to do with Tuscany not having the correct types
> registered
> (adding the above import fixes it). But the thing that confuses me is
that
> it only fails on processing the return message in the client. It has
quite
> happily
>
>  1/ Converted the request message into a wrapped message on the client
>  2/ Converted the wrapped message back into the required message on the
> server
>  3/ Converted the response message into a wrapped response on the server
>
> only to fail at the final hurdle when trying to unwrap the response on
the
> client. So it seems to be able to do quite a lot without the imported
> information. Why is it required for the last step.
>
> I'm happy to look into this if there is not an obvious answer. If
nothing
> else we need better error messages here.
>
> Regards
>
> Simon
>


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

Hi Raymond, thanks for the info.


I still don't understand how this works with the requst message (as opposed
to the response message). At the target component the message handlers (?)
are converting from the XML to the wrapped object and from there to the
child object successfully. What extra information is available at the target
component for request processing that isn't available for response
processing at the client component?

Simon

Databinding itest reorg proposal

[Simon Laws]

I think we need to reorg the itest directory for databinding a bit and I
need some help to get the maven bit correct as I'm a bit of a maven novice.
I'm looking at the integration branch at the moment as that is where the
tests are checked in but I don't see why these tests can't go in the trunk
also.

Currently we have:

itest
  databinding
  sdo
  jaxb
  transformers (not sure what this is but assume it tests the data type
transformer logic)


From previous threads on this subject, [1] and [2], we talked about changing

to something like

itest
  databinding
  generator
  common
  sdo
  jaxb
  interop
  transformers (not sure what this is but assume it tests the data type
transformer logic)

Where common holds xsd, wsdl and files generated from them that are common
between the tests, interop holds tests that look at cross databinding
testing and generator holds a test generator. This chane means moving most
of the WSDL and XML files from where they are now out into common and also
replacing test source files with generated versions.

Interop would depend on sdo and jaxb which in turn depend on common. Can we
do this in maven simply by adding suitable dependency lines in the module
poms. In particular I will need to copy some schema and wsdl files from one
module to another. I notice that various build helper plugins are used in
various poms. Is there a recommended one for  copying resources in from
dependencies.

I have created a test generator to build the test source and configuration
automatically. As we have quite a number of datatypes to tests (potentially
in the 100s) I made some velocity templates to create the 8 files required
by the test. Initially I intended to throw the generator away having run it
but now feel that it might be useful as we extend the tests. So I want to
run it more than once but not every time the test is compiled/run. Is this a
candidate for a maven profile? Or is there another mechanism for runinning
the generator occasionally?

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13947.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15261.html

[sca-java-integration-branch] databinding sdo test case failure

[Simon Laws]

Just took an update from svn, and removed my mvn repository, and am getting
failures in the sdo databinding tests starting with...

Running org.apache.tuscany.databinding.sdo.SDOExceptionHandlerTestCase
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.09 sec <<<
FAI
LURE!
testGetFaultType(
org.apache.tuscany.databinding.sdo.SDOExceptionHandlerTestCase)
 Time elapsed: 0.03 sec  <<< ERROR!
java.lang.ExceptionInInitializerError
   at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
   at
org.apache.tuscany.databinding.sdo.SDOExceptionHandlerTestCase.setUp(
SDOExceptionHandlerTestCase.java:47)
   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)

Is this just me?

Simon

Re: [sca-java-integration-branch] databinding sdo test case failure

[Simon Laws]

On 3/14/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Just took an update from svn, and removed my mvn repository, and am
getting failures in the sdo databinding tests starting with...

Running org.apache.tuscany.databinding.sdo.SDOExceptionHandlerTestCase
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.09 sec
<<< FAI
LURE!
testGetFaultType(
org.apache.tuscany.databinding.sdo.SDOExceptionHandlerTestCase)
  Time elapsed: 0.03 sec  <<< ERROR!
java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
at
org.apache.tuscany.databinding.sdo.SDOExceptionHandlerTestCase.setUp(
SDOExceptionHandlerTestCase.java:47)
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)

Is this just me?

Simon


Apparently it was just me. Went in and cleaned/built the module in question
independently as opposed to from a higher level and the problem went away? I
have now started  getting this

at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)

problem in other modules so something in my build is out of line. Time for
another complete refresh I think

Simon

Simon

Checkstyle in testing/sca

[Simon Laws]

I note that there are some checkstyle/pmd plugin configurations in the
testing/sca pom. Can anyone tell me if this is actually running. I've not
seen any indication in the mvn builds that I'm doing that it is. Maybe it's
just that the code is perfect or that I'm not configuring mvn properly!

Outside of the test hierarchy there is a profile ( sourcecheck I think) for
this. Why is this different in the testing modules?

Thanks

Simon

Re: Checkstyle in testing/sca

[Simon Laws]

On 3/14/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I'll probably not answer you question about differences, but what I
usually
just run mvn -Psourcecheck. But i have found very useful to use checkstyle
and pmd plugins inside IDE (my case eclipse).

On 3/14/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> I note that there are some checkstyle/pmd plugin configurations in the
> testing/sca pom. Can anyone tell me if this is actually running. I've
not
> seen any indication in the mvn builds that I'm doing that it is. Maybe
> it's
> just that the code is perfect or that I'm not configuring mvn properly!
>
> Outside of the test hierarchy there is a profile ( sourcecheck I think)
> for
> this. Why is this different in the testing modules?
>
> Thanks
>
> Simon
>



--
Luciano Resende
http://people.apache.org/~lresende


Hi Luciano

Thanks for that. Doing mvn -Psourcecheck does at least give me some output!
It also gives an error...

Embedded error: Could not find resource
'C:\simon\Projects\Tuscany\java\java-int
egration\testing\sca\itest\databindings\sdo/.ruleset'.

Is this important?

Simon

Re: Native M3 Release Candidate

[Simon Laws]

On 3/14/07, Pete Robbins <[EMAIL PROTECTED]> wrote:


On 14/03/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> I've just given this a try with the windows binary builds and following
> the
> getting started instructions to run the calculator sample.
>
> The first try failed as libxml2 and iconv are missing. I see now it does
> mention these in the SDO system prereqs section but a note pointing that
> out
> in the "Getting Tuscany SDO for C++ working with the binary release on
> Windows" would make this a bit clearer.


I've added some extra words for this.

Thanks for checking it out,

--
Pete



Pete

Have tried SDO on Fedora Core 5 and it compiled and ran according to the
GettingStarted instructions Have to go now but will try SCA also.

Simon

Re: Native M3 Release Candidate

[Simon Laws]

On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


ant elder wrote:
> I was using libxml2 2.6.27, seeing you had 2.6.24 i went looking for
that
> but can't find a pre-compiled win32 version for that, so I tried
> 2.6.23 and
> using that the sample runs fine.
>
>   ...ant
>

Would it help to have on our Wiki a page with actual links to the
(Windows) dependency downloads that people have been successful with?
This way users won't have to fish for distributions of libxml for
example that work for us.

What do you think?

--
Jean-Sebastien


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

The getting started pages in the release have got dependency lists with

quite an amount of detail in but I like the idea  of having somewhere where
we can record the links to dependencies and update it with any funnies that
people find.  This page was started a while back  (
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Dependencies) but
not finished. We could tidy that up and put more accurate links in.

Simon

Re: Native M3 Release Candidate

[Simon Laws]

On 3/15/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > I was using libxml2 2.6.27, seeing you had 2.6.24 i went looking for
> that
> > but can't find a pre-compiled win32 version for that, so I tried
> > 2.6.23 and
> > using that the sample runs fine.
> >
> >   ...ant
> >
>
> Would it help to have on our Wiki a page with actual links to the
> (Windows) dependency downloads that people have been successful with?
> This way users won't have to fish for distributions of libxml for
> example that work for us.
>
> What do you think?
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> The getting started pages in the release have got dependency lists with
quite an amount of detail in but I like the idea  of having somewhere where
we can record the links to dependencies and update it with any funnies that
people find.  This page was started a while back  (
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Dependencies)
but not finished. We could tidy that up and put more accurate links in.

Simon


Just compiling up SCA (on a fresh Fedora Core 6 machine this time). A few
comments when following the instructions so far.

Builidng core SCA
 Without Ant and JDK on the path the tools build fails

Looking at the getting starter page. Not sure what to do once the core has
been built. I know from experience that I need to build a sample and, before
this, build the appropriate extensions. But it's not obvious from the SCA
getting started page. Would be good to give an example of the very first
thing someone might like to try after buidling the core, e.g. now go build
the C++ extensions and try the CPPCalculator sample. Or is there some other
test I should try to prove that the compile was successful?

Tuscany SCA Extensions

Links don't work as doc is missing.

Samples
Small point - Could you extend the link highlighting from "getting started"
to "samples getting started".

Tuscany Samples - Getting Started

Samples Dependencies table 1.
Doc appears to be missing from the doc directory so links at top of table
don;t work
HTTPDBigBang link doesn't work
AlertAggregator link doesn't work

Just downloading a JDK so will let you know how I get on once done.

Simon

Re: Checkstyle in testing/sca

[Simon Laws]

On 3/14/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I've seen some recent commits from Raymond and myself around cleaning up
checkstyle and pmd violations in the sca-java-integration branch. And, as
I
said before, having the checkstyle and pmd plugins directly integrated in
the IDE helps identifying violation right when you are coding.

On 3/14/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 3/14/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 3/14/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > >
> > > I'll probably not answer you question about differences, but what I
> > > usually
> > > just run mvn -Psourcecheck. But i have found very useful to use
> > checkstyle
> > > and pmd plugins inside IDE (my case eclipse).
> > >
> > > On 3/14/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I note that there are some checkstyle/pmd plugin configurations in
> the
> > > > testing/sca pom. Can anyone tell me if this is actually running.
> I've
> > > not
> > > > seen any indication in the mvn builds that I'm doing that it is.
> Maybe
> > > > it's
> > > > just that the code is perfect or that I'm not configuring mvn
> > properly!
> > > >
> > > > Outside of the test hierarchy there is a profile ( sourcecheck I
> > think)
> > > > for
> > > > this. Why is this different in the testing modules?
> > > >
> > > > Thanks
> > > >
> > > > Simon
> > > >
> > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > http://people.apache.org/~lresende
> > >
> > Hi Luciano
> >
> > Thanks for that. Doing mvn -Psourcecheck does at least give me some
> > output!
> > It also gives an error...
> >
> > Embedded error: Could not find resource
> > 'C:\simon\Projects\Tuscany\java\java-int
> > egration\testing\sca\itest\databindings\sdo/.ruleset'.
> >
> > Is this important?
> >
> > Simon
> >
>
> I don't think we used the sourcecheck stuff in the sca-java-integration
> branch, I never use it anyway, and i guess from what you're seeing
others
> don't either.
>
>...ant
>



--
Luciano Resende
http://people.apache.org/~lresende


OK thanks everyone. I'll run the new code I have through mvn -Psourcecheck
and see if I can get the IDE integration up and running.

Simon

Re: Native M3 Release Candidate

[Simon Laws]

On 3/15/07, ant elder <[EMAIL PROTECTED]> wrote:


So that prompted me to check the licenses. Zlib and libxml2 look fine i
think though they do need to be added to the Tuscany LICENSE and NOTICE
files if the Tuscany code is using those APIs whether or not Tuscany
Native
is distributing them. Looks like iconv is LGPL which isn't ASF friendly.
Is
the Tuscany Native code actually using the iconv APIs?

   ...ant

On 3/15/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> On 15/03/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > > ant elder wrote:
> > > > I was using libxml2 2.6.27, seeing you had 2.6.24 i went looking
for
> > > that
> > > > but can't find a pre-compiled win32 version for that, so I tried
> > > > 2.6.23 and
> > > > using that the sample runs fine.
> > > >
> > > >   ...ant
> > > >
> > >
> > > Would it help to have on our Wiki a page with actual links to the
> > > (Windows) dependency downloads that people have been successful
with?
> > > This way users won't have to fish for distributions of libxml for
> > > example that work for us.
> > >
> > > What do you think?
> >
> >
> > Sure that would be useful but IMHO even better would be to just
> distribute
> > these dependencies with the binary distro. I know not everyone agrees
> with
> > that though.
> >
> >   ...ant
> >
>
> I really think that is a bad thing to do even considering the License
> issues
> of re-distributing some of them.
>
> --
> Pete
>



You might want to ignore this as I didn't strictly follow the
instructions

I installed IBM JDK 5 and dependencies on my Fedora Core 6 box (only becuase
that's what I have on my FC5 box which has worked fine with Tuscany Native
in the past). Am getting strange results from scagen. In the CppCalculator
test it generated, for example

...
float CalculatorImpl_CalculatorService_Proxy::add( float arg0,  float arg1)
{
   tuscany::sca::Operation operation("add");
   operation.addParameter("arg1", &arg0);
   operation.addParameter("arg2", &arg1);
   float ret;
   operation.setReturnValue(&ret);
   target->invoke(operation);
   return *(float*)operation.getReturnValue();
}
...

I.e. it seems to be URL encoding the generated code. I suspect this is some
setting somewhere as I've not had this before and Sebastien has just run
successfully.  I'll look at it a little closer later when I have more time.

Simon

Re: Databinding itest reorg proposal

[Simon Laws]

On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Comments inline

Raymond Feng wrote:
> +1.
>
> "transformers" could go under "interop" because it's there to test
> transformations across databindings at the transformer level.
>

+1 from me, I'm assuming you meant move the tests currently in
transformer to interop and not creating interop/transformer.



I'll  look at combining the transformer tests into interop


Thanks,
> Raymond
>
> - Original Message - From: "Simon Laws"
> <[EMAIL PROTECTED]>
> To: "tuscany-dev" 
> Sent: Wednesday, March 14, 2007 4:06 AM
> Subject: Databinding itest reorg proposal
>
>
>> I think we need to reorg the itest directory for databinding a bit and
I
>> need some help to get the maven bit correct as I'm a bit of a maven
>> novice.
>> I'm looking at the integration branch at the moment as that is where
the
>> tests are checked in but I don't see why these tests can't go in the
>> trunk
>> also.
>>
>> Currently we have:
>>
>> itest
>>   databinding
>>   sdo
>>   jaxb
>>   transformers (not sure what this is but assume it tests the
>> data type
>> transformer logic)
>>
>> From previous threads on this subject, [1] and [2], we talked about
>> changing
>> to something like
>>
>> itest
>>   databinding
>>   generator
>>   common
>>   sdo
>>   jaxb
>>   interop
>>   transformers (not sure what this is but assume it tests the
>> data type
>> transformer logic)
>>
>> Where common holds xsd, wsdl and files generated from them that are
>> common
>> between the tests, interop holds tests that look at cross databinding
>> testing and generator holds a test generator. This chane means moving
>> most
>> of the WSDL and XML files from where they are now out into common and
>> also
>> replacing test source files with generated versions.
>>
>> Interop would depend on sdo and jaxb which in turn depend on common.
>> Can we
>> do this in maven simply by adding suitable dependency lines in the
>> module
>> poms.

Yes

>> In particular I will need to copy some schema and wsdl files from one
>> module to another.
>> I notice that various build helper plugins are used in
>> various poms. Is there a recommended one for  copying resources in from
>> dependencies.

I apologize if I missed it in an earlier thread but why would the build
need to copy the files around?



No problem. I wasn't very clear. The question was motivated by needing to
use all of the resource (XSDs etc) in the common module in  the other test
modules. I.e. I  want to use the same XSD across tests but don't want to
create manual copies=. How do the processors in each test access the common
resources?




>> I have created a test generator to build the test source and
>> configuration
>> automatically. As we have quite a number of datatypes to tests
>> (potentially
>> in the 100s) I made some velocity templates to create the 8 files
>> required
>> by the test. Initially I intended to throw the generator away having
>> run it
>> but now feel that it might be useful as we extend the tests. So I
>> want to
>> run it more than once but not every time the test is compiled/run.

Wouldn't it be simpler to just run it as part of the build and not check
in the generated tests, to make sure that they are always up to date?



I had originally though that parts of the test would have to be hand crafted
but I expect as we add more types this will be impractical so maybe you are
right.


Is this a

>> candidate for a maven profile? Or is there another mechanism for
>> runinning
>> the generator occasionally?
>>

I was looking for the generator but couldn't find it, can you point us
to it? Thanks.



Sorry about that. Am trying to check it in at the moment. Was just trying to
work out this resource dependency thing.



Regards

>>
>> Simon
>>
>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13947.html
>> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15261.html
>>
>


--
Jean-Sebastien


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

Re: Databinding itest reorg proposal

[Simon Laws]

On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


[snip]
Simon Laws wrote:
>>
>> >> In particular I will need to copy some schema and wsdl files from
one
>> >> module to another.
>> >> I notice that various build helper plugins are used in
>> >> various poms. Is there a recommended one for  copying resources in
>> from
>> >> dependencies.
>>
>> I apologize if I missed it in an earlier thread but why would the build
>> need to copy the files around?
>
>
> No problem. I wasn't very clear. The question was motivated by needing
to
> use all of the resource (XSDs etc) in the common module in  the other
> test
> modules. I.e. I  want to use the same XSD across tests but don't want to
> create manual copies=. How do the processors in each test access the
> common
> resources?
>
As always, there's probably many ways to do it, but here's one way.

Add this to your pom:

...
common
...
test


Put abc.wsdl in common/src/main/resources.

And in your test case:
getClass().getClassLoader().getResourceAsStream("abc.wsdl")

Hope this helps.

--
Jean-Sebastien


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



Thanks Jean-Sebastien.

This might be useful actually. The direction I took was to add a dependency
with common and then unpack common into the test project.

I also decided to try out your suggestion of running the test generation
every time. Getting everything in the right place at the right time has been
interesting and I know a lot more about maven now! There must be easier ways
of doing this though.

Basically the scheme is that common holds all the XSDs, generation templates
and a small program that reads a configuration file and runs the templates.
The test projects (i've only been playing with SDO at present - see sdogen)
have nothing in them apart from the generation configuration file and the
pom. The pom reads the configuration files generates the test, compiles it
an runs it.

The wrinkle at the moment is that when you change the configuration file to
add more types to a test project you have to run maven twice in that test
project This is because the test generation step generates the pom itself
(the pom directs the SDO generation processing and has to have lines
generated into it). The second time you run it you pick up the newly
generated pom and the test should run as intended. You then check this new
pom and carry on.

Looking at your suggested code above I expect we can actually do all the
hard work in the generate program and also drive the sdo generation step
from here. This would remove the need to generate the pom and hence the need
to run maven twice when you update the config file. Anyhow I didn't really
want to make a career out of building test generators so it can probably
stay as it is for the time being. The next task is to do the real testing.

I haven't included this generation stuff in the databindings pom some
hopefully you will see no different when running tests at present. You can
run it though just by referencing common and sdogen.

Regards

Simon

Re: Databinding itest reorg proposal

[Simon Laws]

On 3/15/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Simon Laws wrote:
> >>
> >> >> In particular I will need to copy some schema and wsdl files from
> one
> >> >> module to another.
> >> >> I notice that various build helper plugins are used in
> >> >> various poms. Is there a recommended one for  copying resources in
> >> from
> >> >> dependencies.
> >>
> >> I apologize if I missed it in an earlier thread but why would the
> build
> >> need to copy the files around?
> >
> >
> > No problem. I wasn't very clear. The question was motivated by needing
> to
> > use all of the resource (XSDs etc) in the common module in  the other
> > test
> > modules. I.e. I  want to use the same XSD across tests but don't want
> to
> > create manual copies=. How do the processors in each test access the
> > common
> > resources?
> >
> As always, there's probably many ways to do it, but here's one way.
>
> Add this to your pom:
> 
> ...
> common
> ...
> test
> 
>
> Put abc.wsdl in common/src/main/resources.
>
> And in your test case:
> getClass().getClassLoader().getResourceAsStream(" abc.wsdl")
>
> Hope this helps.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


Thanks Jean-Sebastien.

This might be useful actually. The direction I took was to add a
dependency with common and then unpack common into the test project.

I also decided to try out your suggestion of running the test generation
every time. Getting everything in the right place at the right time has been
interesting and I know a lot more about maven now! There must be easier ways
of doing this though.

Basically the scheme is that common holds all the XSDs, generation
templates and a small program that reads a configuration file and runs the
templates. The test projects (i've only been playing with SDO at present -
see sdogen) have nothing in them apart from the generation configuration
file and the pom. The pom reads the configuration files generates the test,
compiles it an runs it.

The wrinkle at the moment is that when you change the configuration file
to add more types to a test project you have to run maven twice in that test
project This is because the test generation step generates the pom itself
(the pom directs the SDO generation processing and has to have lines
generated into it). The second time you run it you pick up the newly
generated pom and the test should run as intended. You then check this new
pom and carry on.

Looking at your suggested code above I expect we can actually do all the
hard work in the generate program and also drive the sdo generation step
from here. This would remove the need to generate the pom and hence the need
to run maven twice when you update the config file. Anyhow I didn't really
want to make a career out of building test generators so it can probably
stay as it is for the time being. The next task is to do the real testing.

I haven't included this generation stuff in the databindings pom some
hopefully you will see no different when running tests at present. You can
run it though just by referencing common and sdogen.

Regards

Simon


I forgot to mention that the reason that so many XML files have suddenly

appeared is that I've take the files that currently live in /interop and
renamed and refactored them. Still needs more work but gives us plenty to
test with. Still have more to pull in from CTS and SDO if we want also. I'm
not committed to leaving these all in the databindings/common project
because whatever the final set of XSDs we come up with I'm sure they have
wider applicability. However my maven skills aren't sufficiently honed to
get it all to hang together from /interop so we can move them to a more
suitable place in the future. This is really something we need to do in head
rather than the integration branch so I'm keeping an open mind at the
moment. Primarily, having been through them once, I wanted to get a safe
copy of them.

Regards

Simon

Re: svn move, was: Databinding itest reorg proposal

[Simon Laws]

On 3/15/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 15, 2007, at 3:34 PM, Simon Laws wrote:
> I forgot to mention that the reason that so many XML files have
> suddenly
> appeared is that I've take the files that currently live in /
> interop and
> renamed and refactored them.

Thanks for explaining as this did look a bit odd.

One way to avoid that is to use "svn move" to move the files rather
than adding them again. When you do that, SVN shows that the file was
copied from somewhere else in the repo and so it is fairly clear that
it isn't a new work but just a derivative. This also has the
advantage that the history of the file is maintained so users can
track changes even across the move. It has an even bigger benefit in
that it makes life easier for the lawyers, and a happy lawyer is much
nicer to have than a grumpy one :-)

Some IDEs which grew up with CVS don't seem to realize that SVN
allows them to just move things rather than delete old and add new
(losing history in the process). If that's the case, then you can
still get the benefits of moving through the svn command.

--
Jeremy


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

Ah, apollogies for that. I have to admit that I'm a cvs person at heart so

just getting to grips with svn. I ljust ooked up svn move and got that "why
didn't I look there first" feeling, so I'll remember that for next time.
Thanks for taking the time to explain.

Regards

Simon

Re: svn move, was: Databinding itest reorg proposal

[Simon Laws]

On 3/16/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


> Ah, apollogies for that. I have to admit that I'm a cvs person at
> heart so
> just getting to grips with svn. I ljust ooked up svn move and got
> that "why
> didn't I look there first" feeling, so I'll remember that for next
> time.
> Thanks for taking the time to explain.

If you're new to Subversion I highly recommend reading this:
   http://svnbook.red-bean.com/

There's an Appendix on "Subversion for CVS Users" :-)
--
Jeremy


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

Cool. Thanks Jeremy

Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++

[Simon Laws]

On 3/20/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote:


I've downloaded the SDO src distribution on XP and it builds and runs as
advertised.

+1 from me.

Geoff.

On 20/03/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> +1
>
>...ant
>
> On 3/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > Please vote to approve the release of milestone 3 of Tuscany SCA
Native
> > and
> > Tuscany SDO C++.
> >
> > The SDO release includes performance improvements (30-40%) along with
> > improvements to robustness.
> > The SCA release includes support for C++, Python and Ruby languages
and
> > sca,
> > webservice and REST bindings.
> >
> > The distribution artifacts are here:
> >
> >- linux and Mac OS X (source only) -
> >http://people.apache.org/~robbinspg/M3-RC4/linux-macosx/
> >- windows (source and binary) -
> >http://people.apache.org/~robbinspg/M3-RC4/win32/
> >
> > The RAT tool output for the release artifacts is here:
> > http://people.apache.org/~robbinspg/M3-RC4/
> >
> > The SDO release is tagged here
> >
> >
>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-sdo-1.0.incubating-M3-RC1/
> > The SCA release is tagged here
> >
> >
>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/native-sca-1.0.incubating-M3-RC4/
> >
> > Thank you.
> >
> > --
> > Pete
> >
>


Pete

I installed the new RCs on my Fedora Core 6 box this evening

+1 for SDO

I still get this strange effect with SCA where scagen inserts URL encoded
strings from the scagen XSL into generated CPP files. I have the IBM
java2-i386-50 JDK installed. Has anyone else tried with that? I might try
with a different version and see if that has the desired effect.

Regards

Simon

Re: [VOTE] Release Milestone 3 of Tuscany SCA Native and Tuscany SDO C++

[Simon Laws]

On 3/21/07, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 3/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> On 21/03/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 20/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > On 3/20/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I've downloaded the SDO src distribution on XP and it builds and
> runs as
> > > > advertised.
> > > >
> > > > +1 from me.
> > > >
> > > > Geoff.
> > > >
> > > > On 20/03/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > +1
> > > > >
> > > > >...ant
> > > > >
> > > > > On 3/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Please vote to approve the release of milestone 3 of Tuscany
SCA
> > > > Native
> > > > > > and
> > > > > > Tuscany SDO C++.
> > > > > >
> > > > > > The SDO release includes performance improvements (30-40%)
along
> with
> > > > > > improvements to robustness.
> > > > > > The SCA release includes support for C++, Python and Ruby
> languages
> > > > and
> > > > > > sca,
> > > > > > webservice and REST bindings.
> > > > > >
> > > > > > The distribution artifacts are here:
> > > > > >
> > > > > >- linux and Mac OS X (source only) -
> > > > > >http://people.apache.org/~robbinspg/M3-RC4/linux-macosx/
> > > > > >- windows (source and binary) -
> > > > > >http://people.apache.org/~robbinspg/M3-RC4/win32/
> > > > > >
> > > > > > The RAT tool output for the release artifacts is here:
> > > > > > http://people.apache.org/~robbinspg/M3-RC4/
> > > > > >
> > > > > > The SDO release is tagged here
> > > > > >
> > > > > >
> > > > >
> > > >
>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/cpp-sdo-1.0.incubating-M3-RC1/
> > > > > > The SCA release is tagged here
> > > > > >
> > > > > >
> > > > >
> > > >
>
http://svn.apache.org/repos/asf/incubator/tuscany/tags/native-sca-1.0.incubating-M3-RC4/
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > --
> > > > > > Pete
> > > > > >
> > > > >
> > > >
> > > Pete
> > >
> > > I installed the new RCs on my Fedora Core 6 box this evening
> > >
> > > +1 for SDO
> > >
> > > I still get this strange effect with SCA where scagen inserts URL
> encoded
> > > strings from the scagen XSL into generated CPP files. I have the IBM
> > > java2-i386-50 JDK installed. Has anyone else tried with that? I
might
> try
> > > with a different version and see if that has the desired effect.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> > Sorry Simon I've never seen anything like this on any of my 3 systems
> > with various Java SDKs. Not sure I've tried with that IBM Java though.
> >
>

I think I have seen this on my Linux system when I tried using the IBM JDK
5
a while ago - I reverted to JDK 1.4.2 and it works fine.
Have you tried an earlier JDK Simon?
We should raise a jira & add this to the readme I guess.

Cheers
Andy


OK, so after complete reinstall on my FC5 machine with the same JDK the URL
encoding problem does not appear so there must be some character encoding
setting on my other machine that I'm not seeing. Anyhow not a problem with
the  SCA release candidate but a warning note somewhere would be good.

The basic samples that I tried worked like a dream. Nice one.  I can't try
the WS samples here because of some other lonstanding issue on this box
(this is why I was trying on my nice clean FC6 machine in the first case)
but I'll give it the benefit of the doubt assuming someone else is able to
run them on linux. So +1 from me for SCA now also.

The only slight gotcha for the unwary I found was that when building SCA
with ./build_scanative.sh for me it assumes you want the C++ extension and
hence expects JAVA_HOME and ANT_HOME to be set which I didn't have. Anyhow
once set it all went OK.

Simon

Re: maven dependency plugin un pack problem in samples

[Simon Laws]

On 3/21/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


There's an example in

http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/pom.xml?view=markup
Hope that helps,
Kelvin.


On 21/03/07, muhwas <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am trying to run hello world web service sample. I
> am following instructions given with the sample.
> According to instruction
>
> 1. To build the sample  issue :
>
> mvn
>
> 2. Set up the Tuscany standalone runtime environment
> using the following command:
>
> mvn dependency:unpack
>
> After completion there should be a target\distribution
> subdirectory created that has the Tuscany standalone
> runtime.
>
> But when i am running "mvn dependency:unpack". I am
> getting error.
>
> [0] inside the definition for plugin:
> 'maven-dependency-plugin'specify the foll
> wing:
>
> 
>...
>VALUE
> .
>
> Can somebody please tell me what should i specify in
> the articatItems to fix this problem.
>
> thank you,
> muhwas
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


Hi Muhwas

Looking at your question I seems you are trying the M2 SCA distribution. I
had a go at downloading the sca bin and sample jars and get the same effect
as you. I.e. the unpack stage doesn't. I don't know how the poms, as
configured in the downloads, are intended to work. I expect someone involved
in M2 will be able to give us the details. However I can make it work
manually (I tried the standalone calculator sample as it's a little simpler
to start with).

I downloaded tuscany-sca-1.0-incubator-M2-bin.zip and unpacked it to
/sca-bin
I downloaded tuscany-sca-1.0-incubator-M2-samples.zip and unpacked it to
/samples
cd \samples
mvn
cd \samples\standalone\calculator (I just did this to be as faithful to the
readme as I could)
java -jar ..\..\..\sca-bin\bin\launcher.jar target\sample-calculator.jar

produces
3 + 2=5.0
3 - 2=1.0
3 * 2=6.0
3 / 2=1.5
Which looks like the right kind of thing.

I'm not able to use mvn in the calculator directory directly unless I mess
around with the pom hierarchy so maybe this is a bug.
Not sure why the unpack doesn't work. You can do an unpack-dependencies and
this will get you all the class files but you would have to work out your
java classpath and get the launcher up and running.

Anyhow. I hope that helps. I'm sure an M2 expert will be on soon and can
tell us the real answer.

Regards

Simon

Re: Revolutions or a Mess!!

[Simon Laws]

On 3/21/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Hi,

I am glad you brought this point up.

You mentioned about constant confrontation between two sets of people. I
would say, unfortunately, this has been caused by a lack of diversity in
the community.

I hope most of these confrontations are based on technical differences.

For the first group, who I understand all work for a specific vendor,
the push has always been just on simple spec compliance, with no
emphasis on value adds, end user experience etc. I am not saying that
spec compliance is an inconsequential issue; however, there are other
issues that are as important. To give an example, some of the work that
has been happening on distributed heterogeneous federation is something
which I think is a key differentiator for Tuscany. This has been
discussed heavily on the list, and unfortunately only three of the
committers, who don't work for a specific vendor, that took any interest
in this discussion.

I sincerely hope the technical direction within Tuscany is not purely
shaped by a given vendor's aspirations for getting their product suite
SCA-compliant. Otherwise, independent committers like me would be
wasting our time on this.

I would say we need to generate better community interest and bring in
more independent committers, so that there is a better balance on
technical debates. Unfortunately, these constant conflicts have been
putting people off. I don't think the differences are irreconcilable;
however, there should be a willingness from both sides to have an open
discussion, leaving other vested interests out, purely based on what is
best for us as a community to build Tuscany.

Thanks
Meeraj

-Original Message-
From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 21, 2007 1:31 PM
To: tuscany-dev@ws.apache.org
Subject: Revolutions or a Mess!!

Folks,

I don't really like what's going on. Too much conflicts between people.
Whatever be the issue of the day, I see 2 sets of people in constant
confrontation. The constant branching/merging is not healthy or
productive. Is there any effort or hope of reconciliation or should we
start looking at other options?

Thanks,
dims

--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
Developers

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


This message has been checked for all email viruses by MessageLabs.


*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

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

Hi


I'm looking at this as someone who has been nibbling away at the edges of
the java implementation for a while. I'm not currently a user neither have I
been a full on developer of the java code. I've spent my time working on a
PHP implementation of SCA (or at least a simplified version of SCA) and on
the Tuscany Native SCA implementation. I guess my personal motivation is to
understand how SCA is realized in more that one environment and how they
play together. For that reason (and because it's pretty cool stuff) I am
interested in the success of the Java implementation and have started
getting involved.

Primarily I want to see SCA be accepted as a useful tool in all of its
guises. If we only support a small subset of our potential users with SCA
then we are not really living up to the promise of SOA. For this to happen I
think we need people to actually use the software, we need them to feed back
requirements, problems, enhancements etc and we need to encourage them to
get involved directly in the community.

I realize that Tuscany is incubation and we may be looking for the tech
savvy user but we can't just wish for this. To make this happen we need an
effective development environment where working software can be released
regularly in a form that is consumable by users with a wide variety of
requirements. It's great that we get to build interesting stuff but we
really don't do ourselves justice if people can't download and run it easily
and update it regularly.

Looking at the mail list I see people trying to do good work in a project
they believe in. By careful design we have a runtime with a core and
extensions which build o

Re: ServerSide Presentation and Demo

[Simon Laws]

On 3/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi Jim,

Thanks for sharing this information - its really useful.

- Venkat

On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> We just finished the ServerSide demo and I figured I send a mail to
> the list outlining how it went...
>
> We had the slot following the opening keynote and were up against Rod
> (Spring) and Patrick (OpenJPA) as the other  two talks. I was
> surprised to find that the ballroom was pretty full. I gave the talk
> and the demo showing end-to-end federated deployment and reaction
> seemed very positive.  Meeraj gets the "hero" award for staying up to
> an obscene hour in the morning to implement a JMS-based discovery
> service as we encountered last-minute hiccups with JXTA.
>
> My observations are:
>
> - After speaking with people after the presentation, feedback on the
> value of SCA was consistent. Specifically, they thought the
> programming model was nice but not a differentiator. What people got
> excited about was being able to dynamically provision services to
> remote nodes and have a representation of their service network.  In
> this respect, I think the demo worked well. Two people said they need
> what the demo showed for projects they currently have underway.
>
> - People asked how SCA is different than Spring.  They reacted
> positively when I said "federation" and "distributed wiring". Related
> to this, people get dependency injection (i.e. it's old-hat) and just
> seem to assume that is the way local components obtain references.
>
> - People seemed to react positively when I compared SCA to Microsoft WCF
>
> - People liked the idea of heterogeneous service networks and support
> for components written in different languages, particularly C++.
>
> - People didn't ask about web services. People were nodding their
> heads (in agreement) when I talked about having the runtime select
> alternative bindings such as AMQP and JMS.
>
> - People want modularity and choice. Two areas they wanted choice in
> was databinding and persistence. They liked the fact that we are not
> locked into one databinding solution and that we have JPA
> integration. (as an aside, they also liked that SDO can be used
> without SCA). Spring integration was also popular.
>
> - People also liked the idea of a 2MB kernel download. One person
> mentioned they only want to download what they intend to use and not
> a lot of extra "clutter".
>
> - People wanted to know how SCA is different than an ESB. I basically
> described it using the switch vs. router metaphor and how a component
> implementation type can be a proxy for an ESB. Related to this and
> point-to-point wires, people thought wire optimization by the
> Controller was cool.
>
> - People seemed to be more interested in running Tuscany as a
> standalone edge server or embedded in an OSGi container. I didn't get
> any questions about running Tuscany in a Servlet container or J2EE
> application server. This seems to be consistent with there being a
> number of talks on server-side OSGi.
>
> My big takeway is that we need to make the demo a reality.
>
> Jim
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


Jim,

Nice one. Thanks for the summary. Did the conference record the talk? Would
be good to see it. Noting your comment and recent mails about the last
minute changes to get JMS working in short order, is everything checked in
that's needed to run the demo? Looking back I see several notes on build
instructions and it would be pretty cool to give it a spin.

Can I ask a question about support for components written in different
languages? Did people specifically say they were interested in C++? Did they
mention other languages (and, if so, which ones)?

Presumably the sweet spot is the ability to show components implemented in
various languages all acting as part of a single SCA Domain. How big a deal
do you think this ability to be able to draw a "picture" of you
heterogeneous service network (in SCDL) vs some of the other things you
mention like "standalone edge server" or "selectable bindings". I'm asking
this question because, as you know, I like the idea and from your notes it
seems the audience likes the idea but I'm interested to know how much
interest there was for this vs other things.

I imagine, from reading your closing comments, you have a whole stack of
ideas now in your head about what needs doing next. This would seem like a
great opportunity for us all to look at what technical challenges lie ahead
and to have a discussion about how, as a community, we step up to meeting
some of them. How do we do this? Do we start some threads on individual
items? A thread on the grand plan and then split onto areas of peoples
interest. Having this summary is great because is really pushes on what we
really need to focus on, i.e. maki

Re: ServerSide Presentation and Demo

[Simon Laws]

On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Simon,

All the work that was done for the demo has been committed. I posted a
set of build instructions to get the demo running for Mario. However,
the information is scattered across multiple emails. I can collate them
and repost it to the list, if that helps.

Thanks
Meeraj

-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 11:31 AM
To: tuscany-dev@ws.apache.org
Subject: Re: ServerSide Presentation and Demo

On 3/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi Jim,
>
> Thanks for sharing this information - its really useful.
>
> - Venkat
>
> On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > We just finished the ServerSide demo and I figured I send a mail to
> > the list outlining how it went...
> >
> > We had the slot following the opening keynote and were up against
> > Rod
> > (Spring) and Patrick (OpenJPA) as the other  two talks. I was
> > surprised to find that the ballroom was pretty full. I gave the talk

> > and the demo showing end-to-end federated deployment and reaction
> > seemed very positive.  Meeraj gets the "hero" award for staying up
> > to an obscene hour in the morning to implement a JMS-based discovery

> > service as we encountered last-minute hiccups with JXTA.
> >
> > My observations are:
> >
> > - After speaking with people after the presentation, feedback on the

> > value of SCA was consistent. Specifically, they thought the
> > programming model was nice but not a differentiator. What people got

> > excited about was being able to dynamically provision services to
> > remote nodes and have a representation of their service network.  In

> > this respect, I think the demo worked well. Two people said they
> > need what the demo showed for projects they currently have underway.
> >
> > - People asked how SCA is different than Spring.  They reacted
> > positively when I said "federation" and "distributed wiring".
> > Related to this, people get dependency injection (i.e. it's old-hat)

> > and just seem to assume that is the way local components obtain
references.
> >
> > - People seemed to react positively when I compared SCA to Microsoft

> > WCF
> >
> > - People liked the idea of heterogeneous service networks and
> > support for components written in different languages, particularly
C++.
> >
> > - People didn't ask about web services. People were nodding their
> > heads (in agreement) when I talked about having the runtime select
> > alternative bindings such as AMQP and JMS.
> >
> > - People want modularity and choice. Two areas they wanted choice in

> > was databinding and persistence. They liked the fact that we are not

> > locked into one databinding solution and that we have JPA
> > integration. (as an aside, they also liked that SDO can be used
> > without SCA). Spring integration was also popular.
> >
> > - People also liked the idea of a 2MB kernel download. One person
> > mentioned they only want to download what they intend to use and not

> > a lot of extra "clutter".
> >
> > - People wanted to know how SCA is different than an ESB. I
> > basically described it using the switch vs. router metaphor and how
> > a component implementation type can be a proxy for an ESB. Related
> > to this and point-to-point wires, people thought wire optimization
> > by the Controller was cool.
> >
> > - People seemed to be more interested in running Tuscany as a
> > standalone edge server or embedded in an OSGi container. I didn't
> > get any questions about running Tuscany in a Servlet container or
> > J2EE application server. This seems to be consistent with there
> > being a number of talks on server-side OSGi.
> >
> > My big takeway is that we need to make the demo a reality.
> >
> > Jim
> >
> >
> >
> >
> >
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
Jim,

Nice one. Thanks for the summary. Did the conference record the talk?
Would be good to see it. Noting your comment and recent mails about the
last minute changes to get JMS working in short order, is everything
checked in that's needed to run the demo? Looking back I see several
notes on build instructions and it would be pretty cool to give it a
spin.

Can I ask a question about support

A question of federation - was: Planning kernel release 2.0

[Simon Laws]

On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Hi,

Now that the SPI is getting stable and we have the initial end-to-end
story for federation working, I would suggest we plan for the final
release for kernel 2.0, with emphasis on federation and user experience.
I was thinking about aiming for a beta in June in time for TSSJS
Barcelona and the final release for August. Maybe we can have couple of
alpha releases from now and June as well. These are the features, I
would like to see in 2.0.

1. Tidy up anything required in physical model, now that it is starting
to take good shape.
2. Tidy up generators from logical to physical model.
3. Fix the JXTA discovery issues, also investigate other discovery
protocols.
4. Federation end-to-end fully completed, this would include, maybe,
profiles advertising their capabilities and the information being used
in intent-based autowiring etc.
5. Intent-based auto wiring
6. Emphasis on end user experience in terms of ease of use.
7. Assembly service, this kind of now related to the generators that
have been introduced in the last week or so
8. Artifact management, especially mobile code when we target components
to remote profiles.

Also, now the SPI has started settling in, we need to start looking at
binding and container extensions as well. Some of the bindings I would
be interested in are,

1. JMS
2. AMQP
3. Hessian

Ta
Meeraj


*

You can find us at www.voca.com

*
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX. United Kingdom

VAT No. 226 6112 87


This message has been checked for all email viruses by MessageLabs.

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

Hi Meeraj



From my perspective having demonstrable code in June would be spot on as I

have to speak on SCA then and would consider a demo if we could do it.

I don't have the knowledge yet to comment on the details of your proposal
just yet (hence the new subject) but a question. From a future demo point of
view I would like to show various runtime options some of which are not
federated  examples some of which are. Can I miss out the federation bit if
I want to? For example, I would potentially like to show a variety of
scenarios

- Hello world. the simplest possible single process example to get people
into how SCA works
- Standalone domain (a single VM)
service provision (perhaps an AJAX style example where an SCA composite
provides services to the browser)
service consumption (backend service access providing content to my
AJAX service)
- Federated domain (multiple VM)
How SCA describes many connected composites.

I'm just starting now to look at how all the kernel stuff works so I expect
all this will become clear soon enough (I found your previous posts giving
explantion b.t.w - so am starting from there)

Regards

Simon

Re: ServerSide Presentation and Demo

[Simon Laws]

On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Simon,

My reply to Mario has all the detail to run the demo.

Ta
Meeraj

-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 12:00 PM
To: tuscany-dev@ws.apache.org
Subject: Re: ServerSide Presentation and Demo

On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>
> Simon,
>
> All the work that was done for the demo has been committed. I posted a

> set of build instructions to get the demo running for Mario. However,
> the information is scattered across multiple emails. I can collate
> them and repost it to the list, if that helps.
>
> Thanks
> Meeraj
>
> -Original Message-
> From: Simon Laws [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 22, 2007 11:31 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: ServerSide Presentation and Demo
>
> On 3/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi Jim,
> >
> > Thanks for sharing this information - its really useful.
> >
> > - Venkat
> >
> > On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > We just finished the ServerSide demo and I figured I send a mail
> > > to the list outlining how it went...
> > >
> > > We had the slot following the opening keynote and were up against
> > > Rod
> > > (Spring) and Patrick (OpenJPA) as the other  two talks. I was
> > > surprised to find that the ballroom was pretty full. I gave the
> > > talk
>
> > > and the demo showing end-to-end federated deployment and reaction
> > > seemed very positive.  Meeraj gets the "hero" award for staying up

> > > to an obscene hour in the morning to implement a JMS-based
> > > discovery
>
> > > service as we encountered last-minute hiccups with JXTA.
> > >
> > > My observations are:
> > >
> > > - After speaking with people after the presentation, feedback on
> > > the
>
> > > value of SCA was consistent. Specifically, they thought the
> > > programming model was nice but not a differentiator. What people
> > > got
>
> > > excited about was being able to dynamically provision services to
> > > remote nodes and have a representation of their service network.
> > > In
>
> > > this respect, I think the demo worked well. Two people said they
> > > need what the demo showed for projects they currently have
underway.
> > >
> > > - People asked how SCA is different than Spring.  They reacted
> > > positively when I said "federation" and "distributed wiring".
> > > Related to this, people get dependency injection (i.e. it's
> > > old-hat)
>
> > > and just seem to assume that is the way local components obtain
> references.
> > >
> > > - People seemed to react positively when I compared SCA to
> > > Microsoft
>
> > > WCF
> > >
> > > - People liked the idea of heterogeneous service networks and
> > > support for components written in different languages,
> > > particularly
> C++.
> > >
> > > - People didn't ask about web services. People were nodding their
> > > heads (in agreement) when I talked about having the runtime select

> > > alternative bindings such as AMQP and JMS.
> > >
> > > - People want modularity and choice. Two areas they wanted choice
> > > in
>
> > > was databinding and persistence. They liked the fact that we are
> > > not
>
> > > locked into one databinding solution and that we have JPA
> > > integration. (as an aside, they also liked that SDO can be used
> > > without SCA). Spring integration was also popular.
> > >
> > > - People also liked the idea of a 2MB kernel download. One person
> > > mentioned they only want to download what they intend to use and
> > > not
>
> > > a lot of extra "clutter".
> > >
> > > - People wanted to know how SCA is different than an ESB. I
> > > basically described it using the switch vs. router metaphor and
> > > how a component implementation type can be a proxy for an ESB.
> > > Related to this and point-to-point wires, people thought wire
> > > optimization by the Controller was cool.
> > >
> > > - People seemed to be more interested in running Tuscany as a
> > > standalone edge server or embedded in an OSGi container. I didn't
> > > get any qu

Re: A question of federation - was: Planning kernel release 2.0

[Simon Laws]

On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Simon,

As Jim mentioned in an earler email, A single-VM or runtime physical
topology is just a degenerate case of a multi-VM model. In a single-VM
scenario there is only one profile that runs the master and the slave.
With some minor modifications, we should be able to run the TSS demo in
a single VM mode from deploying the SCDL within the admin console,
through to invoking the application. That has been one of the key
drivers for separating logical and physical aspects of the model.
Physical model is generated from the logical model based on the targeted
runtimes for the components included in the composite that is being
contributed. In a single-VM model, all the physical components will be
targeted onto the same runtime.

In fact, though the demo showed the federation aspects of Tuscany, the
actual application after deployment onto the slave ran in single-VM mode
using local bindings.

HTH

Ta
Meeraj

-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 12:22 PM
To: tuscany-dev@ws.apache.org
Subject: A question of federation - was: Planning kernel release 2.0

On 3/22/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Now that the SPI is getting stable and we have the initial end-to-end
> story for federation working, I would suggest we plan for the final
> release for kernel 2.0, with emphasis on federation and user
experience.
> I was thinking about aiming for a beta in June in time for TSSJS
> Barcelona and the final release for August. Maybe we can have couple
> of alpha releases from now and June as well. These are the features, I

> would like to see in 2.0.
>
> 1. Tidy up anything required in physical model, now that it is
> starting to take good shape.
> 2. Tidy up generators from logical to physical model.
> 3. Fix the JXTA discovery issues, also investigate other discovery
> protocols.
> 4. Federation end-to-end fully completed, this would include, maybe,
> profiles advertising their capabilities and the information being used

> in intent-based autowiring etc.
> 5. Intent-based auto wiring
> 6. Emphasis on end user experience in terms of ease of use.
> 7. Assembly service, this kind of now related to the generators that
> have been introduced in the last week or so 8. Artifact management,
> especially mobile code when we target components to remote profiles.
>
> Also, now the SPI has started settling in, we need to start looking at

> binding and container extensions as well. Some of the bindings I would

> be interested in are,
>
> 1. JMS
> 2. AMQP
> 3. Hessian
>
> Ta
> Meeraj
>
>
> *
>
> You can find us at www.voca.com
>
> *
> This communication is confidential and intended for the exclusive use
> of the addressee only. You should not disclose its contents to any
> other person.
> If you are not the intended recipient please notify the sender named
> above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX. United Kingdom
>
> VAT No. 226 6112 87
>
>
> This message has been checked for all email viruses by MessageLabs.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Meeraj

From my perspective having demonstrable code in June would be spot on as
I have to speak on SCA then and would consider a demo if we could do it.

I don't have the knowledge yet to comment on the details of your
proposal just yet (hence the new subject) but a question. From a future
demo point of view I would like to show various runtime options some of
which are not federated  examples some of which are. Can I miss out the
federation bit if I want to? For example, I would potentially like to
show a variety of scenarios

- Hello world. the simplest possible single process example to get
people into how SCA works
- Standalone domain (a single VM)
 service provision (perhaps an AJAX style example where an SCA
composite provides services to the browser)
 service consumption (backend service access providing content to my
AJAX service)
- Federated domain (multiple VM)
 How SCA describes many connected composites.

I'm just starting now to look at how all the kernel stuff works so I
expect all this will become clear soon enough (I found your previous
posts giving explantion b.t.w - so am starting from there)

Regards

Simon


This message has been checked for all email viruses by MessageLabs.

This message has been checked f

Re: Compilation status

[Simon Laws]

On 3/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I think this issue will be raised again and again every time new members
come to try Tuscany trunk, and this is very bad for a project that is
trying
to build a community.  Also, trying to quote an article Jim Marino sent
from
Martin Fowler about Continuous Integration [1] :

"Automated environments for builds are a common feature of systems. The
Unix
world has had make for decades, the Java community developed Ant, the .NET
community has had Nant and now has MSBuild. Make sure you can build and
launch your system using these scripts using a single command.

A common mistake is not to include everything in the automated build."

also, this has been already discussed in various other threads [2] [3].

Based on this, I'll start a VOTE around a proposal to get a set of
profiles
to allow for building the trunk in a more automated way.

[1] - http://www.martinfowler.com/articles/continuousIntegration.html
[2] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html
[3] -
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15303.html


On 3/22/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I hate to bring up this issue again, but I really share the pain that
> Mario
> just went through. Don't we think we have room for improvements to build
> the
> stuff in a much simpler fashion? To me, to have a build for a bundle
which
> consists of a set of the modules working together at the same level
would
> be
> really helpful for the poor guys. It's very difficult to manually
> coordinate
> the build across modules even with published SNAPSHOTs (which I don't
see
> it
> happens frequently and it's also very hard because a collection of
> SNAPSHOTs
> don't really establish a baseline for those who want to try the latest
> code).
>
> I (assume that I) understand all the rationales and pricinples for
> modulization. But I'm really scared by the user experiences. Where is
the
> reasonable middle ground?
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Antollini, Mario" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, March 22, 2007 6:57 AM
> Subject: RE: Compilation status
>
>
> Meeraj,
>
> Finally, I was able to generate the server.star.jar file.
>
> This is compilation order that worked for me:
>
> java/spec/commonj/
> java/spec/sca-api-r1.0/
> java/sca/kernel/
> java/sca/runtime/
> java/sca/services/
> java/sca/contrib/discovery/
> java/sca/contrib/discovery/jms
> java/sca/console/
> java/sca/core-samples/
> java/distribution/sca/demo.app
> java/distribution/sca/demo/
>
> Disclaimer: I have been struggling with the compilation for two days, I
> cannot fully assure that the order of the above list is the actual
> order. If anyone is able to compile this exact way, please let us know.
>
> BTW, java/sca/extensions/ cannot be compiled for now.
>
> Besides the good news, I was not able to start the servers (take a look
> at the attachment to see the errors)
>
> Do you have any idea what could be happening?
>
> Thanks and regards,
> Mario
>
>
> -Original Message-
> From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 22, 2007 10:13 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: Compilation status
>
> Mario,
>
> AFAIK extensions in trunk is still in a bit of a flux. If you want to
> run the demo, you don't need to run the extensions (the demo uses Java
> container with local bindings), I will try to post a dfeinitive list of
> tasks to build and run the demo later in the day, which will be useful
> to Simon as well.
>
> Ta
> Meeraj
>
> -Original Message-
> From: Antollini, Mario [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 22, 2007 12:29 PM
> To: tuscany-dev@ws.apache.org
> Subject: Compilation status
>
> Meeraj,
>
>
>
> I just wanted you to know that I am still not able to compile the code I
> checked out from SVN. The main problem is located in the *extensions*
> project. I have been modifying the pom files within this project but I
> did not manage to get it compiled yet.
>
>
>
> Basically, the main problems are related to inconsistencies between
> parent references (e.g.; axis2's root project is using groupId
> *org.apache.tuscany.sca.axis2* while the plugin subproject states that
> its parent is *org.apache.tuscany.sca.extensions.axis2*).
>
>
>
> Any tips about this?
>
>
>
> Thanks,
>
> Mario
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
> *
>
> You can find us at www.voca.com
>
> *
> This communication is confidential and intended for
> the exclusive use of the addressee only. You should
> not disclose its contents to any other person.
> If you are not the intended recipient please notify
> the sender named above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homes

Re: Build structure - having cake and still eating

[Simon Laws]

On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:

> +1.
>
> I think it's in line with the proposal in my response to Meeraj.
>
> One question: For a bundle to reference a module in the Tuscany
> source tree, do we really have to copy (or use svn:externals
> property) if it points to a location (under trunk, tags, or
> branches) in the Tuscany tree? I think a relative path for the
>  will work.

It will.

The difference would be that with a ../.. type relative path someone
can't just check out the assembly module, they need to check out the
whole tree from some common root. With an external they could just
check out the assembly module and the source for the dependency would
be checked out as well. Of course, then they might have multiple
copies of the dependency source to manage.

Either works and it would up to the users of the assembly module to
choose which style they prefer.

--
Jeremy


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

Sounds like a good compromise to me



When you talk about flattening the module hierarchy do you mean this
literally in svn (which I like the sound of as I can never find anything in
all the nested dirs - my inexperience showing) or is this some virtual
flattening?


Simon

Re: A question of federation - was: Planning kernel release 2.0

[Simon Laws]

On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 22, 2007, at 8:47 AM, Simon Laws wrote:
>> Ok, cool, so I can run a simple app in a single VM. Let me try it
>> out.

Just to set expectations, I don't think the system configuration in
the default runtime has been switched over to the federated deployer
yet. So if you run the calc sample on that runtime then it will still
be using the old stuff.

If you want to experiment with the federated stuff, you would need to
use the scdl from the master profile in the demo.

--
Jeremy


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

so I get the option to include/exclude federation by modifying the system

configuration? Nice. Not saying I don't want federation but nice to have the
option.

S

Re: Compilation status

[Simon Laws]

On 3/22/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:



Simon,

This is the script I am using right now. The script file must be located
one level above of the java directory:

echo
echo java/spec/commonj/ ...
echo
cd ./java/spec/commonj/
mvn install
echo
echo java/spec/sca-api-r1.0/ ...
echo
cd ../../../java/spec/sca-api-r1.0/
mvn install
echo
echo java/sca/kernel/ ...
echo
cd ../../../java/sca/kernel/
mvn install
echo
echo java/sca/runtime/ ...
echo
cd ../../../java/sca/runtime/
mvn install
echo
echo java/sca/services/ ...
echo
cd ../../../java/sca/services/
mvn install
echo
echo java/sca/contrib/discovery/ ...
echo
cd ../../../java/sca/contrib/discovery/
mvn install
echo
echo java/sca/contrib/discovery/jms ...
echo
cd ../../../../java/sca/contrib/discovery/jms
mvn install
echo
echo java/sca/console/ ...
echo
cd ../../../java/sca/console/
mvn install
echo
echo java/sca/core-samples/ ...
echo
cd ../../../java/sca/core-samples/
mvn install
echo
echo java/distribution/sca/demo.app ...
echo
cd ../../../java/distribution/sca/demo.app
mvn install
echo
echo java/distribution/sca/demo/ ...
echo
cd ../../../../java/distribution/sca/demo/
mvn install
cd ../../../../


Mario


-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 1:43 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Compilation status

On 3/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I think this issue will be raised again and again every time new
members
> come to try Tuscany trunk, and this is very bad for a project that is
> trying
> to build a community.  Also, trying to quote an article Jim Marino
sent
> from
> Martin Fowler about Continuous Integration [1] :
>
> "Automated environments for builds are a common feature of systems.
The
> Unix
> world has had make for decades, the Java community developed Ant, the
.NET
> community has had Nant and now has MSBuild. Make sure you can build
and
> launch your system using these scripts using a single command.
>
> A common mistake is not to include everything in the automated
build."
>
> also, this has been already discussed in various other threads [2]
[3].
>
> Based on this, I'll start a VOTE around a proposal to get a set of
> profiles
> to allow for building the trunk in a more automated way.
>
> [1] - http://www.martinfowler.com/articles/continuousIntegration.html
> [2] -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html
> [3] -
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15303.html
>
>
> On 3/22/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I hate to bring up this issue again, but I really share the pain
that
> > Mario
> > just went through. Don't we think we have room for improvements to
build
> > the
> > stuff in a much simpler fashion? To me, to have a build for a bundle
> which
> > consists of a set of the modules working together at the same level
> would
> > be
> > really helpful for the poor guys. It's very difficult to manually
> > coordinate
> > the build across modules even with published SNAPSHOTs (which I
don't
> see
> > it
> > happens frequently and it's also very hard because a collection of
> > SNAPSHOTs
> > don't really establish a baseline for those who want to try the
latest
> > code).
> >
> > I (assume that I) understand all the rationales and pricinples for
> > modulization. But I'm really scared by the user experiences. Where
is
> the
> > reasonable middle ground?
> >
> > Thanks,
> > Raymond
> >
> > - Original Message -
> > From: "Antollini, Mario" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Thursday, March 22, 2007 6:57 AM
> > Subject: RE: Compilation status
> >
> >
> > Meeraj,
> >
> > Finally, I was able to generate the server.star.jar file.
> >
> > This is compilation order that worked for me:
> >
> > java/spec/commonj/
> > java/spec/sca-api-r1.0/
> > java/sca/kernel/
> > java/sca/runtime/
> > java/sca/services/
> > java/sca/contrib/discovery/
> > java/sca/contrib/discovery/jms
> > java/sca/console/
> > java/sca/core-samples/
> > java/distribution/sca/demo.app
> > java/distribution/sca/demo/
> >
> > Disclaimer: I have been struggling with the compilation for two
days, I
> > cannot fully assure that the order of the above list is the actual
> > order. If anyone is able to compile this exact way, please let us
know.
> >
> > BTW, java/sca/extensions/ cannot be compiled for now.
> >
> > Besides the good news, I was not able to start the serv

Re: Build structure - having cake and still eating

[Simon Laws]

On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 22, 2007, at 11:19 AM, Simon Laws wrote:
> 
> When you talk about flattening the module hierarchy do you mean this
> literally in svn (which I like the sound of as I can never find
> anything in
> all the nested dirs - my inexperience showing) or is this some virtual
> flattening?
> 

Not a  at all. We can do either or both ...

The logical/virtual tree here is the  structure in the pom.
Maven projects can inherit project definitions (stuff like
dependencies, repo locations, plugins to use) from another project by
specifying it in their  element - this can be used to avoid
repetition of stuff like dependency versions, plugin configurations
and so on.

This is actually independent of the physical directory structure,
although often the pom in one directory is used as the parent for
 that it builds. This is actually conflating physical
structure and logical structure together and although it seemed like
a good idea at the time I don't think that it is working any more.


I think we should first flatten the logical hierarchy so that all
independent module groups inherit from a global parent. This would be
org.apache.tuscany:sca:1.0-incubating.  By "independent" I mean
things that could be released independently - these could be groups
of tightly coupled modules (such the current "kernel" or "runtime")
or individual modules such as "http.jetty"

I started on this for the modules that were part of 2.0-alpha but
have not done it yet for the modules in extensions or services that
were not. I think we should do this now for the others - I'll make a
start on the ones used in the demo.

An orthogonal issue is how we lay out the physical directory tree. It
is probably simpler to get rid of midlevel parents like "extensions"
and "services" all together and just have a flat structure under
"sca" - I think that would help make things easier to find.

We started doing that with a gradual migration of stuff from
"services" to "extensions" but I think doing this gradually has
probably just added to the confusion. I'd suggest we give up on the
gradual approach and move everything under "contrib" until we can fix
the logical structure as above.

To summarize:
1) move everything that does not logical depend on
org.apache.tuscany:sca:1.0-incubating to contrib
2) update each module or group in contrib to be logically independent
3) once the module is independent move it to the flat structure under
sca so it is easy to find

I'm going to get started with the modules used in the demo.
--
Jeremy

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

Jeremy. This sounds like a simpler approach than what is there now. I like

the idea but a question.

1) move everything that does not logical depend on
org.apache.tuscany:sca:1.0-incubating to contrib

from your previous definition do you mean those things that are not
considered to be independent. Or do you mean things that could be
independent but just aren't packaged that way now. I assume that you mean
the latter as your next point is to go ahead and make them independent.

Also is the global parent version 1.0-incubating or 1.0-incubating-SNAPSHOT.
I note that now you have it without SNAPSHOT but its children with SNAPSHOT.
Are you just saying that the global parent doesn't get packaged/released
per-se SNAPSHOT or not.

S

Re: Build structure - having cake and still eating

[Simon Laws]

On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
> Jeremy. This sounds like a simpler approach than what is there now.
> I like
> the idea but a question.
>
> 1) move everything that does not logical depend on
> org.apache.tuscany:sca:1.0-incubating to contrib
>
> from your previous definition do you mean those things that are not
> considered to be independent. Or do you mean things that could be
> independent but just aren't packaged that way now. I assume that
> you mean
> the latter as your next point is to go ahead and make them
> independent.

Yes things aren't really independent due to the intermediate poms in
the physical directory tree.

>
> Also is the global parent version 1.0-incubating or 1.0-incubating-
> SNAPSHOT.
> I note that now you have it without SNAPSHOT but its children with
> SNAPSHOT.
> Are you just saying that the global parent doesn't get packaged/
> released
> per-se SNAPSHOT or not.

This is the pom defined in the tag here:
   https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/
sca/1.0-incubating

which is a stable artifact - one we have voted to release but are
waiting for the IPMC to approve. It will not move.

[[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS
THREAD]]
   http://mail-archives.apache.org/mod_mbox/incubator-general/
200703.mbox/[EMAIL PROTECTED]

The things in trunk are not stable and so have a SNAPSHOT version.
--
Jeremy


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

Ok, I get it. Thanks Jemery.


S

svn problems

[Simon Laws]

I had a few problems trying to commit to svn yesterday (using Tortoise svn
from Windows). For example,

Adding:
simon\Projects\Tuscany\java\java-integration\testing\sca\itest\databindings\common\src\main\resources\generate\DatabindingTestCase.java.vm

Sending content:
simon\Projects\Tuscany\java\java-integration\testing\sca\itest\databindings\common\src\main\resources\generate\DatabindingTestCase.java.vm

Error: Commit failed (details follow):
Error: Cannot write to the prototype revision file of transaction '522261-1'
because a previous representation is currently being written by another
process

Googling this seems to point to a permissions problem but that doesn't hold
water for me as it was intermittent. I have had problems with my ADSL link
over the last few days (to the extent that I was completely offline
Friday/Saturday) but thought it was fixed. This looks like a server side svn
thing to me but am prepared to accept that it's an ISP thing my end. Just
checking that I'm not doing something obviously stupid. Maybe there was
infrastructure work going on yesterday. I had a quick scout round but
couldn't find any obvious notices. Anyhow all the commits that I wanted to
do are now done b.t.w so they worked eventually. Be interested to know if
this is just me so I can chase this end if it happens again.

Simon

Re: Databinding itest reorg proposal

[Simon Laws]

On 3/15/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 3/15/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> On 3/15/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> >
> > [snip]
> > Simon Laws wrote:
> > >>
> > >> >> In particular I will need to copy some schema and wsdl files
> > from one
> > >> >> module to another.
> > >> >> I notice that various build helper plugins are used in
> > >> >> various poms. Is there a recommended one for  copying resources
> > in
> > >> from
> > >> >> dependencies.
> > >>
> > >> I apologize if I missed it in an earlier thread but why would the
> > build
> > >> need to copy the files around?
> > >
> > >
> > > No problem. I wasn't very clear. The question was motivated by
> > needing to
> > > use all of the resource (XSDs etc) in the common module in  the
> > other
> > > test
> > > modules. I.e. I  want to use the same XSD across tests but don't
> > want to
> > > create manual copies=. How do the processors in each test access the
> > > common
> > > resources?
> > >
> > As always, there's probably many ways to do it, but here's one way.
> >
> > Add this to your pom:
> > 
> > ...
> > common
> > ...
> > test
> > 
> >
> > Put abc.wsdl in common/src/main/resources.
> >
> > And in your test case:
> > getClass().getClassLoader().getResourceAsStream(" abc.wsdl")
> >
> > Hope this helps.
> >
> > --
> > Jean-Sebastien
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Thanks Jean-Sebastien.
>
> This might be useful actually. The direction I took was to add a
> dependency with common and then unpack common into the test project.
>
> I also decided to try out your suggestion of running the test generation
> every time. Getting everything in the right place at the right time has been
> interesting and I know a lot more about maven now! There must be easier ways
> of doing this though.
>
> Basically the scheme is that common holds all the XSDs, generation
> templates and a small program that reads a configuration file and runs the
> templates. The test projects (i've only been playing with SDO at present -
> see sdogen) have nothing in them apart from the generation configuration
> file and the pom. The pom reads the configuration files generates the test,
> compiles it an runs it.
>
> The wrinkle at the moment is that when you change the configuration file
> to add more types to a test project you have to run maven twice in that test
> project This is because the test generation step generates the pom itself
> (the pom directs the SDO generation processing and has to have lines
> generated into it). The second time you run it you pick up the newly
> generated pom and the test should run as intended. You then check this new
> pom and carry on.
>
> Looking at your suggested code above I expect we can actually do all the
> hard work in the generate program and also drive the sdo generation step
> from here. This would remove the need to generate the pom and hence the need
> to run maven twice when you update the config file. Anyhow I didn't really
> want to make a career out of building test generators so it can probably
> stay as it is for the time being. The next task is to do the real testing.
>
> I haven't included this generation stuff in the databindings pom some
> hopefully you will see no different when running tests at present. You can
> run it though just by referencing common and sdogen.
>
> Regards
>
> Simon
>
>
> I forgot to mention that the reason that so many XML files have suddenly
appeared is that I've take the files that currently live in /interop and
renamed and refactored them. Still needs more work but gives us plenty to
test with. Still have more to pull in from CTS and SDO if we want also. I'm
not committed to leaving these all in the databindings/common project
because whatever the final set of XSDs we come up with I'm sure they have
wider applicability. However my maven skills aren't sufficiently honed to
get it all to hang together from /interop so we can move them to a more
suitable place in the future. This is really something we need to do in head
rather than the integration branch so I&#x

Re: A question of federation - was: Planning kernel release 2.0

[Simon Laws]

On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote:


>> > Hi Meeraj
>>
>> From my perspective having demonstrable code in June would be spot
>> on as
>> I have to speak on SCA then and would consider a demo if we could
>> do it.
>>
Maybe we can even get something earlier -  I'm also speaking at JavaOne.

>> I don't have the knowledge yet to comment on the details of your
>> proposal just yet (hence the new subject) but a question. From a
>> future
>> demo point of view I would like to show various runtime options
>> some of
>> which are not federated  examples some of which are. Can I miss
>> out the
>> federation bit if I want to? For example, I would potentially like to
>> show a variety of scenarios
>>
>> - Hello world. the simplest possible single process example to get
>> people into how SCA works
>> - Standalone domain (a single VM)
>>  service provision (perhaps an AJAX style example where an SCA
>>

+1

I think it would be good to finish out some of the programming model
for web apps, in particular allowing injection on Services. If you
want to demo something with Flex, let me know as I have some contacts
there that may be able to help us.

For a simple example, in my talk I used the loan-app example from the
core samples. I basically started with a simple LoanClient that
talked to a LoanService (pulled from the core-samples) in a stateless
manner. I showed how components can be simple POJOs with no
annotations and then demonstrated how they are configured in a very
simple assembly. I've done a number of SCA presentations and the
approach that seems to resonate the most is first providing a high-
level picture of what SCA is by comparing it to Microsoft WCF. I then
have one slide basically saying "components offer services and have
references". This is similar to Don Box's description of WCF when he
talks about services having "ABCs". Right after that slide, I jump
into a POJO example with the point of saying "you [the audience]
already know how to write components in Java using SCA". I usually
show the assembly SCDL next which is just a few lines. Then I update
the example to apply conversational scope and callbacks to
demonstrate why the development paradigm is an evolution from what
current exists. At that, point I then say "this isn't something
entirely new, this can be done today...what is new is federation,
runtime selection of bindings, etc. etc."


>> composite provides services to the browser)
>>  service consumption (backend service access providing content
>> to my
>> AJAX service)
>> - Federated domain (multiple VM)
>>  How SCA describes many connected composites.
>>
>> I'm just starting now to look at how all the kernel stuff works so I
>> expect all this will become clear soon enough (I found your previous
>> posts giving explantion b.t.w - so am starting from there)

Cool. I think making this stuff a reality and moving it beyond
demoware would be a great way to promote collaboration. Let me know
how I can help.

Jim



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

Thanks for that Jim, makes life a little easier when someone has thought

through this before. I like the build up approach. Something I would also
like to do is include some alternative component type implementations.
Anyhow, it's a little while off yet so I'll see what comes together over the
coming two months. I'm less concerned now that we won't have anything to
show!

Regards

Simon

Re: Tag for TSSS demo code

[Simon Laws]

On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I've created a tag corresponding to the code used to build the demo
(r520715) and added a trivial pom to build the lot. To build:
   $ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/
java/tsss-demo
   $ mvn install

I did not change the versions in the poms so they are using the same
ones as trunk. To avoid conflict in the snapshot repo we should not
deploy jars built from this.

--
Jeremy

On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:

> Jeremy,
>
> This is the definitve list, thanks to Mario.
>
> java/spec/commonj/
> java/spec/sca-api-r1.0/
> java/sca/kernel/
> java/sca/runtime/
> java/sca/services/
> java/sca/contrib/discovery/
> java/sca/contrib/discovery/jms
> java/sca/console/
> java/sca/core-samples/
> java/distribution/sca/demo.app
> java/distribution/sca/demo/
>
> Ta
> Meeraj
>
> -Original Message-
> From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 22, 2007 1:52 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Compilation status
>
> I think we should tag and deploy SNAPSHOTs of the revision used for
> the
> demo - that way people can build as much or as little as they wish. If
> you can post the list, I get those modules tagged and deployed later
> today.
>
> --
> Jeremy
>
> On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:
>
>> Mario,
>>
>> AFAIK extensions in trunk is still in a bit of a flux. If you want to
>> run the demo, you don't need to run the extensions (the demo uses
>> Java
>
>> container with local bindings), I will try to post a dfeinitive list
>> of tasks to build and run the demo later in the day, which will be
>> useful to Simon as well.
>>
>> Ta
>> Meeraj
>>
>> -Original Message-
>> From: Antollini, Mario [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, March 22, 2007 12:29 PM
>> To: tuscany-dev@ws.apache.org
>> Subject: Compilation status
>>
>> Meeraj,
>>
>>
>>
>> I just wanted you to know that I am still not able to compile the
>> code
>
>> I checked out from SVN. The main problem is located in the
>> *extensions* project. I have been modifying the pom files within this
>> project but I did not manage to get it compiled yet.
>>
>>
>>
>> Basically, the main problems are related to inconsistencies between
>> parent references (e.g.; axis2's root project is using groupId
>> *org.apache.tuscany.sca.axis2* while the plugin subproject states
>> that
>
>> its parent is *org.apache.tuscany.sca.extensions.axis2*).
>>
>>
>>
>> Any tips about this?
>>
>>
>>
>> Thanks,
>>
>> Mario
>>
>>
>> This message has been checked for all email viruses by MessageLabs.
>>
>>
>> *
>>
>> You can find us at www.voca.com
>>
>> *
>> This communication is confidential and intended for the exclusive use
>> of the addressee only. You should not disclose its contents to any
>> other person.
>> If you are not the intended recipient please notify the sender named
>> above immediately.
>>
>> Registered in England, No 1023742,
>> Registered Office: Voca Limited
>> Drake House, Three Rivers Court,
>> Homestead Road, Rickmansworth,
>> Hertfordshire, WD3 1FX. United Kingdom
>>
>> VAT No. 226 6112 87
>>
>>
>> This message has been checked for all email viruses by MessageLabs.
>>
>> -
>> 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]
>
>
> This message has been checked for all email viruses by MessageLabs.
>
> This message has been checked for all email viruses by MessageLabs.
>
> -
> 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]

Hi Jeremy


I'm giving the tss demo distribution module you created a spin...

I checked it out and along came all of the svn external dependencies
I did a mvn install at the top level and got a clean build
I took the zip that was generated in the demo project and unzipped it (I
just guessed that this was what was required)

It doesn't run stright off though as there are a number of dependencies
missing from the various directories. I'm working my way through them now,
e.g I'm adding the following to the boot directory of the master profile
 tuscany-jms-discovery-0.1-incubating-SNAPSHOT.jar
 the open MQ jar (some of the base jms classes are required and this was
the first place I found them)
 tuscany-http-jetty-0.1-incubating-SNAPSHOT.jar
 jetty and jetty util jars
 tuscany-sca-console-0.1-incubating-S

Re: Tag for TSSS demo code

[Simon Laws]

On 3/26/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Simon,

Did you start ActiveMQ before you started the master?

Ta
Meeraj


>From: "Simon Laws" <[EMAIL PROTECTED]>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Tag for TSSS demo code
>Date: Mon, 26 Mar 2007 17:35:24 +0100
>
>On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>>
>>I've created a tag corresponding to the code used to build the demo
>>(r520715) and added a trivial pom to build the lot. To build:
>>$ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/
>>java/tsss-demo
>>$ mvn install
>>
>>I did not change the versions in the poms so they are using the same
>>ones as trunk. To avoid conflict in the snapshot repo we should not
>>deploy jars built from this.
>>
>>--
>>Jeremy
>>
>>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:
>>
>> > Jeremy,
>> >
>> > This is the definitve list, thanks to Mario.
>> >
>> > java/spec/commonj/
>> > java/spec/sca-api-r1.0/
>> > java/sca/kernel/
>> > java/sca/runtime/
>> > java/sca/services/
>> > java/sca/contrib/discovery/
>> > java/sca/contrib/discovery/jms
>> > java/sca/console/
>> > java/sca/core-samples/
>> > java/distribution/sca/demo.app
>> > java/distribution/sca/demo/
>> >
>> > Ta
>> > Meeraj
>> >
>> > -Original Message-
>> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
>> > Sent: Thursday, March 22, 2007 1:52 PM
>> > To: tuscany-dev@ws.apache.org
>> > Subject: Re: Compilation status
>> >
>> > I think we should tag and deploy SNAPSHOTs of the revision used for
>> > the
>> > demo - that way people can build as much or as little as they wish.
If
>> > you can post the list, I get those modules tagged and deployed later
>> > today.
>> >
>> > --
>> > Jeremy
>> >
>> > On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:
>> >
>> >> Mario,
>> >>
>> >> AFAIK extensions in trunk is still in a bit of a flux. If you want
to
>> >> run the demo, you don't need to run the extensions (the demo uses
>> >> Java
>> >
>> >> container with local bindings), I will try to post a dfeinitive list
>> >> of tasks to build and run the demo later in the day, which will be
>> >> useful to Simon as well.
>> >>
>> >> Ta
>> >> Meeraj
>> >>
>> >> -Original Message-
>> >> From: Antollini, Mario [mailto:[EMAIL PROTECTED]
>> >> Sent: Thursday, March 22, 2007 12:29 PM
>> >> To: tuscany-dev@ws.apache.org
>> >> Subject: Compilation status
>> >>
>> >> Meeraj,
>> >>
>> >>
>> >>
>> >> I just wanted you to know that I am still not able to compile the
>> >> code
>> >
>> >> I checked out from SVN. The main problem is located in the
>> >> *extensions* project. I have been modifying the pom files within
this
>> >> project but I did not manage to get it compiled yet.
>> >>
>> >>
>> >>
>> >> Basically, the main problems are related to inconsistencies between
>> >> parent references (e.g.; axis2's root project is using groupId
>> >> *org.apache.tuscany.sca.axis2* while the plugin subproject states
>> >> that
>> >
>> >> its parent is *org.apache.tuscany.sca.extensions.axis2*).
>> >>
>> >>
>> >>
>> >> Any tips about this?
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Mario
>> >>
>> >>
>> >> This message has been checked for all email viruses by MessageLabs.
>> >>
>> >>
>> >> *
>> >>
>> >> You can find us at www.voca.com
>> >>
>> >> *
>> >> This communication is confidential and intended for the exclusive
use
>> >> of the addressee only. You should not disclose its contents to any
>> >> other person.
>> >> If you are not the intended recipient please notify the sender named
>> >> above immediately.
>> >>
>> >> Registered in En

Re: Tag for TSSS demo code

[Simon Laws]

On 3/26/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 3/26/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>
> Simon,
>
> Did you start ActiveMQ before you started the master?
>
> Ta
> Meeraj
>
>
> >From: "Simon Laws" <[EMAIL PROTECTED]>
> >Reply-To: tuscany-dev@ws.apache.org
> >To: tuscany-dev@ws.apache.org
> >Subject: Re: Tag for TSSS demo code
> >Date: Mon, 26 Mar 2007 17:35:24 +0100
> >
> >On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >>
> >>I've created a tag corresponding to the code used to build the demo
> >>(r520715) and added a trivial pom to build the lot. To build:
> >>$ svn co https://svn.apache.org/repos/asf/incubator/tuscany/tags/
> >>java/tsss-demo
> >>$ mvn install
> >>
> >>I did not change the versions in the poms so they are using the same
> >>ones as trunk. To avoid conflict in the snapshot repo we should not
> >>deploy jars built from this.
> >>
> >>--
> >>Jeremy
> >>
> >>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:
> >>
> >> > Jeremy,
> >> >
> >> > This is the definitve list, thanks to Mario.
> >> >
> >> > java/spec/commonj/
> >> > java/spec/sca-api-r1.0/
> >> > java/sca/kernel/
> >> > java/sca/runtime/
> >> > java/sca/services/
> >> > java/sca/contrib/discovery/
> >> > java/sca/contrib/discovery/jms
> >> > java/sca/console/
> >> > java/sca/core-samples/
> >> > java/distribution/sca/demo.app
> >> > java/distribution/sca/demo/
> >> >
> >> > Ta
> >> > Meeraj
> >> >
> >> > -Original Message-
> >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> >> > Sent: Thursday, March 22, 2007 1:52 PM
> >> > To: tuscany-dev@ws.apache.org
> >> > Subject: Re: Compilation status
> >> >
> >> > I think we should tag and deploy SNAPSHOTs of the revision used for
>
> >> > the
> >> > demo - that way people can build as much or as little as they wish.
> If
> >> > you can post the list, I get those modules tagged and deployed
> later
> >> > today.
> >> >
> >> > --
> >> > Jeremy
> >> >
> >> > On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:
> >> >
> >> >> Mario,
> >> >>
> >> >> AFAIK extensions in trunk is still in a bit of a flux. If you want
> to
> >> >> run the demo, you don't need to run the extensions (the demo uses
> >> >> Java
> >> >
> >> >> container with local bindings), I will try to post a dfeinitive
> list
> >> >> of tasks to build and run the demo later in the day, which will be
> >> >> useful to Simon as well.
> >> >>
> >> >> Ta
> >> >> Meeraj
> >> >>
> >> >> -Original Message-
> >> >> From: Antollini, Mario [mailto:[EMAIL PROTECTED]
> >> >> Sent: Thursday, March 22, 2007 12:29 PM
> >> >> To: tuscany-dev@ws.apache.org
> >> >> Subject: Compilation status
> >> >>
> >> >> Meeraj,
> >> >>
> >> >>
> >> >>
> >> >> I just wanted you to know that I am still not able to compile the
> >> >> code
> >> >
> >> >> I checked out from SVN. The main problem is located in the
> >> >> *extensions* project. I have been modifying the pom files within
> this
> >> >> project but I did not manage to get it compiled yet.
> >> >>
> >> >>
> >> >>
> >> >> Basically, the main problems are related to inconsistencies
> between
> >> >> parent references (e.g.; axis2's root project is using groupId
> >> >> *org.apache.tuscany.sca.axis2* while the plugin subproject states
> >> >> that
> >> >
> >> >> its parent is *org.apache.tuscany.sca.extensions.axis2*).
> >> >>
> >> >>
> >> >>
> >> >> Any tips about this?
> >> >>
> >> >>
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Mario
> >> >>
> >> >>
> >> >> This

Re: [VOTE] Adopt a near-zero-tolerance "Be Nice" policy

[Simon Laws]

On 3/26/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:


Touché :)

On 3/26/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> +1, and here's a first test case of saying what I "really think". I hope
> nobody is going to "slam" me :-)
>
> I think Ant's suggestion should go without saying. The fact that we need
> to have a vote as juvenile as this one, makes it hard for any of us to
> "maintain our dignity".
>
> Frank.
>
>
> "kelvin goodson" <[EMAIL PROTECTED]> wrote on 03/26/2007 02:38:51
> PM:
>
> > +1
> >
> > On 26/03/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > I'd like to have a near-zero-tolerance "Be Nice" policy on the
Tuscany
> > > mailing lists where we don't allow participants to slam anyone's
> posts.
> > > When
> > > replying to email we need to do it in a way that maintains the
> original
> > > authors dignity.
> > >
> > > We've some tough things to work out over the next days and we're
only
> > > going
> > > to achieve any real consensus if we all feel the environment allows
us
> to
> > > say what we really think.
> > >
> > > I'd really like to see everyone vote on this, surely if nothing else
> this
> > > is
> > > something we can all agree on?
> > >
> > > Here's my +1.
> > >
> > >...ant
> > >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

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

+1

Re: Tag for TSSS demo code

[Simon Laws]

On 3/26/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:


Simon,

I had had the same problem than you. I solved it starting ActiveMQ
first.

The final steps are:

1 - Donwload ActiveMQ:
http://people.apache.org/repo/m2-incubating-repository/org/apache/active
mq/apache-activemq/4.1.0-incubator/apache-activemq-4.1.0-incubator.zip
2 - uncompress it somewhere and start it (...\bin\ activemq.bat)
3 - compile the TSSS demo
4 -  uncompress
...\tuscany\java\distribution\sca\demo\target\demo-2.0-alpha2-incubating
-SNAPSHOT-bin.zip
5 - go to the bin directory of the uncompressed file and run "java
-Dtuscany.adminPort=2000 -jra start.server.jar master"

Mario

-Original Message-----
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Monday, March 26, 2007 2:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tag for TSSS demo code

On 3/26/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> On 3/26/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
> >
> > Simon,
> >
> > Did you start ActiveMQ before you started the master?
> >
> > Ta
> > Meeraj
> >
> >
> > >From: "Simon Laws" <[EMAIL PROTECTED]>
> > >Reply-To: tuscany-dev@ws.apache.org
> > >To: tuscany-dev@ws.apache.org
> > >Subject: Re: Tag for TSSS demo code
> > >Date: Mon, 26 Mar 2007 17:35:24 +0100
> > >
> > >On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> > >>
> > >>I've created a tag corresponding to the code used to build the
demo
> > >>(r520715) and added a trivial pom to build the lot. To build:
> > >>$ svn co
https://svn.apache.org/repos/asf/incubator/tuscany/tags/
> > >>java/tsss-demo
> > >>$ mvn install
> > >>
> > >>I did not change the versions in the poms so they are using the
same
> > >>ones as trunk. To avoid conflict in the snapshot repo we should
not
> > >>deploy jars built from this.
> > >>
> > >>--
> > >>Jeremy
> > >>
> > >>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:
> > >>
> > >> > Jeremy,
> > >> >
> > >> > This is the definitve list, thanks to Mario.
> > >> >
> > >> > java/spec/commonj/
> > >> > java/spec/sca-api-r1.0/
> > >> > java/sca/kernel/
> > >> > java/sca/runtime/
> > >> > java/sca/services/
> > >> > java/sca/contrib/discovery/
> > >> > java/sca/contrib/discovery/jms
> > >> > java/sca/console/
> > >> > java/sca/core-samples/
> > >> > java/distribution/sca/demo.app
> > >> > java/distribution/sca/demo/
> > >> >
> > >> > Ta
> > >> > Meeraj
> > >> >
> > >> > -Original Message-
> > >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
> > >> > Sent: Thursday, March 22, 2007 1:52 PM
> > >> > To: tuscany-dev@ws.apache.org
> > >> > Subject: Re: Compilation status
> > >> >
> > >> > I think we should tag and deploy SNAPSHOTs of the revision used
for
> >
> > >> > the
> > >> > demo - that way people can build as much or as little as they
wish.
> > If
> > >> > you can post the list, I get those modules tagged and deployed
> > later
> > >> > today.
> > >> >
> > >> > --
> > >> > Jeremy
> > >> >
> > >> > On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:
> > >> >
> > >> >> Mario,
> > >> >>
> > >> >> AFAIK extensions in trunk is still in a bit of a flux. If you
want
> > to
> > >> >> run the demo, you don't need to run the extensions (the demo
uses
> > >> >> Java
> > >> >
> > >> >> container with local bindings), I will try to post a
dfeinitive
> > list
> > >> >> of tasks to build and run the demo later in the day, which
will be
> > >> >> useful to Simon as well.
> > >> >>
> > >> >> Ta
> > >> >> Meeraj
> > >> >>
> > >> >> -Original Message-
> > >> >> From: Antollini, Mario [mailto:[EMAIL PROTECTED]
> > >> >> Sent: Thursday, March 22, 2007 12:29 PM
> > >> >> To: tuscany-dev@ws.apache.org
> > >> >> Subject: Compilation status
> > >> >>
> >

Re: [Discussion] Tuscany kernel modulization

[Simon Laws]

On 3/26/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

By reading through a bunch of e-mails on this mailing list and adding my
imagination, I put together a conceptual diagram at the following wiki
page
to illustrate the kernel modulization.


http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions

This diagram is merely for the discussion purpose and it only reflects my
understandings so far. By no means it is meant to be complete and
accurate.
But I hope we can use it as the starting point for the technical
discussion.

Going through this exercise, I start to see values of the efforts which
would lead to greater adoption of Tuscany/SCA by various embedders
including
other Apache projects and simplication of the kernel that the community
can
work together. You might take the following items as my crazy
brainstorming:

1) Allow different ways to populate the assembly model: from SCDL, from
other Domain Specific Languages (DSL) or even from another model such as
the
Spring context. On the hand, make it possible to convert the SCA assembly
model to be executed by other frameworks such as Spring.

2) Improve the federation story so that we can plugin different federation
mechanisms, such as P2P discovery-based or repository-based schemes.

3) Bootstrap the Tuscany kernel without the Java container in case that
either the hosting runtime is resource-constrained (for example, cellular
phones or network appliances) or it doesn't need to the support for POJO
(for example, scripting for Web 2.0).

4) Provide more flexibility to integrate with different hosting
environments
with a subset of kernel modules.
...

I guess I throw out enough seeds for thoughts and now it's your turn :-).

Thanks,
Raymond



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

Simple question to start Raymond. Can you give a quick runtime on the

colour coding. I see that the colours group realted items but some of the
groups I'm not sure about. Is it intended to related the modules to what is
in the kernel now?

Simon

Re: Tag for TSSS demo code

[Simon Laws]

On 3/27/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Sorry for late replies Simon, I am offsite in India for the next two
weeks.

Regarding the SCDL, there was a post earlier in the list with the SCDL
(from
me). You can use the calculator scdl in core-samples and remove the client
component, also each component needs to be targeted with a runtimeId
attribute. Obviously, you will have to start the targeted node on a
different JMX port, before you deploy the SCDL.

On the execption, IIRC, you can register a formatter that will print the
required information.

HTH
Meeraj


>From: "Simon Laws" <[EMAIL PROTECTED]>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Tag for TSSS demo code
>Date: Mon, 26 Mar 2007 22:54:43 +0100
>
>On 3/26/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:
>>
>>Simon,
>>
>>I had had the same problem than you. I solved it starting ActiveMQ
>>first.
>>
>>The final steps are:
>>
>>1 - Donwload ActiveMQ:
>>http://people.apache.org/repo/m2-incubating-repository/org/apache/active
>>mq/apache-activemq/4.1.0-incubator/apache-activemq-4.1.0-incubator.zip
>>2 - uncompress it somewhere and start it (...\bin\ activemq.bat)
>>3 - compile the TSSS demo
>>4 -  uncompress
>>...\tuscany\java\distribution\sca\demo\target\demo-2.0-alpha2-incubating
>>-SNAPSHOT-bin.zip
>>5 - go to the bin directory of the uncompressed file and run "java
>>-Dtuscany.adminPort=2000 -jra start.server.jar master"
>>
>>Mario
>>
>>-Original Message-
>>From: Simon Laws [mailto:[EMAIL PROTECTED]
>>Sent: Monday, March 26, 2007 2:41 PM
>>To: tuscany-dev@ws.apache.org
>>Subject: Re: Tag for TSSS demo code
>>
>>On 3/26/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 3/26/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Simon,
>> > >
>> > > Did you start ActiveMQ before you started the master?
>> > >
>> > > Ta
>> > > Meeraj
>> > >
>> > >
>> > > >From: "Simon Laws" <[EMAIL PROTECTED]>
>> > > >Reply-To: tuscany-dev@ws.apache.org
>> > > >To: tuscany-dev@ws.apache.org
>> > > >Subject: Re: Tag for TSSS demo code
>> > > >Date: Mon, 26 Mar 2007 17:35:24 +0100
>> > > >
>> > > >On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>> > > >>
>> > > >>I've created a tag corresponding to the code used to build the
>>demo
>> > > >>(r520715) and added a trivial pom to build the lot. To build:
>> > > >>$ svn co
>>https://svn.apache.org/repos/asf/incubator/tuscany/tags/
>> > > >>java/tsss-demo
>> > > >>$ mvn install
>> > > >>
>> > > >>I did not change the versions in the poms so they are using the
>>same
>> > > >>ones as trunk. To avoid conflict in the snapshot repo we should
>>not
>> > > >>deploy jars built from this.
>> > > >>
>> > > >>--
>> > > >>Jeremy
>> > > >>
>> > > >>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:
>> > > >>
>> > > >> > Jeremy,
>> > > >> >
>> > > >> > This is the definitve list, thanks to Mario.
>> > > >> >
>> > > >> > java/spec/commonj/
>> > > >> > java/spec/sca-api-r1.0/
>> > > >> > java/sca/kernel/
>> > > >> > java/sca/runtime/
>> > > >> > java/sca/services/
>> > > >> > java/sca/contrib/discovery/
>> > > >> > java/sca/contrib/discovery/jms
>> > > >> > java/sca/console/
>> > > >> > java/sca/core-samples/
>> > > >> > java/distribution/sca/demo.app
>> > > >> > java/distribution/sca/demo/
>> > > >> >
>> > > >> > Ta
>> > > >> > Meeraj
>> > > >> >
>> > > >> > -Original Message-
>> > > >> > From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
>> > > >> > Sent: Thursday, March 22, 2007 1:52 PM
>> > > >> > To: tuscany-dev@ws.apache.org
>> > > >> > Subject: Re: Compilation status
>> > > >> >
>> 

Re: Tag for TSSS demo code

[Simon Laws]

On 3/27/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 3/27/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>
> Sorry for late replies Simon, I am offsite in India for the next two
> weeks.
>
> Regarding the SCDL, there was a post earlier in the list with the SCDL
> (from
> me). You can use the calculator scdl in core-samples and remove the
> client
> component, also each component needs to be targeted with a runtimeId
> attribute. Obviously, you will have to start the targeted node on a
> different JMX port, before you deploy the SCDL.
>
> On the execption, IIRC, you can register a formatter that will print the
>
> required information.
>
> HTH
> Meeraj
>
>
> >From: "Simon Laws" <[EMAIL PROTECTED]>
> >Reply-To: tuscany-dev@ws.apache.org
> >To: tuscany-dev@ws.apache.org
> >Subject: Re: Tag for TSSS demo code
> >Date: Mon, 26 Mar 2007 22:54:43 +0100
> >
> >On 3/26/07, Antollini, Mario < [EMAIL PROTECTED]> wrote:
> >>
> >>Simon,
> >>
> >>I had had the same problem than you. I solved it starting ActiveMQ
> >>first.
> >>
> >>The final steps are:
> >>
> >>1 - Donwload ActiveMQ:
> >>http://people.apache.org/repo/m2-incubating-repository/org/apache/active
>
> >>mq/apache-activemq/4.1.0-incubator/apache-activemq-4.1.0-incubator.zip
> >>2 - uncompress it somewhere and start it (...\bin\ activemq.bat)
> >>3 - compile the TSSS demo
> >>4 -  uncompress
> >>...\tuscany\java\distribution\sca\demo\target\demo-
> 2.0-alpha2-incubating
> >>-SNAPSHOT-bin.zip
> >>5 - go to the bin directory of the uncompressed file and run "java
> >>-Dtuscany.adminPort=2000 -jra start.server.jar master"
> >>
> >>Mario
> >>
> >>-Original Message-
> >>From: Simon Laws [mailto:[EMAIL PROTECTED] ]
> >>Sent: Monday, March 26, 2007 2:41 PM
> >>To: tuscany-dev@ws.apache.org
> >>Subject: Re: Tag for TSSS demo code
> >>
> >>On 3/26/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> >
> >> > On 3/26/07, Meeraj Kunnumpurath < [EMAIL PROTECTED]>
> wrote:
> >> > >
> >> > > Simon,
> >> > >
> >> > > Did you start ActiveMQ before you started the master?
> >> > >
> >> > > Ta
> >> > > Meeraj
> >> > >
> >> > >
> >> > > >From: "Simon Laws" <[EMAIL PROTECTED]>
> >> > > >Reply-To: tuscany-dev@ws.apache.org
> >> > > >To: tuscany-dev@ws.apache.org
> >> > > >Subject: Re: Tag for TSSS demo code
> >> > > >Date: Mon, 26 Mar 2007 17:35:24 +0100
> >> > > >
> >> > > >On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >> > > >>
> >> > > >>I've created a tag corresponding to the code used to build the
> >>demo
> >> > > >>(r520715) and added a trivial pom to build the lot. To build:
> >> > > >>$ svn co
> >>https://svn.apache.org/repos/asf/incubator/tuscany/tags/
> >> > > >>java/tsss-demo
> >> > > >>$ mvn install
> >> > > >>
> >> > > >>I did not change the versions in the poms so they are using the
> >>same
> >> > > >>ones as trunk. To avoid conflict in the snapshot repo we should
>
> >>not
> >> > > >>deploy jars built from this.
> >> > > >>
> >> > > >>--
> >> > > >>Jeremy
> >> > > >>
> >> > > >>On Mar 22, 2007, at 7:39 AM, Meeraj Kunnumpurath wrote:
> >> > > >>
> >> > > >> > Jeremy,
> >> > > >> >
> >> > > >> > This is the definitve list, thanks to Mario.
> >> > > >> >
> >> > > >> > java/spec/commonj/
> >> > > >> > java/spec/sca-api-r1.0/
> >> > > >> > java/sca/kernel/
> >> > > >> > java/sca/runtime/
> >> > > >> > java/sca/services/
> >> > > >> > java/sca/contrib/discovery/
> >> > > >> > java/sca/contrib/discovery/jms
> >> > > >> > java/sca/console/
> >> > > >> > java/sca/core-samples/
> >> > > >> >

Re: Discovery update

[Simon Laws]

On 3/27/07, Antollini, Mario <[EMAIL PROTECTED]> wrote:


Meeraj,

I finally got JXTA working! The problem was that the message being sent
was null...

In JxtaDiscoverService.java the code for sending the message was:

public int sendMessage(final String runtimeId, final XMLStreamReader
content) throws DiscoveryException {

if(content == null) {
throw new IllegalArgumentException("Content id is null");
}

PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException("Unrecognized runtime " +
runtimeId);
}
}

String message = null;
try {
StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}



So, note that the StaxUtil.serialize(content) method is not assigning
the returned value to the message.

Besides that, remember that when you try to contribute the SCDL (via the
browser), there is an exception since it is trying to send the message
to the peer called "slave" and there is not such peer in the network.
Therefore, I did another modification to the sendMessage method in order
to send the message to all the peers (just to see if it works). So, the
working piece of code is:


public int sendMessage(String runtimeId, final XMLStreamReader content)
throws DiscoveryException {

runtimeId = null;

if(content == null) {
throw new IllegalArgumentException("Content id is null");
}

PeerID peerID = null;
if(runtimeId != null) {
peerID = peerListener.getPeerId(runtimeId);
if(peerID == null) {
throw new DiscoveryException("Unrecognized runtime " +
runtimeId);
}
}

String message = null;
try {
message = StaxUtil.serialize(content);
} catch(XMLStreamException ex) {
throw new DiscoveryException(ex);
}



Note that I removed the final keyword to the runtimeId parameter in
order to turn it to null in the first statement of the method (to allow
broadcast of the message).
In addition to that I just modified "StaxUtil.serialize(content);" for
" message = StaxUtil.serialize(content);"

And that is all I did and after pressing the "Contribute SCDL" button, I
saw in both slaves' console window a system.out I added to the
processQuery(ResolverQueryMsg queryMessage) method in
TuscanyQueryHandler.java.

So, now it is important to know why the runtimeId arrives with a value
equal to "slave". I had already tried to figure it out and sent you an
email, remember? I am copying it here just in case:


Now, I was trying to understand where the target name comes wrong from
and I think the problem could be that the AssemblyServiceImpl class is
setting the wrong id in the include method:
.
// create physical wire definitions
for (ComponentDefinition child :
type.getDeclaredComponents().values()) {
  URI id = child.getRuntimeId()
.

Since, it finally invokes the marshallAndSend(id, context), which in
turn invokes the
discoveryService.sendMessage(id.toASCIIString(), pcsReader) method,
which ends up in an invocation to  JxtaDiscoveryService.sendMessage(...)
with the wrong runtimeId (i.e.; slave)

So, as you can see, it seems that the problem comes from some place
outside of the scope of JXTA and I am not experienced enough to deal
with such issue. Do you have any idea where the "slave" id is being
wrongly set?


Ok, I hope it is all useful and if you need any further help, please do
not hesitate to contact me.

Best regards,
Mario



-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 25, 2007 5:52 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Discovery update

Thanks Mario. If you have any more queries, pls post to the list.

Ta
Meerj


>From: "Antollini, Mario" <[EMAIL PROTECTED]>
>Reply-To: tuscany-dev@ws.apache.org
>To: 
>Subject: RE: Discovery update
>Date: Sun, 25 Mar 2007 07:53:39 -0700
>
>Meeraj,
>
>You were right, it is not working yet. I am still struggling with it.
>I'll come back to you as soon as I have any news about it.
>
>Regards,
>Mario
>
>-Original Message-
>From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
>Sent: Friday, March 23, 2007 8:16 PM
>To: tuscany-dev@ws.apache.org
>Subject: RE: Discovery update
>
>Mario,
>
>By hard-coding the runtime id of the target peer, did the message
>actually reached the intended peer? i.e. did you see any log messages
on
>the console widow of slave1 or slave2?
>
>Thanks
>Meeraj
>
> >> -Original Message-
> >> From: Antollini, Mario [mailto:[EMAIL PROTECTED]
> >> Sent: 23 March 2007 21:02
> >> To: tuscany-dev@ws.apache.org
> >> Subject: RE: Discovery update
> >>
> >> Meeraj,
> >>
> >> I got the JXTA working for sending messages. However, what I
> >> d

Re: Merge improved databinding code into trunk

[Simon Laws]

On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I'll go ahead to commit the last piece which integrates the databinding
framework with the latest core if there are no other concerns.

The new picture will be:

kernel/core: will depend on databinding-framework (the dependency would be
removed as the core is further decomposed)
services/databinding/databinding-framework: Databinding SPIs and built-in
transformers for XML
kernel/databinding: Databinding related WirePostProcessors and Inteceptors

Thanks,
Raymond

- Original Message -
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: 
Sent: Friday, March 16, 2007 10:38 PM
Subject: Merge improved databinding code into trunk


> Hi,
>
> As you might have noticed on the ML, I have improved the databinding
code
> in the sca-java-integration branch over time. I would like to merge the
> changes back to the trunk and bring up the databinding support again in
> the trunk.
>
> Here is the summary of the improvements:
>
> 1. Minimize the usage of @DataType by agressively introspecting the java
> classes
>
> 2. Data transformation for business exceptions
>
> 3. Add copy() support for JAXB and AXIOM
>
> 4. More databindings and transformers such as:
>   * JSON databinding
>   * SDO --> AXIOM using OMDataSource
>   * JavaBean --> XMLStreamReader
>
> 5. More unit and integration test cases for better coverage
>
> To avoid the disruption, I'll stage them as follows:
> 1) Add a "databinding-framework" module under
> "java/sca/services/databinding" to hold the updated code in spi and
core.
> 2) Update individual databindings
> 3) Integrate the databinding pieces with the latest core
>
> Thanks,
> Raymond
>


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

Hi


If you are updating Databinding funtionality in the trunk I would like to
copy the databinding itests from the integration branch into the trunk. We
can use the itests to test the updated databinding functionality. Also gives
us a chance to shake down the tests a little more. Does that sound OK to
everyone?

Regards

Simon

Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together

[Simon Laws]

On 3/29/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:


If I understand your clarification correctly, this vote is about putting
out
a single release with a certain number of modules in it, and with each
module having the same version number. In particular, this vote does
not set a cast-in-stone precedent about how future releases will be put
together. Also, it is assumed that consensus will eventually be able to
be reached about what the modules in the release will be (without this
assumption, this vote seems pointless to me).

While it is not clear to me that this is the best approach to follow from
an open source project point of view, with the constraints and assump-
tions above it seems to me to be reasonably safe to vote +1.

So, if the constraints and assumptions above are true, then here's
my +1.

Thanks

On 3/29/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> I wasn't clear enough when starting this vote, let me try to fix that:
>
> I intended this vote to *be* the short term reality, I.e. about getting
a
> release out from trunk with everyone contributing.
>
> It may well be right that a single module version doesn't scale, in the
> longer term maybe we need to adopt one the many proposals that has been
> made
> on this subject. We can revisit all this once we've managed to get the
> next
> release out.
>
> The specifics of what extensions are included in this release is left
out
> of
> this vote and can be decided in the release plan discussion. All this
vote
> is saying is that all the modules that are to be included in this next
> release will have the same version and that a top level pom.xml will
exist
> to enable building all those modules at once. We don't have so many
> extensions planed for the next release so i think this will scale ok for

> now.
>
> Does that help at all? Would anyone more vote for this now?
>
> If there isn't a reasonably large majority one way or the other I'm fine
> with forgetting this vote and going back to the drawing board for a
> different approach. I'd really prefer not to have to do that though as
we
> need to start finding some ways to make progress, so lets keep this
going
> till tomorrow to see how the votes look then.
>
>   ...ant
>
> On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >
> > Hi, Bert.
> >
> > I think I'm with you on the proposal. The rule of the game should be
> very
> > simple as follows:
> >
> > Let's agree on a set of modules that are supposed to work together for
> the
> > next target (a release or a demo), then define an assembly and
pom.xmlto
> > enforce the cohesions.
> >
> > Thanks,
> > Raymond
> >
> > - Original Message -
> > From: "Bert Lamb" < [EMAIL PROTECTED]>
> > To: 
> > Sent: Wednesday, March 28, 2007 1:28 PM
> > Subject: Re: [VOTE] Use single version for all Java/SCA modules and
> enable
> > building all modules together
> >
> >
> > > Would something like what I outlined in this email[1] be more
amenable
> > > to people voting against this proposal?
> > >
> > > -Bert
> > >
> > > [1]
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html
> > >
> > > On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]>
wrote:
> > >> I have expressed my views on all modules sharing the same version
and
> a
> > >> top
> > >> down build in quite a bit of detail in my previous emails on the
same
> > >> subject. Unfortunately, I will have to vote -1 on this.
> > >>
> > >> Meeraj
> > >>
> > >>
> > >> >From: Jim Marino <[EMAIL PROTECTED]>
> > >> >Reply-To: tuscany-dev@ws.apache.org
> > >> >To: tuscany-dev@ws.apache.org
> > >> >Subject: Re: [VOTE] Use single version for all Java/SCA modules
and
> > >> >enable
> > >> >building all modules together
> > >> >Date: Wed, 28 Mar 2007 12:19:53 -0700
> > >> >
> > >> >
> > >> >On Mar 28, 2007, at 12:51 AM, ant elder wrote:
> > >> >
> > >> >>Here's the vote on this I said [1] I'd start to get closure on
this
> > >> >>issue.
> > >> >>
> > >> >>The proposal is to have top-level pom for the Java SCA project
that
> > >> >>enables
> > >> >>building all the modules together - kernel, services, runtimes,
> > >> >>extensions
> > >> >>etc, and for that to work all those modules need to use the same
> > >> >>version
> > >> >>name.
> > >> >>
> > >> >>Here's my +1.
> > >> >>
> > >> >>   ...ant
> > >> >>
> > >> >>[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >>msg16024.html
> > >> >
> > >> >
> > >> >
> > >> >There has been no proposal for how to resolve the issue
> > about  building
> > >> >extensions using multiple versions of kernel and how modules  on
> > >> >different
> > >> >release schedules requiring different levels of kernel  or plugins
> > will
> > >> >be
> > >> >handled.
> > >> >
> > >> >Until we can come up with a solution for these issues, I feel I
> > have  to
> > >> >vote against the proposal.
> > >> >
> > >> >-1
> > >> >
> > >> >Jim
> > >> >
> > >>
> >-
> > >> >To unsubscribe, e-mail: [EMAIL P

Re: [VOTE] Adriano Crestani for Tuscany Committer

[Simon Laws]

On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


+1 from me.

Thanks,
Raymond

- Original Message -
From: "Luciano Resende" <[EMAIL PROTECTED]>
To: "tuscany-dev" 
Sent: Tuesday, March 27, 2007 11:37 AM
Subject: [VOTE] Adriano Crestani for Tuscany Committer


> I'd like to nominate Adriano Crestani to become a Tuscany committer.
>
> Adriano started by helping on Java DAS, and recently is contributing a
new
> DAS C++ Implementation, he has also participated in discussions and is
> helping expand the Tuscany community around his college campus in
Brazil.
> He's contributing to Tuscany for several months now, and I think he is
> going
> to be a great addition not only for the Tuscany DAS community, but for
the
> Tuscany community in general.
>
> Here is my +1
>
> --
> Luciano Resende
> http://people.apache.org/~lresende 
>


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



Lots of work has gone into the DAS implementation. Nice one Adriano. +1 from
me and welcome.

Simon

Re: Unpack issues with Tuscany

[Simon Laws]

On 3/29/07, Brian Fox <[EMAIL PROTECTED]> wrote:


Hi,
I'm one of the Maven developers next-door at apache and the main
developer for the maven-dependency-plugin. We've had a few requests
recently from Tuscany users who have problems with the instructions or
with the pom. (I haven't found the instructions yet so I can't be
positive) You can see this thread for more info:
http://www.nabble.com/mvn-dependency%3Aunpack-tf3436260s177.html#a9580702

It seems that the instructions indicate to run "mvn
dependency:unpack", however the POM isn't setup correctly to do this.
I recently added a FAQ to the site as well as more examples for this
use case here:
http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#question

I figured I'd pop in to see if we can try to get this fixed up so the
users don't have a bad experience both with Tuscany and Maven. Let me
know if there's anything I can do to help.

-Brian

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

Hi Brian, Thanks for dropping by. I worked with Muhwas to get him a work

around so he could get our M2 tests running. I couldn't get the Tuscany M2
samples to work either following the instructions as documented in the
readme. It specifically says to do  "mvn dependecy:unpack" but I can't find
anywhere that the maven-dependency-plugin is configured in the pom hierarchy
for our M2 release. What is the intended behaviour if you do "mvn
dependecy:unpack" against a pom with no maven-dependency-plugin
configuration? Should it do anything sensible.

I wasn't very close to the M2 release but I know people tried the samples
before cutting the tag so something strange is going on. Anyhow I suspect
that it's a Tuscany problem and not a Maven problem but it needs more
investigation. If nothing else we need to fix our documentation!

Thanks again for posting this.

Simon

Re: Tuscany Unpack issues

[Simon Laws]

On 3/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi, Brian.

It's so nice of you to remind us. IIRC, the original problem was due to
the
newer versions of the maven-dependency-plugin as we referenced the
SNAPSHOT
version of the plugin in M2 driver. I think we have fixed the wrong
configuration in the latest code but I'll double-check.

BTW, do you know if there is a way in the pom.xml to use LATEST RELEASED
plugin? Maven takes the latest SNAPSHOTs if the version is not explicitly
specified. As we know, it's very risky for a release to depend on
SNAPSHOTs.

Thanks,
Raymond


- Original Message -
From: "Brian Fox" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, March 29, 2007 4:31 PM
Subject: Tuscany Unpack issues


> Hi,
> I'm one of the Maven developers next-door at apache and the main
> developer for the maven-dependency-plugin. We've had a few requests
> recently from Tuscany users who have problems with the instructions or
> with the pom. (I haven't found the instructions yet so I can't be
> positive) You can see this thread for more info:
>
http://www.nabble.com/mvn-dependency%3Aunpack-tf3436260s177.html#a9580702
>
> It seems that the instructions indicate to run "mvn
> dependency:unpack", however the POM isn't setup correctly to do this.
> I recently added a FAQ to the site as well as more examples for this
> use case here:
>
http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#question
>
> I figured I'd pop in to see if we can try to get this fixed up so the
> users don't have a bad experience both with Tuscany and Maven. Let me
> know if there's anything I can do to help.
>
> -Brian
>
> -
> 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]

Hi Raymond, snap. I just replied on the other thread. So what you are

saying is that it means that  our M2 poms are effectively wrong now. So we
need to do a point release to fix it or document a work round on the
download page I guess. We should probably put a note up on the download page
now anyhow. Want me to go do that.

Regards

Simon

Re: Unpack issues with Tuscany

[Simon Laws]

On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:


Simon,
The dependency:unpack and copy goals are intended to be used by binding
to a phase in the pom. They use custom objects (ArtifactItems) that
can't be defined on the CLI. If you want to run it from the CLI, you
have to first add the configuration to the pom as described on the link
I sent below.

Another alternative that doesn't require pom config would be
unpack-dependencies but that will grab all dependencies...there are some
flags that could be used to filter them that are doc'd on the plugin
page.

Based on what it looks like you're doing, you want unpack but just need
to put the config in the pom. Alternatively, you could add it to the
build and make it happen for the user automatically.

-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Friday, March 30, 2007 12:03 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Unpack issues with Tuscany

On 3/29/07, Brian Fox <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I'm one of the Maven developers next-door at apache and the main
> developer for the maven-dependency-plugin. We've had a few requests
> recently from Tuscany users who have problems with the instructions or

> with the pom. (I haven't found the instructions yet so I can't be
> positive) You can see this thread for more info:
> http://www.nabble.com/mvn-dependency%3Aunpack-tf3436260s177.html#a9580
> 702
>
> It seems that the instructions indicate to run "mvn
> dependency:unpack", however the POM isn't setup correctly to do this.
> I recently added a FAQ to the site as well as more examples for this
> use case here:
> http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#quest
> ion
>
> I figured I'd pop in to see if we can try to get this fixed up so the
> users don't have a bad experience both with Tuscany and Maven. Let me
> know if there's anything I can do to help.
>
> -Brian
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Brian, Thanks for dropping by. I worked with Muhwas to get him a
> work
around so he could get our M2 tests running. I couldn't get the Tuscany
M2 samples to work either following the instructions as documented in
the readme. It specifically says to do  "mvn dependecy:unpack" but I
can't find anywhere that the maven-dependency-plugin is configured in
the pom hierarchy for our M2 release. What is the intended behaviour if
you do "mvn dependecy:unpack" against a pom with no
maven-dependency-plugin configuration? Should it do anything sensible.

I wasn't very close to the M2 release but I know people tried the
samples before cutting the tag so something strange is going on. Anyhow
I suspect that it's a Tuscany problem and not a Maven problem but it
needs more investigation. If nothing else we need to fix our
documentation!

Thanks again for posting this.

Simon

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

Great, thanks for that info Brian. Will take a look at it and see if we

can come up with a suitable fix.

Regards

Simon

Re: Merge improved databinding code into trunk

[Simon Laws]

On 3/29/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi Raymond,

Once you have done this, I'd like to get started with syncing up the trunk
for complex and many valued properties since this depends on the
databinding
framework to trasform property definitions in SCDLs to JavaObejects.

- Venkat

On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'll go ahead to commit the last piece which integrates the databinding
> framework with the latest core if there are no other concerns.
>
> The new picture will be:
>
> kernel/core: will depend on databinding-framework (the dependency would
be
> removed as the core is further decomposed)
> services/databinding/databinding-framework: Databinding SPIs and
built-in
> transformers for XML
> kernel/databinding: Databinding related WirePostProcessors and
Inteceptors
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Raymond Feng" <[EMAIL PROTECTED]>
> To: 
> Sent: Friday, March 16, 2007 10:38 PM
> Subject: Merge improved databinding code into trunk
>
>
> > Hi,
> >
> > As you might have noticed on the ML, I have improved the databinding
> code
> > in the sca-java-integration branch over time. I would like to merge
the
> > changes back to the trunk and bring up the databinding support again
in
> > the trunk.
> >
> > Here is the summary of the improvements:
> >
> > 1. Minimize the usage of @DataType by agressively introspecting the
java
> > classes
> >
> > 2. Data transformation for business exceptions
> >
> > 3. Add copy() support for JAXB and AXIOM
> >
> > 4. More databindings and transformers such as:
> >   * JSON databinding
> >   * SDO --> AXIOM using OMDataSource
> >   * JavaBean --> XMLStreamReader
> >
> > 5. More unit and integration test cases for better coverage
> >
> > To avoid the disruption, I'll stage them as follows:
> > 1) Add a "databinding-framework" module under
> > "java/sca/services/databinding" to hold the updated code in spi and
> core.
> > 2) Update individual databindings
> > 3) Integrate the databinding pieces with the latest core
> >
> > Thanks,
> > Raymond
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


Hi

I'm now in the process of copying the Databindings itest from the
integration branch to the trunk. I've copied tests for only a few simple
types but it doesn't  work yet as there are problems with the axis extension
(WorkContexT param missing from some method signatures). Once extension
problems are ironed out we can back fill with more complex type testing,
transformer tests etc. I don't have much time this week so will move it
along as and when I can grab 5 mins. It's not plumbed into the higher level
itest pom yet so it shouldn't break anything.

Regards

Simon

Which samples work?

[Simon Laws]

Ok, so back in from Easter hols and I've debugged through the Calculator
sample with the newly organized trunk. You guys have been busy! I'd like to
get some more of the samples on line and hence learn more about how it
works. I was thinking of having a crack at composite-impl because this looks
like it doesn't have complicated bindings. Is this a good one to pick? Is
someone else working on it?

Regards

Simon

Re: Which samples work?

[Simon Laws]

On 4/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Simon Laws wrote:
> Ok, so back in from Easter hols and I've debugged through the Calculator
> sample with the newly organized trunk. You guys have been busy! I'd
> like to
> get some more of the samples on line and hence learn more about how it
> works. I was thinking of having a crack at composite-impl because this
> looks
> like it doesn't have complicated bindings. Is this a good one to pick?
Is
> someone else working on it?
>
> Regards
>
> Simon
>

Yes, it looks like a good one to me. Once bindings have been brought
back up then we'll be able to run many more samples, but for now it's
probably best to start with the samples that only exercise composition
and Java components.

--
Jean-Sebastien


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

great - thanks jean-sebastien. I'll give it a go.


Simon

Project conventions

[Simon Laws]

Hi

In debugging through the calculator sample I chased the various dependencies
[2]

1/ the articfact names are mostly, but not always, the module name with
tuscany prepended.
  - I see that the artifact name is used at the start of the resulting jar
file so having "tuscany" is good if the jar is encountered in isolation.
  - Can we have the module (directory) name be the same as the artifact id.

  - should samples-* be tuscany-samples-*?
2/ the names don't add much value (to me at least:-) and mostly the poms
don't have descriptions.
  - How about we instigate  project meta data and point out to the
more detailed documentation for a module (when there is some).
  - we should also tidy the names and decide between Apache Tuscany and
Apache Tuscany SCA unless there is a good reason for the difference.
3/ package names within the modules don't always match the module name which
makes it trick to find classes sometimes. I don't have loads of examples
here  but the problem I have was trying to find
o.a.t.api.SCARuntime
  This is in the host-embedded module. Is it practical to suggest that
package names to at least contain the module name?

As an aside (and in the hope that we can get a complete list;-) I've copied
the info from the SCA source tree mail [1] into the wiki [2]. Would be
useful to have all the info about all the hidden conventions in one place so
that we can record and extend as we see fit. What more is there to add?

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16253.html
[2] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=51313
[3] calculator sample dependencies

DirectoryArtifact
   Name

Java

 Buildtools -
Apache Tuscany Build Tools

Pom

  Parent -
Apache Tuscany Project Parent

Sca

  Contrib.

  itest

  modules

  assembly tuscany-assembly
Apache Tuscany Assembly Model

  assembly-xml   tuscany-assemly-xml
Apache
Tuscany SCA XML Assembly Support

  contribution  tuscany-contribution
Apache Tuscany SCA Contribution Service

  contribution-impl   tuscany-contribution-impl
Apache Tuscany SCA Contribution Service Implementation

  core tuscany-core
Apache Tuscany SCA Core Runtime

  core-spituscany-core-spi
Apache Tuscany SCA Core SPI

  host-embedded tuscany-host-embedded
Apache Tuscany Embedded Runtime Host

  host-spi   tuscany-host-spi
Apache Tuscany Host SPI

  implementation-java  tuscany-implementation-java
Apache
Tuscany Java Implementation Model

  implementation-java-runtime   tuscany-implementation-java-runtime
Apache Tuscany Java Implementation Runtime

  implementation-java-xmltuscany-implementation-java-xml
Apache Tuscany SCA XML Java Implementation Extension

  interface   tuscany-interface
Apache Tuscany Interface Model

  interface-javatuscany-interface-java
Apache Tuscany Java Interface Model

  interface-java-xml  tuscany-interface-java-xml
Apache Tuscany SCA XML Java Interface Extension

  policy  tuscany-policy
Apache Tuscany Policy Model

  sca-apisca-api
   Apache Tuscany SCA API

samples

 calculator   samples-calculator

Eclipse project generation

[Simon Laws]

To debug the calculator sample I did a mvn -Peclipse eclipse:eclipse in
java/sca and imported the calculator sample project and all dependecy
projects, into eclipse.  Is there a way of generating the workspace
automatically to avoid the import step? Looking at the eclipse plugin
documentation there doesn't seem to be an option.

Regards

Simon

Re: Eclipse project generation

[Simon Laws]

On 4/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Look at how people is doing in Apache Abdera
https://svn.apache.org/repos/asf/incubator/abdera/java/trunk/BUILDING

I think you can use :

mvn -Declipse.workspace=/path/to/workspace eclipse:eclipse



On 4/11/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> To debug the calculator sample I did a mvn -Peclipse eclipse:eclipse in
> java/sca and imported the calculator sample project and all dependecy
> projects, into eclipse.  Is there a way of generating the workspace
> automatically to avoid the import step? Looking at the eclipse plugin
> documentation there doesn't seem to be an option.
>
> Regards
>
> Simon
>



--
Luciano Resende
http://people.apache.org/~lresende


Thanks Luciano for pointing that out. I tried it and it seems to be tryting
to do the right sort of thing but not quite getting all the way, i.e. the
resulting workspace doesn't load with projects in it. As their advice is to
start with the manual import I'll stick with what I have for now and
investigate alternatives in the future.

Regards

Simon

Re: Project conventions

[Simon Laws]

On 4/11/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Hi

In debugging through the calculator sample I chased the various
dependencies [2]

1/ the articfact names are mostly, but not always, the module name with
tuscany prepended.
   - I see that the artifact name is used at the start of the resulting
jar file so having "tuscany" is good if the jar is encountered in isolation.

   - Can we have the module (directory) name be the same as the artifact
id.
   - should samples-* be tuscany-samples-*?
2/ the names don't add much value (to me at least:-) and mostly the poms
don't have descriptions.
   - How about we instigate  project meta data and point out to the
more detailed documentation for a module (when there is some).
   - we should also tidy the names and decide between Apache Tuscany and
Apache Tuscany SCA unless there is a good reason for the difference.
3/ package names within the modules don't always match the module name
which makes it trick to find classes sometimes. I don't have loads of
examples here  but the problem I have was trying to find
 o.a.t.api.SCARuntime
   This is in the host-embedded module. Is it practical to suggest that
package names to at least contain the module name?

As an aside (and in the hope that we can get a complete list;-) I've
copied the info from the SCA source tree mail [1] into the wiki [2]. Would
be useful to have all the info about all the hidden conventions in one place
so that we can record and extend as we see fit. What more is there to add?

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16253.html
[2] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=51313
[3] calculator sample dependencies

DirectoryArtifact
Name

Java

  Buildtools -
Apache Tuscany Build Tools

Pom

   Parent -
Apache Tuscany Project Parent

Sca

   Contrib.

   itest

   modules

   assembly tuscany-assembly
Apache Tuscany Assembly Model

   assembly-xml   tuscany-assemly-xml   
Apache
Tuscany SCA XML Assembly Support

   contribution  tuscany-contribution
Apache Tuscany SCA Contribution Service

   contribution-impl   tuscany-contribution-impl
Apache Tuscany SCA Contribution Service Implementation

   core tuscany-core
Apache Tuscany SCA Core Runtime

   core-spituscany-core-spi
Apache Tuscany SCA Core SPI

   host-embedded tuscany-host-embedded
Apache Tuscany Embedded Runtime Host

   host-spi   tuscany-host-spi
Apache Tuscany Host SPI

   implementation-java  tuscany-implementation-java 
Apache
Tuscany Java Implementation Model

   implementation-java-runtime   tuscany-implementation-java-runtime
Apache Tuscany Java Implementation Runtime

   implementation-java-xmltuscany-implementation-java-xml
Apache Tuscany SCA XML Java Implementation Extension

   interface   tuscany-interface
Apache Tuscany Interface Model

   interface-javatuscany-interface-java
Apache Tuscany Java Interface Model

   interface-java-xml  tuscany-interface-java-xml
Apache Tuscany SCA XML Java Interface Extension

   policy  tuscany-policy
Apache Tuscany Policy Model

   sca-apisca-api
Apache Tuscany SCA API

 samples

  calculator   samples-calculator


Scratch the point about sample-* being tuscany-samples-*. Am looking at them
now they already are. I must be going mad!

Simon

re: Project conventions

[Simon Laws]

On 4/12/07, haleh mahbod <[EMAIL PROTECTED] > wrote:


Can you please add conventions for Java SCA to this page

http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Development

This makes it easier for contributors to find the information.

Thank you,
Haleh

On 4/11/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
>
> [snip]
> Simon Laws wrote:
> >
> >> 3/ package names within the modules don't always match the module
name
> >> which makes it trick to find classes sometimes. I don't have loads of

> >> examples here  but the problem I have was trying to find
> >>  o.a.t.api.SCARuntime
> >>This is in the host-embedded module. Is it practical to suggest
that
> >> package names to at least contain the module name?
> >>
>
> I'm planning to start fixing some of these package names later this
> evening. For example the packages in implementation-java-runtime
> currenty start with o.a.t.core, I'll rename them to
> o.a.t.implementation.java
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


Hi

We have several java pages on the wiki with "develop*" in the title. I added
another one yesterday as the others are not linked off the Java SCA menu and
I didn't notice them. They contain two types of information. Some is
infrastructure development information like coding standards. Others contain
information for those wanting to develop applications.I've drawn together
the information that I think is to do with infrastructure development under
the "developer Guide"link [1]. This is linked from the "guides" section of
the menu (i've left the old page in place for comparison but should be
removed in due course). Obviously needs more work but we can collect info
here.

There was another "developer guide" page [2] which is to do with building
applications. This needs to be moved under the user guide section but I
think there is still a general confusion here because we have a hierarchy of
documents call "SCA Java"[3] and one called "Java SCA"[4]. We need to
combine these two and merge the information as appropriate. This is not
helped as the top level link called SCA Java actually links to Java SCA:-(.
Anyhow, I know people have been working in SCA Java [5] but that this isn't
linked from the top level. I'm happy to get stuck in and help sort this out
(and give Shelita some help) but I'm in the middle of something just at the
moment so If someone else wants to make a start feel free.

Regards

Simon

[1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Developer+Guide

[2] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Developer+Guide
[3] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java
[4] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA
[5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg16117.html

Re: JAVA_SCA_M2 slides

[Simon Laws]

On 4/11/07, Salvucci, Sebastian <[EMAIL PROTECTED]> wrote:


Hello,

I uploaded a document to
http://cwiki.apache.org/confluence/download/attachments/47512/TuscanyJAV
ASCA.pdf which contains some slides about Java SCA Runtime. They are
based on M2 but perhaps some graphics could serve to be reused for the
web site or future documentation.

Regards,



Sebastian Salvucci



Hi Sebastian


The look pretty cool to me. I particularly like the 3Dness of them. At the
level you have described the code I don't think it would be too much of a
problem to bring the diagrams into line with how the code is now. What tool
did you use to prepare the diagrams? Are you happy to share the source?

Regards

Simon

Composites implementing components problem

[Simon Laws]

I'm trying to bring the composite-impl sample up. The sample uses nested
composite files and if fails trying to wire up the references from a top
level component (which is implemented in a separate composite - see [1]) to
another component.

The failure happens during the connect phase of  DeployerImpl.deploy(). Here
it loops round all of the references specified in the model for the
component in question and then goes to the component implementation to get
the reference definition so it can subsequently create a wire. Here is the
top of the loop from DeployerImpl.connect() (I added some comments here to
highlight the points of interest)

   // for each  the references specified in the SCDL for the component
   for (ComponentReference ref : definition.getReferences()) {
   List wires = new ArrayList();
   String refName = ref.getName();
   // get the definition of the reference which is described by the
component implementation
   org.apache.tuscany.assembly.Reference refDefinition =
getReference(definition.getImplementation(), refName);
   assert refDefinition != null;

So when it comes to "SourceComponent" [1] it finds that the component is
implemented by another composite. When this information is read into the
model by the CompositeProcessor there is code that specifically reads the
implementation.composite element, i.e.

   } else if
(IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {

   // Read an implementation.composite
   Composite implementation =
factory.createComposite();
   implementation.setName(getQName(reader, NAME));
   implementation.setUnresolved(true);
   component.setImplementation(implementation);

Now all this does as far as I can see is create a composite type with just
the composite name in it (I assume that the intention is to resolve this
later on). Hence the connect step fails because the component implementation
in our example has nothing in it. Specifically it has none of the reference
definition information that it would have to look in the other composite
file to get.

The problem is I'm not sure when this information is intended to be linked
up. During the resolve phase when this component implementation is reached
the resolver just finds a composite with nothing in it and, as far as I can
tell, just ignores it. How does the system know that this implementation
refers to a composite defined elsewhere rather than just defining a
composite with nothing in it?

I would assume at the resolve or optimize stages this should happen so that
we have a complete model when it comes time to build the runtime. Maybe we
need a new type or flag to indicate that this is a composite implementing a
component.  I'll keep plugging away but if someone could give me a pointer
that would be great?

[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/composite-impl/src/main/resources/OuterComposite.composite

Re: Wiring of Services and References ?

[Simon Laws]

On 4/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I'm trying to run the echo-binding testcases after updating the binding
implementation, but I'm getting the exception below.
Are we actually wiring services and references  ?

java.lang.IllegalStateException: java.lang.NullPointerExceptionat
org.apache.tuscany.api.SCARuntime.start(SCARuntime.java:170)at
org.apache.tuscany.binding.echo.EchoBindingTestCase.setUp(
EchoBindingTestCase.java:35)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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
JUnit4TestReference.java:38)at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java
:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:460)at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:673)at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
RemoteTestRunner.java:386)at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
RemoteTestRunner.java:196)Caused by: java.lang.NullPointerExceptionat
org.apache.tuscany.core.implementation.PojoAtomicComponent.start(
PojoAtomicComponent.java:217)at
org.apache.tuscany.host.embedded.SimpleRuntimeImpl.start(
SimpleRuntimeImpl.java:158)at
org.apache.tuscany.host.embedded.DefaultSCARuntime.startup(
DefaultSCARuntime.java:50)at org.apache.tuscany.api.SCARuntime.start(
SCARuntime.java:168)... 15 more

--
Luciano Resende
http://people.apache.org/~lresende


Luciano

Did you get past this. I'm getting an NPE in composite-impl where the system
is trying to create wires (just posted on it). Be interested to know if you
solved your problem?

Regards

Simon

Re: Wiring of Services and References ?

[Simon Laws]

On 4/12/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

If the calulator sample is working then I suppose the wiring is in place
isn't it ?   Let me go and try this one.

- Venkat

On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 4/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > I'm trying to run the echo-binding testcases after updating the
binding
> > implementation, but I'm getting the exception below.
> > Are we actually wiring services and references  ?
> >
> > java.lang.IllegalStateException: java.lang.NullPointerExceptionat
> > org.apache.tuscany.api.SCARuntime.start(SCARuntime.java:170)at
> > org.apache.tuscany.binding.echo.EchoBindingTestCase.setUp(
> > EchoBindingTestCase.java:35)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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
> > JUnit4TestReference.java:38)at
> > org.eclipse.jdt.internal.junit.runner.TestExecution.run(
> TestExecution.java
> > :38)
> > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> > RemoteTestRunner.java:460)at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> > RemoteTestRunner.java:673)at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
> > RemoteTestRunner.java:386)at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
> > RemoteTestRunner.java:196)Caused by: java.lang.NullPointerException
> at
> > org.apache.tuscany.core.implementation.PojoAtomicComponent.start(
> > PojoAtomicComponent.java:217)at
> > org.apache.tuscany.host.embedded.SimpleRuntimeImpl.start(
> > SimpleRuntimeImpl.java:158)at
> > org.apache.tuscany.host.embedded.DefaultSCARuntime.startup(
> > DefaultSCARuntime.java:50)at
org.apache.tuscany.api.SCARuntime.start
> (
> > SCARuntime.java:168)... 15 more
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
> Luciano
>
> Did you get past this. I'm getting an NPE in composite-impl where the
> system
> is trying to create wires (just posted on it). Be interested to know if
> you
> solved your problem?
>
> Regards
>
> Simon
>


Hi

I did go back and try the calculator with the latest code from head and it
still works for me. I am getting output from the CompositUtil about the
problems it has found.

Composite configuration problem:
[EMAIL PROTECTED]

I've not looked into this one specifically but it doesn't stop the test
passing. I do get more of these problem reports in the composite-impl test
that I'm playing with and it is a real problem in that case. Still looking
at whats going on.

Regards

Simon

Re: JAVA_SCA_M2 slides

[Simon Laws]

On 4/12/07, Salvucci, Sebastian <[EMAIL PROTECTED]> wrote:


Hi Simon,
I'm happy to share the source. I just used PowerPoint for preparing the
diagrams. The ppt document is already uploaded; you can find it at:
http://cwiki.apache.org/confluence/download/attachments/47512/TuscanyJAV
ASCA.ppt
Regards,

+sebastian


-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 4:40 AM
To: [EMAIL PROTECTED]
Subject: Re: JAVA_SCA_M2 slides

On 4/11/07, Salvucci, Sebastian <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I uploaded a document to
>
http://cwiki.apache.org/confluence/download/attachments/47512/TuscanyJAV
> ASCA.pdf which contains some slides about Java SCA Runtime. They are
> based on M2 but perhaps some graphics could serve to be reused for the
> web site or future documentation.
>
> Regards,
>
>
>
> Sebastian Salvucci
>
>
>
> Hi Sebastian

The look pretty cool to me. I particularly like the 3Dness of them. At
the
level you have described the code I don't think it would be too much of
a
problem to bring the diagrams into line with how the code is now. What
tool
did you use to prepare the diagrams? Are you happy to share the source?

Regards

Simon

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

Great, Thanks for pointing that out Sebastian. It would be good to have a

go at moving them forward to reflecting the new code base. Are you looking
at head now or are you using the released code in M2? Maybe what we could do
is make a page on the wiki and document each slide/part of the
infrastructure and the look at how the code works now. Then update the
diagrams accordingly. I'm just learning how the latest code works so it's
all good edcuational stuff.

Raymond has, in the past, been working on an architecure guide [1] but I
know that this is a little out of date too. Maybe we can join forces and
help him out.

[1]
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+Architecture+Guide

Re: Wiring of Services and References ?

[Simon Laws]

On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:
> [snip]
> Simon Laws wrote:
>>
>> Composite configuration problem:
>> [EMAIL PROTECTED]
>>
>> I've not looked into this one specifically but it doesn't stop the test
>> passing. I do get more of these problem reports in the composite-impl
>> test
>> that I'm playing with and it is a real problem in that case. Still
>> looking
>> at whats going on.
>>
>> Regards
>>
>> Simon
>>
> Simon,
>
> This output is produced by temporary test code that I added to
> CompositeUtil to help track problems in most of .composite files,
> which are not all following the SCA assembly XML spec 1.0. In
particular:
> - declare a targetNamespace
> - use qnames to name referenced composites
> - name included composites in the content of the  element
> instead of a "name" attribute
> - use "target" attributes on references instead of naming the target
> in the element content
> - use "promote" attributes on composite services and references
>
> So before testing, you need to make sure that the .composite files are
> correct. These print statements should help you detect that there are
> problems (even if they just dump the model objects at the moment).
> Then to debug you can set a breakpoint on the line that does the
> print, and figure what 's wrong in the test case from there.
>
Simon,

I just committed a change to print more debug info when encountering a
composite configuration problem. Hope this helps.

--
Jean-Sebastien


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

Great, thanks Sebastien.Thanks for doing that. I gave the new code a spin

and the extra info is interesting. Looking at the CompositeUtil code is
looks like it is always comparing the component definition from the SCDL
with the implementation. Do you have any objection if I go in and add some
more info to the  problem model to record and report the exact nature of the
problem found?

Simon

Simon

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Simon Laws wrote:
> I'm trying to bring the composite-impl sample up. The sample uses nested
> composite files and if fails trying to wire up the references from a top
> level component (which is implemented in a separate composite - see
> [1]) to
> another component.
>
> The failure happens during the connect phase of
> DeployerImpl.deploy(). Here
> it loops round all of the references specified in the model for the
> component in question and then goes to the component implementation to
> get
> the reference definition so it can subsequently create a wire. Here is
> the
> top of the loop from DeployerImpl.connect() (I added some comments
> here to
> highlight the points of interest)
>
>// for each  the references specified in the SCDL for the
> component
>for (ComponentReference ref : definition.getReferences()) {
>List wires = new ArrayList();
>String refName = ref.getName();
>// get the definition of the reference which is described
> by the
> component implementation
>org.apache.tuscany.assembly.Reference refDefinition =
> getReference(definition.getImplementation(), refName);
>assert refDefinition != null;
>
> So when it comes to "SourceComponent" [1] it finds that the component is
> implemented by another composite. When this information is read into the
> model by the CompositeProcessor there is code that specifically reads
the
> implementation.composite element, i.e.
>
>} else if
> (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
>
>// Read an implementation.composite
>Composite implementation =
> factory.createComposite();
>implementation.setName(getQName(reader,
> NAME));
>implementation.setUnresolved(true);
>component.setImplementation(implementation);
>
> Now all this does as far as I can see is create a composite type with
> just
> the composite name in it (I assume that the intention is to resolve this
> later on). Hence the connect step fails because the component
> implementation
> in our example has nothing in it. Specifically it has none of the
> reference
> definition information that it would have to look in the other composite
> file to get.
>
> The problem is I'm not sure when this information is intended to be
> linked
> up. During the resolve phase when this component implementation is
> reached
> the resolver just finds a composite with nothing in it and, as far as
> I can
> tell, just ignores it. How does the system know that this implementation
> refers to a composite defined elsewhere rather than just defining a
> composite with nothing in it?
>
> I would assume at the resolve or optimize stages this should happen so
> that
> we have a complete model when it comes time to build the runtime.
> Maybe we
> need a new type or flag to indicate that this is a composite
> implementing a
> component.  I'll keep plugging away but if someone could give me a
> pointer
> that would be great?
>
> [1]
>
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/composite-impl/src/main/resources/OuterComposite.composite
>
>

Simon,

This code:
   // Read an implementation.composite
   Composite implementation =
factory.createComposite();
   implementation.setName(getQName(reader, NAME));
   implementation.setUnresolved(true);
   component.setImplementation(implementation);
creates a reference to the named composite marked Unresolved.

Later in the CompositeProcessor.resolve method, we resolve the
Implementations of all the Components in the Composite, including
references to other Composites, as follows:
   // Resolve component implementations, services and references
for (Component component: composite.getComponents()) {
constrainingType = component.getConstrainingType();
constrainingType = resolver.resolve(ConstrainingType.class,
constrainingType);
component.setConstrainingType(constrainingType);

Implementation implementation = component.getImplementation();
implementation = resolveImplementation(implementation,
resolver);
component.setImplementation(implementation);

resolveContracts(component.getServices(), resolver);
resolveContracts(component.getReferences(), resolver);
}

Hope this helps.

--
Jean-Sebastien


-
To u

Re: Wiring of Services and References ?

[Simon Laws]

On 4/12/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi Simon,

Thanks for considering on expanding the 'problem model'.  Infact I was
wondering if every SCA Object such as a Composite, Component, Reference,
 has a bunch of 'error contexts' encapsulated within it.  So if
something is wrong with a Reference defn, you simply add the problematic
'reference defn. instance' (as it is being done now) and also the Error
Context say something as 'MULTIPLICY_TO_TARGET_MISMATCH'.  The for each of
these 'Error Contexts' the SCA Object also encapsulates what information
would be relevant to output as Error Information.  So if you'd as for an
error message to the Reference Object given the context
'MULTIPLICY_TO_TARGET_MISMATCH' it would provide you the multiplicity and
target settings.

So we simply stack the problematic SCA Objects and simply ask for Error
Information at the end.

Not sure it this would complicate things... it was just a thought... maybe
there are better options.

- Venkat



On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> > Jean-Sebastien Delfino wrote:
> > > [snip]
> > > Simon Laws wrote:
> > >>
> > >> Composite configuration problem:
> > >> [EMAIL PROTECTED]
> > >>
> > >> I've not looked into this one specifically but it doesn't stop the
> test
> > >> passing. I do get more of these problem reports in the
composite-impl
> > >> test
> > >> that I'm playing with and it is a real problem in that case. Still
> > >> looking
> > >> at whats going on.
> > >>
> > >> Regards
> > >>
> > >> Simon
> > >>
> > > Simon,
> > >
> > > This output is produced by temporary test code that I added to
> > > CompositeUtil to help track problems in most of .composite files,
> > > which are not all following the SCA assembly XML spec 1.0. In
> > particular:
> > > - declare a targetNamespace
> > > - use qnames to name referenced composites
> > > - name included composites in the content of the  element
> > > instead of a "name" attribute
> > > - use "target" attributes on references instead of naming the target
> > > in the element content
> > > - use "promote" attributes on composite services and references
> > >
> > > So before testing, you need to make sure that the .composite files
are
> > > correct. These print statements should help you detect that there
are
> > > problems (even if they just dump the model objects at the moment).
> > > Then to debug you can set a breakpoint on the line that does the
> > > print, and figure what 's wrong in the test case from there.
> > >
> > Simon,
> >
> > I just committed a change to print more debug info when encountering a
> > composite configuration problem. Hope this helps.
> >
> > --
> > Jean-Sebastien
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > Great, thanks Sebastien.Thanks for doing that. I gave the new code a
> spin
> and the extra info is interesting. Looking at the CompositeUtil code is
> looks like it is always comparing the component definition from the SCDL
> with the implementation. Do you have any objection if I go in and add
some
> more info to the  problem model to record and report the exact nature of
> the
> problem found?
>
> Simon
>
> Simon
>


I like the idea that when capturing the state of the object we capture the
error state as well. A question though. Were you thinking of doing this with
the model objects in the assembly or, when you say "SCA Object", do you mean
passing the info through to the runtime objects some how. If the latter not
sure how you would do this as I assume they are not around until after the
build stage. If the former then that sounds OK to me. It would be a more
detailed version of the "unresolved" flag, I.e. I tried to resolve it but
found errors.

As an aside why is that flag called "unresolved"? Shouldn't it be called
"resolved". I struggle with the Unresolved=false double negative. (not a
major point - feel free to ignore me:-)

Regards

Simon

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Simon Laws wrote:
> On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Simon Laws wrote:
>> > I'm trying to bring the composite-impl sample up. The sample uses
>> nested
>> > composite files and if fails trying to wire up the references from
>> a top
>> > level component (which is implemented in a separate composite - see
>> > [1]) to
>> > another component.
>> >
>> > The failure happens during the connect phase of
>> > DeployerImpl.deploy(). Here
>> > it loops round all of the references specified in the model for the
>> > component in question and then goes to the component implementation
to
>> > get
>> > the reference definition so it can subsequently create a wire. Here
is
>> > the
>> > top of the loop from DeployerImpl.connect() (I added some comments
>> > here to
>> > highlight the points of interest)
>> >
>> >// for each  the references specified in the SCDL for the
>> > component
>> >for (ComponentReference ref : definition.getReferences()) {
>> >List wires = new ArrayList();
>> >String refName = ref.getName();
>> >// get the definition of the reference which is described
>> > by the
>> > component implementation
>> >org.apache.tuscany.assembly.Reference refDefinition =
>> > getReference(definition.getImplementation(), refName);
>> >assert refDefinition != null;
>> >
>> > So when it comes to "SourceComponent" [1] it finds that the
>> component is
>> > implemented by another composite. When this information is read
>> into the
>> > model by the CompositeProcessor there is code that specifically reads
>> the
>> > implementation.composite element, i.e.
>> >
>> >} else if
>> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
>> >
>> >// Read an implementation.composite
>> >Composite implementation =
>> > factory.createComposite();
>> >implementation.setName(getQName(reader,
>> > NAME));
>> >implementation.setUnresolved(true);
>> >
>> component.setImplementation(implementation);
>> >
>> > Now all this does as far as I can see is create a composite type with
>> > just
>> > the composite name in it (I assume that the intention is to resolve
>> this
>> > later on). Hence the connect step fails because the component
>> > implementation
>> > in our example has nothing in it. Specifically it has none of the
>> > reference
>> > definition information that it would have to look in the other
>> composite
>> > file to get.
>> >
>> > The problem is I'm not sure when this information is intended to be
>> > linked
>> > up. During the resolve phase when this component implementation is
>> > reached
>> > the resolver just finds a composite with nothing in it and, as far as
>> > I can
>> > tell, just ignores it. How does the system know that this
>> implementation
>> > refers to a composite defined elsewhere rather than just defining a
>> > composite with nothing in it?
>> >
>> > I would assume at the resolve or optimize stages this should happen
so
>> > that
>> > we have a complete model when it comes time to build the runtime.
>> > Maybe we
>> > need a new type or flag to indicate that this is a composite
>> > implementing a
>> > component.  I'll keep plugging away but if someone could give me a
>> > pointer
>> > that would be great?
>> >
>> > [1]
>> >
>>
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/composite-impl/src/main/resources/OuterComposite.composite
>>
>> >
>> >
>>
>> Simon,
>>
>> This code:
>>// Read an implementation.composite
>>Composite implementation =
>> factory.createComposite();
>>implementation.setName(getQName(reader,
>> NAME));
>>implementation.setUnresolved(true);
>>component.setImplementation(implementation);
>> creates a reference to the named composite

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Simon Laws wrote:
> > On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >>
> >> Simon Laws wrote:
> >> > I'm trying to bring the composite-impl sample up. The sample uses
> >> nested
> >> > composite files and if fails trying to wire up the references from
> >> a top
> >> > level component (which is implemented in a separate composite - see
> >> > [1]) to
> >> > another component.
> >> >
> >> > The failure happens during the connect phase of
> >> > DeployerImpl.deploy(). Here
> >> > it loops round all of the references specified in the model for the
>
> >> > component in question and then goes to the component implementation
> to
> >> > get
> >> > the reference definition so it can subsequently create a wire. Here
> is
> >> > the
> >> > top of the loop from DeployerImpl.connect() (I added some comments
> >> > here to
> >> > highlight the points of interest)
> >> >
> >> >// for each  the references specified in the SCDL for the
> >> > component
> >> >for (ComponentReference ref : definition.getReferences()) {
> >> >List wires = new ArrayList();
> >> >String refName = ref.getName();
> >> >// get the definition of the reference which is
> described
> >> > by the
> >> > component implementation
> >> >org.apache.tuscany.assembly.Reference refDefinition =
> >> > getReference(definition.getImplementation(), refName);
> >> >assert refDefinition != null;
> >> >
> >> > So when it comes to "SourceComponent" [1] it finds that the
> >> component is
> >> > implemented by another composite. When this information is read
> >> into the
> >> > model by the CompositeProcessor there is code that specifically
> reads
> >> the
> >> > implementation.composite element, i.e.
> >> >
> >> >} else if
> >> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
> >> >
> >> >// Read an implementation.composite
> >> >Composite implementation =
> >> > factory.createComposite();
> >> >implementation.setName(getQName(reader,
> >> > NAME));
> >> >implementation.setUnresolved(true);
> >> >
> >> component.setImplementation(implementation);
> >> >
> >> > Now all this does as far as I can see is create a composite type
> with
> >> > just
> >> > the composite name in it (I assume that the intention is to resolve
> >> this
> >> > later on). Hence the connect step fails because the component
> >> > implementation
> >> > in our example has nothing in it. Specifically it has none of the
> >> > reference
> >> > definition information that it would have to look in the other
> >> composite
> >> > file to get.
> >> >
> >> > The problem is I'm not sure when this information is intended to be
> >> > linked
> >> > up. During the resolve phase when this component implementation is
> >> > reached
> >> > the resolver just finds a composite with nothing in it and, as far
> as
> >> > I can
> >> > tell, just ignores it. How does the system know that this
> >> implementation
> >> > refers to a composite defined elsewhere rather than just defining a
>
> >> > composite with nothing in it?
> >> >
> >> > I would assume at the resolve or optimize stages this should happen
> so
> >> > that
> >> > we have a complete model when it comes time to build the runtime.
> >> > Maybe we
> >> > need a new type or flag to indicate that this is a composite
> >> > implementing a
> >> > component.  I'll keep plugging away but if someone could give me a
> >> > pointer
> >> > that would be great?
> >> >
> >> > [1]
> >> >
> >>
> 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/composite-impl/src/main/resour

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Simon Laws wrote:
> On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Simon Laws wrote:
>> > On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Simon Laws wrote:
>> >> > I'm trying to bring the composite-impl sample up. The sample uses
>> >> nested
>> >> > composite files and if fails trying to wire up the references from
>> >> a top
>> >> > level component (which is implemented in a separate composite -
see
>> >> > [1]) to
>> >> > another component.
>> >> >
>> >> > The failure happens during the connect phase of
>> >> > DeployerImpl.deploy(). Here
>> >> > it loops round all of the references specified in the model for
the
>> >> > component in question and then goes to the component
implementation
>> to
>> >> > get
>> >> > the reference definition so it can subsequently create a wire.
Here
>> is
>> >> > the
>> >> > top of the loop from DeployerImpl.connect() (I added some comments
>> >> > here to
>> >> > highlight the points of interest)
>> >> >
>> >> >// for each  the references specified in the SCDL for the
>> >> > component
>> >> >for (ComponentReference ref : definition.getReferences()) {
>> >> >List wires = new ArrayList();
>> >> >String refName = ref.getName();
>> >> >// get the definition of the reference which is
>> described
>> >> > by the
>> >> > component implementation
>> >> >org.apache.tuscany.assembly.Reference refDefinition =
>> >> > getReference(definition.getImplementation(), refName);
>> >> >assert refDefinition != null;
>> >> >
>> >> > So when it comes to "SourceComponent" [1] it finds that the
>> >> component is
>> >> > implemented by another composite. When this information is read
>> >> into the
>> >> > model by the CompositeProcessor there is code that specifically
>> reads
>> >> the
>> >> > implementation.composite element, i.e.
>> >> >
>> >> >} else if
>> >> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
>> >> >
>> >> >// Read an implementation.composite
>> >> >Composite implementation =
>> >> > factory.createComposite();
>> >> >implementation.setName(getQName(reader,
>> >> > NAME));
>> >> >implementation.setUnresolved(true);
>> >> >
>> >> component.setImplementation(implementation);
>> >> >
>> >> > Now all this does as far as I can see is create a composite type
>> with
>> >> > just
>> >> > the composite name in it (I assume that the intention is to
resolve
>> >> this
>> >> > later on). Hence the connect step fails because the component
>> >> > implementation
>> >> > in our example has nothing in it. Specifically it has none of the
>> >> > reference
>> >> > definition information that it would have to look in the other
>> >> composite
>> >> > file to get.
>> >> >
>> >> > The problem is I'm not sure when this information is intended to
be
>> >> > linked
>> >> > up. During the resolve phase when this component implementation is
>> >> > reached
>> >> > the resolver just finds a composite with nothing in it and, as
>> far as
>> >> > I can
>> >> > tell, just ignores it. How does the system know that this
>> >> implementation
>> >> > refers to a composite defined elsewhere rather than just defining
a
>> >> > composite with nothing in it?
>> >> >
>> >> > I would assume at the resolve or optimize stages this should
happen
>> so
>> >> > that
>> >> > we have a complete model when it comes time to build the runtime.
>> >> > Maybe we
>> >> > need a new type or flag to indicate that this is a comp

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> >
> > Simon Laws wrote:
> > > On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Simon Laws wrote:
> > >> > I'm trying to bring the composite-impl sample up. The sample uses
> >
> > >> nested
> > >> > composite files and if fails trying to wire up the references
> > from
> > >> a top
> > >> > level component (which is implemented in a separate composite -
> > see
> > >> > [1]) to
> > >> > another component.
> > >> >
> > >> > The failure happens during the connect phase of
> > >> > DeployerImpl.deploy(). Here
> > >> > it loops round all of the references specified in the model for
> > the
> > >> > component in question and then goes to the component
> > implementation to
> > >> > get
> > >> > the reference definition so it can subsequently create a wire.
> > Here is
> > >> > the
> > >> > top of the loop from DeployerImpl.connect() (I added some
> > comments
> > >> > here to
> > >> > highlight the points of interest)
> > >> >
> > >> >// for each  the references specified in the SCDL for the
> > >> > component
> > >> >for (ComponentReference ref : definition.getReferences())
> > {
> > >> >List wires = new ArrayList();
> > >> >String refName = ref.getName();
> > >> >// get the definition of the reference which is
> > described
> > >> > by the
> > >> > component implementation
> > >> >org.apache.tuscany.assembly.Reference refDefinition =
> > >> > getReference(definition.getImplementation(), refName);
> > >> >assert refDefinition != null;
> > >> >
> > >> > So when it comes to "SourceComponent" [1] it finds that the
> > >> component is
> > >> > implemented by another composite. When this information is read
> > >> into the
> > >> > model by the CompositeProcessor there is code that specifically
> > reads
> > >> the
> > >> > implementation.composite element, i.e.
> > >> >
> > >> >} else if
> > >> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
> > >> >
> > >> >// Read an implementation.composite
> > >> >Composite implementation =
> > >> > factory.createComposite();
> > >> >implementation.setName(getQName(reader,
> >
> > >> > NAME));
> > >> >implementation.setUnresolved(true);
> > >> >
> > >> component.setImplementation(implementation);
> > >> >
> > >> > Now all this does as far as I can see is create a composite type
> > with
> > >> > just
> > >> > the composite name in it (I assume that the intention is to
> > resolve
> > >> this
> > >> > later on). Hence the connect step fails because the component
> > >> > implementation
> > >> > in our example has nothing in it. Specifically it has none of the
> > >> > reference
> > >> > definition information that it would have to look in the other
> > >> composite
> > >> > file to get.
> > >> >
> > >> > The problem is I'm not sure when this information is intended to
> > be
> > >> > linked
> > >> > up. During the resolve phase when this component implementation
> > is
> > >> > reached
> > >> > the resolver just finds a composite with nothing in it and, as
> > far as
> > >> > I can
> > >> > tell, just ignores it. How does the system know that this
> > >> implementation
> > >> > refers to a composite defined elsewhere rather than just defining
> > a
> > >> > composite with nothing in it?
> > >> >
> > >> > I would assume at the resolve or optimize stages this should
> > happen so
>

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi, Simon.

For the composite component, it's probably not necessary to attach the
wire.
Can you try to add the following code in DeployerImpl.connect() to see if
it
helps?

public void connect(Map models,
org.apache.tuscany.assembly.Component definition)
throws WiringException {
// Skip the composite
if(definition.getImplementation() instanceof Composite) {
return;
}
// End of skip

...
}

Thanks,
Raymond

- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 12, 2007 12:19 PM
Subject: Re: Composites implementing components problem


> On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
>> > >
>> > > Simon Laws wrote:
>> > > > On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> > > >>
>> > > >> Simon Laws wrote:
>> > > >> > I'm trying to bring the composite-impl sample up. The sample
>> > > >> > uses
>> > >
>> > > >> nested
>> > > >> > composite files and if fails trying to wire up the references
>> > > from
>> > > >> a top
>> > > >> > level component (which is implemented in a separate composite
-
>> > > see
>> > > >> > [1]) to
>> > > >> > another component.
>> > > >> >
>> > > >> > The failure happens during the connect phase of
>> > > >> > DeployerImpl.deploy(). Here
>> > > >> > it loops round all of the references specified in the model
for
>> > > the
>> > > >> > component in question and then goes to the component
>> > > implementation to
>> > > >> > get
>> > > >> > the reference definition so it can subsequently create a wire.
>> > > Here is
>> > > >> > the
>> > > >> > top of the loop from DeployerImpl.connect() (I added some
>> > > comments
>> > > >> > here to
>> > > >> > highlight the points of interest)
>> > > >> >
>> > > >> >// for each  the references specified in the SCDL for
the
>> > > >> > component
>> > > >> >for (ComponentReference ref : definition.getReferences
())
>> > > {
>> > > >> >List wires = new ArrayList();
>> > > >> >String refName = ref.getName();
>> > > >> >// get the definition of the reference which is
>> > > described
>> > > >> > by the
>> > > >> > component implementation
>> > > >> >org.apache.tuscany.assembly.Reference refDefinition
=
>> > > >> > getReference(definition.getImplementation(), refName);
>> > > >> >assert refDefinition != null;
>> > > >> >
>> > > >> > So when it comes to "SourceComponent" [1] it finds that the
>> > > >> component is
>> > > >> > implemented by another composite. When this information is
read
>> > > >> into the
>> > > >> > model by the CompositeProcessor there is code that
specifically
>> > > reads
>> > > >> the
>> > > >> > implementation.composite element, i.e.
>> > > >> >
>> > > >> >} else if
>> > > >> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
>> > > >> >
>> > > >> >// Read an implementation.composite
>> > > >> >Composite implementation =
>> > > >> > factory.createComposite();
>> > > >> >
>> > > >> > implementation.setName(getQName(reader,
>> > >
>> > > >> > NAME));
>> > > >> >implementation.setUnresolved(true);
>> > > >> >
>> > > >> component.setImplementation(implementation);
>> > > >> >
>> > > >> > Now all this does as far as I

Re: How to tell if a component reference is promoted by a comosite reference?

[Simon Laws]

On 4/13/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

With the current assembly model, how can we tell if a component reference
is
promoted by a comosite reference? I can get all the promoted references
from
CompositeReference but not the other way.

Thanks,
Raymond


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

If the model is a true reflection of what appears in the SCDL then I

assume you would have to loop over all the references in the composite that
contains the component in question and test if the componet reference is
being promoted. I know that isn't telling you anything you don't already
know but it's just and excuse to add a related question to this thread

Is the philosophy with the assembly model to have it represent precisely
what appears in the SCDL or is there room to include value add, for example,
links from components references to the composite references that promote
them?

Simon

Re: website - SCA Java developer Guide & Get Involved - can they be merged?

[Simon Laws]

On 4/13/07, ant elder <[EMAIL PROTECTED]> wrote:


The content in the java-sca-developer-guide looks most up to date to me.
I'm
not sure that the first section on principles should really be there in
this
developer guide though, and I'd also like to greatly simplify the sections
on coding and testing standards if no one has an objection to that?

   ...ant

On 4/12/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Content of these two links are very similar
>
> http://cwiki.apache.org/TUSCANY/java-sca-developer-guide.html
>
> and
>
> http://cwiki.apache.org/TUSCANY/sca-java-development.html
>
>
> Audience for both of these pages seem to be the developer who wants to
get
> involved in Java SCA.
> We are using the 'get involved' link in each subproject  for information
> that helps developers to get involved.
>
> Can information on these two pages be merged or was
> http://cwiki.apache.org/TUSCANY/java-sca-developer-guide.html
>
> created for another purpose?
>
> Haleh
>


I've no objection Ant I just pulled together what I could find to try and
get it in one place. We shouldn't loose useful info though;-)

Simon

Re: Composites implementing components problem

[Simon Laws]

On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 4/12/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
>
> Hi, Simon.
>
> For the composite component, it's probably not necessary to attach the
> wire.
> Can you try to add the following code in DeployerImpl.connect() to see
> if it
> helps?
>
> public void connect(Map models,
> org.apache.tuscany.assembly.Component definition)
> throws WiringException {
> // Skip the composite
> if(definition.getImplementation() instanceof Composite) {
> return;
> }
> // End of skip
>
> ...
> }
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Simon Laws" < [EMAIL PROTECTED]>
> To: < [EMAIL PROTECTED]>
> Sent: Thursday, April 12, 2007 12:19 PM
> Subject: Re: Composites implementing components problem
>
>
> > On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
> >> On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> >
> >> > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> >> > >
> >> > > Simon Laws wrote:
> >> > > > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> wrote:
> >> > > >>
> >> > > >> Simon Laws wrote:
> >> > > >> > I'm trying to bring the composite-impl sample up. The sample
>
> >> > > >> > uses
> >> > >
> >> > > >> nested
> >> > > >> > composite files and if fails trying to wire up the
> references
> >> > > from
> >> > > >> a top
> >> > > >> > level component (which is implemented in a separate
> composite -
> >> > > see
> >> > > >> > [1]) to
> >> > > >> > another component.
> >> > > >> >
> >> > > >> > The failure happens during the connect phase of
> >> > > >> > DeployerImpl.deploy(). Here
> >> > > >> > it loops round all of the references specified in the model
> for
> >> > > the
> >> > > >> > component in question and then goes to the component
> >> > > implementation to
> >> > > >> > get
> >> > > >> > the reference definition so it can subsequently create a
> wire.
> >> > > Here is
> >> > > >> > the
> >> > > >> > top of the loop from DeployerImpl.connect() (I added some
> >> > > comments
> >> > > >> > here to
> >> > > >> > highlight the points of interest)
> >> > > >> >
> >> > > >> >// for each  the references specified in the SCDL for
> the
> >> > > >> > component
> >> > > >> >for (ComponentReference ref :
> definition.getReferences())
> >> > > {
> >> > > >> >List wires = new ArrayList();
> >> > > >> >String refName = ref.getName();
> >> > > >> >// get the definition of the reference which is
> >> > > described
> >> > > >> > by the
> >> > > >> > component implementation
> >> > > >> >org.apache.tuscany.assembly.ReferencerefDefinition =
> >> > > >> > getReference(definition.getImplementation (), refName);
> >> > > >> >assert refDefinition != null;
> >> > > >> >
> >> > > >> > So when it comes to "SourceComponent" [1] it finds that the
> >> > > >> component is
> >> > > >> > implemented by another composite. When this information is
> read
> >> > > >> into the
> >> > > >> > model by the CompositeProcessor there is code that
> specifically
> >> > > reads
> >> > > >> the
> >> > > >> > implementation.composite element, i.e.
> >> > > >> >
> >> > > >> >} else if
> >> > > >> > (IMPLEMENTATION_COMPOSITE_QNAME.equals(name)) {
> >> > > >> >
> >> > > >> >// Read an
> implementation.composite
> >

Re: Composites implementing components problem

[Simon Laws]

On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 4/12/07, Simon Laws <[EMAIL PROTECTED] > wrote:
>
>
>
> On 4/12/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
> >
> > Hi, Simon.
> >
> > For the composite component, it's probably not necessary to attach the
> > wire.
> > Can you try to add the following code in DeployerImpl.connect() to see
> > if it
> > helps?
> >
> > public void connect(Map models,
> > org.apache.tuscany.assembly.Component definition)
> > throws WiringException {
> > // Skip the composite
> > if(definition.getImplementation() instanceof Composite) {
> > return;
> >     }
> > // End of skip
> >
> > ...
> > }
> >
> > Thanks,
> > Raymond
> >
> > - Original Message -
> > From: "Simon Laws" < [EMAIL PROTECTED]>
> > To: < [EMAIL PROTECTED]>
> > Sent: Thursday, April 12, 2007 12:19 PM
> > Subject: Re: Composites implementing components problem
> >
> >
> > > On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >>
> > >> On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> > >> > >
> > >> > > Simon Laws wrote:
> > >> > > > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> > wrote:
> > >> > > >>
> > >> > > >> Simon Laws wrote:
> > >> > > >> > I'm trying to bring the composite-impl sample up. The
> > sample
> > >> > > >> > uses
> > >> > >
> > >> > > >> nested
> > >> > > >> > composite files and if fails trying to wire up the
> > references
> > >> > > from
> > >> > > >> a top
> > >> > > >> > level component (which is implemented in a separate
> > composite -
> > >> > > see
> > >> > > >> > [1]) to
> > >> > > >> > another component.
> > >> > > >> >
> > >> > > >> > The failure happens during the connect phase of
> > >> > > >> > DeployerImpl.deploy(). Here
> > >> > > >> > it loops round all of the references specified in the
> > model for
> > >> > > the
> > >> > > >> > component in question and then goes to the component
> > >> > > implementation to
> > >> > > >> > get
> > >> > > >> > the reference definition so it can subsequently create a
> > wire.
> > >> > > Here is
> > >> > > >> > the
> > >> > > >> > top of the loop from DeployerImpl.connect() (I added some
> > >> > > comments
> > >> > > >> > here to
> > >> > > >> > highlight the points of interest)
> > >> > > >> >
> > >> > > >> >// for each  the references specified in the SCDL
> > for the
> > >> > > >> > component
> > >> > > >> >for (ComponentReference ref :
> > definition.getReferences())
> > >> > > {
> > >> > > >> >List wires = new ArrayList();
> > >> > > >> >String refName = ref.getName();
> > >> > > >> >// get the definition of the reference which is
> > >> > > described
> > >> > > >> > by the
> > >> > > >> > component implementation
> > >> > > >> >org.apache.tuscany.assembly.ReferencerefDefinition =
> > >> > > >> > getReference(definition.getImplementation (), refName);
> > >> > > >> >assert refDefinition != null;
> > >> > > >> >
> > >> > > >> > So when it comes to "SourceComponent" [1] it finds that
> > the
> > >> > > >> component is
> > >> > > >> > implemented by another composite. When this information is
> > read
> > >> > > >> into the
> > >&g

Re: JAVA_SCA_M2 slides

[Simon Laws]

On 4/13/07, Salvucci, Sebastian <[EMAIL PROTECTED]> wrote:


Hi Simon,
I superficially understood Tuscany architecture by looking at the M2
code and the existing documentation some weeks ago. I'm planning to
start looking the current status of the code in the next days.
I agree with you that it's all good educational stuff, so I would like
to join forces for updating/creating diagrams which help the better
understanding of Tuscany architecture. As you proposed, a wiki page for
documenting each part of the infrastructure, getting Raymond's
documentation as a reference, is a very good point for start doing it.
Keep in touch.
Regards,

+sebastian




-Original Message-
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 11:20 AM
To: [EMAIL PROTECTED]
Subject: Re: JAVA_SCA_M2 slides

On 4/12/07, Salvucci, Sebastian <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
> I'm happy to share the source. I just used PowerPoint for preparing
the
> diagrams. The ppt document is already uploaded; you can find it at:
>
http://cwiki.apache.org/confluence/download/attachments/47512/TuscanyJAV
> ASCA.ppt
> Regards,
>
> +sebastian
>
>
> -Original Message-
> From: Simon Laws [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 4:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: JAVA_SCA_M2 slides
>
> On 4/11/07, Salvucci, Sebastian <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > I uploaded a document to
> >
>
http://cwiki.apache.org/confluence/download/attachments/47512/TuscanyJAV
> > ASCA.pdf which contains some slides about Java SCA Runtime. They are
> > based on M2 but perhaps some graphics could serve to be reused for
the
> > web site or future documentation.
> >
> > Regards,
> >
> >
> >
> > Sebastian Salvucci
> >
> >
> >
> > Hi Sebastian
>
> The look pretty cool to me. I particularly like the 3Dness of them. At
> the
> level you have described the code I don't think it would be too much
of
> a
> problem to bring the diagrams into line with how the code is now. What
> tool
> did you use to prepare the diagrams? Are you happy to share the
source?
>
> Regards
>
> Simon
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Great, Thanks for pointing that out Sebastian. It would be good to
have a
go at moving them forward to reflecting the new code base. Are you
looking
at head now or are you using the released code in M2? Maybe what we
could do
is make a page on the wiki and document each slide/part of the
infrastructure and the look at how the code works now. Then update the
diagrams accordingly. I'm just learning how the latest code works so
it's
all good edcuational stuff.

Raymond has, in the past, been working on an architecure guide [1] but I
know that this is a little out of date too. Maybe we can join forces and
help him out.

[1]
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+Architecture+
Guide

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

Ok, am not going to get to it today, but in debugging a problem I have at

the moment have been going the new code and have been taking some notes so
will try and make a start on something next week.

Regards

Simon

Re: Composites implementing components problem

[Simon Laws]

On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:




On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
>
> On 4/12/07, Simon Laws < [EMAIL PROTECTED] > wrote:
> >
> >
> >
> > On 4/12/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi, Simon.
> > >
> > > For the composite component, it's probably not necessary to attach
> > > the wire.
> > > Can you try to add the following code in DeployerImpl.connect() to
> > > see if it
> > > helps?
> > >
> > > public void connect(Map models,
> > > org.apache.tuscany.assembly.Component definition)
> > > throws WiringException {
> > > // Skip the composite
> > > if(definition.getImplementation() instanceof Composite) {
> > > return;
> > > }
> > > // End of skip
> > >
> > > ...
> > > }
> > >
> > > Thanks,
> > > Raymond
> > >
> > > - Original Message -
> > > From: "Simon Laws" < [EMAIL PROTECTED]>
> > > To: < [EMAIL PROTECTED]>
> > > Sent: Thursday, April 12, 2007 12:19 PM
> > > Subject: Re: Composites implementing components problem
> > >
> > >
> > > > On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> > > wrote:
> > > >> > >
> > > >> > > Simon Laws wrote:
> > > >> > > > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> > > wrote:
> > > >> > > >>
> > > >> > > >> Simon Laws wrote:
> > > >> > > >> > I'm trying to bring the composite-impl sample up. The
> > > sample
> > > >> > > >> > uses
> > > >> > >
> > > >> > > >> nested
> > > >> > > >> > composite files and if fails trying to wire up the
> > > references
> > > >> > > from
> > > >> > > >> a top
> > > >> > > >> > level component (which is implemented in a separate
> > > composite -
> > > >> > > see
> > > >> > > >> > [1]) to
> > > >> > > >> > another component.
> > > >> > > >> >
> > > >> > > >> > The failure happens during the connect phase of
> > > >> > > >> > DeployerImpl.deploy(). Here
> > > >> > > >> > it loops round all of the references specified in the
> > > model for
> > > >> > > the
> > > >> > > >> > component in question and then goes to the component
> > > >> > > implementation to
> > > >> > > >> > get
> > > >> > > >> > the reference definition so it can subsequently create a
> > > wire.
> > > >> > > Here is
> > > >> > > >> > the
> > > >> > > >> > top of the loop from DeployerImpl.connect() (I added
> > > some
> > > >> > > comments
> > > >> > > >> > here to
> > > >> > > >> > highlight the points of interest)
> > > >> > > >> >
> > > >> > > >> >// for each  the references specified in the SCDL
> > > for the
> > > >> > > >> > component
> > > >> > > >> >for (ComponentReference ref :
> > > definition.getReferences())
> > > >> > > {
> > > >> > > >> >List wires = new ArrayList();
> > > >> > > >> >String refName = ref.getName();
> > > >> > > >> >// get the definition of the reference which
> > > is
> > > >> > > described
> > > >> > > >> > by the
> > > >> > > >> > component implementation
> > > >> > > >> >org.apache.tuscany.assembly.Referencere

Re: Nested composites and callbacks now working, was: Composites implementing components problem

[Simon Laws]

On 4/14/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Simon Laws wrote:
> On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On 4/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 4/12/07, Simon Laws < [EMAIL PROTECTED] > wrote:
>> > >
>> > >
>> > >
>> > > On 4/12/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
>> > > >
>> > > > Hi, Simon.
>> > > >
>> > > > For the composite component, it's probably not necessary to
attach
>> > > > the wire.
>> > > > Can you try to add the following code in DeployerImpl.connect()
to
>> > > > see if it
>> > > > helps?
>> > > >
>> > > > public void connect(Map models,
>> > > > org.apache.tuscany.assembly.Component definition)
>> > > > throws WiringException {
>> > > > // Skip the composite
>> > > > if(definition.getImplementation() instanceof Composite) {
>> > > > return;
>> > > > }
>> > > > // End of skip
>> > > >
>> > > > ...
>> > > > }
>> > > >
>> > > > Thanks,
>> > > > Raymond
>> > > >
>> > > > - Original Message -
>> > > > From: "Simon Laws" < [EMAIL PROTECTED]>
>> > > > To: < [EMAIL PROTECTED]>
>> > > > Sent: Thursday, April 12, 2007 12:19 PM
>> > > > Subject: Re: Composites implementing components problem
>> > > >
>> > > >
>> > > > > On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On 4/12/07, Simon Laws < [EMAIL PROTECTED]> wrote:
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >> > On 4/12/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
>> > > > wrote:
>> > > > >> > >
>> > > > >> > > Simon Laws wrote:
>> > > > >> > > > On 4/12/07, Jean-Sebastien Delfino <
>> [EMAIL PROTECTED]>
>> > > > wrote:
>> > > > >> > > >>
>> > > > >> > > >> Simon Laws wrote:
>> > > > >> > > >> > I'm trying to bring the composite-impl sample up. The
>> > > > sample
>> > > > >> > > >> > uses
>> > > > >> > >
>> > > > >> > > >> nested
>> > > > >> > > >> > composite files and if fails trying to wire up the
>> > > > references
>> > > > >> > > from
>> > > > >> > > >> a top
>> > > > >> > > >> > level component (which is implemented in a separate
>> > > > composite -
>> > > > >> > > see
>> > > > >> > > >> > [1]) to
>> > > > >> > > >> > another component.
>> > > > >> > > >> >
>> > > > >> > > >> > The failure happens during the connect phase of
>> > > > >> > > >> > DeployerImpl.deploy(). Here
>> > > > >> > > >> > it loops round all of the references specified in the
>> > > > model for
>> > > > >> > > the
>> > > > >> > > >> > component in question and then goes to the component
>> > > > >> > > implementation to
>> > > > >> > > >> > get
>> > > > >> > > >> > the reference definition so it can subsequently
>> create a
>> > > > wire.
>> > > > >> > > Here is
>> > > > >> > > >> > the
>> > > > >> > > >> > top of the loop from DeployerImpl.connect() (I added
>> > > > some
>> > > > >> > > comments
>> > > > >> > > >> > here to
>> > > > >> > > >> > highlight the points of interest)
>> > > > >> > &