date:20070816

[jira] Created: (TUSCANY-1543) Demonstrate faulty transaction support in DAS

2007-08-16 Thread Amita Vadhavkar (JIRA)

Demonstrate faulty transaction support in DAS
-

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


Sample test cases showing where DAS is falling short in providing adequate 
transaction support.

-- 
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: Home page for Tuscany standalone runtime

2007-08-16 Thread Simon Laws

On 8/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 The runtime currently prints the servlet mappings to System.out when it
 starts. In order to make that kind of information easier to use, I've
 started to put together a home page that people can point their Web
 browser to, listing some basic information about the running Tuscany
 runtime, servlet endpoints, etc.

 I'm planning to start adding some of this home page support to a new
 home module.

 --
 Jean-Sebastien


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

 Sounds like a great idea. I'd like to provide and extension to this to add
some more information for when tuscany is running across several nodes. I
think it would be useful to show which nodes are running and, based on what
you say about endpoints, which references are resolved to those endpoints.
I'll look out for the new module.

Simon

Re: Tuscany/Geronimo Integration Demo

2007-08-16 Thread Vamsavardhana Reddy

I am not referencing this class directly in my code. Can it be that the
published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or not
the latest?? I can not think of other possibilities.

Vamsi

On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote:

On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

We put together a demo [1] on Tuscany/Geronimo integration for the
LinuxWorld 2007. You are welcome to play with it and give us feedback.

Please follow the instructions at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT
.
The demo scenario is captured at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png
.

The demo is built on top of the sandbox code in Geronimo [2] which is
discussed on [3].

Please note this is just the starting of effort and there are still
quite
a
lot to do. Please join us on this effort.

In the near term, I believe that we need to do the following:

1) Move the code out of sandbox and have them in the build with test
cases.
2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA
0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to
1.0-incubating-SNAPSHOT so that we have consistent modules.

After switching to 1.0-incubating-SNAPSHOT, I have run into a
NoClassDefFoundError:
org/apache/tuscany/sca/assembly/DefaultSCABindingFactory.

3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to
move
this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the
RC1?

GERONIMO-3351 has not been integrated into 2.0 release. Part of the
problem
is addressed in branches\2.0 and trunk. It affects only SNAPSHOT
dependencies and there is some discussion on whether the downloaded
version
(if it is different from SNAPSHOT) should be renamed, by the plugin
installer, to SNAPSHOT or the dependency resolution is Geronimo should
handle it in a different way. The problem we have run into is in
conjunction with another problem that occurs when a trailing / is not
present in the maven repo URL. This has been fixed in branches\2.0 and
trunk (not in 2.0 release though) and the work around for this is to put
that trailing / in the maven repo URLs in geronimo-plugin.xml. These
two
fixes will (most likely, but not guaranteed) go into 2.0.1 due to be
released soon (probably this week).

[1]

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/
[2]
http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/
[3]

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration
[4] https://issues.apache.org/jira/browse/GERONIMO-3351

Thanks,
Raymond

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

org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out a
week or so ago when I moved the majority of sca binding into the
binding-sca
module. I'm thinking that I was a little overzealous when I took this out
and that it probably needs to go back in. In the mean time can you create
a

org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl

instead?

Regards

Simon

Re: [DAS] Transaction support

2007-08-16 Thread Amita Vadhavkar

Hi Haleh,
Please see all the use case details below.

There are three user cases going wrong which I am trying to fix.

I have created a JIRA-1543 to demonstrate with examples how DAS is failing
in these use case scenarios. Patch contains 3 new test cases as below in
TransactionTests.java.
So far TransactionTests.java had only 1 test case and was not enough to
uncover these
issues.

1) when user passes connection to DAS, it is obvious that user is always
going to have a handle to it and so the only option should be to make user
control the transaction. Current DAS code issues commit/rollback / Command
for this case, which is an erroneous behavior. Due to this user loses its
ability to group commands based on business need in a transaction.
---check testUserUnableToControlExternallyInitedTransaction()

2) when managedtx=false and connection is created by DAS, NEITHER DAS NOR
USER issue any commit/rollback ANYTIME. This is equaly wrong. This way the
Transaction control is at the mercy of How DBMS behaves upon  close of a
connection. This can be corrected if getConnection() is exposed.
---check testUnableToCommitTransaction()

3) most important-data integrity violation! When managedtx=true and
Connection is created by DAS, and there are multiple applyChanges() which
need to be in same transaction to ensure data integrity, DAS fails
completely. Here exposing getConnection() won't do, as with this user can
even issue closeConnection() and DAS will not function with that. Instead,
if startTransaction(), endTransaction() are exposed, user will be able to
maintain data integrity based on his demand.
---check testDataIntegrityViolation()
___
Alternative approach will be remove managedtx attribute itself from
config.xsd and let user do whatever  he wants with the connection, in this
case just making sure user has handle to connection (either because he
created it or because of getConnection()) will be enough. i.e. always
delegate transaction control to the caller and don't handle it in DAS.
___
1testUserUnableToControlExternallyInitedTransaction
Scenario:- Stopped Employee department transfer
0) John Jones is in Advanced Technologies(Department1)
1) John Jones is removed from Advanced Technologies
2) User decides to revert the decision and rollsback the transaction

Ideally, it is expected that remove from Department1 (1)) should not have
happened
and John Jones should still be in Department1.

What is found in the end result is John Jones is removed from Department1
even though user has issued rollback.
_
2testUnableToCommitTransaction
Scenario:- Employee department transfer
0) John Jones is in Advanced Technologies(Department1)
1) John Jones is removed from Advanced Technologies
2) John Jones is added to New Technologies(Department2)

DAS Config has ConnectionInfo specified and user does not pass Connection to
DAS. Thus Connection is created by DAS and used in Commands. Also, in DAS
Config ConnectionInfo, managedtx=FALSE is set by user.  This signals DAS to
stop issuing any commit/rollback. Also, as Connection is internally formed
by DAS and not exposed to user, there is no way user can handle
commit/rollback.

After , 0), 1), 2), user assumes that change has happened and John Jones
is removed from Department1 and added to Department2. He creates a new
Connection and a new DAS instance and checks data in  database. When he
issues query using new connection and new DAS ., he gets SQLException
indicating lock could not be obtained on tables of interest and query could
not go thru. This is because  1),2) are not commited by DAS nor user and so
tables remained locked.
___
3testDataIntegrityViolation

Scenario:- Bank account money transter
0) Account1 original balance $1, account2 original balance $500
1) user removes $200 from account1
2) user adds $200 into account2

DAS Config has ConnectionInfo specified and user does not pass Connection to
DAS. Thus Connection is created by DAS and used in Commands. Also, in DAS
Config ConnectionInfo, managedtx=TRUE is set by user.  This signals DAS to
issue commit/rollback/Command. Also, as Connection is internally formed by
DAS and not exposed to user, there is no way user can handle
commit/rollback.

After , 0), 1), there is a network crash during 2) and so 2) does not go
thru, but on the other hand there is a SQLException thrown during 2) due to
which DAS attempts a rollback. Now what is expected is 1) and 2) should both
be rolled back, and account1 and account2 should have old balaces. This will
ensure data integrity.

When user checks data in DBMS, what is found is account1 is $200

Re: Tuscany/Geronimo Integration Demo

2007-08-16 Thread Simon Laws

On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

I am not referencing this class directly in my code. Can it be that the
published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or
not
the latest?? I can not think of other possibilities.

Vamsi

On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote:

On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

We put together a demo [1] on Tuscany/Geronimo integration for the
LinuxWorld 2007. You are welcome to play with it and give us
feedback.

Please follow the instructions at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT
.
The demo scenario is captured at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png
.

The demo is built on top of the sandbox code in Geronimo [2] which
is
discussed on [3].

Please note this is just the starting of effort and there are still
quite
a
lot to do. Please join us on this effort.

In the near term, I believe that we need to do the following:

1) Move the code out of sandbox and have them in the build with test
cases.
2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java
SCA
0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to
1.0-incubating-SNAPSHOT so that we have consistent modules.

After switching to 1.0-incubating-SNAPSHOT, I have run into a
NoClassDefFoundError:
org/apache/tuscany/sca/assembly/DefaultSCABindingFactory.

3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared
to
move
this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in
the
RC1?

GERONIMO-3351 has not been integrated into 2.0 release. Part of the
problem
is addressed in branches\2.0 and trunk. It affects only SNAPSHOT
dependencies and there is some discussion on whether the downloaded
version
(if it is different from SNAPSHOT) should be renamed, by the plugin
installer, to SNAPSHOT or the dependency resolution is Geronimo should
handle it in a different way. The problem we have run into is in
conjunction with another problem that occurs when a trailing / is
not
present in the maven repo URL. This has been fixed in branches\2.0
and
trunk (not in 2.0 release though) and the work around for this is to
put
that trailing / in the maven repo URLs in geronimo-plugin.xml
. These
two
fixes will (most likely, but not guaranteed) go into 2.0.1 due to be
released soon (probably this week).

[1]

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/
[2]
http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/
[3]

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration
[4] https://issues.apache.org/jira/browse/GERONIMO-3351

Thanks,
Raymond

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

org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out
a
week or so ago when I moved the majority of sca binding into the
binding-sca
module. I'm thinking that I was a little overzealous when I took this
out
and that it probably needs to go back in. In the mean time can you
create
a

org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl

instead?

Regards

Simon

You may very well be right. Time to push some new snapshots out! Let me find
out how to do that.

Simon

[jira] Assigned: (TUSCANY-1543) Demonstrate faulty transaction support in DAS

2007-08-16 Thread Amita Vadhavkar (JIRA)


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

Amita Vadhavkar reassigned TUSCANY-1543:


Assignee: Amita Vadhavkar

 Demonstrate faulty transaction support in DAS
 -

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


 Sample test cases showing where DAS is falling short in providing adequate 
 transaction support.

-- 
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-1543) Demonstrate faulty transaction support in DAS

