date:20070702

On 7/2/07, haleh mahbod [EMAIL PROTECTED] wrote:

I agree with Simon Nash that we need a manual copy of the 'whole' website
on
TuscanyWiki since otherwise it will be very difficult for those who are
not
committers to see what their changes look like. I re-organized the wiki
before it got locked and I would have not been able to do it if I could
not
see how my changes affected the navigation and flow of things.

Tuscany wiki was organized in such a way that all related documentation
for
each subproject appeared under that subproject and there were two
categories
under documentation 1) Completed documentation 2) work in progress
It would be good to maintain this for clarity.

On 7/1/07, Luciano Resende [EMAIL PROTECTED] wrote:

I'd say, SCA Native Project would be on the same level of SCA Java
Project. I think what we have today on the website is similar to this,
but it gives the distinction between Java/C++ in a deeper level, and
for the tuscanywiki space, i think we can avoid this extra level. The
main goal here is group related information together in a organized
way, and try to avoid content to be put directly on the root level of
the tuscanywiki.

The TuscanyWiki space already have part of what I described, but not
many content, other then the copy of the old website is available as
of now.

Thoughts ?

On 7/1/07, Mike Edwards [EMAIL PROTECTED] wrote:
Luciano,

How does this compare with the existing structure? This seems to
approach things from a Java perspective rather than an SCA / SDO
perspective - is that right?

It might be useful to create an example of what you mean in the
TuscanyWiki psace...

Yours, Mike.

Luciano Resende wrote:
I'd like to propose using a structure similar to the one described
below to group documents together and make it easier to find related
information. It's probably good not to have very deep hierarchy, and
maybe start grouping things on a specific level via page name (e.g
distribution-import-export, distribution-model, etc)

SCA Java Project
|
|--- SCA related Documents

SDO Java Project
|
|--- SDO related Documents

DAS Java Project
|
|--- DAS related Documents

Infrastructure
|
|--- Infra related Documents such as builds, sync, etc

Website
|
|--- Website related documents and old website copy

Thoughts ?

On 6/30/07, Simon Laws [EMAIL PROTECTED] wrote:

On 6/15/07, Simon Nash [EMAIL PROTECTED] wrote:

I'd like to retain the copied pages from the Tuscany web
site. As
Venkat
said, this makes it easy for non-committers to develop and
preview
proposed
updates to the Web site. I agree that it would be good to create
a
new
front page for the Wiki, with the copied Web site home page
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home
linked from the TUSCANYWIKI front page.

Simon

Simon Laws wrote:

I agree. Looking at it now it is confusing with the complete
copy
of the
web
site material presented on the front page. It's not clear where
the
definitive source of this material is.

+1 to the proposal for changing the front page of TUSCANYWIKI.
I
would
have
thought we can just start with a subpage of TUSCANYWIKI for
main
site
pages
in preparation. Everthing else is wiki content with an
organization of
our
choosing.

Regards

Simon

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

I've had a go at reorganizing the front page of the wiki. But it's
a
wiki so
if you don't like it

Simon

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

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

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

There is a manual copy of the website on the wiki - see the linkTuscany
Website Pages In
Preparationhttp://cwiki.apache.org/confluence/display/TUSCANYWIKI/Manual+Copy+Of+The+Tuscany+Website
at the bottom of the wiki front page (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home). I think that
that is an apporpriate place to do web page preparation work.

What I thought Luciano was proposing was a simple organization of any wiki
pages that are not intended to be part of the web site. It's very useful to
have the wiki space for creating arbitrary pages where we can record
information about ongoing work. This doesn't mean these

Re: How are we going to use the Tuscany Wiki space?

2007-07-02 Thread Luciano Resende

+1 That's what I was thinking about... sorry if it was causing any confusion...

On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:

On 7/2/07, haleh mahbod [EMAIL PROTECTED] wrote:

On 7/1/07, Luciano Resende [EMAIL PROTECTED] wrote:

The TuscanyWiki space already have part of what I described, but not
many content, other then the copy of the old website is available as
of now.

Thoughts ?

On 7/1/07, Mike Edwards [EMAIL PROTECTED] wrote:
Luciano,

How does this compare with the existing structure? This seems to
approach things from a Java perspective rather than an SCA / SDO
perspective - is that right?

It might be useful to create an example of what you mean in the
TuscanyWiki psace...

Yours, Mike.

SCA Java Project
|
|--- SCA related Documents

SDO Java Project
|
|--- SDO related Documents

DAS Java Project
|
|--- DAS related Documents

Infrastructure
|
|--- Infra related Documents such as builds, sync, etc

Website
|
|--- Website related documents and old website copy

Thoughts ?

On 6/30/07, Simon Laws [EMAIL PROTECTED] wrote:

On 6/15/07, Simon Nash [EMAIL PROTECTED] wrote:

Simon

Simon Laws wrote:

I agree. Looking at it now it is confusing with the complete
copy
of the
web
site material presented on the front page. It's not clear where
the
definitive source of this material is.

Regards

Simon

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

I've had a go at reorganizing the front page of the wiki. But it's
a
wiki so
if you don't like it

Simon

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

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

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

Re: [VOTE] Release Tuscany Java DAS beta1


On 7/1/07, Luciano Resende [EMAIL PROTECTED] wrote:


Please vote to release the beta1 distribution of Tuscany DAS for Java.

The Release Candidate RC1 for Tuscany Java DAS beta1 is available at

   http://people.apache.org/~lresende/tuscany/das-beta1-rc1/

Release Notes are available at


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/distribution/binary/RELEASE_NOTES

The maven repository artifacts are posted in a staging repository and
is available at

   http://people.apache.org/~lresende/tuscany/das-beta1-rc1/maven/

The release audit tool (rat) results are available at


http://people.apache.org/~lresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log

The tag for the source code is at


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/

Seems OK to me, here is my +1



Looks ok so +1 from me.

The few issues I found are below, none of them are blocking problems (it
maybe worth while fixing the sample issues anyway)  but if the release is
respun for some reason it would be good to fix some of these:

  ...ant

- The distributions downloads unzip into a folder of the same name

- A sentence or two at the top of the release notes saying what DAS is would
be good

- The NOTICE file still includes the incubator disclaimer even though
there's now a separate disclaimer file (I've fixed that in trunk)

- Does there really need to be a BUILDING file in the bin distro? Maybe
instead an INSTALL file that says how DAS could be used (the dependencies
and config file etc)?

- Could the last two remaining RAT warnings be fixed - what license is the
JSTL stuff?

- Could have a top level sample overview readme in the samples dir saying
what each of the samples does

- The derby-10.1.2.1.jar is included in samples\customer but the readme for
samples\companyweb says to go download it

- The dastest sample dbs isn't included in the binary distro so have to
build from src distro and copy form there to test the samples in the bin
distro

- the customer sample readme doesn't actually say how to run or use the
sample

- I can't get the ajax sample to work, fails with the error below. I have
setup tomcat as described in the readme, looking in the tomcat databases
folder the ajaxdastest does not exist so wasn't ever created yet:

java.lang.NullPointerException at
org.apache.tuscany.das.rdb.dbconfig.DBHelper.dropDatabaseTables(
DBHelper.java:185)
   at
org.apache.tuscany.das.rdb.dbconfig.DBInitializer.initializeDatabase(
DBInitializer.java:128)
   at
org.apache.tuscany.das.rdb.dbconfig.DBInitializer.refreshDatabaseData(
DBInitializer.java:152)
   at org.apache.tuscany.samples.web.CommandServlet.refreshDB(
CommandServlet.java:51)
   at org.apache.tuscany.samples.web.CommandServlet.init(
CommandServlet.java:60)
   at org.apache.catalina.core.StandardWrapper.loadServlet(
StandardWrapper.java:1161)
   at org.apache.catalina.core.StandardWrapper.allocate(
StandardWrapper.java:806)
   at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:133)
   at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:175)
   at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:128)
   at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:104)
   at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:109)
   at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:216)
   at org.apache.coyote.http11.Http11Processor.process(
Http11Processor.java:844)
   at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:634)
   at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
JIoEndpoint.java:445)
   at java.lang.Thread.run(Thread.java:595)

Re: [VOTE] Release Tuscany Java DAS beta1


On 7/2/07, ant elder [EMAIL PROTECTED] wrote:




On 7/1/07, Luciano Resende [EMAIL PROTECTED] wrote:

 Please vote to release the beta1 distribution of Tuscany DAS for Java.

 The Release Candidate RC1 for Tuscany Java DAS beta1 is available at


http://people.apache.org/~lresende/tuscany/das-beta1-rc1/http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/

 Release Notes are available at


 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/distribution/binary/RELEASE_NOTES

 The maven repository artifacts are posted in a staging repository and
 is available at


http://people.apache.org/~lresende/tuscany/das-beta1-rc1/maven/http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/maven/

 The release audit tool (rat) results are available at


 
http://people.apache.org/~lresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.loghttp://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log

 The tag for the source code is at


 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/

 Seems OK to me, here is my +1


Looks ok so +1 from me.

The few issues I found are below, none of them are blocking problems (it
maybe worth while fixing the sample issues anyway)  but if the release is
respun for some reason it would be good to fix some of these:

   ...ant

- The distributions downloads unzip into a folder of the same name

- A sentence or two at the top of the release notes saying what DAS is
would be good

- The NOTICE file still includes the incubator disclaimer even though
there's now a separate disclaimer file (I've fixed that in trunk)

- Does there really need to be a BUILDING file in the bin distro? Maybe
instead an INSTALL file that says how DAS could be used (the dependencies
and config file etc)?

- Could the last two remaining RAT warnings be fixed - what license is the
JSTL stuff?

- Could have a top level sample overview readme in the samples dir saying
what each of the samples does

- The derby-10.1.2.1.jar is included in samples\customer but the readme
for samples\companyweb says to go download it

- The dastest sample dbs isn't included in the binary distro so have to
build from src distro and copy form there to test the samples in the bin
distro

- the customer sample readme doesn't actually say how to run or use the
sample

- I can't get the ajax sample to work, fails with the error below. I have
setup tomcat as described in the readme, looking in the tomcat databases
folder the ajaxdastest does not exist so wasn't ever created yet:

java.lang.NullPointerException at
org.apache.tuscany.das.rdb.dbconfig.DBHelper.dropDatabaseTables(
DBHelper.java:185)
at
org.apache.tuscany.das.rdb.dbconfig.DBInitializer.initializeDatabase(
DBInitializer.java :128)
at
org.apache.tuscany.das.rdb.dbconfig.DBInitializer.refreshDatabaseData(
DBInitializer.java:152)
at org.apache.tuscany.samples.web.CommandServlet.refreshDB(
CommandServlet.java:51)
at org.apache.tuscany.samples.web.CommandServlet.init(
CommandServlet.java:60)
at org.apache.catalina.core.StandardWrapper.loadServlet(
StandardWrapper.java:1161)
at org.apache.catalina.core.StandardWrapper.allocate (
StandardWrapper.java:806)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:133)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:104)
at org.apache.catalina.core.StandardEngineValve.invoke (
StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:216)
at org.apache.coyote.http11.Http11Processor.process(
Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:634)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java :595)



Chatted with Luciano, the ajax sample issue was a problem in my tomcat
config and the sample works fine now.

  ...ant

Re: The complete patch for TUSCANY-1341 is available

2007-07-02 Thread Simon Nash


I am reconsidering the changes made in stage 2 of this patch, which
added two new methods to the Binding SPI interface.

I made these changes for the reasons stated in
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
and
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html
These methods allow bindings to be marked as either callback or
forward bindings.  This allows callback binding semantics to be
supported correctly with relatively little change to the core runtime.

Unfortunately these is a flip side to these benefits.  Adding these
methods changes the current published stable Binding SPI, and
(probably worse) introduces pollution of the Binding SPI to carry
information that is there for the convenience of the core runtime,
rather than an intrinsic part of the binding semantics.

The alternative is to keep the Binding SPI as it was, and make more
extensive changes in the core runtime to use the more correct version
of the model as proposed in
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html

I will look at the impact to the core runtime of the alternative
approach that keeps the Binding SPI unchanged and I will post my
findings back to this list.

This discussion only affects the Binding SPI changes in stage 2 of
the patch.  It does not affect the provider SPI changes in stage 1
of the patch.

I'd be interested in any comments on the above or on any other aspects
of this patch.

  Simon

Simon Nash wrote:

Please review and apply the patch for TUSCANY-1341 which I have
attached to the JIRA in 7 parts as follows.

Stages 1, 2 and 3 contain new SPIs and bug fixes that are needed
to support callbacks across bindings.  They do not have cross-
dependencies and can be applied in any order.

Stage 4 depends on the previous stages and provides core runtime
enablement for the new callback functionality.

Stage 5 depends on the previous stages and provides callback support
in the Web Service binding.

Stage 6 provides a new sample to illustrate this capability.

Stage 7 makes this new sample part of the build.

See my comments in the JIRA for the above patches for more details
of what they contain.

  Simon




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

[jira] Updated: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests

2007-07-02 Thread Rajini Sivaram (JIRA)


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

Rajini Sivaram updated TUSCANY-1382:


Attachment: (was: itest-osgi-implementation.zip)

 Minor fixes to OSGi declarative services support and additional tests
 -

 Key: TUSCANY-1382
 URL: https://issues.apache.org/jira/browse/TUSCANY-1382
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA OSGi Integration
Reporter: Rajini Sivaram
 Attachments: sample-osgi-supplychain-patch.txt


 Attached are patches to osgi-implementation support. 
 Changes include improved support for declarative services and versioning and 
 changes to the directory structure to make it in line with 
 implementation-java.
 Integration tests are included in the zip file.

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


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

[jira] Updated: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests

2007-07-02 Thread Rajini Sivaram (JIRA)


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

Rajini Sivaram updated TUSCANY-1382:


Attachment: (was: tuscany-implementation-osgi-patch.txt)

 Minor fixes to OSGi declarative services support and additional tests
 -

 Key: TUSCANY-1382
 URL: https://issues.apache.org/jira/browse/TUSCANY-1382
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA OSGi Integration
Reporter: Rajini Sivaram
 Attachments: sample-osgi-supplychain-patch.txt


 Attached are patches to osgi-implementation support. 
 Changes include improved support for declarative services and versioning and 
 changes to the directory structure to make it in line with 
 implementation-java.
 Integration tests are included in the zip file.

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


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

[jira] Updated: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests

2007-07-02 Thread Rajini Sivaram (JIRA)


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

Rajini Sivaram updated TUSCANY-1382:


Attachment: itest-osgi-implementation.zip
tuscany-implementation-osgi.zip

Ant,

New zip files for modules/implementation-osgi and itest/osgi-implementation are 
attached. 

Thank you...

- Rajini

 Minor fixes to OSGi declarative services support and additional tests
 -

 Key: TUSCANY-1382
 URL: https://issues.apache.org/jira/browse/TUSCANY-1382
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA OSGi Integration
Reporter: Rajini Sivaram
 Attachments: itest-osgi-implementation.zip, 
 sample-osgi-supplychain-patch.txt, tuscany-implementation-osgi.zip


 Attached are patches to osgi-implementation support. 
 Changes include improved support for declarative services and versioning and 
 changes to the directory structure to make it in line with 
 implementation-java.
 Integration tests are included in the zip file.

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


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

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating


On 6/29/07, ant elder [EMAIL PROTECTED] wrote:


On 6/28/07, Venkata Krishnan [EMAIL PROTECTED] wrote:

 Hi,

 Please review and vote on the 0.91 release artifacts of Tuscany SCA for
 Java.

 The artifacts are available for review at:
 http://people.apache.org/~svkrish/tuscany/0.91-rc1/

 The SVN tag for the release is:


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/

 Seems ok to me, so here is my +1.

 Thanks.

 - Venkat


+1

This looks pretty good to me. There's a few things that could be improved
-
missing readme's for demos and some samples, some missing license headers
have crept in, the rmi calculator client fails for me - none of those are
blocking problems though. The biggest is for 0.90 we were asked to list
all
the jars under the Apache license just to make the licensing clear but
thats
missing, again not a blocker but it would be good to show we listen. I'll
try to fix most of these in the brn in case we do cut another rc, but
unless
many more problems are discovered this rc gets my vote.

   ...ant




Apologies for being so late to review the RC. Was away last week. Anyhow...

I got a clean build of the source distro.
I went through the samples in the bind distro. The issues I found are
attached below. Ant, I'm assuming you have fixed many of these. If you let
me know which ones are outstanding I'll go and provide fixes.

None of these in their own right are blockers but together I think they mark
a backward step in terms of quality from 0.90.  I would like to see another
RC but as I'm so late in doing this have to vote -0.5.


Get rid of svg files from the distribution

Samples/README - overview samples list doesn't match current samples list

calculator-rmi-reference
--

Doesn't run for me from the command line.

C:\simon\tuscany\r0.91-rc1\apache-
tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
ncubating\samples\calculator-rmi-referenceant run
Buildfile: build.xml

run:
[java] Composite assembly problem: No targets for reference: addService
[java] Composite assembly problem: No targets for reference:
divideService
[java] Composite assembly problem: No targets for reference:
multiplyServic
e
[java] Composite assembly problem: No targets for reference:
subtractServic
e
[java] Exception in thread main java.lang.NullPointerException
[java] at calculator.CalculatorServiceImpl.add(
CalculatorServiceImpl.ja
va:54)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAcces
sorImpl.java:64)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMet
hodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:615)
[java] at
org.apache.tuscany.sca.implementation.java.invocation.JavaTar
getInvoker.invokeTarget(JavaTargetInvoker.java:112)
[java] at
org.apache.tuscany.sca.implementation.java.invocation.JavaTar
getInvoker.invoke(JavaTargetInvoker.java:134)
[java] at
org.apache.tuscany.sca.implementation.java.invocation.TargetI
nvokerInvoker.invoke(TargetInvokerInvoker.java:46)
[java] at
org.apache.tuscany.sca.core.invocation.AbstractInvocationHand
ler.invoke(AbstractInvocationHandler.java:84)
[java] at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i
nvoke(JDKInvocationHandler.java:73)
[java] at $Proxy1.add(Unknown Source)
[java] at calculator.CalculatorClient.main(CalculatorClient.java
:35)
[java] Java Result: 1

Calculator-webapp
--

The ant file produces a war called sample-calculator-web.war rather than
sample-calculator-webapp.war

chat-webapp
--

has no README, diagram or ant build file. Here's the URL you need to use

http://localhost:8080/sample-chat-webapp/

databining-echo
---

C:\simon\tuscany\r0.91-rc1\apache-
tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
ncubating\samples\databinding-echoant run
Buildfile: build.xml

run:
[java] Exception in thread main org.osoa.sca.ServiceRuntimeException:
jav
a.lang.IllegalStateException: java.lang.ClassNotFoundException:
echo.module.Echo
ModuleActivator
[java] at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta
nce(SCADomain.java:263)
[java] at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC
ADomain.java:68)
[java] at dbecho.EchoDataBindingClient.main(
EchoDataBindingClient.java:
31)
[java] Caused by: java.lang.IllegalStateException:
java.lang.ClassNotFoundE
xception: echo.module.EchoModuleActivator
[java] at
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeB
uilder.getServices(ReallySmallRuntimeBuilder.java:276)
[java] at
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.
startModules(ReallySmallRuntime.java:154)
[java] at

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating


Thanks Simon.  Let me go fix these things.  Will call out for help when
needed.  :)
- Venkat


On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:


On 6/29/07, ant elder [EMAIL PROTECTED] wrote:

 On 6/28/07, Venkata Krishnan [EMAIL PROTECTED] wrote:
 
  Hi,
 
  Please review and vote on the 0.91 release artifacts of Tuscany SCA
for
  Java.
 
  The artifacts are available for review at:
  http://people.apache.org/~svkrish/tuscany/0.91-rc1/
 
  The SVN tag for the release is:
 
 

https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
 
  Seems ok to me, so here is my +1.
 
  Thanks.
 
  - Venkat
 

 +1

 This looks pretty good to me. There's a few things that could be
improved
 -
 missing readme's for demos and some samples, some missing license
headers
 have crept in, the rmi calculator client fails for me - none of those
are
 blocking problems though. The biggest is for 0.90 we were asked to list
 all
 the jars under the Apache license just to make the licensing clear but
 thats
 missing, again not a blocker but it would be good to show we listen.
I'll
 try to fix most of these in the brn in case we do cut another rc, but
 unless
 many more problems are discovered this rc gets my vote.

...ant



Apologies for being so late to review the RC. Was away last week.
Anyhow...

I got a clean build of the source distro.
I went through the samples in the bind distro. The issues I found are
attached below. Ant, I'm assuming you have fixed many of these. If you let
me know which ones are outstanding I'll go and provide fixes.

None of these in their own right are blockers but together I think they
mark
a backward step in terms of quality from 0.90.  I would like to see
another
RC but as I'm so late in doing this have to vote -0.5.


Get rid of svg files from the distribution

Samples/README - overview samples list doesn't match current samples list

calculator-rmi-reference
--

Doesn't run for me from the command line.

C:\simon\tuscany\r0.91-rc1\apache-
tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
ncubating\samples\calculator-rmi-referenceant run
Buildfile: build.xml

run:
 [java] Composite assembly problem: No targets for reference:
addService
 [java] Composite assembly problem: No targets for reference:
divideService
 [java] Composite assembly problem: No targets for reference:
multiplyServic
e
 [java] Composite assembly problem: No targets for reference:
subtractServic
e
 [java] Exception in thread main java.lang.NullPointerException
 [java] at calculator.CalculatorServiceImpl.add(
CalculatorServiceImpl.ja
va:54)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAcces
sorImpl.java:64)
 [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMet
hodAccessorImpl.java:43)
 [java] at java.lang.reflect.Method.invoke(Method.java:615)
 [java] at
org.apache.tuscany.sca.implementation.java.invocation.JavaTar
getInvoker.invokeTarget(JavaTargetInvoker.java:112)
 [java] at
org.apache.tuscany.sca.implementation.java.invocation.JavaTar
getInvoker.invoke(JavaTargetInvoker.java:134)
 [java] at
org.apache.tuscany.sca.implementation.java.invocation.TargetI
nvokerInvoker.invoke(TargetInvokerInvoker.java:46)
 [java] at
org.apache.tuscany.sca.core.invocation.AbstractInvocationHand
ler.invoke(AbstractInvocationHandler.java:84)
 [java] at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i
nvoke(JDKInvocationHandler.java:73)
 [java] at $Proxy1.add(Unknown Source)
 [java] at calculator.CalculatorClient.main(CalculatorClient.java
:35)
 [java] Java Result: 1

Calculator-webapp
--

The ant file produces a war called sample-calculator-web.war rather than
sample-calculator-webapp.war

chat-webapp
--

has no README, diagram or ant build file. Here's the URL you need to use

http://localhost:8080/sample-chat-webapp/

databining-echo
---

C:\simon\tuscany\r0.91-rc1\apache-
tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
ncubating\samples\databinding-echoant run
Buildfile: build.xml

run:
 [java] Exception in thread main
org.osoa.sca.ServiceRuntimeException:
jav
a.lang.IllegalStateException: java.lang.ClassNotFoundException:
echo.module.Echo
ModuleActivator
 [java] at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta
nce(SCADomain.java:263)
 [java] at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC
ADomain.java:68)
 [java] at dbecho.EchoDataBindingClient.main(
EchoDataBindingClient.java:
31)
 [java] Caused by: java.lang.IllegalStateException:
java.lang.ClassNotFoundE
xception: echo.module.EchoModuleActivator
 [java] at
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntimeB

Re: SCA 0.92 release?


Hi,

I am looking at the Policy Framework and shall update the wiki on the
specifics soon.  Once this is done to some level, I'd also like to help a
bit with the ws-* things (may be WS-Security to start with) that Ant has
listed on the wiki page.

- Venkat

On 6/30/07, ant elder [EMAIL PROTECTED] wrote:


With the SCA 0.91 release now being voted on how about starting on 0.92?

I've already been adding some things I'm interested in getting done to the
next release wiki page -

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
so far thats mainly related to improving web services functionality.

So anyone else interested in helping with an 0.92 release or have any
function they'd like to suggest or add to the wiki page? How does aiming
for
getting it done 4 - 6 weeks again sound?

   ...ant

[jira] Commented: (TUSCANY-1379) Admin:Core start/stop/query admin services

2007-07-02 Thread Simon Laws (JIRA)

[
https://issues.apache.org/jira/browse/TUSCANY-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509538
]

Simon Laws commented on TUSCANY-1379:
-

As part of the distributed runtime there is an implementation of a node
(somewhere where Tuscany applications can run) that contains a NodeSCADomain
instance which is provided to run a composite containing management components.
The node looks for a file called nodename.node which is actually just a normal
composite file. I have only created one management component to date,
ComponentRegistry, but of course it's easy to create new ones and use all of
the facilities to expose them to the outside world.

The node can also contain 1 or more DistributedSCADomains. These are pretty
similar to the embedded domain with a few small exceptions. Once change is that
the DistributedSCADomain holds a reference to the NodeSCADomain and in this way
various parts of the runtime can get hold of local references to management
components as required.

One thing that worries me about this is that the .node file is expected to hold
a specific set of management components for the node to work and I haven't
included specific validation to ensure that this is the case yet.

Admin:Core start/stop/query admin services
--

Key: TUSCANY-1379
URL: https://issues.apache.org/jira/browse/TUSCANY-1379
Project: Tuscany
Issue Type: Improvement
Affects Versions: Java-SCA-Next
Reporter: ant elder
Fix For: Java-SCA-Next

Admin:Core start/stop/query admin services - implement basic core services to
start/stop/query running components.

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

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

Re: SCA 0.92 release?


On 7/2/07, Venkata Krishnan [EMAIL PROTECTED] wrote:


Hi,

I am looking at the Policy Framework and shall update the wiki on the
specifics soon.  Once this is done to some level, I'd also like to help a
bit with the ws-* things (may be WS-Security to start with) that Ant has
listed on the wiki page.

- Venkat

On 6/30/07, ant elder [EMAIL PROTECTED] wrote:

 With the SCA 0.91 release now being voted on how about starting on 0.92?

 I've already been adding some things I'm interested in getting done to
the
 next release wiki page -


http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
 so far thats mainly related to improving web services functionality.

 So anyone else interested in helping with an 0.92 release or have any
 function they'd like to suggest or add to the wiki page? How does aiming
 for
 getting it done 4 - 6 weeks again sound?

...ant