2007-08-16 Thread Amita Vadhavkar (JIRA)


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

Amita Vadhavkar updated TUSCANY-1543:
-

Attachment: 1543.patch

testUnableToCommitTransaction - is commented in patch as it locks tables in 
database and so disturbs other  test cases. It can be uncommented and run 
stanalone though.

 Demonstrate faulty transaction support in DAS
 -

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

 Attachments: 1543.patch


 Sample test cases showing where DAS is falling short in providing adequate 
 transaction support.

-- 
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: XQuery Implementation type for SCA

2007-08-16 Thread Jean-Sebastien Delfino


[snip]
Raymond Feng wrote:

Hi,

MPL seems to be acceptable if we don't modify the sources. Please see 
http://people.apache.org/~rubys/3party.html.


The SAXON is available at 
http://repo1.maven.org/maven2/net/sf/saxon/saxon/8.7/saxon-8.7.jar.


Thanks,
Raymond

- Original Message - From: Vasil Vasilev [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, August 14, 2007 11:04 AM
Subject: Re: XQuery Implementation type for SCA



Sure! That is a perfect idea!

However, we should think of the Saxon binaries. Are they already 
available in the repository or we should add them? Are there any 
legal issues also involved?


Bye, Vasil


 Оригинално писмо 
От:  ant elder [EMAIL PROTECTED]
Относно: Re: XQuery Implementation type for SCA
До: tuscany-dev@ws.apache.org
Изпратено на: Вторник, 2007, Август 14 18:45:26 EEST
--

Thats a pretty impressive amount of work!

In the JIRA you comment that its not ready for checkin yet, i know 
it needs
things like the pom.xml's fixed up before it will run as part of the 
build

but how about we check in to the svn trunk code now anyway and just not
include the new modules in the build and then we can all help 
incrementally

fix it up?

   ...ant



Pretty impressive indeed!

I took a look at what you attached to the JIRA and was able to get your 
databinding-saxon and implementation-xquery modules and the quote-xquery 
sample working almost right away.


I just had to download saxonb8-9j.zip manually, install saxon8.jar and 
saxon8-dom.jar in my local Maven repository (as the public Maven repos 
seems to only have an old saxon 8.7), come up with Maven pom.xml files 
for your three modules, move TestHelper.java from 
quote-xquery/src/test/java to src/main/java (as with Maven code under 
src/main doesn't see src/test) and...


---
T E S T S
---
Running xquery.quote.XQueryQuoteClientTestCase
Added Servlet mapping: http://localhost:8085/QuoteJoinService
Added Servlet mapping: http://localhost:8085/AvailQuoteProviderService
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.591 sec

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

...

[INFO] 


[INFO] BUILD SUCCESSFUL
[INFO] 



:)

That's really great work!

I have checked in the three modules for others to take a look. They are 
there:

http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-saxon/
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-xquery
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/quote-xquery

I have also put in databinding-saxon/mvn-install-saxon.sh a small Linux 
script to help people download and install saxon in their local Maven 
repositories for now. At some point we're going to need saxonb 8.9 in a 
public Maven repository to avoid this manual install step.


I think we should start new discussion threads on the dev list to discuss:
- how implementation-xquery works and how we can leverage it to do 
interesting things
- the questions and issues you raised in 
http://issues.apache.org/jira/browse/TUSCANY-1536


Thanks again for this contribution!

--
Jean-Sebastien


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

[jira] Assigned: (TUSCANY-1536) Implementation type for XQuery

2007-08-16 Thread Jean-Sebastien Delfino (JIRA)

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

Jean-Sebastien Delfino reassigned TUSCANY-1536:
---

Assignee: Jean-Sebastien Delfino

Implementation type for XQuery
--

Key: TUSCANY-1536
URL: https://issues.apache.org/jira/browse/TUSCANY-1536
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Misc Implementation Extensions
Reporter: Vasil Janov Vasilev
Assignee: Jean-Sebastien Delfino
Priority: Minor
Fix For: Java-SCA-Next

Attachments: xquery_impl.tar.gz

An implementation type for components written using the XQuery script.
Some notes about this prototype:
1. I see XQuery as a mighty data integration technology, that's why, in my
opinion, the SCA specification should be enhanced with XQuery-related
implementation type.
2. In order to prove this concept I created simple extension to Tuscany,
which interprets implementation type implementation.xquery. Generally
the following contributions were done:
- xquery artifact resolver
- xquery implementation provider
- Saxon data binding and transormes for DOM Nodes and SDO DataObjects
3. As underlying implementation Saxon B is used. This has its
limitations - it is not schema aware, but it is free (MPL - licensed).
4. I created test cases for the following scenarios:
- Sending data from one SCA component to XQuery component
- Feeding data to XQuery component by using properties
- Binding XQuery component as a web service
- referencing other SCA components from the XQuery component
5. In order to allow integration of XQuery in SCA I have also provided
some specification of how references, services and properties can be
defined in the XQuery file (see examples).
The prototype is not ready to checkin, i.e. for example: it is not formated,
there are no all needed
unit tests, it is not made runnable with Maven, i.e. it is compilable with
Eclipse (I have used Eclipse 3.2)
It consists of the following projects (you can find them in the attachment)
- tuscany-implementation-xquery - provides the xquery implementation
- tuscany-databinding-saxon - provides saxon-related databindings and
transformations
- sample-quote-xquery - integration scenario for the prototype
- saxon-lib - the saxon libraries
This prototype has the following limitations - as currently seen by me:
1. The Saxon should be enhanced so that one can set external variables (of
Object type) when making single function call
2. Currently in create of XQueryImplementationProvider I set data bindings
for the services and references. In order to have a data transformer later,
all these
references and services should be with remotable interfaces, so that their
original bindings are set. Is this the correct way to do it? Or may be I
should provide my own binding (not databinding, but binding)?
3. Limitation - only Java interfaces can be implemented by XQuery
implementations
4. Is there any way to say which configuration is associated with a given
invocation? Currently NodeInfo objects are transformed from one configuration
to another which has performance impact. I.e. can I associate an object with
an invocaion in some kind of context?
5. Limitation: currently the result of XQuery cane be only a single item, not
a collection
6. Saxon B can not interpret XML documents in which there are namespace
declarations. This requires conversion, which is a step that increases memory
overhead and speed
7. For DataObjects transformation, it is presupposed that that their starting
element is the name of the implemented interface with its first letter made
to lower case. Is this the best variant?
8. Why I can not invoke directly from the client a component with data
binding, i.e. why the self reference can not contain Data transformation
interceptor?

--
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] Commented: (TUSCANY-1536) Implementation type for XQuery

2007-08-16 Thread Jean-Sebastien Delfino (JIRA)

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

Jean-Sebastien Delfino commented on TUSCANY-1536:
-

I have commited the three modules:

- tuscany-databinding-saxon
- tuscany-implementation-xquery
- sample-quote-xquery

under revision r566530.

Thanks a lot for this great contribution to Tuscany!

Implementation type for XQuery
--

Attachments: xquery_impl.tar.gz

--
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] Commented: (TUSCANY-1536) Implementation type for XQuery

2007-08-16 Thread Jean-Sebastien Delfino (JIRA)

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

Jean-Sebastien Delfino commented on TUSCANY-1536:
-

I am leaving the JIRA open for now as you have raised interesting design
limitations / issues, which still need to be addressed.

Implementation type for XQuery
--

Attachments: xquery_impl.tar.gz

--
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: Move up to Axis2 1.3?

2007-08-16 Thread Venkata Krishnan

+1 to do this now.

- Venkat

On 8/14/07, ant elder [EMAIL PROTECTED] wrote:

 Axis2 1.3 has just been released so how about moving up to that? There's a
 lot of improvements and bug fixes in it and as its the level we'll likely
 go
 1.0 with i think it would be good to get it in sooner so we have time to
 find and fixes any problems. There's a few minor changes we need to do in
 Tuscany to move up but I have it almost going, just one failing testcase
 remaining, so what do people think, should we move up now or wait till
 after
 our next release?

...ant

Re: DAS - relationship with composite keys

2007-08-16 Thread Amita Vadhavkar

I think with JIRA-1464 resolved, this issue is fixed.
Regards,
Amita

On 4/28/07, Adriano Crestani [EMAIL PROTECTED] wrote:

 Sorry, the query above should be SELECT A.id http://a.id/, A.b_id1,
 B_id1,
 B_id2 from A, B; instead of SELECT A.id http://a.id/, A.b_id1 from A,
 B;

 Adriano Crestani

 On 4/27/07, Adriano Crestani [EMAIL PROTECTED] wrote:
 
  I guess the relationship is considered for the key part present in
 select.
  e.g. if you look at the current CompoundKeyRelationshipTests in java rdb
  das,
 
  If the relationship is considered only for the keypart present in
 select,
  the populated graph will possible not correctly represent the data on
 the
  database.
 
  For example:
 
  Table A:
  Metadata = id, b_id1, b_id2 (composed foreign key)
  Row1 = 1, 1, 1
  Row2 = 2, 2, 1
  Row3 = 3, 1, 2
  Row4 = 4, 2, 2
 
  Table B:
  Metadata = id1, id2 (composed primary key)
  Row1 = 1, 1
  Row2 = 2, 1
  Row3 = 1, 2
  Row4 = 2, 2
 
  To clarify the references between tables mapped to ERD(Entity
 Relationship
  Diagram):
 
  B(Row1) - A(Row1)
  B(Row2) - A(Row2)
  B (Row3) - A (Row3)
  B(Row4) - A(Row4)
 
  Relationship definition:
  Relationship name=*A-B* primaryKeyTable=B
 foreignKeyTable=Amany
  =*true*
 KeyPair primaryKeyColumn=id1 foreignKeyColumn =*b_id1* /
KeyPair primaryKeyColumn =id2 foreignKeyColumn=*b_id2* /
  /Relationship
 
  The query SELECT A.id, A.b_id1 from A, B;
 
  Supposing that the relationship is created even if not all the keypairs
  are present on the result, the sdo graph references created, if I'm not
  missing anything, as described bellow:
 
  B(1, 1) - A(1, 1)
 
  B(3, 1) - A(1, 1)
 
  B(2, 1) - A(2, 2)
 
  B(2, 2) - A(2, 2)
 
  B(1, 1) - A(3, 1)
 
  B(3, 1) - A(3, 1)
 
  B(2, 1) - A(4, 2)
 
  B(2, 2) - A(4, 2)
 
  Concluding, the data related on sdo graph are not correctly described,
  cause it is different from how they are related on the database. Though,
 if
  the sdo user does not know how the data are on the database, the user
 would
  get a wrong idea of how data are linked. On the example above the sdo
 user
  may think that a row of table A is referenced by two different rows of
 table
  B,  but  on the database it does not exist.
 
  Adriano Crestani
 
 
  On 4/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
  
   I am not sure if I am interpreting the question correct, but please
 see
   below findings.
  
   I guess the relationship is considered for the key part present in
   select.
   e.g. if you look at the current CompoundKeyRelationshipTests in java
 rdb
   das,
   Data:
   -
   protected static Object[][] orderDetailsData = {{ Integer.valueOf
   (1),
   Integer.valueOf(1), new Float(1.1)},
   {Integer.valueOf(1), Integer.valueOf(2), new Float(1.2)},
   {Integer.valueOf(2), Integer.valueOf(1), new Float(2.1)},
   {Integer.valueOf (2), Integer.valueOf(2), new Float(2.2)}};
  
  
   protected static Object[][] orderDetailsDescriptionData =
   {   {Integer.valueOf(1), Integer.valueOf(1), Integer.valueOf(1),
   Descr
   1,1,1},
   { Integer.valueOf(2), Integer.valueOf(1), Integer.valueOf(1),
   Descr
   2,1,1},
   {Integer.valueOf(3), Integer.valueOf(1), Integer.valueOf(2),
   Descr
   3,1,2},
   {Integer.valueOf(4), Integer.valueOf(1), Integer.valueOf(2),
   Descr
   4,1,2},
   {Integer.valueOf(5), Integer.valueOf(2), Integer.valueOf(1),
   Descr
   6,2,1},
   {Integer.valueOf(6), Integer.valueOf(2), Integer.valueOf(2),
   Descr
   6,2,2}};
  
   SQL:
   -
   the below statement's graph does consider relationship
   String statement = SELECT ORDERDETAILS.ORDERID,
   ORDERDETAILSDESC.ORDERID
   FROM ORDERDETAILS LEFT JOIN ORDERDETAILSDESC 
   + ON ORDERDETAILS.ORDERID =
 ORDERDETAILSDESC.ORDERIDAND 
   +
  ORDERDETAILS.PRODUCTID =
 ORDERDETAILSDESC.PRODUCTID +
  WHERE ORDERDETAILS.ORDERID = 1 AND
   ORDERDETAILS.PRODUCTID = 1;
  
   where the compound key is {ORDERID, PRODUCTID}.
  
   Similar is case when we have
   SELECT ORDERDETAILS.ORDERID, ORDERDETAILSDESC.PRODUCTID
  
   OR
   basically at lease any one column from ORDERDETAILS.ORDERID/PRODUCTID
   and at
   least any one
   column from ORDERDETAILSDESC.ORDERID/PRODUCTID - makes DAS to look at
   relationship.
  
   But I see there one more confusion:-
   even if the relationship is getting considered, in above cases or even
   case
   like below which covers
   the complete compound key:-
   SELECT ORDERDETAILS.ORDERID, ORDERDETAILS.PRODUCTID,
   ORDERDETAILSDESC.ORDERID,ORDERDETAILSDESC.PRODUCTID+
FROM ORDERDETAILS LEFT JOIN ORDERDETAILSDESC 
   + ON ORDERDETAILS.ORDERID = ORDERDETAILSDESC.ORDERID AND  +
  ORDERDETAILS.PRODUCTID = ORDERDETAILSDESC.PRODUCTID  +
  WHERE ORDERDETAILS.ORDERID = 1 AND ORDERDETAILS.PRODUCTID = 1;
  
   As, TableData.columnData is a java Map, the returned count of
   orderdetailsdesc for the orderdetail(1,1)

Re: Move up to Axis2 1.3?

2007-08-16 Thread ant elder

On 8/14/07, ant elder [EMAIL PROTECTED] wrote:

 Axis2 1.3 has just been released so how about moving up to that? There's a
 lot of improvements and bug fixes in it and as its the level we'll likely go
 1.0 with i think it would be good to get it in sooner so we have time to
 find and fixes any problems. There's a few minor changes we need to do in
 Tuscany to move up but I have it almost going, just one failing testcase
 remaining, so what do people think, should we move up now or wait till after
 our next release?

...ant


Actually, I've been talking to one of our big Tuscany users about this and
it would be more convenient for them if we stayed at Axis2 1.2 for the time
being so they don't have to update all their associated Axis2 code.

...ant

Re: Contribute to SCA-OSGi integration

2007-08-16 Thread ant elder

Hi SCA/OSGi-ers,

Just bringing this up again to see if there is any interesting in moving
this along still. We've been talking about having a Tuscany 1.0 release in a
couple of months, be great if we could have a good OSGi story for that. Also
the Apache Felix 1.0 release is out now and the existing
implemention.osgicode has been moved off  SNAPSHOTs to use Felix
1.0 so we can now include that in releases (though i think one of the itests
still has an intermittent failure so would be good to fix that as well).

   ...ant


On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote:

 Hi SCA/OSGi-ers.

 I did some initial work back during the M2 days (working with Nicole) to
 host Tuscany in an Equinox runtime. It looks like I may have some time
 to re-engage during the next few months, so is there anything in
 particular that I could be looking at to help move the OSGi efforts
 ahead? Like Bill and Raymond below, my primary interest is in seeing
 OSGi used as a container for hosting SCA.

 Cheers,
 Joel

 -Original Message-
 From: Rajini Sivaram [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, June 27, 2007 4:20 AM
 To: tuscany-dev@ws.apache.org
 Subject: Re: Contribute to SCA-OSGi integration

 Sebastien,

 Graham and I will be looking at the support for packaging of SCA
 contributions as OSGi bundles, once the work on implementation.osgi is
 complete.


 Thank you...

 Regards,

 Rajini

 On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
 
  Bill Barnhill wrote:
   Hi,
  
   As I may have mentioned earlier I also have been working on the
 SCA-OSGi
   integration, but from the third aspect that Raymond mentions, using
   OSGi as
   an underlying technology for an SCA container providing an extension
   mechanism, dependency resolution and service registry capabilities.
  
   I think my work would dovetail nicely with the work Rajini and
 Graham
   have
   been doing. Would it be possible to create an osgi directory under
   contrib
   with a subdir under that for each of our efforts (host, binding,
   implementation)
  
   What do you think?
  
 
  Hi Bill,
 
  That sounds like a good idea. Tuscany modules are not that different
  from OSGI bundles, I think it wouldn't be too difficult to package
 them
  as actual bundles, and come up with a variation of host-embedded that
  will load them as such, allowing for some isolation and better
  jar/bundle dependency management.
 
  Do you have the structure you need with sca/modules/host-osgi? Do you
  have code that we can look at?
 
  Any questions or issues that we can help with?
 
  On a different, but related subject, has anybody started on supporting
  the package of (application) SCA contributions (as defined by the SCA
  assembly spec) as OSGI bundles?
 
  Thanks
 
  --
  Jean-Sebastien
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 The contents of this e-mail are intended for the named addressee only. It
 contains information that may be confidential. Unless you are the named
 addressee or an authorized designee, you may not copy or use it, or disclose
 it to anyone else. If you received it in error please notify us immediately
 and then destroy it.

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

[jira] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML

2007-08-16 Thread Ron Gavlin (JIRA)


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

Ron Gavlin commented on TUSCANY-1541:
-

Hi Sunny,

In order to correctly identify whether this is an SCA databinding problem or an 
SDO problem, would it be possible for you to invoke XMLHelper.load() with the 
same xml stream outside of the SCA environment?

Thanks,

- Ron

 XMLStreamException in when calling XMLHelper.load() with a large XML
 

 Key: TUSCANY-1541
 URL: https://issues.apache.org/jira/browse/TUSCANY-1541
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
 Environment: Tomcat
Reporter: Sunny Ip
Priority: Critical
 Fix For: Java-SDO-Next


 When XMLHelper.load() is called with a very long XML string, OMStAXWrapper 
 throws an XMLStreamException. I get this problem when I'm receiving a WS 
 response with an SDO object containing a collection of records, leading to a 
 TransformationException when databinding. 

-- 
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]

Spec clarification for conversational/callback semantics

2007-08-16 Thread Simon Laws