The above link has an extrenuous - on the end. Taking that off gets me to
the page. Can we move this information across the to the new wiki space (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
everyone (including non committers) can add to it?

I'm working on the next phase of the distributed runtime which I want to get
into the next release. This involves a few items.

SCA Binding
Topology model
Distributed domain
Node implementation
Management assembly

Also I need some of the ws items, in particular the ability to run without
wsdl, so can help out there.

We need to do something about logging and events to improvide runtime
usability. We've talked about it before but not done anything yet. Ties into
the management assembly.

I'd also like to see the JMS binding in the release but can't commit to
doing lots more work on including spec features. It's been working fine for
me in my limited synchronous/rpc model. If I get time I'll take a look to
see what it will take to add minimum asynch support but if anyone else
fancies having a go at this then it's a good way to learn about Tuscany
extensions.

I'll add these to the web page.

Simon

[jira] Updated: (TUSCANY-1393) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:int


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

Ron Gavlin updated TUSCANY-1393:


Attachment: sdo-TUSCANY-1393.patch

This patch resolves the problem by adding missing methods to 
DataObjectBase.java. It also includes a new test case which exposed the 
original problem.

 ClassCastException saving codegen-based DataGraph with ChangeSummary 
 containing an xsd:int
 --

 Key: TUSCANY-1393
 URL: https://issues.apache.org/jira/browse/TUSCANY-1393
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
 Attachments: sdo-TUSCANY-1393.patch


 Please add the following test case to 
 sdo\tools\src\test\java\org\apache\tuscany\sdo\test\ChangeSummaryGenTestCase.java.
  The new test method currently generates a ClassCastException when an Integer 
 is expected and a Double is provided. I have listed the stacktrace below:
 
 public void testChangeSummaryOnDataGraphWithInt() throws Exception {
   
   HelperContext hc = HelperProvider.getDefaultContext();
   CustomerFactory factory = CustomerFactory.INSTANCE;
   factory.register(hc);
   Customer customer = factory.createCustomer();
   Account account = factory.createAccount();
   customer.setAccount(account);
   DataObject customerDO = (DataObject) customer; 
   DataGraph dg = SDOUtil.createDataGraph();
   SDOUtil.setRootObject(dg, customerDO);
   dg.getChangeSummary().beginLogging();
   dg.getRootObject().getDataObject(0).delete();
   ByteArrayOutputStream baos = new ByteArrayOutputStream();
   SDOUtil.saveDataGraph(dg, baos, null);
 }
 
 testChangeSummaryOnDataGraphWithInt(org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase)
 java.lang.ClassCastException: java.lang.Double
   at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertIntToString(ModelFactoryImpl.java:2079)
   at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertToString(ModelFactoryImpl.java:321)
   at 
 org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.convertToString(FactoryBase.java:284)
   at 
 org.eclipse.emf.ecore.util.EcoreUtil.convertToString(EcoreUtil.java:2994)
   at 
 org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getDataValue(FeatureChangeImpl.java:228)
   at 
 org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.eIsSet(FeatureChangeImpl.java:771)
   at 
 org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:818)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1107)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:620)
   at 
 org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$SaveImpl.traverse(DataGraphResourceFactoryImpl.java:382)
   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203)
   at 
 org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
   at 
 org.apache.tuscany.sdo.helper.SDOHelperImpl.saveDataGraph(SDOHelperImpl.java:201)
   at org.apache.tuscany.sdo.api.SDOUtil.saveDataGraph(SDOUtil.java:158)
   at 
 org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithInt(ChangeSummaryGenTestCase.java:128)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at

[jira] Commented: (TUSCANY-1395) XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or xsd:boolean types


[ 
https://issues.apache.org/jira/browse/TUSCANY-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509542
 ] 

Ron Gavlin commented on TUSCANY-1395:
-

Although the symptoms of this problem are different from Bug TUSCANY-1393, the 
solution is the same. Feel free to mark this resolved once the patch for 
TUSCANY-1393 is applied. 

 XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or 
 xsd:boolean types
 -

 Key: TUSCANY-1395
 URL: https://issues.apache.org/jira/browse/TUSCANY-1395
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical

 Classes generated by XSD2JavaGenerator with the -noUnsettable option do not 
 compile if the associated schema has elements/attributes of type xsd:int or 
 xsd:boolean. 
 In order to reproduce the problem, invoke XSD2JavaGenerator with the 
 -noUnsettable flag and the customerAccount.xsd test schema. The following 
 method in the generated com.example.customer.impl.AccountImpl class has a 
 compiler error in its last line [notify(int, int, int, int) is invalid]. 
   public void setAccountNum(int newAccountNum)
   {
 int oldAccountNum = accountNum;
 accountNum = newAccountNum;
 if (isNotifying())
   notify(ChangeKind.SET, ACCOUNT_NUM, oldAccountNum, accountNum); // 
 COMPILER ERROR
   }
 - Ron

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


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

[jira] Created: (TUSCANY-1399) Generate SDO test classes using maven-sdo-plugin

Generate SDO test classes using maven-sdo-plugin


 Key: TUSCANY-1399
 URL: https://issues.apache.org/jira/browse/TUSCANY-1399
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Tools
Reporter: Ron Gavlin
Priority: Minor


Tuscany needs a better way to test the various options supported by the 
XSD2JavaGenerator. The first step is to code-generate test classes on the fly 
using the maven-sdo-plugin rather than managing code-generated classes directly 
within SVN. Then a significant number of the same tests could be run multiple 
times using different options passed to the maven-sdo-plugin.

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


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

Re: [VOTE] Release Tuscany Java DAS beta1


On 7/2/07, ant elder [EMAIL PROTECTED] wrote:


On 7/2/07, ant elder [EMAIL PROTECTED] wrote:



 On 7/1/07, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Please vote to release the beta1 distribution of Tuscany DAS for Java.
 
  The Release Candidate RC1 for Tuscany Java DAS beta1 is available at
 
 http://people.apache.org/~lresende/tuscany/das-beta1-rc1/
http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/
 
  Release Notes are available at
 
 
 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/distribution/binary/RELEASE_NOTES
 
  The maven repository artifacts are posted in a staging repository and
  is available at
 
 http://people.apache.org/~lresende/tuscany/das-beta1-rc1/maven/
http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/maven/
 
  The release audit tool (rat) results are available at
 
 
 
http://people.apache.org/~lresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log

http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log

 
  The tag for the source code is at
 
 
 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/
 
  Seems OK to me, here is my +1


 Looks ok so +1 from me.

 The few issues I found are below, none of them are blocking problems (it
 maybe worth while fixing the sample issues anyway)  but if the release
is
 respun for some reason it would be good to fix some of these:

...ant

 - The distributions downloads unzip into a folder of the same name

 - A sentence or two at the top of the release notes saying what DAS is
 would be good

 - The NOTICE file still includes the incubator disclaimer even though
 there's now a separate disclaimer file (I've fixed that in trunk)

 - Does there really need to be a BUILDING file in the bin distro? Maybe
 instead an INSTALL file that says how DAS could be used (the
dependencies
 and config file etc)?

 - Could the last two remaining RAT warnings be fixed - what license is
the
 JSTL stuff?

 - Could have a top level sample overview readme in the samples dir
saying
 what each of the samples does

 - The derby-10.1.2.1.jar is included in samples\customer but the readme
 for samples\companyweb says to go download it

 - The dastest sample dbs isn't included in the binary distro so have to
 build from src distro and copy form there to test the samples in the bin
 distro

 - the customer sample readme doesn't actually say how to run or use the
 sample

 - I can't get the ajax sample to work, fails with the error below. I
have
 setup tomcat as described in the readme, looking in the tomcat databases
 folder the ajaxdastest does not exist so wasn't ever created yet:

 java.lang.NullPointerException at
 org.apache.tuscany.das.rdb.dbconfig.DBHelper.dropDatabaseTables(
 DBHelper.java:185)
 at
 org.apache.tuscany.das.rdb.dbconfig.DBInitializer.initializeDatabase(
 DBInitializer.java :128)
 at
 org.apache.tuscany.das.rdb.dbconfig.DBInitializer.refreshDatabaseData(
 DBInitializer.java:152)
 at org.apache.tuscany.samples.web.CommandServlet.refreshDB(
 CommandServlet.java:51)
 at org.apache.tuscany.samples.web.CommandServlet.init(
 CommandServlet.java:60)
 at org.apache.catalina.core.StandardWrapper.loadServlet(
 StandardWrapper.java:1161)
 at org.apache.catalina.core.StandardWrapper.allocate (
 StandardWrapper.java:806)
 at org.apache.catalina.core.StandardWrapperValve.invoke(
 StandardWrapperValve.java:133)
 at org.apache.catalina.core.StandardContextValve.invoke(
 StandardContextValve.java:175)
 at org.apache.catalina.core.StandardHostValve.invoke(
 StandardHostValve.java:128)
 at org.apache.catalina.valves.ErrorReportValve.invoke(
 ErrorReportValve.java:104)
 at org.apache.catalina.core.StandardEngineValve.invoke (
 StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(
 CoyoteAdapter.java:216)
 at org.apache.coyote.http11.Http11Processor.process(
 Http11Processor.java:844)
 at
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
 Http11Protocol.java:634)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
 JIoEndpoint.java:445)
 at java.lang.Thread.run(Thread.java :595)


Chatted with Luciano, the ajax sample issue was a problem in my tomcat
config and the sample works fine now.

   ...ant



I started taking a look at the binary distro but had to move over to the
source distro to get the sample DB (as ant mentioned above) but I'm having
trouble building it. When I unpack the source distro and run maven at the
top level I get...

[INFO] [compiler:compile]
[INFO] Compiling 107 source files to C:\simon\tuscany\das-
r1.0-beta1-rc1\tuscany
-
das-1.0-incubating-beta1-src\tuscany-das-1.0-incubating-beta1\rdb\target\classe
s
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[jira] Updated: (TUSCANY-1237) DAS should support JDK 1.4


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

Ron Gavlin updated TUSCANY-1237:


Attachment: das-TUSCANY-1237.patch

 DAS should support JDK 1.4
 --

 Key: TUSCANY-1237
 URL: https://issues.apache.org/jira/browse/TUSCANY-1237
 Project: Tuscany
  Issue Type: Improvement
  Components: Java DAS RDB
 Environment: Windows, Sun JDK 1.4.2_11
Reporter: Ron Gavlin
 Fix For: Java-DAS-Next

 Attachments: das-TUSCANY-1237.patch


 Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would 
 seem to make sense for the DAS
 JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany 
 SDO currently supports JDK 1.4+. After browsing the DAS source code, there 
 appear to be only a few places that leverage JDK 1.5 features. These could 
 easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 
 until SDO 3 is released at which time I presume SDO will require JDK 1.5.

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


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

[jira] Updated: (TUSCANY-1237) DAS should support JDK 1.4


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

Ron Gavlin updated TUSCANY-1237:


Patch Info: [Patch Available]

 DAS should support JDK 1.4
 --

 Key: TUSCANY-1237
 URL: https://issues.apache.org/jira/browse/TUSCANY-1237
 Project: Tuscany
  Issue Type: Improvement
  Components: Java DAS RDB
 Environment: Windows, Sun JDK 1.4.2_11
Reporter: Ron Gavlin
 Fix For: Java-DAS-Next

 Attachments: das-TUSCANY-1237.patch


 Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would 
 seem to make sense for the DAS
 JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany 
 SDO currently supports JDK 1.4+. After browsing the DAS source code, there 
 appear to be only a few places that leverage JDK 1.5 features. These could 
 easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 
 until SDO 3 is released at which time I presume SDO will require JDK 1.5.

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


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

[jira] Updated: (TUSCANY-1393) ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:int


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

Ron Gavlin updated TUSCANY-1393:


Patch Info: [Patch Available]

 ClassCastException saving codegen-based DataGraph with ChangeSummary 
 containing an xsd:int
 --

 Key: TUSCANY-1393
 URL: https://issues.apache.org/jira/browse/TUSCANY-1393
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
 Attachments: sdo-TUSCANY-1393.patch


 Please add the following test case to 
 sdo\tools\src\test\java\org\apache\tuscany\sdo\test\ChangeSummaryGenTestCase.java.
  The new test method currently generates a ClassCastException when an Integer 
 is expected and a Double is provided. I have listed the stacktrace below:
 
 public void testChangeSummaryOnDataGraphWithInt() throws Exception {
   
   HelperContext hc = HelperProvider.getDefaultContext();
   CustomerFactory factory = CustomerFactory.INSTANCE;
   factory.register(hc);
   Customer customer = factory.createCustomer();
   Account account = factory.createAccount();
   customer.setAccount(account);
   DataObject customerDO = (DataObject) customer; 
   DataGraph dg = SDOUtil.createDataGraph();
   SDOUtil.setRootObject(dg, customerDO);
   dg.getChangeSummary().beginLogging();
   dg.getRootObject().getDataObject(0).delete();
   ByteArrayOutputStream baos = new ByteArrayOutputStream();
   SDOUtil.saveDataGraph(dg, baos, null);
 }
 
 testChangeSummaryOnDataGraphWithInt(org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase)
 java.lang.ClassCastException: java.lang.Double
   at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertIntToString(ModelFactoryImpl.java:2079)
   at 
 org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.convertToString(ModelFactoryImpl.java:321)
   at 
 org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.convertToString(FactoryBase.java:284)
   at 
 org.eclipse.emf.ecore.util.EcoreUtil.convertToString(EcoreUtil.java:2994)
   at 
 org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getDataValue(FeatureChangeImpl.java:228)
   at 
 org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.eIsSet(FeatureChangeImpl.java:771)
   at 
 org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:818)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1107)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1036)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:922)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2182)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1390)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2462)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:620)
   at 
 org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$SaveImpl.traverse(DataGraphResourceFactoryImpl.java:382)
   at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233)
   at 
 org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:203)
   at 
 org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:993)
   at 
 org.apache.tuscany.sdo.helper.SDOHelperImpl.saveDataGraph(SDOHelperImpl.java:201)
   at org.apache.tuscany.sdo.api.SDOUtil.saveDataGraph(SDOUtil.java:158)
   at 
 org.apache.tuscany.sdo.test.ChangeSummaryGenTestCase.testChangeSummaryOnDataGraphWithInt(ChangeSummaryGenTestCase.java:128)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)

[jira] Updated: (TUSCANY-1395) XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or xsd:boolean types


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

Ron Gavlin updated TUSCANY-1395:


Patch Info: [Patch Available]

 XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or 
 xsd:boolean types
 -

 Key: TUSCANY-1395
 URL: https://issues.apache.org/jira/browse/TUSCANY-1395
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical

 Classes generated by XSD2JavaGenerator with the -noUnsettable option do not 
 compile if the associated schema has elements/attributes of type xsd:int or 
 xsd:boolean. 
 In order to reproduce the problem, invoke XSD2JavaGenerator with the 
 -noUnsettable flag and the customerAccount.xsd test schema. The following 
 method in the generated com.example.customer.impl.AccountImpl class has a 
 compiler error in its last line [notify(int, int, int, int) is invalid]. 
   public void setAccountNum(int newAccountNum)
   {
 int oldAccountNum = accountNum;
 accountNum = newAccountNum;
 if (isNotifying())
   notify(ChangeKind.SET, ACCOUNT_NUM, oldAccountNum, accountNum); // 
 COMPILER ERROR
   }
 - Ron

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


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

Behaviour of getList() with open content properties

2007-07-02 Thread Andy Grove


I have a question about the correct behaviour of getList().

If I have an open DataObject and I call getList( foo ) where foo is
not a defined property or an instance property, I would expect
getList() to return NULL. This is currently the case in Tuscany.

If foo is set and later unset, I would still expect getList( foo )
to return NULL. However, in this case, Tuscany returns an empty list.

This appears to be a bug in Tuscany but before I raise a JIRA and
write a CTS test I wanted to ask if this is the intended behaviour and
if I am interpreting the specification correctly here.

Thanks,

Andy Grove
Product Architect, HydraSDO
Rogue Wave Software
http://www.roguewave.com

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

Re: SCA 0.92 release?


On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:


On 7/2/07, Venkata Krishnan [EMAIL PROTECTED] wrote:

 Hi,

 I am looking at the Policy Framework and shall update the wiki on the
 specifics soon.  Once this is done to some level, I'd also like to help
a
 bit with the ws-* things (may be WS-Security to start with) that Ant has
 listed on the wiki page.

 - Venkat

 On 6/30/07, ant elder [EMAIL PROTECTED] wrote:
 
  With the SCA 0.91 release now being voted on how about starting on
0.92?
 
  I've already been adding some things I'm interested in getting done to
 the
  next release wiki page -
 
 

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
  so far thats mainly related to improving web services functionality.
 
  So anyone else interested in helping with an 0.92 release or have any
  function they'd like to suggest or add to the wiki page? How does
aiming
  for
  getting it done 4 - 6 weeks again sound?
 
 ...ant
 


The above link has an extrenuous - on the end. Taking that off gets me
to
the page. Can we move this information across the to the new wiki space (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
everyone (including non committers) can add to it?

I'm working on the next phase of the distributed runtime which I want to
get
into the next release. This involves a few items.

SCA Binding
Topology model
Distributed domain
Node implementation
Management assembly

Also I need some of the ws items, in particular the ability to run without
wsdl, so can help out there.

We need to do something about logging and events to improvide runtime
usability. We've talked about it before but not done anything yet. Ties
into
the management assembly.

I'd also like to see the JMS binding in the release but can't commit to
doing lots more work on including spec features. It's been working fine
for
me in my limited synchronous/rpc model. If I get time I'll take a look to
see what it will take to add minimum asynch support but if anyone else
fancies having a go at this then it's a good way to learn about Tuscany
extensions.



All these sound good, but its starting to sound a lot to get done in just a
few weeks. How does the suggesting timeframe of 4 or so weeks sound?

We'd talked once about having a release specifically targeting things like
logging, events, and error handling. I'd still like to do that, if anyone
wants to start now thats great but I doubt I'd have much time to help this
release.

  ...ant

Re: [VOTE] Release Tuscany Java DAS beta1


On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:




On 7/2/07, ant elder [EMAIL PROTECTED] wrote:

 On 7/2/07, ant elder [EMAIL PROTECTED] wrote:
 
 
 
  On 7/1/07, Luciano Resende [EMAIL PROTECTED]  wrote:
  
   Please vote to release the beta1 distribution of Tuscany DAS for
 Java.
  
   The Release Candidate RC1 for Tuscany Java DAS beta1 is available at
  
   
http://people.apache.org/~lresende/tuscany/das-beta1-rc1/http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/
 http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/ 
  
   Release Notes are available at
  
  
  
 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/distribution/binary/RELEASE_NOTES
  
   The maven repository artifacts are posted in a staging repository
 and
   is available at
  
  
http://people.apache.org/~lresende/tuscany/das-beta1-rc1/maven/http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/maven/
  http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/maven/
  
   The release audit tool (rat) results are available at
  
  
  
 
http://people.apache.org/~lresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.loghttp://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log
 
http://people.apache.org/%7Elresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log
 
  
   The tag for the source code is at
  
  
   
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/

  
   Seems OK to me, here is my +1
 
 
  Looks ok so +1 from me.
 
  The few issues I found are below, none of them are blocking problems
 (it
  maybe worth while fixing the sample issues anyway)  but if the release
 is
  respun for some reason it would be good to fix some of these:
 
 ...ant
 
  - The distributions downloads unzip into a folder of the same name
 
  - A sentence or two at the top of the release notes saying what DAS is

  would be good
 
  - The NOTICE file still includes the incubator disclaimer even though
  there's now a separate disclaimer file (I've fixed that in trunk)
 
  - Does there really need to be a BUILDING file in the bin distro?
 Maybe
  instead an INSTALL file that says how DAS could be used (the
 dependencies
  and config file etc)?
 
  - Could the last two remaining RAT warnings be fixed - what license is
 the
  JSTL stuff?
 
  - Could have a top level sample overview readme in the samples dir
 saying
  what each of the samples does
 
  - The derby-10.1.2.1.jar is included in samples\customer but the
 readme
  for samples\companyweb says to go download it
 
  - The dastest sample dbs isn't included in the binary distro so have
 to
  build from src distro and copy form there to test the samples in the
 bin
  distro
 
  - the customer sample readme doesn't actually say how to run or use
 the
  sample
 
  - I can't get the ajax sample to work, fails with the error below. I
 have
  setup tomcat as described in the readme, looking in the tomcat
 databases
  folder the ajaxdastest does not exist so wasn't ever created yet:
 
  java.lang.NullPointerException at
  org.apache.tuscany.das.rdb.dbconfig.DBHelper.dropDatabaseTables(
  DBHelper.java:185)
  at
  org.apache.tuscany.das.rdb.dbconfig.DBInitializer.initializeDatabase (
  DBInitializer.java :128)
  at
  org.apache.tuscany.das.rdb.dbconfig.DBInitializer.refreshDatabaseData(
  DBInitializer.java:152)
  at org.apache.tuscany.samples.web.CommandServlet.refreshDB (
  CommandServlet.java:51)
  at org.apache.tuscany.samples.web.CommandServlet.init(
  CommandServlet.java:60)
  at org.apache.catalina.core.StandardWrapper.loadServlet(
  StandardWrapper.java :1161)
  at org.apache.catalina.core.StandardWrapper.allocate (
  StandardWrapper.java:806)
  at org.apache.catalina.core.StandardWrapperValve.invoke(
  StandardWrapperValve.java:133)
  at org.apache.catalina.core.StandardContextValve.invoke(
  StandardContextValve.java:175)
  at org.apache.catalina.core.StandardHostValve.invoke(
  StandardHostValve.java:128)
  at org.apache.catalina.valves.ErrorReportValve.invoke(
  ErrorReportValve.java:104)
  at org.apache.catalina.core.StandardEngineValve.invoke (
  StandardEngineValve.java:109)
  at org.apache.catalina.connector.CoyoteAdapter.service(
  CoyoteAdapter.java:216)
  at org.apache.coyote.http11.Http11Processor.process(
  Http11Processor.java:844)
  at
 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
  Http11Protocol.java:634)
  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
  JIoEndpoint.java:445)
  at java.lang.Thread.run(Thread.java :595)
 

 Chatted with Luciano, the ajax sample issue was a problem in my tomcat
 config and the sample works fine now.

...ant


I started taking a look at the binary distro but had to move over to the
source distro to get the sample DB (as ant mentioned above) but I'm having

Re: Behaviour of getList() with open content properties

2007-07-02 Thread kelvin goodson


Andy,
for the following code snippet 

List pFoo = person1.getList(foo);
List bar = *new* ArrayList();
person1.set(foo, bar);
pFoo = person1.getList(foo);
person1.unset(foo);
pFoo = person1.getList(foo);



I see pFoo ending up as null

Regards, Kelvin.


On 02/07/07, Andy Grove [EMAIL PROTECTED] wrote:


I have a question about the correct behaviour of getList().

If I have an open DataObject and I call getList( foo ) where foo is
not a defined property or an instance property, I would expect
getList() to return NULL. This is currently the case in Tuscany.

If foo is set and later unset, I would still expect getList( foo )
to return NULL. However, in this case, Tuscany returns an empty list.

This appears to be a bug in Tuscany but before I raise a JIRA and
write a CTS test I wanted to ask if this is the intended behaviour and
if I am interpreting the specification correctly here.

Thanks,

Andy Grove
Product Architect, HydraSDO
Rogue Wave Software
http://www.roguewave.com

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

[jira] Closed: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests

2007-07-02 Thread ant elder (JIRA)


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

ant elder closed TUSCANY-1382.
--

Resolution: Fixed

Applied. Thanks for the pacthes Rajini.

 Minor fixes to OSGi declarative services support and additional tests
 -

 Key: TUSCANY-1382
 URL: https://issues.apache.org/jira/browse/TUSCANY-1382
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA OSGi Integration
Reporter: Rajini Sivaram
 Attachments: itest-osgi-implementation.zip, 
 sample-osgi-supplychain-patch.txt, tuscany-implementation-osgi.zip


 Attached are patches to osgi-implementation support. 
 Changes include improved support for declarative services and versioning and 
 changes to the directory structure to make it in line with 
 implementation-java.
 Integration tests are included in the zip file.

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


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

Re: SCA 0.92 release?


On 7/2/07, ant elder [EMAIL PROTECTED] wrote:


On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:

 On 7/2/07, Venkata Krishnan [EMAIL PROTECTED] wrote:
 
  Hi,
 
  I am looking at the Policy Framework and shall update the wiki on the
  specifics soon.  Once this is done to some level, I'd also like to
help
 a
  bit with the ws-* things (may be WS-Security to start with) that Ant
has
  listed on the wiki page.
 
  - Venkat
 
  On 6/30/07, ant elder [EMAIL PROTECTED] wrote:
  
   With the SCA 0.91 release now being voted on how about starting on
 0.92?
  
   I've already been adding some things I'm interested in getting done
to
  the
   next release wiki page -
  
  
 

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
   so far thats mainly related to improving web services functionality.
  
   So anyone else interested in helping with an 0.92 release or have
any
   function they'd like to suggest or add to the wiki page? How does
 aiming
   for
   getting it done 4 - 6 weeks again sound?
  
  ...ant
  


 The above link has an extrenuous - on the end. Taking that off gets me
 to
 the page. Can we move this information across the to the new wiki space