While reviewing support for conversational services there were a few
outstanding issues (https://issues.apache.org/jira/browse/TUSCANY-1511). A
couple of these issues require a little clarification of the SCA
specifications. Can someone with their SCA spec hat on help out? Here are
the two primary issues:

1/ Stateful Callbacks - Given the the following scenario where the
ConversationalClient has a reference to a ConversationalService

@Remotable
@Conversational
public interface ConversationalCallback {
  ...
}

@Remotable
@Conversational
@Callback(ConversationalCallback.class)
public interface ConversationalService {
  
}

@Scope(CONVERSATION)
public class ConversationalClientImpl implements ConversationalClient,
ConversationalCallback {
@Reference
protected ConversationalService conversationalService;
  
}

@Scope(CONVERSATION)
public class ConversationalServiceImpl implements ConversationalService {
@Callback
protected ConversationalCallback conversationalCallback;
  ...
}

In the current implementation the specification has been interpreted to mean
that the client component, i.e. the component implementing the callback
interface, must be marked as having conversational scope if it is required
that callback messages return to the same instance of the client component
that originated the conversational call. Is this the correct interpretation
of the specification, in particular Section 1.6.7.1 of the SCA Java
Annotations and APIs V1.0 specification.


2/ The specifications describe the freeing of state associated with a
conversation when Conversation.end() is called on a conversation object .
See section 1.6.5 of the SCA Java Annotations and APIs V1.0 specification.

Assuming that the Conversation object is available from a service reference
within the client of the conversation then, in the current implementation,
the state associated with the conversation held by the service will not be
freed directly if end() is called.

A separate message exchange would be required between client and service to
carry this end() instruction directly. As it stands the target conversation
will eventually time out.

What is the specification's intention in this case?

Regards

Simon

Re: Monitoring, logging and exceptions (again)

2007-08-16 Thread Simon Laws

On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 ant elder wrote:
  On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
 
  Simon Laws wrote:
 
  On 8/8/07, ant elder [EMAIL PROTECTED] wrote:
 
 
  On 8/7/07, Simon Laws [EMAIL PROTECTED] wrote:
 
 
  We talked about this before (
  http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16784.html)
 
  but
 
  didn't come to any conclusions. So,
 
  1/ What is the requirement?
  2/ What is the technical solution?
  3/ When should we try and get it done?
 
  To get things going again here are some thoughts drawn from what was
 
 
  said
 
 
  in
  the referenced thread.
 
  1/ An API in line with accepted logging/management practices to
 
  support
 
  arbitrary debugging and runtime info, warning and error logging
  A common approach to exception/error handling specifically
 around
 
 
  the
 
 
  detail recorded in the error messages
  Internationalization/localization
  Execution Tracing
 
  2/ Keeping it simple was a popular sentiment
  A number of java logging solutions have been proposed Log4J,
 SLF4J
  etc.
 I believe DAS is using Log4J.
 We have dependencies that also use logging tools. We can take
 a
  look
  at how others approach this, e.g, quick glance at the last CxF
 release
  shows
  they include SLF4J jars
  Aspects were investigated to show how they can be used for
 
  tracing,
 
  seems like an interesting optional facility but adds extra
  complexity/dependencies
  There was also a suggestion that we could implement some higher
 
 
  level
 
 
  tracing, e.g. runtime starts, stops, application loading, component
  instance
  creation etc.
  We need to move error message out of the code and into resource
 
 
  files
 
 
  3/ I think we can reasonably expect to agree what approach we are
 
  going
 
  to
 
 
  take fairly quickly and provide some examples, i.e. before the next
  release?
  People suggested before that we take time out to go through the
 
  code
 
  based and bring it into line. This will take a lot of time but can
 we
 
 
  get
 
 
  it
  into 1.0?
 
  Please add your thoughts to the list and we can then draw them
 
  together,
 
  try
  some of it out and come to some conclusions.
 
  Simon
 
 
 
  +1 for going with SLF4J. If we can decide on this soon then we can
 all
  just
  start adding it in to the code we're working on and debugging, and
 then
  maybe have a focused sweep before 1.0 to make sure its in everywhere
  useful.
 
 ...ant
 
 
 
  Cross posting to the user list also as I expect this is close to
 
  everyone
 
  heart.  Can everyone reply to both lists.
 
  Thanks
 
  Simon
 
 
 
  We had a similar discussion in April [1].
 
  Here's what I suggest for logging:
 
  - Separate the trace calls from the runtime code. Insert them
  automatically at build time or run time using Aspectj. Raymond on SCA
  and Kelvin on SDO already showed how to do it.
 
  - Use SLF4J in these generated trace calls.
 
  [1]
 
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL 
 PROTECTED]
 
  Thoughts?
 
 
 
  There were several posts on that referenced thread less keen on using
  aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour
 the
  simplicity of the  more traditional approach of explicit logging calls
 in
  Tuscany.
 
 ...ant
 
  [1]
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL 
 PROTECTED]
  [2]
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL 
 PROTECTED]
  [3]
 
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL 
 PROTECTED]
 
 

 OK then, I don't care much about whether or not we use aspects, but I
 think that calls to trace method entry/exit+parameters should be
 externalized and inserted automatically when we build Tuscany, as IMO
 writing all these repetitive calls by hand will be problematic:
 - it's a lot of work and will be difficult to maintain and keep
 consistent (when methods are renamed, parameters added etc.)
 - it puts a big requirement on people contributing Tuscany extensions to
 write all these calls in their extensions as well
 - it will make Tuscany difficult to integrate in an environment using a
 different logging framework

 Thoughts?

 --
 Jean-Sebastien


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

 A number of different requirements have been discussed and solutions
proposed. My 2p (I'm using Raymond's definitions b.t.w)

Tracing: Dump out input/output/exception for method calls for the purpose of
debugging/troubleshooting. (Target for developers/technical support)

I feel that tracing of execution paths through the Tuscany codebase would be
useful but agree that  it's a lot of work and will be difficult to maintain
and keep consistent if we did it manually.  I'm happy

Re: Late resolution of reference targets - was:Accessing global domain information

2007-08-16 Thread Simon Laws

On 8/15/07, Simon Laws [EMAIL PROTECTED] wrote:



 On 8/15/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
 
  Raymond Feng wrote:
   Comments inline.
  
   Thanks,
   Raymond
  
   - Original Message - From: Simon Laws
   [EMAIL PROTECTED] 
   To: tuscany-dev tuscany-dev@ws.apache.org
   Sent: Tuesday, August 14, 2007 12:37 AM
   Subject: Late resolution of reference targets - was:Accessing global
   domain information
  
  
   Currently in CompositeWireBuilderImpl.connectComponentReference all
   targets
   are converted to bindings on a reference and the targets are
   removed. During this process the source and target bindings are
  compared
   until matching wireable bindings are found.
  
  
   This is not always possible because some of the targets are not
   resolvable at this point.
  
   Currently only the sca binding implements WireableBinding. I've
  opened
   https://issues.apache.org/jira/browse/TUSCANY-1534 about this.
  
   If the domain is distributed then at the build stage some of the
  targets
   will remain unresolved. For the new sca binding I have made the
   assumption
   here that unresolved targets take a copy of the bindings they may be
   resolved against at a later date and that the targets are maintained
   on the
   reference after the build stage. I still assume that the SCA binding
   is the
   only valid wireable binding at present.
  
  
   I start to look into this area too from a different perspetive. Please
 
   see
  
  http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Service+References
  .
  
  
   So I'm proposing that
  
   1. The builder should retain the list of unresolved targets for use
   after
   the build stage
   2. The list of bindings that might be used to resolve a target at a
   later
   date are associated with each target
  
  
   +1. What will the data structure look like? There are some cases that
   mixed styles are used to define the binding endpoint if the reference
   multiplicity is greater than 1 and promotion is used. For example, we
   can have the following:
  
   InnerComposite:
   composite name=InnerComposite ..
  component name=C1 ...
  reference name=myRef target=C2/S1 C3/S1
  binding.sca/
  binding.x/
  /reference
  /component
  
  component name=C2 ...
  ...
  /component
  
  component name=C3 ...
  ...
  /component
  
  reference name=myOuterRef promote=C1/myRef
  binding.y
  /reference
   /composite
  
   composite name=OuterComposite ...
  component name=C4 implementation.composite=ns1:InnerComposite
  reference name=myOuterRef target=C5/S1/
  /component
  ...
  component name=C5 ...
  ...
  /component
   /composite
  
   Then the effective wires for myRef will be:
  
   C2/S1 (binding.sca/binidng.x), C3/S1 (binding.sca/binding.x), C5/S1
   (binidng.y)
  
  
   Come wire creation time care must be take to create remote wires for
   unresolved targets. What I do at the moment is:
  
   CompositeActivatorImpl.addReferenceBindingProviders
 As before, create  providers for all bindings that represent
   resolved
   targets
  
 For all unresolved targets
  If support is enabled create a cloned SCA binding and add
   it to
   the reference binding list (so that a wire will be created).
  This is pretty much what goes on in the
   CompositeWireBuilder
   but I've delayed it until here in the expectation that we will do
  remote
   binding matching one wireable support is fixed
  Create an SCA binding provider which will look up the
  remote
   endpoint at start() time.
  
   Thoughts?
  
   Regards
  
   Simon
  
  
 
  Sorry, but I'm having trouble understanding all this, it's starting to
  get a little complicated for me... Could somebody please give a *short*
  summary of the scenario that this is attempting to cover? Thanks.
 
  --
  Jean-Sebastien
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
  Raymond is coming at the problem from a different direction to me so
 I'll let him give examples. For me the scenario is

 composite ... name=HelloWorld
 component name=HelloWorldClient
 implementation.java class=HelloWorldClient /
 reference name=helloWorldService target=HelloWorldService /
 /component
 /composite

 Where HelloWorldService does not appear in the loaded contributions.

 Simon

Hi, as an alternative to this is there a way that we can just create all the
bindings/wires for the unresolved targets and then select the correct wire
either when the invocation handler is created or even as late as when the
first call is made through a reference.

I've been thinking about this because it is clear that we don't know how
long in the future it will be before a target is available to

Javadoc in sca/itest

2007-08-16 Thread Brian Murray

 I'd like to take a crack at expanding the Javadoc in the sca itests, and
I'd like some feedback on the benefit and conventions of doing so.

I've noticed that the Javadoc in the sca/itests could be enhanced (or in
many cases is absent altogether). Javadoc seems to me a great way to
document the intent of the test cases.  Including the package.html and
overview.html files will allow a single source of documentation.  This will
allow us to more easily assess test coverage of concepts (rather than merely
API's).

As for javadoc conventions:

I'd like to add javadoc to the src/test subdirectories.  This is where we
would document the scenario being tested.  (e.g. Attempt to locate a service
with an invalid name.)

I'd like to add javadoc to the src/main subdirectories to describe the
requirements on the services (e.g.  This must be a composite within a
composite) for the test case scenario to be achieved.

Please let me know if you'd like me to add or subtract from the above.

Re: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

2007-08-16 Thread Jean-Sebastien Delfino


[snip]
[EMAIL PROTECTED] wrote:
Online report : 
http://vmbuild.apache.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/381/buildId/257310 


Build statistics:
  State: Failed

  

[snip]

[INFO] 


[ERROR] FATAL ERROR
[INFO] 


[INFO] Java heap space
[INFO] 


[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
[INFO] 


[INFO] Total time: 29 minutes 48 seconds
[INFO] Finished at: Wed Aug 15 02:00:26 PDT 2007
[INFO] Final Memory: 63M/63M
[INFO] 



 

  


It looks like our nightly build is breaking with out of memory 
exceptions. Most of us are running with more than 63M allocated to Maven 
and are not running into this issue in our local builds.


What needs to happen for the continuum build to allocate more than 63M 
heap to Maven as well?


--
Jean-Sebastien


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

[jira] Assigned: (TUSCANY-1477) CompositeActivatorImpl.deactivate() is empty

2007-08-16 Thread Jean-Sebastien Delfino (JIRA)


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

Jean-Sebastien Delfino reassigned TUSCANY-1477:
---

Assignee: Jean-Sebastien Delfino

 CompositeActivatorImpl.deactivate() is empty
 

 Key: TUSCANY-1477
 URL: https://issues.apache.org/jira/browse/TUSCANY-1477
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.91
Reporter: Vamsavardhana Reddy
Assignee: Jean-Sebastien Delfino
 Fix For: Java-SCA-Next


 CompositeActivatorImpl.deactivate() is empty.  Should there be some code in 
 there?
 I am seeing a problem with removing components and composites from 
 EmbeddedSCADomain.  I have called EmbeddedSCADomain.DomainCompositeHelper 
 ().stopComponent() with all the component names in my composite and then 
 EmbeddedSCADomain.DomainCompositeHelper ().removeComposite().  I am noticing 
 that the components are not getting removed from 
 EmbeddedSCADomain.domainComposite.  
 EmbeddedSCADomain.DomainCompositeHelper.removeComposite() is calling 
 compositeActivator.deactivate().  But CompositeActivatorImpl.deactivate() is 
 empty. 

-- 
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: Tuscany/Geronimo Integration Demo

2007-08-16 Thread Jean-Sebastien Delfino

Simon Laws wrote:

On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

I am not referencing this class directly in my code. Can it be that the
published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or
not
the latest?? I can not think of other possibilities.

Vamsi

On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote:

On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

We put together a demo [1] on Tuscany/Geronimo integration for the
LinuxWorld 2007. You are welcome to play with it and give us

feedback.

Please follow the instructions at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT

.
The demo scenario is captured at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png

The demo is built on top of the sandbox code in Geronimo [2] which

discussed on [3].

Please note this is just the starting of effort and there are still

quite

a
lot to do. Please join us on this effort.

In the near term, I believe that we need to do the following:

1) Move the code out of sandbox and have them in the build with test
cases.
2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java

SCA

0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to
1.0-incubating-SNAPSHOT so that we have consistent modules.

After switching to 1.0-incubating-SNAPSHOT, I have run into a
NoClassDefFoundError:
org/apache/tuscany/sca/assembly/DefaultSCABindingFactory.

3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared

move

this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in

the

RC1?

not

present in the maven repo URL. This has been fixed in branches\2.0

and

trunk (not in 2.0 release though) and the work around for this is to

put

that trailing / in the maven repo URLs in geronimo-plugin.xml

. These

two
fixes will (most likely, but not guaranteed) go into 2.0.1 due to be
released soon (probably this week).

[1]

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/

[2]

http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/

[3]

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration

[4] https://issues.apache.org/jira/browse/GERONIMO-3351

Thanks,
Raymond

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

org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken out

week or so ago when I moved the majority of sca binding into the
binding-sca
module. I'm thinking that I was a little overzealous when I took this

out

and that it probably needs to go back in. In the mean time can you

create

org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl

instead?

Regards

Simon

You may very well be right. Time to push some new snapshots out! Let me find
out how to do that.

Simon

Yes I think that new published snapshots will resolve that issue.

In addition, how about adding the Tuscany/Geronimo integration modules
to our build? This will help us check that we're not breaking them when
we make changes in the rest of the Tuscany code. It will also make it
easier for people to try out the integration from their Tuscany
workspace / development environment.

The simplest is probably to point to these modules in the Geronimo
sandbox SVN from our java/sca/modules directory using an SVN externals
property...

Thoughts?

--
Jean-Sebastien

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

Re: Javadoc in sca/itest

2007-08-16 Thread venu reddy

Hi Brian,
That will be a boon to developers who want's to get started with integration
tests. In addition  we can also have brief documentation about itests itself
or FAQ about itest.  Few things those can be included are What are itests?,
How to create configure a new itest module? so that surefire plugin can
execute the tests successfully.
Thanks,
Venu.



On 8/16/07, Brian Murray [EMAIL PROTECTED] wrote:

 I'd like to take a crack at expanding the Javadoc in the sca itests, and
 I'd like some feedback on the benefit and conventions of doing so.

 I've noticed that the Javadoc in the sca/itests could be enhanced (or in
 many cases is absent altogether). Javadoc seems to me a great way to
 document the intent of the test cases.  Including the package.html and
 overview.html files will allow a single source of documentation.  This
 will
 allow us to more easily assess test coverage of concepts (rather than
 merely
 API's).

 As for javadoc conventions:

 I'd like to add javadoc to the src/test subdirectories.  This is where we
 would document the scenario being tested.  (e.g. Attempt to locate a
 service
 with an invalid name.)

 I'd like to add javadoc to the src/main subdirectories to describe the
 requirements on the services (e.g.  This must be a composite within a
 composite) for the test case scenario to be achieved.

 Please let me know if you'd like me to add or subtract from the above.




-- 
-
A 'wish' changes nothing. A 'decision' changes everything!  Anon
Even if you're on the right track, you'll get run over if you just sit
there. Will Rogers

build failure in java2wsdl

2007-08-16 Thread Simon Laws

Just doing a clean build so that I can publish module snapshots and I get
the following. Anyone any ideas?

Simon

java2wsdl\target\classes
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package
com.
sun.org.apache.xml.internal.serialize does not exist

C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package
com.
sun.org.apache.xml.internal.serialize does not exist

C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot
find
symbol
symbol  : class OutputFormat
location: class
org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
pl

C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot
find
 symbol
symbol  : class OutputFormat
location: class
org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
pl

C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot
find
symbol
symbol  : class XMLSerializer
location: class
org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
pl

C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot
find
 symbol
symbol  : class XMLSerializer
location: class
org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
pl

Re: build failure in java2wsdl

2007-08-16 Thread Luciano Resende

Are you using IBM JDK ? Looks like my latest changes have some issues
with that JDK.

On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote:
 Just doing a clean build so that I can publish module snapshots and I get
 the following. Anyone any ideas?

 Simon

 java2wsdl\target\classes
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure

 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49] package
 com.
 sun.org.apache.xml.internal.serialize does not exist

 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49] package
 com.
 sun.org.apache.xml.internal.serialize does not exist

 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8] cannot
 find
 symbol
 symbol  : class OutputFormat
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl

 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34] cannot
 find
  symbol
 symbol  : class OutputFormat
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl

 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8] cannot
 find
 symbol
 symbol  : class XMLSerializer
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl

 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39] cannot
 find
  symbol
 symbol  : class XMLSerializer
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl



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

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

Re: build failure in java2wsdl

2007-08-16 Thread Simon Laws

On 8/16/07, Luciano Resende [EMAIL PROTECTED] wrote:

 Are you using IBM JDK ? Looks like my latest changes have some issues
 with that JDK.

 On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote:
  Just doing a clean build so that I can publish module snapshots and I
 get
  the following. Anyone any ideas?
 
  Simon
 
  java2wsdl\target\classes
  [INFO]
  
  [ERROR] BUILD FAILURE
  [INFO]
  
  [INFO] Compilation failure
 
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
  uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49]
 package
  com.
  sun.org.apache.xml.internal.serialize does not exist
 
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
  uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49]
 package
  com.
  sun.org.apache.xml.internal.serialize does not exist
 
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
  uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8]
 cannot
  find
  symbol
  symbol  : class OutputFormat
  location: class
  org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
  pl
 
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
  uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34]
 cannot
  find
   symbol
  symbol  : class OutputFormat
  location: class
  org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
  pl
 
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
  uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8]
 cannot
  find
  symbol
  symbol  : class XMLSerializer
  location: class
  org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
  pl
 
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
  uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39]
 cannot
  find
   symbol
  symbol  : class XMLSerializer
  location: class
  org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
  pl
 


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

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

 Yep - I'm on the IBM JDK. I guess I can  get away without the wsdl
generation pieces for now unless you know a quick fix?

Simon

Re: Javadoc in sca/itest

2007-08-16 Thread haleh mahbod

Hi,
Javadoc for iTests will help clearify what is there or missing and help the
reader to better understand the tests. I went through itests once to try to
figure out what is missing and how I can potentially contribute. I did not
get too far.

Venu, your idea of 'how to create configure a new itest module or what are
itests' are things that can be covered in the development guide. There is
already a 'test' section in this guide that seems to be a bit out dated. [1]

http://incubator.apache.org/tuscany/sca-java-development-guide.html#SCAJavaDevelopmentGuide-Testing

Just a suggestion..

Haleh

On 8/16/07, venu reddy [EMAIL PROTECTED] wrote:

Hi Brian,
That will be a boon to developers who want's to get started with
integration
tests. In addition we can also have brief documentation about itests
itself
or FAQ about itest. Few things those can be included are What are
itests?,
How to create configure a new itest module? so that surefire plugin can
execute the tests successfully.
Thanks,
Venu.

On 8/16/07, Brian Murray [EMAIL PROTECTED] wrote:

I'd like to take a crack at expanding the Javadoc in the sca itests, and
I'd like some feedback on the benefit and conventions of doing so.