(
 http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
 everyone (including non committers) can add to it?

 I'm working on the next phase of the distributed runtime which I want to
 get
 into the next release. This involves a few items.

 SCA Binding
 Topology model
 Distributed domain
 Node implementation
 Management assembly

 Also I need some of the ws items, in particular the ability to run
without
 wsdl, so can help out there.

 We need to do something about logging and events to improvide runtime
 usability. We've talked about it before but not done anything yet. Ties
 into
 the management assembly.

 I'd also like to see the JMS binding in the release but can't commit to
 doing lots more work on including spec features. It's been working fine
 for
 me in my limited synchronous/rpc model. If I get time I'll take a look
to
 see what it will take to add minimum asynch support but if anyone else
 fancies having a go at this then it's a good way to learn about Tuscany
 extensions.


All these sound good, but its starting to sound a lot to get done in just
a
few weeks. How does the suggesting timeframe of 4 or so weeks sound?

We'd talked once about having a release specifically targeting things like
logging, events, and error handling. I'd still like to do that, if anyone
wants to start now thats great but I doubt I'd have much time to help this
release.

   ...ant


I think 4 weeks is a bit too short. Given that we are getting into holday
season I like the sound of 6 weeks better.

I agree there is a lot there but in the spirit of your WS list I wasn't
proposing that all of it gets done. I do think we need to make a start on
the logging/errors sooner rather than later though even if it doesn't get
into the next release. I'll offer my effort to help move it along once the
distributed work starts drawing to a close.

Simon

Re: [jira] Closed: (TUSCANY-1382) Minor fixes to OSGi declarative services support and additional tests


Thanks for these patches, I've applied them.

There is a problem now with the implementation-osgi extension, it doesn't
work with the latest trunk code with tests failing with a class cast
exception,  thats with or without the latest patches, and it works fine when
using the 0.90 release of the runtime. It looks like something to do with
the recent changes to how componentType's are handled and
implementation-osgi extending a ComponentTypeImpl class, but I'm not sure
exactly what the problem is. Anyone have any ideas or want to take a look?
If this can be fixed I'll add to the main build so this type of problem
doesn't happen.

  ...ant

Re: The complete patch for TUSCANY-1341 is available


On 7/2/07, Simon Nash [EMAIL PROTECTED] wrote:


I am reconsidering the changes made in stage 2 of this patch, which
added two new methods to the Binding SPI interface.

I made these changes for the reasons stated in
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
and
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html
These methods allow bindings to be marked as either callback or
forward bindings.  This allows callback binding semantics to be
supported correctly with relatively little change to the core runtime.

Unfortunately these is a flip side to these benefits.  Adding these
methods changes the current published stable Binding SPI, and
(probably worse) introduces pollution of the Binding SPI to carry
information that is there for the convenience of the core runtime,
rather than an intrinsic part of the binding semantics.

The alternative is to keep the Binding SPI as it was, and make more
extensive changes in the core runtime to use the more correct version
of the model as proposed in
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html

I will look at the impact to the core runtime of the alternative
approach that keeps the Binding SPI unchanged and I will post my
findings back to this list.

This discussion only affects the Binding SPI changes in stage 2 of
the patch.  It does not affect the provider SPI changes in stage 1
of the patch.

I'd be interested in any comments on the above or on any other aspects
of this patch.



It sounds good the binding SPI can remain unchanged, it also sounded like
from the other thread that it should be possible to avoid some of the other
SPI changes in stage 1 as well which would be good.

How about trying to get as much as this going with as few changes to the
existing SPI as possible for now even if doing that requires some less then
perfect code in the runtime impl and axis2 binding, and then once we have
call backs and async working well with axis2 and ws-addressing and ideally
at least another extension or two then look at what the best way to change
the SPIs might be?

There's a few other unrelated changes we probably need to do in the  SPI as
well, maybe we can save them all up and then have a single separate release
specially for all these breaking changes and deprecate things so its really
clear how/what/why things changed.

  ...ant

Re: Behaviour of getList() with open content properties

2007-07-02 Thread Andy Grove


Thanks, Kelvin. I thought I was seeing different behaviour last week
when I was testing this but I must have had a bug in my test. I've
added a test to the CTS based on your code snippet.

Thanks,

Andy.

On 7/2/07, kelvin goodson [EMAIL PROTECTED] wrote:

Andy,
 for the following code snippet 

List pFoo = person1.getList(foo);
List bar = *new* ArrayList();
person1.set(foo, bar);
pFoo = person1.getList(foo);
person1.unset(foo);
pFoo = person1.getList(foo);



I see pFoo ending up as null

Regards, Kelvin.


On 02/07/07, Andy Grove [EMAIL PROTECTED] wrote:

 I have a question about the correct behaviour of getList().

 If I have an open DataObject and I call getList( foo ) where foo is
 not a defined property or an instance property, I would expect
 getList() to return NULL. This is currently the case in Tuscany.

 If foo is set and later unset, I would still expect getList( foo )
 to return NULL. However, in this case, Tuscany returns an empty list.

 This appears to be a bug in Tuscany but before I raise a JIRA and
 write a CTS test I wanted to ask if this is the intended behaviour and
 if I am interpreting the specification correctly here.

 Thanks,

 Andy Grove
 Product Architect, HydraSDO
 Rogue Wave Software
 http://www.roguewave.com

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






--
Thanks,

Andy.

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

Update from board regarding our oversight of WS project.

2007-07-02 Thread Davanum Srinivas


Team,

The board would like WS reports to move towards the style and
development that the Jakarta and Incubator reports are done (i.e.,
owners for subprojects developing their parts, and the overall chair
acting as editor). For Inspiration, See [1]

So, Firstly, Please volunteer (take ownership!!) to take charge for
reports for your subproject. If i don't hear from anyone on a specific
subproject, i will assume that no one is interested in that subproject
anymore and we can start the process of pruning that subproject. FYI,
the Spring cleaning is done [2]

Secondly, If there are folks who are not on the ws pmc, but who should
be, then please bring up their nomination on private AT ws.apache.org

I really hope the exisiting PMC members and the new ones will
rejuvenate our board reporting duty and continued oversight of the
umbrella WS project. It may be time to do some spring cleaning of
the pmc too as there are quite a few folks who are not active anymore.
One option is to change them to Emeritus status. If anyone falls into
this category, please let chime in.

BTW, i was a bit late in submission, we have to do another board
report for this month. I've started a page here:
http://wiki.apache.org/ws/ReportForJul2007

thanks,
dims

[1] http://wiki.apache.org/incubator/June2007
[2] http://mail-archives.apache.org/mod_mbox/ws-general/200703.mbox/[EMAIL 
PROTECTED]
--
Davanum Srinivas :: http://davanum.wordpress.com

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

[jira] Commented: (TUSCANY-1341) Callback over WS Binding is not functioning various issues

2007-07-02 Thread ant elder (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509603
 ] 

ant elder commented on TUSCANY-1341:


I've committed the simple-callback-ws.zip for now, thanks for the code Simon, 
leaving the others for now while they still evolving, see 
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/[EMAIL 
PROTECTED]

 

 Callback over WS Binding is not functioning various issues
 --

 Key: TUSCANY-1341
 URL: https://issues.apache.org/jira/browse/TUSCANY-1341
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Misc Binding Extensions
Affects Versions: Java-SCA-0.90
Reporter: Lou Amodeo
 Attachments: jira1341-patch1, jira1341-patch2, jira1341-patch3, 
 jira1341-patch4, jira1341-patch5, jira1341-patch7, simple-callback-ws.zip


 The callback function using WS bindings doesnt appear to be operation.  So 
 far I have :
 1) WebServiceBindingProcessor.java 
 -  The resolve() method does not setup the callbackInterface on its 
 InterfaceContract resulting in NPE.
 (i.e. interfaceContract.setCallbackInterface(wsdlCallbackInterface); )
 [6/11/07 13:33:02:220 EDT] 0025 SystemOut O   ... 87 more
 [6/11/07 13:33:02:220 EDT] 0025 SystemOut O Caused by: 
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(InterfaceContractMapperImpl.java:246)
   at 
 org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:337)
   at 
 org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:269)
   at 
 org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:580)
   at 
 org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain$DomainCompositeHelper.addComposite(EmbeddedSCADomain.java:124)
   at 
 com.ibm.ws.sca2.tuscany.util.TuscanyInterfaceImpl.startModule(TuscanyInterfaceImpl.java:223)
   at 
 com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:82)
   at 
 com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:366)
   at 
 com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.stateChanged(SCARuntimeImpl.java:286)
   at 
 com.ibm.ws.runtime.component.ApplicationMgrImpl.stateChanged(ApplicationMgrImpl.java:1264)
   at 
 com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectEvent(DeployedApplicationImpl.java:1112)
   at 
 com.ibm.ws.runtime.component.DeployedModuleImpl.setState(DeployedModuleImpl.java:206)
   at 
 com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:566)
   at 
 com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:814)
   at 
 com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:965)
   at 
 com.ibm.ws.runtime.component.ApplicationMgrImpl$1.run(ApplicationMgrImpl.java:1495)
   at 
 com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:3924)
   at 
 com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:4001)
   at 
 com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:245)
   at 
 com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1500)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:265)
   at 
 javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1089)
   at 
 javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:971)
   at 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:231)
   at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:238)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
   at 
 com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1080)
   at

significant typo on http://incubator.apache.org/tuscany/sca-java-development-guide.html

2007-07-02 Thread Matthew Peters

on the subject page it says do:

mvn -Declipse.workspace=[path-to-eclipse-workspace] eclipse:add-maven-rep


but the target should have an 'o' on the end. As it stands the command 
does not work. I have maven 2.0.6. 

mvn -Declipse.workspace=[path-to-eclipse-workspace] eclipse:add-maven-repo



Matthew Peters
SWG AB Incubators
Int: 246740 
Ext: +44-(0)1962- 816740
MP 146, IBM United Kingdom Ltd, Hursley Park
http://w3.ibm.com/bluepages/searchByName.wss?uid=073271866task=viewrecord
Internet: [EMAIL PROTECTED]






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [VOTE] Release Tuscany Java DAS beta1


Hi, I tried out the source and binary distributions and here are some
observations: -

Source Distro

- In the license file there is a mention of Tuscany SDO and Eclipse license,
but am not able to figure out a distribution of these packages.  If we are
not distributing them why do we include them in the licenses?
- The Notice file contains a mention of packages used from osoa.org but did
not quite find a distribution for it and don't know if something from osoa
is at all used.
- In the file BUILDING the following could be changed for clairty : -

 Change to the top level directory to Apache Tuscany source distribution
to
Go over to the directory where you have extracted the DAS Source
Distribution and execute the following:
- cd tuscany-das-1.0-incubating-beta1
- mvn

- I cleaned up das and sdo from my local repo and was able to build the
source successfully.

Binary Distribution
--
- There are some dependent jars that are spread into the sample
directories.  Just wonder if we can bring them all under the lib and make
the samples use them from lib as we are doing in SCA
- sample-ajax-das has a war file that has jstl.jar packaged in it.  I don't
find any mention of jstl.jar in the license file.

- Samples (from Binary Distribution)
   - CompanyWeb Sample :
   - In the readme for section titled Running from Tomcat configured
by the build we should probably make it clear that this is an option to be
tried only with the source disb.  And then there is a mention of
java/das/samples/testing/tomcat build which needs to be made relative to
the source disb. extraction.
   -  The section Deploying the CompanyWeb WAR into a Tomcat you
configure yourself needs to be updated a bit.  For example it mentions
about downloading derby. jar whereas its already a part of the war
   - Customer Sample - the readme does not have enuf info on how to go
about running it.

I will give the samples another shot tomorrow to get them to work.

Thanks

- Venkat



On 7/1/07, Luciano Resende [EMAIL PROTECTED] wrote:


Please vote to release the beta1 distribution of Tuscany DAS for Java.

The Release Candidate RC1 for Tuscany Java DAS beta1 is available at

   http://people.apache.org/~lresende/tuscany/das-beta1-rc1/

Release Notes are available at


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/distribution/binary/RELEASE_NOTES

The maven repository artifacts are posted in a staging repository and
is available at

   http://people.apache.org/~lresende/tuscany/das-beta1-rc1/maven/

The release audit tool (rat) results are available at


http://people.apache.org/~lresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log

The tag for the source code is at


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/

Seems OK to me, here is my +1

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

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

Re: The complete patch for TUSCANY-1341 is available

2007-07-02 Thread Simon Nash


I'd like to get some other views on this before I spend a lot of
time reworking this patch.  Please see my comments inline below.

  Simon

ant elder wrote:


On 7/2/07, Simon Nash [EMAIL PROTECTED] wrote:



I am reconsidering the changes made in stage 2 of this patch, which
added two new methods to the Binding SPI interface.

I made these changes for the reasons stated in
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
and
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html
These methods allow bindings to be marked as either callback or
forward bindings.  This allows callback binding semantics to be
supported correctly with relatively little change to the core runtime.

Unfortunately these is a flip side to these benefits.  Adding these
methods changes the current published stable Binding SPI, and
(probably worse) introduces pollution of the Binding SPI to carry
information that is there for the convenience of the core runtime,
rather than an intrinsic part of the binding semantics.

The alternative is to keep the Binding SPI as it was, and make more
extensive changes in the core runtime to use the more correct version
of the model as proposed in
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html

I will look at the impact to the core runtime of the alternative
approach that keeps the Binding SPI unchanged and I will post my
findings back to this list.

This discussion only affects the Binding SPI changes in stage 2 of
the patch.  It does not affect the provider SPI changes in stage 1
of the patch.

I'd be interested in any comments on the above or on any other aspects
of this patch.




It sounds good the binding SPI can remain unchanged, it also sounded like
from the other thread that it should be possible to avoid some of the other
SPI changes in stage 1 as well which would be good.


I'm getting on quite well with reworking the code that currently depends
on the changes to the binding SPI.  There's one slightly ugly area, but I
think I'll be able to get around it without too much hackery.

The provider SPI changes can't be avoided, though they can be deferred.
In the short term this may seem attractive because it gets something
working with less new code.  However, the total amount of work will be
greater since my patch already contains all the necessary collateral
changes for code that's impacted by the provider SPI changes.  I would
have to do significant rework on the patch to remove these for now, then
repeat much of this work to recreate a smilar set of collateral changes
when we finally adopt these new SPIs.


How about trying to get as much as this going with as few changes to the
existing SPI as possible for now even if doing that requires some less then
perfect code in the runtime impl and axis2 binding, and then once we have
call backs and async working well with axis2 and ws-addressing and ideally
at least another extension or two then look at what the best way to change
the SPIs might be?


I think there's pretty much a straight trade-off between how many of
these SPI changes are deferred and the amount of temporary workaround
code that would be needed in the core to compensate for this.

Let's take the provider SPI changes one by one, in approximate order of
increasing difficulty for working around not having them.

1. Not including the change to remove the redundant isCallback parameter
   from ReferenceBindingProvider.createInvoker() doesn't cause any
   significant problems in the core.  The core can always pass the
   meaningless extra parameter, and the providers can always ignore it.
   This does incur the collateral rework costs that I mentioned above
   for when we get around to cleaning this one up.

2. Not including the supportsAsyncOneWayInvocation() methods on
   ReferenceBindingProvider and ServiceBindingProvider presents a bit
   more of a challenge.  One possibility is to create a new marker
   interface that can be implemented by providers that support
   asynchronous one-way invocation.  The core could test for this marker
   interface and omit the thread switch if the provider implements it.
   I'm not really convinced that this is cleaner (it's probably a bit
   more tricky to explain than just having methods for this as we do
   everywhere else in the SPI), but it would get around the need for a
   breaking SPI change now.  What do people think about this approach?

3. Not including the createCallbackInvoker() method on ServiceBindingProvider.
   seems at first sight to make it impossible for callbacks to work.
   But there is (as always with software) another way.  We could introduce
   a new interface ServiceBindingCallbackProvider that extends
   ServiceBindingProvider and adds the createCallbackInvoker() method.
   Providers that support callbacks would implement this interface,
   and providers that don't support callbacks could continue to
   implement ServiceBindingProvider.  Again, this seems

Re: The complete patch for TUSCANY-1341 is available


On 7/2/07, Simon Nash [EMAIL PROTECTED] wrote:

snip

1. Not including the change to remove the redundant isCallback parameter

from ReferenceBindingProvider.createInvoker() doesn't cause any
significant problems in the core.  The core can always pass the
meaningless extra parameter, and the providers can always ignore it.
This does incur the collateral rework costs that I mentioned above
for when we get around to cleaning this one up.



+1, this sounds a good approach to me

2. Not including the supportsAsyncOneWayInvocation() methods on