I've noticed that the Javadoc in the sca/itests could be enhanced (or in
many cases is absent altogether). Javadoc seems to me a great way to
document the intent of the test cases. Including the package.html and
overview.html files will allow a single source of documentation. This
will
allow us to more easily assess test coverage of concepts (rather than
merely
API's).

As for javadoc conventions:

I'd like to add javadoc to the src/test subdirectories. This is where
we
would document the scenario being tested. (e.g. Attempt to locate a
service
with an invalid name.)

I'd like to add javadoc to the src/main subdirectories to describe the
requirements on the services (e.g. This must be a composite within a
composite) for the test case scenario to be achieved.

Please let me know if you'd like me to add or subtract from the above.

-
A 'wish' changes nothing. A 'decision' changes everything! Anon
Even if you're on the right track, you'll get run over if you just sit
there. Will Rogers

Distributed Runtime and Distributed Calculator

2007-08-16 Thread Giorgio Zoppi

Hi,
i'm highly interested in contributing to the distributed runtime.
Actually I'm trying to understand if this component model could be the
building block for creating autonomic components. An autonomic
component can consist of one or more managed components coupled with a
single manager that controls them. To pursue its goal, the manager may
trigger an adaptation of the managed components to react to a run-time
change (i.e. fault, load balancing, etc).
Some questions..i've updated the svn and it builds but not the
distributed-calculator.
Why? (It could be for me a starting point).
Cheers,
Jo.

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

Re: build failure in java2wsdl

2007-08-16 Thread Raymond Feng


Hi,

I fixed it under r566814.

Thanks,
Raymond

- Original Message - 
From: Simon Laws [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Thursday, August 16, 2007 12:24 PM
Subject: Re: build failure in java2wsdl



On 8/16/07, Luciano Resende [EMAIL PROTECTED] wrote:


Are you using IBM JDK ? Looks like my latest changes have some issues
with that JDK.

On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote:
 Just doing a clean build so that I can publish module snapshots and I
get
 the following. Anyone any ideas?

 Simon

 java2wsdl\target\classes
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure


C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49]
package
 com.
 sun.org.apache.xml.internal.serialize does not exist


C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49]
package
 com.
 sun.org.apache.xml.internal.serialize does not exist


C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8]
cannot
 find
 symbol
 symbol  : class OutputFormat
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl


C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34]
cannot
 find
  symbol
 symbol  : class OutputFormat
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl


C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8]
cannot
 find
 symbol
 symbol  : class XMLSerializer
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl


C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
 uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39]
cannot
 find
  symbol
 symbol  : class XMLSerializer
 location: class
 org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
 pl



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

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

Yep - I'm on the IBM JDK. I guess I can  get away without the wsdl

generation pieces for now unless you know a quick fix?

Simon




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

Re: Distributed Runtime and Distributed Calculator

2007-08-16 Thread Simon Laws

On 8/16/07, Giorgio Zoppi [EMAIL PROTECTED] wrote:

 Hi,
 i'm highly interested in contributing to the distributed runtime.
 Actually I'm trying to understand if this component model could be the
 building block for creating autonomic components. An autonomic
 component can consist of one or more managed components coupled with a
 single manager that controls them. To pursue its goal, the manager may
 trigger an adaptation of the managed components to react to a run-time
 change (i.e. fault, load balancing, etc).
 Some questions..i've updated the svn and it builds but not the
 distributed-calculator.
 Why? (It could be for me a starting point).
 Cheers,
 Jo.

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


Hi Jo and welcome to Tuscany

I'm just making some changes to the calculator sample to fix it up so it
will work again. What we have is a a simple scenario where you start 3 nodes
that run SCA components for different parts of the calculator  application
and the nodes talk to a registry to find out what components are on which
node. Very simple at the moment but the framework is in place to add all
sorts of interesting component management options. Sounds like you have some
good ideas. Let me get the sample fixed up and I'll post back here. You can
then look at something that runs.

Regards

Simon

Re: build failure in java2wsdl

2007-08-16 Thread Simon Laws

On 8/16/07, Raymond Feng [EMAIL PROTECTED] wrote:

 Hi,

 I fixed it under r566814.

 Thanks,
 Raymond

 - Original Message -
 From: Simon Laws [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Thursday, August 16, 2007 12:24 PM
 Subject: Re: build failure in java2wsdl


  On 8/16/07, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Are you using IBM JDK ? Looks like my latest changes have some issues
  with that JDK.
 
  On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote:
   Just doing a clean build so that I can publish module snapshots and I
  get
   the following. Anyone any ideas?
  
   Simon
  
   java2wsdl\target\classes
   [INFO]
  
 
   [ERROR] BUILD FAILURE
   [INFO]
  
 
   [INFO] Compilation failure
  
  
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
   uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[36,49]
  package
   com.
   sun.org.apache.xml.internal.serialize does not exist
  
  
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
   uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[37,49]
  package
   com.
   sun.org.apache.xml.internal.serialize does not exist
  
  
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
   uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,8]
  cannot
   find
   symbol
   symbol  : class OutputFormat
   location: class
   org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
   pl
  
  
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
   uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[131,34]
  cannot
   find
symbol
   symbol  : class OutputFormat
   location: class
   org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
   pl
  
  
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
   uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,8]
  cannot
   find
   symbol
   symbol  : class XMLSerializer
   location: class
   org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
   pl
  
  
 
 C:\simon\tuscany\java-head-test\sca\modules\java2wsdl\src\main\java\org\apache\t
   uscany\tools\java2wsdl\generate\Java2WSDLGeneratorImpl.java:[135,39]
  cannot
   find
symbol
   symbol  : class XMLSerializer
   location: class
   org.apache.tuscany.tools.java2wsdl.generate.Java2WSDLGeneratorIm
   pl
  
 
 
  --
  Luciano Resende
  Apache Tuscany Committer
  http://people.apache.org/~lresende
  http://lresende.blogspot.com/
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
  Yep - I'm on the IBM JDK. I guess I can  get away without the wsdl
  generation pieces for now unless you know a quick fix?
 
  Simon
 


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


Thanks guys

Simon

[jira] Commented: (TUSCANY-1480) Calling EmbeddedSCADomain.activateDomain() after adding a contribution renders services from previous contribution unusable

2007-08-16 Thread Vamsavardhana Reddy (JIRA)


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

Vamsavardhana Reddy commented on TUSCANY-1480:
--

The following may be used to create a testcase for this JIRA:

1.scaDomain = new EmbeddedSCADomain(...);
scaDomain.start();

2.   // Add contribution from calculator sample

3.   scaDomain.getDomainCompositeHelper().activateDomain()

4.   // Call scaDomain.getDomainCompositeHelper().startComponent() on each of 
the components from calculator sample

5.  //At this step access the service provided by calculator sample.

6.  // Add contribution from helloworld sample

7.   scaDomain.getDomainCompositeHelper().activateDomain()

8.   // Call scaDomain.getDomainCompositeHelper().startComponent() on each of 
the components from helloworld sample

9.  // At this step access service provided by calculator sample.  calculator 
service should be accessible.  Note:This is failing currenly
 //  Access service provided by helloworld sample.  helloworld service 
should be accessible.



 Calling EmbeddedSCADomain.activateDomain()  after adding a contribution 
 renders services from previous contribution unusable
 

 Key: TUSCANY-1480
 URL: https://issues.apache.org/jira/browse/TUSCANY-1480
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.91
Reporter: Vamsavardhana Reddy
Assignee: Jean-Sebastien Delfino
 Fix For: Java-SCA-Next


 Here is a situation I am running into.
 Step 0: Create an EmbeddedSCADomain.
 Step 1: Add contribution from contribution1.jar (which provides say
 Service1) to EmbeddedSCADomain from Step 0.
 Step 2: Call EmbeddedSCADomain.DomainCompositeHelper.activateDomain()
 Step 3: Call EmbeddedSCADomain.DomainCompositeHelper.startComponent() on all
 componets from contribution1.jar.
 Step 4: Add contribution from contribution2.jar (which provides say
 Service2) to EmbeddedSCADomain from Step 0.
 Step 5: Call EmbeddedSCADomain.DomainCompositeHelper.activateDomain()
 Step 6: Call EmbeddedSCADomain.DomainCompositeHelper.startComponent() on all
 componets from contribution2.jar.
 After Step 3, I am able to run Service1 successfully.  At Step 5, I get a
 message like the following:
 Composite assembly problem: Service not found for component service:
 CalculatorServiceComponent/$promoted$.CalculatorService
 After Step 6, Service1 no longer runs, where as Service2 runs successfully.
 If I call DomainCompositeHelper.startComponent() on each of the components
 from the first contribution after deploying the second, (that is after Step
 6 from), it results in an Exception which I ignore and continue.  But
 towards the end I have services from both contributions running
 successfully.

-- 
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]

[DAS Native] ant build

2007-08-16 Thread Brady Johnson


Adriano,

You might have seen that both SCA and SDO native now have an ant build
infrastructure. I briefly looked at doing the same for DAS, but couldn't
get it to compile with configure, make, make install at the time, and
never got a chance to come back to it.

I think it should be very easy to copy the SDO ant stuff over to DAS,
what do you think?


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

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Adriano Crestani
Sent: Monday, July 23, 2007 11:21 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

Great idea, soon I will try to apply this idea to Native DAS and see how
it works. I think the idea could also be easily applied to Native SDO,
as it does not have too much dependencies and code generation as Native
SCA does.

A folder ant-core could be created under tuscany/cpp/ folder to place
the ant scripts shared by the projects.

Also, we could add a build.xml under tuscany/ccp/ that builds all 3
subprojects at once, if the 3 to implement this ant build process. What
do you think?