ReferenceBindingProvider and ServiceBindingProvider presents a bit
more of a challenge.  One possibility is to create a new marker
interface that can be implemented by providers that support
asynchronous one-way invocation.  The core could test for this marker
interface and omit the thread switch if the provider implements it.
I'm not really convinced that this is cleaner (it's probably a bit
more tricky to explain than just having methods for this as we do
everywhere else in the SPI), but it would get around the need for a
breaking SPI change now.  What do people think about this approach?



+1, I like it a lot

3. Not including the createCallbackInvoker() method on

ServiceBindingProvider.
seems at first sight to make it impossible for callbacks to work.
But there is (as always with software) another way.  We could
introduce
a new interface ServiceBindingCallbackProvider that extends
ServiceBindingProvider and adds the createCallbackInvoker() method.
Providers that support callbacks would implement this interface,
and providers that don't support callbacks could continue to
implement ServiceBindingProvider.  Again, this seems slightly tricky
but it would work and it wouldn't need a breaking SPI change.



+1 again

Now I'll circle back to 1 again.  The proposal for 3 has inspired me

to imagine a new interface that just contains the new method signature
for createInvoker().  New providers can implement this interface and
the new signature, and old providers can continue with the old signature,
with the core being smart enough to understand both forms and call the
signature that is available.



Another +1

snip

My opinion is that the long term solution is likely

to be the one I have currently implemented, so the work to change other
affected code will need to be done anyway at some point.



I also agree the end result is likely to be similar but IMHO the benefits of
keeping things separate and stable for the time being far out way the extra
work of at some point cleaning up all the SPIs (which we're going to have to
do anyway).

  ...ant

Re: The complete patch for TUSCANY-1341 is available

2007-07-02 Thread Mike Edwards


Folks,

I tend to favour this more conservative approach.  There may be a 
problem longer term in explaining the interfaces to writers of new 
binding types and implementation types, but the mess caused to existing 
implementation types and existing binding types by breaking changes in 
the SPI is not worth it, based on my experiences.


My 2 cents,

Mike.

ant elder wrote:

On 7/2/07, Simon Nash [EMAIL PROTECTED] wrote:

snip

1. Not including the change to remove the redundant isCallback parameter


from ReferenceBindingProvider.createInvoker() doesn't cause any
significant problems in the core.  The core can always pass the
meaningless extra parameter, and the providers can always ignore it.
This does incur the collateral rework costs that I mentioned above
for when we get around to cleaning this one up.




+1, this sounds a good approach to me

2. Not including the supportsAsyncOneWayInvocation() methods on


ReferenceBindingProvider and ServiceBindingProvider presents a bit
more of a challenge.  One possibility is to create a new marker
interface that can be implemented by providers that support
asynchronous one-way invocation.  The core could test for this marker
interface and omit the thread switch if the provider implements it.
I'm not really convinced that this is cleaner (it's probably a bit
more tricky to explain than just having methods for this as we do
everywhere else in the SPI), but it would get around the need for a
breaking SPI change now.  What do people think about this approach?




+1, I like it a lot

3. Not including the createCallbackInvoker() method on


ServiceBindingProvider.
seems at first sight to make it impossible for callbacks to work.
But there is (as always with software) another way.  We could
introduce
a new interface ServiceBindingCallbackProvider that extends
ServiceBindingProvider and adds the createCallbackInvoker() method.
Providers that support callbacks would implement this interface,
and providers that don't support callbacks could continue to
implement ServiceBindingProvider.  Again, this seems slightly tricky
but it would work and it wouldn't need a breaking SPI change.




+1 again

Now I'll circle back to 1 again.  The proposal for 3 has inspired me


to imagine a new interface that just contains the new method signature
for createInvoker().  New providers can implement this interface and
the new signature, and old providers can continue with the old signature,
with the core being smart enough to understand both forms and call the
signature that is available.




Another +1

snip

My opinion is that the long term solution is likely


to be the one I have currently implemented, so the work to change other
affected code will need to be done anyway at some point.




I also agree the end result is likely to be similar but IMHO the 
benefits of

keeping things separate and stable for the time being far out way the extra
work of at some point cleaning up all the SPIs (which we're going to 
have to

do anyway).

  ...ant



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

[jira] Created: (TUSCANY-1400) TuscanySCA C++ SVN head does not compile with SDO SVN head nor with SDO M3

2007-07-02 Thread Brady Johnson (JIRA)

TuscanySCA C++ SVN head does not compile with SDO SVN head nor with SDO M3
--

 Key: TUSCANY-1400
 URL: https://issues.apache.org/jira/browse/TUSCANY-1400
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SCA
Affects Versions: Cpp-Next
 Environment: All platforms
Reporter: Brady Johnson
 Fix For: Cpp-Next


The TuscanySCA CPP source code does not compile due to mixed use of the IntType 
and IntegerType SDO constants.

I know there was some talk and preliminary work done to make SDO and the SCA 
usage of SDO 2.1 spec compliant. 
I believe whatever work that was started on that was rolled back. But it seems 
that the following files were missed.

# grep -r IntType *

runtime/extensions/ws/service/axis2c/src/tuscany/sca/ws/WSServiceProxy.cpp  
 case Type::IntType:
runtime/extensions/rest/service/httpd/src/tuscany/sca/rest/RESTServiceProxy.cpp 
 case Type::IntType:

IntType should simply be changed to IntegerType.

This is an easy enough fix that a patch isnt really necessary. But I can 
provide one if necessary.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]



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


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

TuscanySCA C++ SubVersion head does not compile with TuscanySDO C++ SubVersion head nor with TuscanySDO M3

2007-07-02 Thread Brady Johnson

 
I created a JIRA for this problem:
https://issues.apache.org/jira/browse/TUSCANY-1400
 
 The TuscanySCA CPP source code does not compile due to mixed use of the
IntType and IntegerType SDO constants. 

I know there was some talk and preliminary work done to make SDO and the
SCA usage of SDO 2.1 spec compliant. 
I believe whatever work that was started on that was rolled back. But it
seems that the following files were missed. 

# grep -r IntType * 

runtime/extensions/ws/service/axis2c/src/tuscany/sca/ws/WSServiceProxy.c
pp case Type::IntType: 
runtime/extensions/rest/service/httpd/src/tuscany/sca/rest/RESTServicePr
oxy.cpp case Type::IntType: 

IntType should simply be changed to IntegerType. 

This is an easy enough fix that a patch isnt really necessary. But I can
provide one if necessary. 

 
Brady Johnson 
Lead Software Developer - HydraSCA 
Rogue Wave Software - [EMAIL PROTECTED]

Re: TuscanySCA C++ SubVersion head does not compile with TuscanySDO C++ SubVersion head nor with TuscanySDO M3

2007-07-02 Thread Pete Robbins


Apologies for that. I have now reverted to use IntegerType. The SCA
head will now build against SDO M3. The SDO code will be undergoing
some incompatible API changes to get to 2.1 spec level. We will make
the changes in the SCA code to match this when the SDO code is stable.

Cheers,

On 02/07/07, Brady Johnson [EMAIL PROTECTED] wrote:


I created a JIRA for this problem:
   https://issues.apache.org/jira/browse/TUSCANY-1400

 The TuscanySCA CPP source code does not compile due to mixed use of the
IntType and IntegerType SDO constants.

I know there was some talk and preliminary work done to make SDO and the
SCA usage of SDO 2.1 spec compliant.
I believe whatever work that was started on that was rolled back. But it
seems that the following files were missed.

# grep -r IntType *

runtime/extensions/ws/service/axis2c/src/tuscany/sca/ws/WSServiceProxy.c
pp case Type::IntType:
runtime/extensions/rest/service/httpd/src/tuscany/sca/rest/RESTServicePr
oxy.cpp case Type::IntType:

IntType should simply be changed to IntegerType.

This is an easy enough fix that a patch isnt really necessary. But I can
provide one if necessary.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]





--
Pete

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

[jira] Commented: (TUSCANY-477) SDO runtime should report unresolved types in a meaningful way if xsd:import/include cannot be resolved

2007-07-02 Thread Fuhwei Lwo (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509652
 ] 

Fuhwei Lwo commented on TUSCANY-477:


Possible solution is to modify BaseSDOXSDEcoreBuild.java to the follow snippet 
to throw IllegalArgumentException when the simple and complext type XSD 
definition cannot be found.

else if (xsdSimpleTypeDefinition.getContainer() == null)
{
//  return 
(EDataType)getBuiltInEClassifier(rootSchema.getSchemaForSchemaNamespace(), 
anySimpleType);
throw new IllegalArgumentException();
}

The exception handling/serviceability of XSDHelper.define() is not well defined 
in the SDO 2.1 spec. I don't think current behavior is breaking the spec. Also, 
merely throwing an IllegalArgumentException is not good enough because the SDO 
users may like to know what's wrong with their XSD.

I suggest to keep the current behavior for Tuscany SDO 1.0 release for now.

Fuhwei

 SDO runtime should report unresolved types in a meaningful way if 
 xsd:import/include cannot be resolved
 ---

 Key: TUSCANY-477
 URL: https://issues.apache.org/jira/browse/TUSCANY-477
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SCA-M2
Reporter: Raymond Feng
Assignee: Frank Budinsky
Priority: Minor
 Fix For: Java-SDO-Next

 Attachments: patchtests.zip, TestXSDImport.jar


 I'm seeing different behaviors from XSDHelper.define() if the 
 xsd:import/include cannot be resolved. I wonder if we should have a 
 consistent error handling here. Please see the attached test case (in the 
 case, I pass null as schemaLocation to the define() on purpose).
 Case 1: Unresolved XSD type is silently replaced by Object DataType
 Case 2: IllegalArgumentException is thrown due to a NPE in EMF code

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


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

How does one specify a Property as containment property in XML Schema?

2007-07-02 Thread Pinaki Poddar

Hello,

  How does one specify a Property as containment property in XML Schema?


  I was trying a simple example with a XML Schema (po.xsd) that had the
following snippet:

xsd:complexType name=PurchaseOrderType
xsd:sequence
xsd:element name=shipTo type=USAddress/

  XSDHelper.INSTANCE.define(...) works fine to construct the types from
po.xsd.

  However when the following is executed:

 01: DataObject purchaseOrder =
DataFactory.INSTANCE.create(http://www.example.com/PO;,
PurchaseOrderType);
 02: DataObject shipTo = purchaseOrder.createDataObject(shipTo);

It fails with 
java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
at test.TestModel.testInstance(TestModel.java:41)

  I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.


Pinaki Poddar
972.834.2865


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

Re: How does one specify a Property as containment property in XML Schema?

2007-07-02 Thread kelvin goodson


Hi,
 this doesn't add up --- shipTo should be a containment Property.  Can you
post the whole schema/test code please? Attachments will be stripped from
the list,  so please copy inline into the email.
Regards, Kelvin.


On 02/07/07, Pinaki Poddar [EMAIL PROTECTED] wrote:


Hello,

How does one specify a Property as containment property in XML Schema?


I was trying a simple example with a XML Schema (po.xsd) that had the
following snippet:

   xsd:complexType name=PurchaseOrderType
   xsd:sequence
   xsd:element name=shipTo type=USAddress/

XSDHelper.INSTANCE.define(...) works fine to construct the types from
po.xsd.

However when the following is executed:

01: DataObject purchaseOrder =
DataFactory.INSTANCE.create(http://www.example.com/PO;,
PurchaseOrderType);
02: DataObject shipTo = purchaseOrder.createDataObject(shipTo);

It fails with
java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment
   at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
   at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
   at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
   at test.TestModel.testInstance(TestModel.java:41)

I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.


Pinaki Poddar
972.834.2865


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.

Re: How does one specify a Property as containment property in XML Schema?

2007-07-02 Thread Fuhwei Lwo

Hi Pinaki,

What is the type of shipTo property? It needs to be a complex type. Can you 
post your XSD? Thanks.

Fuhwei


Pinaki Poddar [EMAIL PROTECTED] wrote: Hello,

  How does one specify a Property as containment property in XML Schema?


  I was trying a simple example with a XML Schema (po.xsd) that had the
following snippet:





  XSDHelper.INSTANCE.define(...) works fine to construct the types from
po.xsd.

  However when the following is executed:

 01: DataObject purchaseOrder =
DataFactory.INSTANCE.create(http://www.example.com/PO;,
PurchaseOrderType);
 02: DataObject shipTo = purchaseOrder.createDataObject(shipTo);

It fails with 
java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment
 at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
 at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
 at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
 at test.TestModel.testInstance(TestModel.java:41)

  I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.


Pinaki Poddar
972.834.2865


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.

RE: How does one specify a Property as containment property in XML Schema?

2007-07-02 Thread Pinaki Poddar

Hello Fuhwei,
  I am following your footstep! It is the same po.xsd I copied from your
very readable post
 
http://www.ibm.com/developerworks/webservices/library/ws-sdoxmlschema/in
dex.html

  except that it was missing a closing /xsd:schema

  Thanks for your help.


Pinaki Poddar
972.834.2865

-Original Message-
From: Fuhwei Lwo [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 02, 2007 3:35 PM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema? 

Hi Pinaki,

What is the type of shipTo property? It needs to be a complex type.
Can you post your XSD? Thanks.

Fuhwei


Pinaki Poddar [EMAIL PROTECTED] wrote: Hello,

  How does one specify a Property as containment property in XML Schema?


  I was trying a simple example with a XML Schema (po.xsd) that had the
following snippet:





  XSDHelper.INSTANCE.define(...) works fine to construct the types from
po.xsd.

  However when the following is executed:

 01: DataObject purchaseOrder =
DataFactory.INSTANCE.create(http://www.example.com/PO;,
PurchaseOrderType);
 02: DataObject shipTo = purchaseOrder.createDataObject(shipTo);

It fails with
java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment  at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
 at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
 at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
 at test.TestModel.testInstance(TestModel.java:41)

  I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.


Pinaki Poddar
972.834.2865


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1392) The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set.

2007-07-02 Thread Brady Johnson (JIRA)

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

Brady Johnson updated TUSCANY-1392:
---

Attachment: WSDLDefinition.cpp
WSDLDefinition_cpp_JIRA_TUSCANY_1392
WSDLDefinition_h_JIRA_TUSCANY_1392

Attaching patches. Notice that in addition to the svn diff files, I attached
the actual cpp source file since the its a rather large change.

The WSDLOperation instance returned by WSDLDefinition::findOperation(
portTypeName, operationName ) does not have the endpoint set.
---

Key: TUSCANY-1392
URL: https://issues.apache.org/jira/browse/TUSCANY-1392
Project: Tuscany
Issue Type: Bug
Components: C++ SCA
Affects Versions: Cpp-M3
Environment: All platforms
Reporter: Brady Johnson
Fix For: Cpp-Next

Attachments: WSDLDefinition.cpp,
WSDLDefinition_cpp_JIRA_TUSCANY_1392, WSDLDefinition_h_JIRA_TUSCANY_1392

The WSDLOperation instance returned by WSDLDefinition::findOperation(
portTypeName, operationName ) does not have the endpoint set.
I can see that its not set in WSDLDefinition::findOperation() because that
particular signature of the method does not have access to the WSDL
service, which is where the endpoint is contained. The other signature of
that method: findOperation( serviceName, PortName, operationName )
does set the endpoint in the WSDLOperation since it does have access to the
WSDL service.
The fix for this problem is not trivial, and leads into another issue with
the findOperation() methods. Every time either method is called, they
walk the SDO, which could be an acceptable performance hit during load time,
but is not an efficient runtime search. There is an operationMap
available, but it is never populated.
I think the best solution would be to traverse the wsdlModel SDO upon
instantiation, and when addWSDLModel() is called, and populate
the operationMap. This would solve the above problem of not having access to
the WSDL service endpoint, and also address the runtime
performance issues associated with walking the SDO.
Another less optimal solution would be to at least add the operation to the
operationMap each time findOperation() is called, effectively
caching the operations. But this still doesnt address the problem of the WSDL
service endpoint.
When a solution is decided, I can implement the patch and submit it for a
contributor to put into the code base.

Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

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

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

Re: Resolving files, getting the component interface

2007-07-02 Thread Raymond Feng


Hi,

By reading the spec, the process attribute specifies the target QName of 
an executable WS-BPEL process. We can follow the QName resolving approach to 
figure out which BPEL file to use. During the processing of a SCA 
contribution, we can create a BPELImplementation w/ the QName and mark it 
unresolved. For each BEPL file, we can record an entry to associate an BPEL 
file with the QName of the process. After resolving the QName of a process 
to a BPEL model, we can use the QName of the portType from the partLinkType 
in BEPL file to tell the WSDLs.


Thanks,
Raymond