Regards,
Adriano Crestani

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


 Correction, it should be like this:

   target name=compile.core
 cpp-compile
 srcdir=${core.abs.dir}
 objdir=${lib.dir}
 infiles=${core.cpp.files}
   custom-cc-elements
 defineset if=windows define=SCA_EXPORTS/
   /custom-cc-elements
 /cpp-compile
   /target

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


 -Original Message-
 From: Brady Johnson [mailto:[EMAIL PROTECTED]
 Sent: Monday, July 23, 2007 5:05 PM
 To: tuscany-dev@ws.apache.org
 Subject: RE: [SCA Native] preliminary ant build


 Pete,

 Good catch. That's an easy fix. I'll submit it with the next patch 
 tomorrow. Basically it involves removing SCA_EXPORTS from the 
 Tuscany-BaseCompiler and adding it to the runtime/core/src targets:
 compile.core
 compile.extension
 compile.model
 compile.util

 Like this:
   target name=compile.core
 cpp-compile
 srcdir=${core.abs.dir}
 objdir=${lib.dir}
 infiles=${core.cpp.files}/
   custom-cc-element
 defineset if=windows define=SCA_EXPORTS/
   /custom-cc-element
   /target

 Tomorrow I'll have the python, ruby, rest, and maybe php extensions 
 complete.


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


 -Original Message-
 From: Pete Robbins [mailto:[EMAIL PROTECTED]
 Sent: Monday, July 23, 2007 2:41 PM
 To: tuscany-dev@ws.apache.org
 Subject: Re: [SCA Native] preliminary ant build

 I think there is a problem in the extension compilations. The 
 SCA_EXPORTS directive should only be set when compiling the 
 runtime/core. When compiling for dlls on windows which use the core 
 dll SCA_EXPORTS must not be set. I guess this means we have to move 
 the setting of this directive from the definition of the 
 Tuscany-BaseCompiler

 Cheers,

 On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote:
  I've applied the patch. How are you creating the patches? I had 
  trouble applying it on Windows using ToirtoiseSVN.
 
  I've included the changes in the patch to the tools/TuscanyDriver 
  build. I haven't tested this and I'm not sure if it works with the 
  system.xml etc.
 
  Can you do a clean extract as a base for future patches?
 
  Cheers,
 
  On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote:
   I'll give this a go. I should be able to run it on Mac as well.
  
   Cheers,
  
   On 23/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
   
I updated the jira1438 with update 3, which includes the
 following:
   https://issues.apache.org/jira/browse/TUSCANY-1438
   
   
- added build.xml for the following dirs:
   runtime/extensions/build.xml
   runtime/extensions/cpp/build.xml
   runtime/extensions/sca/build.xml
   runtime/extensions/ws/build.xml
   
- changed system.xml to check for necessary axis, php, python, 
rest, and ruby env vars. If they're not  set in the env, look 
for them in platform.properties
   
- changed compile-targets.xml targets
   cpp-install-headers/ to cpp-install-files/
   cpp-install-lib/ to cpp-install-file/
   
- added compile-targets.xml target: cpp-symlink/
   
- added library versioning and the 
platform.tuscanySCA.library.version
platform.properties property
   
Can someone submit this for me.
   
The only thing left now is the build.xml for these extensions:
php, python, rest, ruby
   
WRT testing on macs, I wont have a mac available until next
week.
   
Thanks
   

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

[jira] Resolved: (TUSCANY-1540) Abstract Static Base Types mixed with Dynamic Extended Types

2007-08-16 Thread Frank Budinsky (JIRA)


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

Frank Budinsky resolved TUSCANY-1540.
-

Resolution: Fixed

Fixed in revision 566876.

I changed the generator to generate a concrete inner subclass for abstract Impl 
classes:

public abstract class AbstractTestImpl extends DataObjectBase implements 
AbstractTest
{
  public static class ConcreteBase extends AbstractTestImpl
  {
public ConcreteBase()
{
  super();
}
  }
  ...
}

and  then added code in FactoryBase$SDOEFactoryImpl.create() to use it if the 
type is abstract.

I've tested it with the following simple program:

  public static void main(String[] args) throws IOException
  {
HelperContext context = SDOUtil.createHelperContext();
Junk3Factory.INSTANCE.register(context);

TypeHelper typeHelper = context.getTypeHelper();
DataFactory factory = context.getDataFactory();
Type abstractType = typeHelper.getType(http://www.example.org/junk/;, 
AbstractTest);

//DataObject testObject = factory.create(abstractType); // should fail

// Create an subtype
DataObject exampleType = DataFactory.INSTANCE.create(commonj.sdo, Type);
exampleType.set(uri, NSURI);
exampleType.set(name, Example);
exampleType.getList(baseType).add(abstractType);
Type type = TypeHelper.INSTANCE.define(exampleType);

DataObject testObject2 = factory.create(type);

if (testObject2.getClass() == AbstractTestImpl.ConcreteBase.class)
  System.out.println(SUCCESS);
else
  System.out.println(FAIL);
  }

It would be good to get a proper JUnit for it. Any volunteers?


 Abstract Static Base Types mixed with Dynamic Extended Types
 

 Key: TUSCANY-1540
 URL: https://issues.apache.org/jira/browse/TUSCANY-1540
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Murtaza Goga
 Fix For: Java-SDO-Next


 Setting a property on a static data object with an object of a type extended 
 in a dynamic model results in a ClassCastException.
 Scenario:
 Static schema-
   xsd:complexType name=CustomerType
 xsd:all
   xsd:element name=number type=xsd:integer /
   xsd:element form=unqualified name=info type=InfoType /
 /xsd:all
   /xsd:complexType
   
   xsd:complexType name=InfoType abstract=true/
 Dynamic Schema
 xsd:complexType name=InfoType
   xsd:complexContent
 xsd:extension base=staticNS:InfoType
   xsd:sequence
 xsd:element name=zipcode type=xsd:string /
   /xsd:sequence
 /xsd:extension
   /xsd:complexContent
 /xsd:complexType
 The following will fail:
 DataFactory factory = scope.getDataFactory();
 factory.create(CustomerType.class).setDataObject(info, 
 factory.create(dynamicNS, InfoType));
 It should be legal to assign a property to an object if they are in the same 
 hierachy.
 Steps to reproduce within Tuscany:
 Testcase org.apache.tuscany.sdo.test.ExtensibleTestCase will break if 
 'InfoType' defined in extensible/customer.xsd  is marked as abstract.

-- 
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] Commented: (TUSCANY-1541) XMLStreamException in when calling XMLHelper.load() with a large XML

2007-08-16 Thread Sunny Ip (JIRA)


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

Sunny Ip commented on TUSCANY-1541:
---

I wasn't sure what the best way of getting all the various classes initialized 
outside of the SCA environment was, so this is what I did to try to simulate 
the serialize/deserialize process:

  /* populate response */
  
  String responseStr = 
XMLHelper.INSTANCE.save((DataObject)response,http://namespace,ResponseType;);
  
  XMLStreamHelperImpl strHelper = new 
XMLStreamHelperImpl(HelperProvider.getDefaultContext());
  XMLDocument doc = XMLHelper.INSTANCE.load(responseStr);
  XMLStreamReader reader = strHelper.createXMLStreamReader(doc);
  reader.next();
  DataObject obj = strHelper.loadObject(reader);
  
  return response;

after populating response (which is an SDO generated object) with a collection 
of child SDO objects in my service impl, which is a component in the SCADomain. 
This succeeded without any problems, and the resulting DataObject looked fine. 
However, I return the original response back to the invoking client (through a 
web service binding) and get the XMLStreamException. If the collection in my 
response contains less objects, then everything works fine. When I have more 
than 30 (in this case) objects in the collection, manually calling 
XMLStreamHelper works but the invoking client fails. 

 XMLStreamException in when calling XMLHelper.load() with a large XML
 

 Key: TUSCANY-1541
 URL: https://issues.apache.org/jira/browse/TUSCANY-1541
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
 Environment: Tomcat
Reporter: Sunny Ip
Priority: Critical
 Fix For: Java-SDO-Next


 When XMLHelper.load() is called with a very long XML string, OMStAXWrapper 
 throws an XMLStreamException. I get this problem when I'm receiving a WS 
 response with an SDO object containing a collection of records, leading to a 
 TransformationException when databinding. 

-- 
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: Tuscany/Geronimo Integration Demo

2007-08-16 Thread Simon Laws

On 8/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

Simon Laws wrote:
On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

I am not referencing this class directly in my code. Can it be that
the
published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc or
not
the latest?? I can not think of other possibilities.

Vamsi

On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote:

On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

We put together a demo [1] on Tuscany/Geronimo integration for the
LinuxWorld 2007. You are welcome to play with it and give us

feedback.

Please follow the instructions at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT

.
The demo scenario is captured at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png

The demo is built on top of the sandbox code in Geronimo [2] which

discussed on [3].

Please note this is just the starting of effort and there are still

quite

a
lot to do. Please join us on this effort.

In the near term, I believe that we need to do the following:

1) Move the code out of sandbox and have them in the build with test
cases.
2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java

SCA

0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to
1.0-incubating-SNAPSHOT so that we have consistent modules.

After switching to 1.0-incubating-SNAPSHOT, I have run into a
NoClassDefFoundError:
org/apache/tuscany/sca/assembly/DefaultSCABindingFactory.

3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared

move

this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in

the

RC1?

not

present in the maven repo URL. This has been fixed in branches\2.0

and

trunk (not in 2.0 release though) and the work around for this is to

put

that trailing / in the maven repo URLs in geronimo-plugin.xml

. These

two
fixes will (most likely, but not guaranteed) go into 2.0.1 due to be
released soon (probably this week).

[1]

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/

[2]

http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/

[3]

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration

[4] https://issues.apache.org/jira/browse/GERONIMO-3351

Thanks,
Raymond

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

org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken
out

week or so ago when I moved the majority of sca binding into the
binding-sca
module. I'm thinking that I was a little overzealous when I took this

out

and that it probably needs to go back in. In the mean time can you

create

org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl

instead?

Regards

Simon

You may very well be right. Time to push some new snapshots out! Let me
find
out how to do that.

Simon

Yes I think that new published snapshots will resolve that issue.

The simplest is probably to point to these modules in the Geronimo
sandbox SVN from our java/sca/modules directory using an SVN externals
property...

Thoughts?

--
Jean-Sebastien

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

Ok, I've published a new set of snapshots for the SCA modules (I haven't
done samples or itests). I tested against the current SDO snapshots. Let us
know if this gets you any further forward.

Regards

Simon

Re: [DAS Native] ant build

2007-08-16 Thread Adriano Crestani

Hi Brady,

Yes, I was plaining to do that after this weekend. I had no chance to do
that so far, cause I was really busy with college's stuffs :(

Regards,
Adriano Crestani

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


 Adriano,

 You might have seen that both SCA and SDO native now have an ant build
 infrastructure. I briefly looked at doing the same for DAS, but couldn't
 get it to compile with configure, make, make install at the time, and
 never got a chance to come back to it.

 I think it should be very easy to copy the SDO ant stuff over to DAS,
 what do you think?

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


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Adriano Crestani
 Sent: Monday, July 23, 2007 11:21 PM
 To: tuscany-dev@ws.apache.org
 Subject: Re: [SCA Native] preliminary ant build

 Great idea, soon I will try to apply this idea to Native DAS and see how
 it works. I think the idea could also be easily applied to Native SDO,
 as it does not have too much dependencies and code generation as Native
 SCA does.

 A folder ant-core could be created under tuscany/cpp/ folder to place
 the ant scripts shared by the projects.

 Also, we could add a build.xml under tuscany/ccp/ that builds all 3
 subprojects at once, if the 3 to implement this ant build process. What
 do you think?

 Regards,
 Adriano Crestani

 On 7/23/07, Brady Johnson [EMAIL PROTECTED] wrote:
 
 
  Correction, it should be like this:
 
target name=compile.core
  cpp-compile
  srcdir=${core.abs.dir}
  objdir=${lib.dir}
  infiles=${core.cpp.files}
custom-cc-elements
  defineset if=windows define=SCA_EXPORTS/
/custom-cc-elements
  /cpp-compile
/target
 
  
  Brady Johnson
  Lead Software Developer - HydraSCA
  Rogue Wave Software - [EMAIL PROTECTED]
 
 
  -Original Message-
  From: Brady Johnson [mailto:[EMAIL PROTECTED]
  Sent: Monday, July 23, 2007 5:05 PM
  To: tuscany-dev@ws.apache.org
  Subject: RE: [SCA Native] preliminary ant build
 
 
  Pete,
 
  Good catch. That's an easy fix. I'll submit it with the next patch
  tomorrow. Basically it involves removing SCA_EXPORTS from the
  Tuscany-BaseCompiler and adding it to the runtime/core/src targets:
  compile.core
  compile.extension
  compile.model
  compile.util
 
  Like this:
target name=compile.core
  cpp-compile
  srcdir=${core.abs.dir}
  objdir=${lib.dir}
  infiles=${core.cpp.files}/
custom-cc-element
  defineset if=windows define=SCA_EXPORTS/
/custom-cc-element
/target
 
  Tomorrow I'll have the python, ruby, rest, and maybe php extensions
  complete.
 
 
  
  Brady Johnson
  Lead Software Developer - HydraSCA
  Rogue Wave Software - [EMAIL PROTECTED]
 
 
  -Original Message-
  From: Pete Robbins [mailto:[EMAIL PROTECTED]
  Sent: Monday, July 23, 2007 2:41 PM
  To: tuscany-dev@ws.apache.org
  Subject: Re: [SCA Native] preliminary ant build
 
  I think there is a problem in the extension compilations. The
  SCA_EXPORTS directive should only be set when compiling the
  runtime/core. When compiling for dlls on windows which use the core
  dll SCA_EXPORTS must not be set. I guess this means we have to move
  the setting of this directive from the definition of the
  Tuscany-BaseCompiler
 
  Cheers,
 
  On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote:
   I've applied the patch. How are you creating the patches? I had
   trouble applying it on Windows using ToirtoiseSVN.
  
   I've included the changes in the patch to the tools/TuscanyDriver
   build. I haven't tested this and I'm not sure if it works with the
   system.xml etc.
  
   Can you do a clean extract as a base for future patches?
  
   Cheers,
  
   On 23/07/07, Pete Robbins [EMAIL PROTECTED] wrote:
I'll give this a go. I should be able to run it on Mac as well.
   
Cheers,
   
On 23/07/07, Brady Johnson [EMAIL PROTECTED] wrote:

 I updated the jira1438 with update 3, which includes the
  following:
https://issues.apache.org/jira/browse/TUSCANY-1438


 - added build.xml for the following dirs:
runtime/extensions/build.xml
runtime/extensions/cpp/build.xml
runtime/extensions/sca/build.xml
runtime/extensions/ws/build.xml

 - changed system.xml to check for necessary axis, php, python,
 rest, and ruby env vars. If they're not  set in the env, look
 for them in platform.properties

 - changed compile-targets.xml targets
cpp-install-headers/ to cpp-install-files/
cpp-install-lib/ to cpp-install-file/

 - added compile-targets.xml target: cpp-symlink/

 - added library versioning and the
 platform.tuscanySCA.library.version
 platform.properties property

[jira] Updated: (TUSCANY-1542) BPEL extension to link sca component into a business process

2007-08-16 Thread Jean-Sebastien Delfino (JIRA)


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

Jean-Sebastien Delfino updated TUSCANY-1542:


Component/s: Java SCA BPEL Implementation Extension

 BPEL extension to link sca component into a business process
 

 Key: TUSCANY-1542
 URL: https://issues.apache.org/jira/browse/TUSCANY-1542
 Project: Tuscany
  Issue Type: Wish
  Components: Java SCA BPEL Implementation Extension
Affects Versions: Java-SCA-Next
Reporter: gengshaoguang
 Fix For: Java-SCA-Next


 What I expect next is: extend a bpel engine, make it interact with Tuscany's 
 sca binding. Of course any bpel engine might link wsdl naturaly. But in the 
 latter case, we make no improvement to SOA tech. BPEL-SCA should work in a 
 more direct way and more effect way. I think 
 SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at 
 section 1.4 .
 I open this issue to arouse collaboration from all of you.
 Thanks.

-- 
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] Commented: (TUSCANY-1542) BPEL extension to link sca component into a business process

2007-08-16 Thread Jean-Sebastien Delfino (JIRA)

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

Jean-Sebastien Delfino commented on TUSCANY-1542:
-

The work started under java/sca/modules/implementation-bpel is about
implementing what's described in the SCA Client and Implementation Model Spec
for WS-BPEL [1].

Could you please explain why you think this work is different from what's
described in the spec or not covering what you're looking for?

Thanks.

[1]
http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1

BPEL extension to link sca component into a business process

Key: TUSCANY-1542
URL: https://issues.apache.org/jira/browse/TUSCANY-1542
Project: Tuscany
Issue Type: Wish
Components: Java SCA BPEL Implementation Extension
Affects Versions: Java-SCA-Next
Reporter: gengshaoguang
Fix For: Java-SCA-Next

What I expect next is: extend a bpel engine, make it interact with Tuscany's
sca binding. Of course any bpel engine might link wsdl naturaly. But in the
latter case, we make no improvement to SOA tech. BPEL-SCA should work in a
more direct way and more effect way. I think
SCA_ClinetAndImplementationModelforBPEL_V100 has specified relevants at
section 1.4 .
I open this issue to arouse collaboration from all of you.
Thanks.

--
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: Tuscany/Geronimo Integration Demo

2007-08-16 Thread Vamsavardhana Reddy

Hit a new error. Stack trace given below:

java.lang.NoClassDefFoundError:
org/apache/tuscany/sca/interfacedef/java/introspect/JavaInterfaceIntrospectorExtensionPoint
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.loadModules(
ReallySmallRuntime.java:181)
at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(
ReallySmallRuntime.java:133)
at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(
EmbeddedSCADomain.java:74)

Vamsi

On 8/17/07, Simon Laws [EMAIL PROTECTED] wrote:

On 8/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

Simon Laws wrote:
On 8/16/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

I am not referencing this class directly in my code. Can it be that
the
published 1.0-incubating-SNAPSHOT jars in maven repos are not in syc
or
not
the latest?? I can not think of other possibilities.

Vamsi

On 8/14/07, Simon Laws [EMAIL PROTECTED] wrote:

On 8/14/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote:

On 8/11/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

We put together a demo [1] on Tuscany/Geronimo integration for the
LinuxWorld 2007. You are welcome to play with it and give us

feedback.

Please follow the instructions at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT

.
The demo scenario is captured at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png

The demo is built on top of the sandbox code in Geronimo [2] which

discussed on [3].

Please note this is just the starting of effort and there are
still

quite

a
lot to do. Please join us on this effort.

In the near term, I believe that we need to do the following:

1) Move the code out of sandbox and have them in the build with
test
cases.
2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java

SCA

0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch
to
1.0-incubating-SNAPSHOT so that we have consistent modules.

After switching to 1.0-incubating-SNAPSHOT, I have run into a
NoClassDefFoundError:
org/apache/tuscany/sca/assembly/DefaultSCABindingFactory.

3) The Geronimo 2.0 RC1 is not being voted on. We should be
prepared

move

this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in

the

RC1?

not

present in the maven repo URL. This has been fixed in branches\2.0

and

trunk (not in 2.0 release though) and the work around for this is
to

put

that trailing / in the maven repo URLs in geronimo-plugin.xml

. These

two
fixes will (most likely, but not guaranteed) go into 2.0.1 due to
be
released soon (probably this week).

[1]

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/

[2]

http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/

[3]

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration

[4] https://issues.apache.org/jira/browse/GERONIMO-3351

Thanks,
Raymond

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

org/apache/tuscany/sca/assembly/DefaultSCABindingFactory. was taken
out

week or so ago when I moved the majority of sca binding into the
binding-sca
module. I'm thinking that I was a little overzealous when I took
this

out

and that it probably needs to go back in. In the mean time can you

create

org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl

instead?

Regards

Simon

You may very well be right. Time to push some new snapshots out! Let
me
find
out how to do that.

Simon

Yes I think that new published snapshots will resolve that issue.

41 matches

Mail list logo