- Original Message - 
From: Matthieu Riou [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Monday, July 02, 2007 9:27 AM
Subject: Resolving files, getting the component interface



Hi guys,

I'm continuing on the ODE / Tuscany integration and I have a few more
riddles. Say that I have to following composite:

composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=
http://bpel;
   xmlns:sc=http://bpel; xmlns:c=http://bpel; name=bpel

   service name=BPELHelloWorldService 
promote=BPELHelloWorldComponent

 interface.wsdl
 interface=
http://tuscany.apache.org/implementation/bpel/example/helloworld.wsd#wsdl.interface(HelloPortType)
/
   /service

   component name=BPELHelloWorldComponent
   implementation.bpel process=bpel-process/
   /component
/composite


I have 2 problems here:

1. How can I retrieve the WSDL interface associated with the BPEL
implementation? I need basic information about that WSDL to be able to 
load

the BPEL file and register it in ODE.
2. How do I load the BPEL file? I could add a specific attribute for the
file name but it's not so nice. Is there something that I can reuse that's
already been implemented? I think you automatically load all the WSDLs 
from

a contribution for example and then check from the namespace when you need
to retrieve something. Can I plug into that resolution mechanism?

I've been looking a bit at the code but a lot of the WSDL-related work is
done in binding components that seem to reuse common binding-specific 
code.


Thanks!
Matthieu




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

Attaching patch for: The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set

2007-07-02 Thread Brady Johnson

 
I attached a patch for
https://issues.apache.org/jira/browse/TUSCANY-1392

It's a rather large change, so I also attached the cpp source file in
case its hard to merge.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

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

Re: [VOTE] Release Tuscany Java DAS beta1

2007-07-02 Thread haleh mahbod


Tried the following:
- download source
- go to tuscany-das-1.0-incubating-beta1
- issue mvn

I get the following error. Any ideas?


C:\das\tuscany-das-1.0-incubating-beta1mvn
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Apache Tuscany DAS Implementation project
[INFO]   Tuscany DAS for Relational Databases
[INFO]   Tuscany DAS Samples
[INFO]   Tuscany DAS Canned DB Initializer Utility
[INFO]   Tuscany DAS Company Sample
[INFO]   Tuscany DAS Ajax Sample
[INFO]   Tuscany DAS J2SE Customer Sample
[INFO]
-
---
[INFO] Building Apache Tuscany DAS Implementation project
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates
from apache.incubator
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-site
-plugin' could not be retrieved from repository: apache.incubator due to an
erro
r: Error transferring file
[INFO] Repository 'apache.incubator' will be blacklisted
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates
from codehaus-snapshot
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-site
-plugin' could not be retrieved from repository: codehaus-snapshot due to an
err
or: Error transferring file
[INFO] Repository 'codehaus-snapshot' will be blacklisted
[INFO] Skipping missing optional mojo:
org.apache.maven.plugins:maven-site-plugi
n:attach-descriptor
Downloading:
http://www.ibiblio.net/pub/packages/maven2/org/apache/maven/plugins
/maven-jar-plugin/2.1/maven-jar-plugin-2.1.pom
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-jar-plugin

Reason: Error getting POM for 'org.apache.maven.plugins:maven-jar-plugin'
from t
he repository: Error transferring file
 org.apache.maven.plugins:maven-jar-plugin:pom:2.1

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 apache.incubator (http://people.apache.org/repo/m2-incubating-repository),
 apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
 codehaus-snapshot (http://snapshots.repository.codehaus.org),
 eclipse.emf (http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/),
 indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/)



[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 3 seconds
[INFO] Finished at: Mon Jul 02 14:11:39 PDT 2007
[INFO] Final Memory: 2M/5M
[INFO]


C:\das\tuscany-das-1.0-incubating-beta1mvn
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Apache Tuscany DAS Implementation project
[INFO]   Tuscany DAS for Relational Databases
[INFO]   Tuscany DAS Samples
[INFO]   Tuscany DAS Canned DB Initializer Utility
[INFO]   Tuscany DAS Company Sample
[INFO]   Tuscany DAS Ajax Sample
[INFO]   Tuscany DAS J2SE Customer Sample
[INFO]
-
---
[INFO] Building Apache Tuscany DAS Implementation project
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] Skipping missing optional mojo:
org.apache.maven.plugins:maven-site-plugi
n:attach-descriptor
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for
upda
tes from apache.incubator
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-inst
all-plugin' could not be retrieved from repository: apache.incubator due to
an e
rror: Error transferring file
[INFO] Repository 'apache.incubator' will be blacklisted
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for
upda
tes from codehaus-snapshot
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-inst
all-plugin' could not be retrieved from repository: codehaus-snapshot due to
an
error: Error transferring file
[INFO] Repository 'codehaus-snapshot' will be blacklisted
Downloading:
http://www.ibiblio.net/pub/packages/maven2/org/apache/maven/plugins
/maven-jar-plugin/2.1/maven-jar-plugin-2.1.pom
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-jar-plugin

Reason: Error getting POM for 'org.apache.maven.plugins:maven-jar-plugin'
from t
he

RE: How does one specify a Property as containment property in XML Schema?

2007-07-02 Thread Fuhwei Lwo

Hi Pinaki,

I think your XSDHelper.define() failed to register types for some reason. Can 
you try this to see whether any types were registered?

java.util.List types = XSDHelper.INSTANCE.define(fis, null);
for (int i=0; itypes.size(); i++) {
System.out.println(Type defined:  + types.get(i));
}

Normally, you should see PurchaseOrderType, USAddress, etc registered.

Fuhwei

Pinaki Poddar [EMAIL PROTECTED] wrote: Hello Fuhwei,
  I am following your footstep! It is the same po.xsd I copied from your
very readable post
 
http://www.ibm.com/developerworks/webservices/library/ws-sdoxmlschema/in
dex.html

  except that it was missing a closing 

  Thanks for your help.


Pinaki Poddar
972.834.2865

-Original Message-
From: Fuhwei Lwo [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 02, 2007 3:35 PM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema? 

Hi Pinaki,

What is the type of shipTo property? It needs to be a complex type.
Can you post your XSD? Thanks.

Fuhwei


Pinaki Poddar 
 wrote: Hello,

  How does one specify a Property as containment property in XML Schema?


  I was trying a simple example with a XML Schema (po.xsd) that had the
following snippet:





  XSDHelper.INSTANCE.define(...) works fine to construct the types from
po.xsd.

  However when the following is executed:

 01: DataObject purchaseOrder =
DataFactory.INSTANCE.create(http://www.example.com/PO;,
PurchaseOrderType);
 02: DataObject shipTo = purchaseOrder.createDataObject(shipTo);

It fails with
java.lang.IllegalArgumentException: The property 'shipTo' of
'PurchaseOrderType' isn't a containment  at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:421)
 at
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
il.java:467)
 at
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
pl.java:1195)
 at test.TestModel.testInstance(TestModel.java:41)

  I am using tuscany-sdo-impl-1.0-incubating-beta1.jar.


Pinaki Poddar
972.834.2865


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity 
named in this message. If you are not the intended recipient, and have received 
this message in error, please immediately return this by email and then delete 
it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attaching patch for: The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set

2007-07-02 Thread Pete Robbins


I've applied the patch. Rather than supplying a patch for each
individual file I find it easier to produce a single patch for the
source tree. It's easier to apply too!

Cheers,

On 02/07/07, Brady Johnson [EMAIL PROTECTED] wrote:


I attached a patch for
https://issues.apache.org/jira/browse/TUSCANY-1392

It's a rather large change, so I also attached the cpp source file in
case its hard to merge.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

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





--
Pete

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

Re: Resolving files, getting the component interface

2007-07-02 Thread Matthieu Riou


Hi,

Thanks for the reply, see my comments in line:

On 7/2/07, Raymond Feng [EMAIL PROTECTED] wrote:snip


We can follow the QName resolving approach to
figure out which BPEL file to use.



Do you have some pointers and code that I can look at to see how this
resolving is done in Tuscany right now? In case I need to extend it for
BPEL.

During the processing of a SCA

contribution, we can create a BPELImplementation w/ the QName and mark it
unresolved. For each BEPL file, we can record an entry to associate an
BPEL
file with the QName of the process. After resolving the QName of a process
to a BPEL model, we can use the QName of the portType from the
partLinkType
in BEPL file to tell the WSDLs.



Right but if I'm following correctly that means that the process will only
be really loaded when the implementation is first used (say on the first
message). That means that the process is only compiled and validated at that
time which makes me a bit nervous. Basically no static validation of a
deployed process would be done before the first message and you would then
need to invoke to find out what's possibly wrong with your process. Ideally
the process should be fully loaded with the contribution.

Cheers,
Matthieu

Thanks,

Raymond

- Original Message -
From: Matthieu Riou [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, July 02, 2007 9:27 AM
Subject: Resolving files, getting the component interface


 Hi guys,

 I'm continuing on the ODE / Tuscany integration and I have a few more
 riddles. Say that I have to following composite:

 composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=
 http://bpel;
xmlns:sc=http://bpel; xmlns:c=http://bpel; name=bpel

service name=BPELHelloWorldService
 promote=BPELHelloWorldComponent
  interface.wsdl
  interface=

http://tuscany.apache.org/implementation/bpel/example/helloworld.wsd#wsdl.interface(HelloPortType)

 /
/service

component name=BPELHelloWorldComponent
implementation.bpel process=bpel-process/
/component
 /composite


 I have 2 problems here:

 1. How can I retrieve the WSDL interface associated with the BPEL
 implementation? I need basic information about that WSDL to be able to
 load
 the BPEL file and register it in ODE.
 2. How do I load the BPEL file? I could add a specific attribute for the
 file name but it's not so nice. Is there something that I can reuse
that's
 already been implemented? I think you automatically load all the WSDLs
 from
 a contribution for example and then check from the namespace when you
need
 to retrieve something. Can I plug into that resolution mechanism?

 I've been looking a bit at the code but a lot of the WSDL-related work
is
 done in binding components that seem to reuse common binding-specific
 code.

 Thanks!
 Matthieu

[jira] Created: (TUSCANY-1401) Incompatible SDO code being generated if different version of tuscany-sdo-plugin is already available

2007-07-02 Thread Luciano Resende (JIRA)

Incompatible SDO code being generated if different version of 
tuscany-sdo-plugin is already available
-

 Key: TUSCANY-1401
 URL: https://issues.apache.org/jira/browse/TUSCANY-1401
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-beta1
Reporter: Luciano Resende
Assignee: Luciano Resende
Priority: Critical
 Fix For: Java-DAS-beta1


The das\rcb\pom.xml does not specify a sdo-plugin version and this causes 
different issues if a different version of the plugin is already available (e.g 
if you build from trunk before building from DAS beta1 source.)

This is what is causing the issue reported by Simon Laws [1]

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

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


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

TuscanySCA CPP: Enhancements to the WSDLOperation class

2007-07-02 Thread Brady Johnson

Currently there is no way to obtain WSDL Operation Message information
as defined in a WSDL. The WSDLOperation class does have 2 attributes
that seem to help serve this purpose, but they are never populated.
commonj::sdo::DataObjectPtr inputMessage;
commonj::sdo::DataObjectPtr outputMessage;
 
I created a JIRA for this:
https://issues.apache.org/jira/browse/TUSCANY-1402
 
I would like to propose adding several methods related to the
input/output messages as follows:
 
// Called from WSDLDefinition, populates std::mapstd::string,
tuscany::sca::model::WSDLMessagePart partMap
// which will map part names to message parts
void WSDLOperation::setInputMessage( commonj::sdo::DataObjectPtr msg
);
void WSDLOperation::setOutputMessage( commonj::sdo::DataObjectPtr
msg );
 
// Allows you to iterate over the input/output message parts
// Initially for Document wrapped, there will only be one part
std::liststd::string WSDLOperation::getInputMessagePartNames();
std::liststd::string WSDLOperation::getOutputMessagePartNames();
 
// Allows you to get the actual input/output message part
// Initially for Document wrapped, there will only be one part
tuscany::sca::model::WSDLMessagePart
WSDLOperation::getInputMessagePart( std::string msgPartName );
tuscany::sca::model::WSDLMessagePart
WSDLOperation::getOutputMessagePart( std::string msgPartName );
 
// Currently WSDLOperation specfies encoding for the entire
operation, when actually
// it should be specified seperately for both the input AND the
output message
void WSDLMessagePart::setInputEncoded( bool ); // replaces
setEncoded
void WSDLMessagePart::setOutputEncoded( bool ); // replaces
setEncoded
bool WSDLMessagePart::isInputEncoded(); // replaces isEncoded
bool WSDLMessagePart::isOutputEncoded(); // replaces isEncoded
 
The WSDLMessagePart class would have the following API:
WSDLMessagePart::WSDLMessagePart( std::string partName, std::string
partType, std::string partUri );
 
std::string WSDLMessagePart::getPartName();
void WSDLMessagePart::setPartName( std::string uri );
 
std::string WSDLMessagePart::getPartType();
void WSDLMessagePart::setPartType( std::string name );
 
std::string WSDLMessagePart::getPartUri();
void WSDLMessagePart::setPartUri( std::string uri );
 
This would be a good step towards making Tuscany support both Document
AND RPC SOAP message binding styles.
 
If everyone agrees with these changes, I can provide a patch shortly.
 

Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1402) TuscanySCA C++: WSDLOperation class provides no access to the input and output Operation Message information

2007-07-02 Thread Brady Johnson (JIRA)

TuscanySCA C++: WSDLOperation class provides no access to the input and output 
Operation Message information


 Key: TUSCANY-1402
 URL: https://issues.apache.org/jira/browse/TUSCANY-1402
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SCA
Affects Versions: Cpp-M3
 Environment: All platforms
Reporter: Brady Johnson
Priority: Minor
 Fix For: Cpp-Next


Currently there is no way to obtain WSDL Operation Message information as 
defined in a WSDL. The WSDLOperation class does have 2 attributes that seem to 
help serve this purpose, but they are never populated.
commonj::sdo::DataObjectPtr inputMessage;
commonj::sdo::DataObjectPtr outputMessage;

I would like to propose adding several methods related to the input/output 
messages as follows:

// Called from WSDLDefinition, populates std::mapstd::string, 
tuscany::sca::model::WSDLMessagePart partMap
// which will map part names to message parts
void WSDLOperation::setInputMessage( commonj::sdo::DataObjectPtr msg );
void WSDLOperation::setOutputMessage( commonj::sdo::DataObjectPtr msg );

// Allows you to iterate over the input/output message parts
// Initially for Document wrapped, there will only be one part
std::liststd::string WSDLOperation::getInputMessagePartNames();
std::liststd::string WSDLOperation::getOutputMessagePartNames();

// Allows you to get the actual input/output message part
// Initially for Document wrapped, there will only be one part
tuscany::sca::model::WSDLMessagePart WSDLOperation::getInputMessagePart( 
std::string msgPartName );
tuscany::sca::model::WSDLMessagePart WSDLOperation::getOutputMessagePart( 
std::string msgPartName );

// Currently WSDLOperation specfies encoding for the entire operation, when 
actually
// it should be specified seperately for both the input AND the output 
message
void WSDLMessagePart::setInputEncoded( bool ); // replaces setEncoded
void WSDLMessagePart::setOutputEncoded( bool ); // replaces setEncoded
bool WSDLMessagePart::isInputEncoded(); // replaces isEncoded
bool WSDLMessagePart::isOutputEncoded(); // replaces isEncoded

The WSDLMessagePart class would have the following API:
WSDLMessagePart::WSDLMessagePart( std::string partName, std::string 
partType, std::string partUri );

std::string WSDLMessagePart::getPartName();
void WSDLMessagePart::setPartName( std::string uri );

std::string WSDLMessagePart::getPartType();
void WSDLMessagePart::setPartType( std::string name );

std::string WSDLMessagePart::getPartUri();
void WSDLMessagePart::setPartUri( std::string uri );

This would be a good step towards making Tuscany support Document AND RPC SOAP 
message binding styles.

If everyone agrees with these changes, I can provide a patch shortly.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


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


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

Re: [VOTE] Release Tuscany Java DAS beta1

2007-07-02 Thread Adriano Crestani


DAS bin, distro and samples worked fine on my machine, here is my +1.

Adriano Crestani

On 7/2/07, haleh mahbod [EMAIL PROTECTED] wrote:


Tried the following:
- download source
- go to tuscany-das-1.0-incubating-beta1
- issue mvn

I get the following error. Any ideas?


C:\das\tuscany-das-1.0-incubating-beta1mvn
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Apache Tuscany DAS Implementation project
[INFO]   Tuscany DAS for Relational Databases
[INFO]   Tuscany DAS Samples
[INFO]   Tuscany DAS Canned DB Initializer Utility
[INFO]   Tuscany DAS Company Sample
[INFO]   Tuscany DAS Ajax Sample
[INFO]   Tuscany DAS J2SE Customer Sample
[INFO]
-
---
[INFO] Building Apache Tuscany DAS Implementation project
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates
from apache.incubator
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-site
-plugin' could not be retrieved from repository: apache.incubator due to
an
erro
r: Error transferring file
[INFO] Repository 'apache.incubator' will be blacklisted
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates
from codehaus-snapshot
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-site
-plugin' could not be retrieved from repository: codehaus-snapshot due to
an
err
or: Error transferring file
[INFO] Repository 'codehaus-snapshot' will be blacklisted
[INFO] Skipping missing optional mojo:
org.apache.maven.plugins:maven-site-plugi
n:attach-descriptor
Downloading:
http://www.ibiblio.net/pub/packages/maven2/org/apache/maven/plugins
/maven-jar-plugin/2.1/maven-jar-plugin-2.1.pom
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-jar-plugin

Reason: Error getting POM for 'org.apache.maven.plugins:maven-jar-plugin'
from t
he repository: Error transferring file
  org.apache.maven.plugins:maven-jar-plugin:pom:2.1

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.incubator (http://people.apache.org/repo/m2-incubating-repository
),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshot (http://snapshots.repository.codehaus.org),
  eclipse.emf (http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/),
  indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/)



[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 3 seconds
[INFO] Finished at: Mon Jul 02 14:11:39 PDT 2007
[INFO] Final Memory: 2M/5M
[INFO]


C:\das\tuscany-das-1.0-incubating-beta1mvn
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Apache Tuscany DAS Implementation project
[INFO]   Tuscany DAS for Relational Databases
[INFO]   Tuscany DAS Samples
[INFO]   Tuscany DAS Canned DB Initializer Utility
[INFO]   Tuscany DAS Company Sample
[INFO]   Tuscany DAS Ajax Sample
[INFO]   Tuscany DAS J2SE Customer Sample
[INFO]
-
---
[INFO] Building Apache Tuscany DAS Implementation project
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] Skipping missing optional mojo:
org.apache.maven.plugins:maven-site-plugi
n:attach-descriptor
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking
for
upda
tes from apache.incubator
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-inst
all-plugin' could not be retrieved from repository: apache.incubator due
to
an e
rror: Error transferring file
[INFO] Repository 'apache.incubator' will be blacklisted
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking
for
upda
tes from codehaus-snapshot
[WARNING] repository metadata for: 'artifact
org.apache.maven.plugins:maven-inst
all-plugin' could not be retrieved from repository: codehaus-snapshot due
to
an
error: Error transferring file
[INFO] Repository 'codehaus-snapshot' will be blacklisted
Downloading:
http://www.ibiblio.net/pub/packages/maven2/org/apache/maven/plugins
/maven-jar-plugin/2.1/maven-jar-plugin-2.1.pom
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error building POM (may not be this

[jira] Created: (TUSCANY-1403) DAS Source distribution extract to same directory as Binary distribution

2007-07-02 Thread Luciano Resende (JIRA)

DAS Source distribution extract to same directory as Binary distribution


 Key: TUSCANY-1403
 URL: https://issues.apache.org/jira/browse/TUSCANY-1403
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-beta1
Reporter: Luciano Resende
Assignee: Luciano Resende
Priority: Minor
 Fix For: Java-DAS-beta1




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


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

[jira] Created: (TUSCANY-1404) Detail DAS samples' readme

2007-07-02 Thread Adriano Crestani (JIRA)

Detail DAS samples' readme
--

 Key: TUSCANY-1404
 URL: https://issues.apache.org/jira/browse/TUSCANY-1404
 Project: Tuscany
  Issue Type: Improvement
  Components: Java DAS RDB
Affects Versions: Java-DAS-beta1
Reporter: Adriano Crestani
Priority: Critical
 Fix For: Java-DAS-beta1


- Create a readme on DAS samples' top level dir that summarizes all DAS samples
- Detail how to run and use customer sample on its readme

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


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

[jira] Assigned: (TUSCANY-1404) Detail DAS samples' readme

2007-07-02 Thread Adriano Crestani (JIRA)


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

Adriano Crestani reassigned TUSCANY-1404:
-

Assignee: Adriano Crestani

 Detail DAS samples' readme
 --

 Key: TUSCANY-1404
 URL: https://issues.apache.org/jira/browse/TUSCANY-1404
 Project: Tuscany
  Issue Type: Improvement
  Components: Java DAS RDB
Affects Versions: Java-DAS-beta1
Reporter: Adriano Crestani
Assignee: Adriano Crestani
Priority: Critical
 Fix For: Java-DAS-beta1


 - Create a readme on DAS samples' top level dir that summarizes all DAS 
 samples
 - Detail how to run and use customer sample on its readme

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


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

Re: SCA 0.92 release?

2007-07-02 Thread Luciano Resende


Now that we are going to have a DAS release out, I'd like to plan to
have implementation.das and implementation.data available for the next
release.

I also like to have some improvements to the Contribution Services,
such as import/export and other scenarios that have been described on
the list recently. I'll update the wiki with these items.

On 7/2/07, haleh mahbod [EMAIL PROTECTED] wrote:

Posting to tuscany-user list as well to get input.

Any real world scenarios/samples that can be shared by users? It would be
great if we could start building a library of tips and real usage
examples..  a knowledge base.

Thanks
Haleh

On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:

 On 7/2/07, ant elder [EMAIL PROTECTED] wrote:
 
  On 7/2/07, Simon Laws [EMAIL PROTECTED] wrote:
  
   On 7/2/07, Venkata Krishnan [EMAIL PROTECTED] wrote:
   
Hi,
   
I am looking at the Policy Framework and shall update the wiki on
 the
specifics soon.  Once this is done to some level, I'd also like to
  help
   a
bit with the ws-* things (may be WS-Security to start with) that Ant
  has
listed on the wiki page.
   
- Venkat
   
On 6/30/07, ant elder [EMAIL PROTECTED] wrote:

 With the SCA 0.91 release now being voted on how about starting on
   0.92?

 I've already been adding some things I'm interested in getting
 done
  to
the
 next release wiki page -


   
  
 
 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
 so far thats mainly related to improving web services
 functionality.

 So anyone else interested in helping with an 0.92 release or have
  any
 function they'd like to suggest or add to the wiki page? How does
   aiming
 for
 getting it done 4 - 6 weeks again sound?

...ant

  
  
   The above link has an extrenuous - on the end. Taking that off gets
 me
   to
   the page. Can we move this information across the to the new wiki
 space
  (
   http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
   everyone (including non committers) can add to it?
  
   I'm working on the next phase of the distributed runtime which I want
 to
   get
   into the next release. This involves a few items.
  
   SCA Binding
   Topology model
   Distributed domain
   Node implementation
   Management assembly
  
   Also I need some of the ws items, in particular the ability to run
  without
   wsdl, so can help out there.
  
   We need to do something about logging and events to improvide runtime
   usability. We've talked about it before but not done anything yet.
 Ties
   into
   the management assembly.
  
   I'd also like to see the JMS binding in the release but can't commit
 to
   doing lots more work on including spec features. It's been working
 fine
   for
   me in my limited synchronous/rpc model. If I get time I'll take a look
  to
   see what it will take to add minimum asynch support but if anyone else
   fancies having a go at this then it's a good way to learn about
 Tuscany
   extensions.
 
 
  All these sound good, but its starting to sound a lot to get done in
 just
  a
  few weeks. How does the suggesting timeframe of 4 or so weeks sound?
 
  We'd talked once about having a release specifically targeting things
 like
  logging, events, and error handling. I'd still like to do that, if
 anyone
  wants to start now thats great but I doubt I'd have much time to help
 this
  release.
 
 ...ant
 
 I think 4 weeks is a bit too short. Given that we are getting into holday
 season I like the sound of 6 weeks better.

 I agree there is a lot there but in the spirit of your WS list I wasn't
 proposing that all of it gets done. I do think we need to make a start on
 the logging/errors sooner rather than later though even if it doesn't get
 into the next release. I'll offer my effort to help move it along once the
 distributed work starts drawing to a close.

 Simon





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

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

Re: The complete patch for TUSCANY-1341 is available