date:20070424


Following on from the release content thread [1] I'd like to kick off a
discussion on how we resurrect support for a distributed runtime. We had
this feature before the core modularization and I think it would be good to
bring it back again. For me this is about working out how the tuscany
runtime  can  be successfully hosted in a distributed environment without
having to recreate what is done very well by existing distributed computing
technologies.

The assembly model specification [3] deals briefly with this in its
discussion of SCA Domains

An SCA Domain represents a complete runtime configuration, potentially
distributed over a series of interconnected runtime nodes.

Here is my quick sketch of the main structures described by the SCA Domain
section of the assembly spec.

SCA Domain
   Logical Services - service to control the domain
   InstalledContribution (1 or more)
   Base URI
   Installed artifact URIs
   Contribution - SCA and non-SCA artefacts contributed to the runtime
   /META_INF/sca-contribution.xml
deployable (composites)
import
export
   Dependent Contributions - references to installed contributions on
which this one depends
   Deployment Time Composites - composites added into an installed
contribution
   Virtual Domain Level Composite - the running set of SCA artefacts. Top
level services are visible outside domain
   Component, Service, Reference
   Derived from notionally included installed composites

The assembly spec says that A goal of SCA's approach to deployment is that
the contents of a contribution should not need to be modified in order to
install and use the contents of the contribution in a domain.. This seems
sensible in that we don't want to have to rewrite composite files every time
we alter the physical set of nodes on which they are to run. Typically in a
distributed environment there is some automation of the assignment of
applications to nodes to cater for resilience, load balancing, throughput
etc.

The assembly spec is not prescriptive about how an SCA Domain should be
mapped and supported across multiple runtime nodes but I guess the starting
point is to consider the set of components a system has, i.e. the set of
(top level?) components that populate the Virtual Domain Composite and
consider them as likely candidates for distributing across runtimes.

So I would expect a manager of a distributed SCA runtime to go through a
number of stages in getting the system up and running.

Define an SCA Domain (Looking at the mailing list Luciano is think these
thoughts also)
 - domain definition
  - as simple as a file structure (based on hierarchy from assembly
spec) in a shared file system.
  - could implement more complex registry based system
 - allocate nodes to the domain
  - As simple as running up SCA runtime on each node in the domain.
  - For more complex scenarios might want to use a
scheduling/management system

Add contributions to the domain
 - Identify contributions required to form running service network
(developers will build/define contributions)
 - Contribution these contributions to the domain
  - in the simple shared file system scenario I would image they just
end up in on this file system available to all nodes in
the domain.

Add contributions to the Virtual Domain Level Composite
 - At this point it think we have to know where artifacts are physically
going to run
 - It could be that all runtimes load all contributions and only expose
those destined for them or, I.e. each node has the full model loaded but
knows which bits it's running.
 - Alternatively we could target each node specifically and ask it to load
a particular installed contribution and define
   a distributed model.

Manage the Domain
 - Need to be able to target the logical service provided by the domain at
the appropriate runtime node

In order to make this work the sca default binding has to be able to work
remotely across distributed runtimes so we need to select an existing
binding, or create a new one, to do this.

I think in the first instance we should set the bar fairly low. I.e have the
target be running a sample application across two SCA runtimes supporting
java component implementations. This pretty much picks up where we were with
the distribution support before the core modularization effort.

I'm not sure what the target scenario should be but we could take one of the
samples we already have, e.g. SimpleBigBank which happens to have two simple
java components in its implementations, but we could go with any of them.

Thoughts

Simon


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16898.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16831.html
[3]
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

Re: Making clear that modules under contrib do not build


On 4/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


I think that the java/sca/contrib directory has potential to confuse
people, as many modules under contrib have obsolete pom.xml files, are
not actively maintained and are not building.

I was thinking about renaming the pom.xml files under contrib to
pom.xml.off for example and adding a README to this directory indicating
the status of these modules, to make this clear and avoid that people
waste time trying to build and use these old modules, like our old
Tuscany WAR plugin under contrib for example.

What do people think?

--
Jean-Sebastien


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

I just yesterday had a conversation with someone saying that one of the

contributed bindings was broken so I think this is  good idea.

Thanks

Simon

[jira] Created: (TUSCANY-1225) Access violation in CopyHelper

Access violation in CopyHelper
--

 Key: TUSCANY-1225
 URL: https://issues.apache.org/jira/browse/TUSCANY-1225
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
 Environment: Win32, PHP
Reporter: Caroline Maynard


Cloning a DataObject withe a property that has been explicitly set to null 
results in an AccessViolation:

commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
 {...}, unsigned char 0x01) line 277 + 3 bytes
commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
 {...}, unsigned char 0x01) line 403 + 41 bytes
commonj::sdo::CopyHelper::copy(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
 {...}) line 267 + 29 bytes
sdo_do_clone_obj(_zval_struct * 0x0120c050, void * * * 0x003d2a20) line 208 + 
33 bytes

On the second entry to internalCopy(), the dataObject is null, which results in 
the AccessViolation when trying to get the DataFactory. 

Example:

schema:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:ord=orderNS xmlns:cust=customerNS targetNamespace=orderNS

  include schemaLocation=./Customer.xsd/

  element name=order type=ord:OrderType
complexType name=OrderType
  sequence
element ref=cust:customer/
  /sequence
/complexType
  /element

/schema

document:
$customer_xsd = EOF2
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
 xmlns:cust=customerNS targetNamespace=customerNS
  element name=customer type=cust:CustomerType
complexType name=CustomerType
  sequence
  /sequence
/complexType
  /element

/schema

logic:
$xmldas = SDO_DAS_XML::create('Order.xsd');
$order = $xmldas-createDataObject('orderNS','OrderType');
$order-customer = null;
$o = clone $order;

If customer is unset, there is no problem. Or if it is set to a real data 
object there is no problem either.

-- 
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-1225) Access violation in CopyHelper


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

Caroline Maynard commented on TUSCANY-1225:
---

Of course those are two parts of  the same schema - there is no input xml 
document

 Access violation in CopyHelper
 --

 Key: TUSCANY-1225
 URL: https://issues.apache.org/jira/browse/TUSCANY-1225
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
 Environment: Win32, PHP
Reporter: Caroline Maynard

 Cloning a DataObject withe a property that has been explicitly set to null 
 results in an AccessViolation:
 commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
  {...}, unsigned char 0x01) line 277 + 3 bytes
 commonj::sdo::CopyHelper::internalCopy(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
  {...}, unsigned char 0x01) line 403 + 41 bytes
 commonj::sdo::CopyHelper::copy(commonj::sdo::RefCountingPointercommonj::sdo::DataObject
  {...}) line 267 + 29 bytes
 sdo_do_clone_obj(_zval_struct * 0x0120c050, void * * * 0x003d2a20) line 208 + 
 33 bytes
 On the second entry to internalCopy(), the dataObject is null, which results 
 in the AccessViolation when trying to get the DataFactory. 
 Example:
 schema:
 ?xml version=1.0 encoding=UTF-8?
 schema xmlns=http://www.w3.org/2001/XMLSchema;
 xmlns:ord=orderNS xmlns:cust=customerNS targetNamespace=orderNS
   include schemaLocation=./Customer.xsd/
   element name=order type=ord:OrderType
 complexType name=OrderType
   sequence
 element ref=cust:customer/
   /sequence
 /complexType
   /element
 /schema
 document:
 $customer_xsd = EOF2
 ?xml version=1.0 encoding=UTF-8?
 schema xmlns=http://www.w3.org/2001/XMLSchema;
  xmlns:cust=customerNS targetNamespace=customerNS
   element name=customer type=cust:CustomerType
 complexType name=CustomerType
   sequence
   /sequence
 /complexType
   /element
 /schema
 logic:
 $xmldas = SDO_DAS_XML::create('Order.xsd');
 $order = $xmldas-createDataObject('orderNS','OrderType');
 $order-customer = null;
 $o = clone $order;
 If customer is unset, there is no problem. Or if it is set to a real data 
 object there is no problem either.

-- 
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: Databinding itests hang, was: svn commit: r531619 - /incubator/tuscany/java/sca/itest/pom.xml


On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Jean-Sebastien Delfino wrote:
 The databinding itests seem to hang, blocking the build. Is anybody
 else running into this?

 I have moved these itests temporarily out of the build until this is
 resolved.

 [EMAIL PROTECTED] wrote:
 Author: jsdelfino
 Date: Mon Apr 23 14:43:24 2007
 New Revision: 531619

 URL: http://svn.apache.org/viewvc?view=revrev=531619
 Log:
 Databinding integration tests hang. Moving them out of the main build
 until this is resolved.

 Modified:
 incubator/tuscany/java/sca/itest/pom.xml

 Modified: incubator/tuscany/java/sca/itest/pom.xml
 URL:

http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/pom.xml?view=diffrev=531619r1=531618r2=531619


==

 --- incubator/tuscany/java/sca/itest/pom.xml (original)
 +++ incubator/tuscany/java/sca/itest/pom.xml Mon Apr 23 14:43:24 2007
 @@ -44,7 +44,9 @@
  modulecallback-set-conversation/module
  modulecontribution/module
  moduleconversations/module
 +!--
  moduledatabindings/module
 +--
  moduleexceptions/module
  moduleoperation-overloading/module
  moduleproperties/module



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






After having switched to use Tomcat instead of Jetty I'm seeing other
errors (like Tomcat not being initialized). The following code in
DataBindingCase does not look right to me:

private static boolean initalised = false;
private GreeterService greeterClient;

/**
 * Runs before each test method
 */
protected void setUp() throws Exception {
if (!initalised) {
SCARuntime.start(greeter.composite);
super.setUp();
initalised = true;
}
}

/**
 * Runs after each test method
 */
protected void tearDown() {

}


I'm not sure why we have this initialized field, and also the tearDown
method should stop the SCA runtime or this test case is going to break
other test cases running after it, by leaving its SCA runtime started
and associated with the current thread.

--
Jean-Sebastien


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

Hi


I think you are right that the tearDown method needs some more in it. I'll
go and fix it.

My build is locking up on the Tuscany WSDL Integration Tests  though. It
took 53 seconds to run the 16 tests in
org.apache.tuscany.sca.itest.WSDLTestCase successfully and then failed after
530 seconds on the org.apache.tuscany.sca.itest.SDOWSDLTestCase with a
SocketTimeoutException. So something funny is going on somewhere.

I'll investigate further but if anyone has any bright ideas .

Simon

[jira] Updated: (TUSCANY-800) Introduce new DAS Sample APP to demonstrate DAS advanced features

2007-04-24 Thread Amita Vadhavkar (JIRA)


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

Amita Vadhavkar updated TUSCANY-800:


Attachment: AjaxDasJIRA800-Apr24-Amita.jar

1)url in ajax js,is the only one place which has path for hardcoded 
incubating - will need replacement later during release.

2)4 tables with data like below are needed - will take care of this later when 
JIRA-863 will get integrated - for now -  the db zipped along with proj has 
below data

TableList
TableNameCOMPANY/TableName
TableNameDEPARTMENT/TableName
TableNameCUSTOMER/TableName
TableNameBOOK/TableName
/TableList

TablesData
TableData TableName=COMPANY Columns='NAME' 
SqlTypes=Types.VARCHAR
TableRow'ACME Publishing'/TableRow
TableRow'Do-rite plumbing'/TableRow
TableRow'MegaCorp'/TableRow
/TableData

TableData TableName=DEPARTMENT Columns='NAME', 'LOCATION', 
'DEPNUMBER' 'COMPANYID' SqlTypes=Types.VARCHAR, Types.VARCHAR, Types.VARCHAR, 
Types.INTEGER
TableRow'Advanced Technologies', 'NY', '123', 
'1'/TableRow
/TableData

TableData TableName=CUSTOMER Columns='ID', 'LASTNAME', 
'ADDRESS' SqlTypes=Types.INTEGER, Types.VARCHAR, Types.VARCHAR
TableRow'1', 'Pavick', 'CA'/TableRow
TableRow'2', 'Williams', 'NJ'/TableRow
/TableData

TableData TableName=BOOK Columns='BOOK_ID', 'NAME', 
'AUTHOR','QUANTITY','OCC' SqlTypes=Types.INTEGER, Types.VARCHAR, 
Types.VARCHAR, Types.INTEGER, Types.INTEGER
TableRow'1', 'The Brothers Karamazov', 'Fyodor 
Dostoevsky','5', '17'/TableRow
/TableData
/TablesData


 Introduce new DAS Sample APP to demonstrate DAS advanced features
 -

 Key: TUSCANY-800
 URL: https://issues.apache.org/jira/browse/TUSCANY-800
 Project: Tuscany
  Issue Type: New Feature
  Components: Java DAS Samples
Reporter: Luciano Resende
 Assigned To: Luciano Resende
 Fix For: Java-DAS-Mx

 Attachments: ajaxDAS.lresende.20061005.zip, AjaxDasApr10.jar, 
 AjaxDasJIRA800-Apr24-Amita.jar, AjaxDASWebSample.doc, 
 JIRA-800-Mar23-Amita.jar, sample-ajax-das-1.0-incubator-SNAPSHOT.war


 Introduce a new DAS sample app to demonstrate DAS advanced features.
 This sample app uses AJAX to perform all the DAS interactions with the 
 persistence store (e.g case derby in tomcat) and an SDO graph is returned 
 back to UI and XSLT transformation is performed to present the data to user.
 Possible improvements to this would be to integrate OCC, and other advanced 
 DAS features into the sample.

-- 
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: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)

2007-04-24 Thread kelvin goodson


Ant,
 your note is well timed as I've had a couple of off-line chats with people
in the last week about release naming, particularly with regard to the
effect that a milestone or alpha name can have on uptake of a release.  In
the IRC chat of 16th April [1] we reached a conclusion that given the fact
that a new release candidate had just been posted for consideration, we
would leave naming as it was.  However, I got the impression that in general
the community was giving me an implicit +0 vote to retaining the M3 release
tag, but the ideal would be to move to a beta1 tag. At the time there was a
handful of small SDO 2.1 spec features for which we didn't have a first cut
implementation.  Now this has reduced to just a couple,  and it seemed that
there was consensus from the discussion that a beta* tag was not
incompatible with this state,  so long as the omissions were documented.

The SDO RC3 has been available for a little while for comment,  but has not
received much attention.  I have a couple of small non-blocking issues with
the candidate that I have spotted that I would like to tidy up.  So I
propose that I quickly cut a new 1.0-incubating-beta1 tag from the M3 tag,
make my small fixes (including adopting the incubating name convention over
the previous incubator convention) post a new candidate and start a vote on
that candidate. I'd like to do this ASAP and I don't think this is
contentious, but I guess I need to give a little time for reaction before
proceeding, as my actions would not be in accordance with the outcome
community discussions; I propose to do this at start of UK business
tomorrow.

Kelvin

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

On 24/04/07, ant elder [EMAIL PROTECTED] wrote:


What are we going to be calling this next SCA release?

We've had M1 and M2 releases, some alpha kernel releases, DAS are talking
about an M3 release and SDO is doing an M3 release although there was some
discussion about renaming that to beta1. I think milestone and alpha
release
names may discourage people from trying a release as it makes it sound
unstable. The spec defined SCA APIs are stable now and we're talking about
making stable SPIs for this next release, so the Tuscany externals are
becoming stable and that sounds better than alpha quality to me.

So how about the next Tuscany SCA release is named beta1? and we could try
to get DAS and SDO to also follow that naming?

Any comments or alternative name suggestions?

   ...ant

[jira] Created: (TUSCANY-1226) Nulls go missing in CopyHelper

Nulls go missing in CopyHelper
--

 Key: TUSCANY-1226
 URL: https://issues.apache.org/jira/browse/TUSCANY-1226
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
 Environment: PHP, WIn32
Reporter: Caroline Maynard
Priority: Minor
 Fix For: Cpp-current


This is perhaps a variation on Tuscany-1225. Problem is that when using 
CopyHelper to clone a DataObject, properties which are set to null remain unset 
in the destination DataObject.

Example:
SCHEMA:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
targetNamespace=PersonNamespace
xmlns:AuthorNS=PersonNamespace
  complexType name=personType
sequence
  element name=name type=string/
  element name=dob type=string/
  element name=pob type=string/
/sequence
  /complexType
/schema

logic:
$xmldas = SDO_DAS_XML::create('person.xsd');

$person = $xmldas-createDataObject('PersonNamespace','personType');

$person-name = William Shakespeare';
$person-dob = null;
$person-pob = null;

$person2 = clone($person);

After the clone the php $person looks like: 

object(SDO_DataObject)#3 (3) {name=William Shakespeare'; dob=NULL; 
pob=NULL}

but $person2 is:
object(SDO_DataObject)#4 (3) {name=William Shakespeare'; dob; pob}

(I can't show you the Tuscany print of the DO, because it causes an 
AccessViolation :-) )

Problem is perhaps that transferitem() doesn't consider nulls

-- 
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: [DISCUSS] Next version - What should be in it


How about Ant as release manager for this release?  He has been very
diligent in reviewing previous Tuscany releases with many helpful
comments.  He has a good understanding of the Apache requirements
and process for publishing a release, and I think he is very well
qualified to take this on.

  Simon

Raymond Feng wrote:


Hi,

After evaluating the features I would like to contribute to this release 
in the short timeframe, I don't think I would have enough time to handle 
the release as I'm new to this process. I would appreciate if somebody 
else with more experience volunteers to be the release manager. This 
way, I can learn more and get ready for the next time.


Thanks,
Raymond

- Original Message - From: Luciano Resende [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, April 20, 2007 10:25 AM
Subject: Re: [DISCUSS] Next version - What should be in it



+1 on focusing on the stability and consumability for the core functions,
other then helping on simplifying the runtime further and work on a 
Domain
concept, I also want to contribute around having a better integration 
with
App Servers, basically start by bringing back WAR plugin and TC 
integration.


+1 on Raymond as Release Manager

On 4/20/07, Raymond Feng [EMAIL PROTECTED] wrote:



Hi,

Considering that we want to achieve this in about 3 weeks, I agree 
that we

focus on the stability and consumability for the core functions.

Other additional features are welcome. We can decide if they will be 
part

of
the release based on the readiness.

Are any of you going to volunteer to be the release manager? If not, 
I can

give a try.

Thanks,
Raymond

- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, April 18, 2007 6:07 PM
Subject: Re: [DISCUSS] Next version - What should be in it


 Davanum Srinivas wrote:
 Folks,

 Let's keep the ball rolling...Can someone please come up with a 
master

 list of extensions, bindings, services, samples which can then help
 decide what's going to get into the next release. Please start a wiki
 page to document the master list. Once we are done documenting the
 list. We can figure out which ones are MUST, which ones are nice to
 have, which ones are out of scope. Then we can work backwards to
 figure out How tightly or loosely coupled each piece is/should be and
 how we could decouple them if necessary using
 interfaces/spi/whatever...

 Quote from Bert Lamb:
 I think there should be a voted upon core set of extensions,
 bindings, services, samples, whatever that should be part of a
 monolithic build.
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html

 Quote from Ant Elder:
 The specifics of what extensions are included in this release is left
out
 of
 this vote and can be decided in the release plan discussion. All this
 vote
 is saying is that all the modules that are to be included in this 
next

 release will have the same version and that a top level pom.xml will
 exist
 to enable building all those modules at once.
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html

 Thanks,
 dims



 Hi all,

 I think we have made good progress since we initially started this
 discussion. We have a simpler structure in trunk with a working  
top-down

 build. Samples and integration tests from the integration branch have
been
 integrated back in trunk and most are now working.

 We have a more modular runtime with a simpler extension mechanism. For
 example we have separate modules for the various models, the core
runtime
 and the Java component support. SPIs between the models and the 
rest of
 the runtime have been refactored and should become more stable. We 
need

to
 do more work to further simplify the core runtime SPIs and improve the
 core runtime but I think this is going in the right direction.

 I'm also happy to see better support for the SCA 1.0 spec, with 
support

 for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 APIs. It
 looks like extensions are starting to work again in the trunk,  
including

 Web Services, Java and scripting components. It shouldn't be too
difficult
 to port some of the other extensions - Spring, JMS, JSON-RPC -  to the
 latest code base as well.

 So, the JavaOne conference is in three weeks, would it make sense 
to  try

 to have a Tuscany release by then?

 We could integrate in that release what we already have working in
trunk,
 mature and stabilize our SPIs and our extensibility story, and this
would
 be a good foundation for people to use, embed or extend.

 On top of that, I think it would be really cool to do some work to:
 - Make it easier to assemble a distributed SCA domain with components
 running on different runtimes / machines.
 - Improve our scripting and JSON-RPC support a little and show how to
 build Web 2.0 applications with Tuscany.
 - Improve our integration story with Tomcat and also start looking 
at  an

 integration

Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)


On 4/24/07, kelvin goodson [EMAIL PROTECTED] wrote:


Ant,
  your note is well timed as I've had a couple of off-line chats with
people
in the last week about release naming, particularly with regard to the
effect that a milestone or alpha name can have on uptake of a release.  In
the IRC chat of 16th April [1] we reached a conclusion that given the fact
that a new release candidate had just been posted for consideration, we
would leave naming as it was.  However, I got the impression that in
general
the community was giving me an implicit +0 vote to retaining the M3
release
tag, but the ideal would be to move to a beta1 tag. At the time there was
a
handful of small SDO 2.1 spec features for which we didn't have a first
cut
implementation.  Now this has reduced to just a couple,  and it seemed
that
there was consensus from the discussion that a beta* tag was not
incompatible with this state,  so long as the omissions were documented.

The SDO RC3 has been available for a little while for comment,  but has
not
received much attention.  I have a couple of small non-blocking issues
with
the candidate that I have spotted that I would like to tidy up.  So I
propose that I quickly cut a new 1.0-incubating-beta1 tag from the M3 tag,
make my small fixes (including adopting the incubating name convention
over
the previous incubator convention) post a new candidate and start a vote
on
that candidate. I'd like to do this ASAP and I don't think this is
contentious, but I guess I need to give a little time for reaction before
proceeding, as my actions would not be in accordance with the outcome
community discussions; I propose to do this at start of UK business
tomorrow.

Kelvin

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

On 24/04/07, ant elder [EMAIL PROTECTED] wrote:

 What are we going to be calling this next SCA release?

 We've had M1 and M2 releases, some alpha kernel releases, DAS are
talking
 about an M3 release and SDO is doing an M3 release although there was
some
 discussion about renaming that to beta1. I think milestone and alpha
 release
 names may discourage people from trying a release as it makes it sound
 unstable. The spec defined SCA APIs are stable now and we're talking
about
 making stable SPIs for this next release, so the Tuscany externals are
 becoming stable and that sounds better than alpha quality to me.

 So how about the next Tuscany SCA release is named beta1? and we could
try
 to get DAS and SDO to also follow that naming?

 Any comments or alternative name suggestions?

...ant



Ant

This is an interesting idea. I think going to beta1 will better describe the
type of release I (we) would like to see. I think though that this does
underline our need to get the supporting material e.g. samples, docs etc. up
to the level we would expect of a beta release. This is not a surprise, it's
been discussed on the release content thread and elsewhere but I think a
naming proposition like this can help focus the mind (separate thread
required to get all this stuff sorted)

So are you suggesting we go to 1.0-incubating-beta1 as Kelvin suggested.

Are there any modules that would be part of a beta release but would not be
named this way?I don't have anything in mind just asking.

Are there modules that we have in the build that we would choose to leave
out if we call it a beta release?

Simon

[jira] Created: (TUSCANY-1227) FileException not thrown when schema file missing

FileException not thrown when schema file missing
-

 Key: TUSCANY-1227
 URL: https://issues.apache.org/jira/browse/TUSCANY-1227
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
 Environment: PHP, Win32
Reporter: Caroline Maynard
Priority: Minor


This regression occurred a few months back. When I do 
XSDHelper::defineFile(nonexistent.xsd), Tuscany used to give me an 
SDOFileNotFoundException. Now it does not throw an exception. Instead it 
returns with a non-zero error count, and messages:

1 parse error(s) occurred when parsing the file 'xxx':
1. xmlSAXUserParseFile returned an error -1 ' in Command line code:1

I'd really like the exception back, because it's confusing for end-users to get 
what looks like a parsing failure when the file is just not there.

If necessary I will check the file stat in the php code before calling Tuscany 
and raise an exception directly, but I'm not sure I know exactly what the path 
spec is that libxml2 uses to find a relative file.

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


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

[jira] Created: (TUSCANY-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase

Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
-

 Key: TUSCANY-1228
 URL: https://issues.apache.org/jira/browse/TUSCANY-1228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove


DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for 
Object types, such as:

assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject));

There is nothing wrong with Tuscany creating this type with this name, but the 
naming of these Object types is not provided in the specification, so this 
test will fail on other implementations. I will provide a patch to remove these 
particular assertions. This is consistent with changes made to other test cases.

-- 
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-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase


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

Andy Grove updated TUSCANY-1228:


Attachment: jira-1228.patch

Patch file.

 Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
 -

 Key: TUSCANY-1228
 URL: https://issues.apache.org/jira/browse/TUSCANY-1228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Attachments: jira-1228.patch


 DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for 
 Object types, such as:
 assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject));
 There is nothing wrong with Tuscany creating this type with this name, but 
 the naming of these Object types is not provided in the specification, so 
 this test will fail on other implementations. I will provide a patch to 
 remove these particular assertions. This is consistent with changes made to 
 other test cases.

-- 
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-952) DAS must support queries that reference tables in different schemas

2007-04-24 Thread Amita Vadhavkar (JIRA)

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

Amita Vadhavkar updated TUSCANY-952:

Attachment: JIRA-952-Details.doc
DAS-JIRA-952-Apr24-Amita.txt

This patch and details doc is for the rdb-das code changes. The patch does not
include any test client. And with the current unit test setup, it is not
possible to
add test cases to it for multiple schema testing. So, a separate J2SE client
sample can be provided for test purpose, based on DB2 database.

Please let me know if such sample will be useful, in that case I will work on
it.

DAS must support queries that reference tables in different schemas
-

Key: TUSCANY-952
URL: https://issues.apache.org/jira/browse/TUSCANY-952
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Reporter: Kevin Williams
Fix For: Java-DAS-Mx

Attachments: DAS-JIRA-952-Apr24-Amita.txt, JIRA-952-Details.doc,
JIRA-952-Feb16-Amita.jar, JIRA-952-Mar01-Amita.jar

The DAS is curently ignorant of database schema designations. This means the
DAS will generate incorrect write statements when it processes the change
summary from a data graph that originated from a query that uses schema names
that are different from the default schema.

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

NPE in databinding

2007-04-24 Thread Ignacio Silva-Lepe


I am getting a NPE in SimpleTypeMapperExtension.toJavaObject,
the full trace is in http://rafb.net/p/JMYwL280.html. After the trace
I append printouts of the source and target operation's input and
output types. Also included are the .composite and .component-
Type files in use, as well as the Java interface of the components
being referred to by TrafficAdvisoryNotificationComponent. Notice
that in that interface there is a @DataBinding annotation that is
commented out, as it does not seem to make a difference. Finally,
notice that the printed out source input type includes Type: null
at the end. I am not sure whether this is the cause of the NPE or
what to do to fix it. A corresponding producer-side sample uses
the exact same componentType (including the interface,wsdl) and
there is no problem, but in that case the TrafficAdvisoryNotification-
Component on the target side of the databinding, rather than on the
source side.

Any ideas?

Re: [Java SDO CTS] adopting some tests from the optional bucket

2007-04-24 Thread kelvin goodson


A little digging shows that the base64binary to Base64Bytes mapping issue
exists due to this spec issue http://www.xcalia.com/support/browse/SDO-128
So I propose to move the XSDComplexTests into the adopted suite as per the
patch for 1224,  but to comment out any assertions with regards to the
mapping of base64binary.  How does that sound?

Kelvin.

On 24/04/07, kelvin goodson [EMAIL PROTECTED] wrote:


Having looked at XSDChoiceTest I think it's fine for moving to the adopted
suite.  Any comments?
Also I've been looking at Andy's patch for TUSCANY-1224, and the fixes
seem fine.  As Andy mentions in the JIRA, Tuscany fails a couple of test as
it stands because it maps xsd's base64Binary to Tuscany SDO's Base64Bytes.
This type was introduced in Tuscany-933,  and IIRC it was necessary due to a
spec grey area.  I'm just looking back at that now to try to understand
again the thought processes that went into that fix.  If the test failure is
due to a spec grey area then I would say that we shouldn't adopt those
failing tests right now.

Regards, Kelvin.

[jira] Created: (TUSCANY-1229) CTS contains duplicate copy of TypeConversion test

CTS contains duplicate copy of TypeConversion test
--

 Key: TUSCANY-1229
 URL: https://issues.apache.org/jira/browse/TUSCANY-1229
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
Priority: Trivial


There are three tests named TypeConversionTest in the CTS:

test.sdo21.paramatizedTests.conversion.TypeConversionTest
test.sdo21.tests.conversion.TypeConversionTest
test.sdo21.tests.typeconv.TypeConversionTest

The last two are duplicates - a diff shows that they are almost identical, 
differing only in comments and format.

We should simply delete test.sdo21.tests.typeconv.TypeConversionTest - it is 
not referenced anywhere.

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


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

[jira] Resolved: (TUSCANY-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase


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

Andy Grove resolved TUSCANY-1228.
-

Resolution: Invalid

I had an old file on my local system that was not in subversion - this issue is 
invalid.

 Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
 -

 Key: TUSCANY-1228
 URL: https://issues.apache.org/jira/browse/TUSCANY-1228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Attachments: jira-1228.patch


 DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for 
 Object types, such as:
 assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject));
 There is nothing wrong with Tuscany creating this type with this name, but 
 the naming of these Object types is not provided in the specification, so 
 this test will fail on other implementations. I will provide a patch to 
 remove these particular assertions. This is consistent with changes made to 
 other test cases.

-- 
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-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase


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

Andy Grove commented on TUSCANY-1228:
-

Ignore the previous comment - I posted this on the wrong JIRA. This issue is 
still valid.

 Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
 -

 Key: TUSCANY-1228
 URL: https://issues.apache.org/jira/browse/TUSCANY-1228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Attachments: jira-1228.patch


 DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for 
 Object types, such as:
 assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject));
 There is nothing wrong with Tuscany creating this type with this name, but 
 the naming of these Object types is not provided in the specification, so 
 this test will fail on other implementations. I will provide a patch to 
 remove these particular assertions. This is consistent with changes made to 
 other test cases.

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


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

[jira] Closed: (TUSCANY-1229) CTS contains duplicate copy of TypeConversion test


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

Andy Grove closed TUSCANY-1229.
---

Resolution: Invalid

I had an old file on my system - the test case is not duplicated after all.

 CTS contains duplicate copy of TypeConversion test
 --

 Key: TUSCANY-1229
 URL: https://issues.apache.org/jira/browse/TUSCANY-1229
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
Priority: Trivial

 There are three tests named TypeConversionTest in the CTS:
 test.sdo21.paramatizedTests.conversion.TypeConversionTest
 test.sdo21.tests.conversion.TypeConversionTest
 test.sdo21.tests.typeconv.TypeConversionTest
 The last two are duplicates - a diff shows that they are almost identical, 
 differing only in comments and format.
 We should simply delete test.sdo21.tests.typeconv.TypeConversionTest - it is 
 not referenced anywhere.

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


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

[jira] Resolved: (TUSCANY-1224) XSDComplexTypeTest patch

2007-04-24 Thread Kelvin Goodson (JIRA)


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

Kelvin Goodson resolved TUSCANY-1224.
-

Resolution: Fixed

applied patch,  but commented out assertions concerning base64binary to Bytes 
mapping because of the pending spec issue SDO-128

 XSDComplexTypeTest patch
 

 Key: TUSCANY-1224
 URL: https://issues.apache.org/jira/browse/TUSCANY-1224
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Attachments: jira-1224.patch


 I have reviews the XSDComplexTypeTest and fixed a number of issues, such as:
 - Removed one test that was specific to Rogue Wave
 - Fixed errors in assertions that checked for sequenced=true or false (many 
 of these were incorrect)
 - Removed assertions that tested how many types were created from each XSD 
 (so the test now only mandates that those types required by the specification 
 are created)
 After making these changes, there are 3 test failures when running against 
 Tuscany. Two of these are related to an incorrect mapping of XSD base64Binary 
 type in Tuscany, the other is due to isNullable not being implemented in 
 Tuscany (an UnsupportedOperationException is thrown).

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


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

[jira] Created: (TUSCANY-1230) Improvements to TypeConversionTest

Improvements to TypeConversionTest
--

 Key: TUSCANY-1230
 URL: https://issues.apache.org/jira/browse/TUSCANY-1230
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Community Test Suite
Reporter: Andy Grove


The attached patch performs the following

- Refactors test.sdo21.tests.conversion.TypeConversionTest to split out a 
subset of the tests into a new StringConversionTest class with a common base 
class of ConversionBase
- Adds TypeConversionTest to the CTSGeneralSuite (all tests pass against 
Tuscany)
- Adds StringConversionTest to the UnderReviewTestSuite (there are quite a few 
failures which need further investigation)

This patch also fixes a number of tests that were testing that the 
implementation threw an exception when performing certain type conversions, 
such as byte - BigInteger, as these conversions are not listed as supported 
conversions in the data type conversion matrix in the specification. However, 
these conversions are completely valid and should have been included in the 
type conversion matrix. See JIRA SDO-188 (OSOA) for more information.


-- 
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-1230) Improvements to TypeConversionTest


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

Andy Grove updated TUSCANY-1230:


Attachment: jira-1230.patch

Patch for above.

 Improvements to TypeConversionTest
 --

 Key: TUSCANY-1230
 URL: https://issues.apache.org/jira/browse/TUSCANY-1230
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SDO Community Test Suite
Reporter: Andy Grove
 Attachments: jira-1230.patch


 The attached patch performs the following
 - Refactors test.sdo21.tests.conversion.TypeConversionTest to split out a 
 subset of the tests into a new StringConversionTest class with a common base 
 class of ConversionBase
 - Adds TypeConversionTest to the CTSGeneralSuite (all tests pass against 
 Tuscany)
 - Adds StringConversionTest to the UnderReviewTestSuite (there are quite a 
 few failures which need further investigation)
 This patch also fixes a number of tests that were testing that the 
 implementation threw an exception when performing certain type conversions, 
 such as byte - BigInteger, as these conversions are not listed as supported 
 conversions in the data type conversion matrix in the specification. However, 
 these conversions are completely valid and should have been included in the 
 type conversion matrix. See JIRA SDO-188 (OSOA) for more information.

-- 
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: NPE in databinding


Hi, Ignacio.

The problem seems to be on the path of transforming the report parameter 
to a XML type expected by the WSDL. By reading your WSDL @ 
http://rafb.net/p/vT10ws82.html, I found the operation is not 
document-literal wrapped style. The WSDL operation trafficNotification 
expects an input like:


inputBody
   report
   reportMyReport/report
   /report
/inputBody

You should use a complex Type for the java method trafficNotification().

The problem should have been captured by the wiring phase, as these two 
interfaces are not compatible. The current checking is a bit relaxed (name 
only) and we need to enforce it as we get clearer about how to check the 
compatiblity between a java method and a WSDL operation.


Thanks,
Raymond

- Original Message - 
From: Ignacio Silva-Lepe [EMAIL PROTECTED]

To: Tuscany Dev List tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 7:07 AM
Subject: NPE in databinding



I am getting a NPE in SimpleTypeMapperExtension.toJavaObject,
the full trace is in http://rafb.net/p/JMYwL280.html. After the trace
I append printouts of the source and target operation's input and
output types. Also included are the .composite and .component-
Type files in use, as well as the Java interface of the components
being referred to by TrafficAdvisoryNotificationComponent. Notice
that in that interface there is a @DataBinding annotation that is
commented out, as it does not seem to make a difference. Finally,
notice that the printed out source input type includes Type: null
at the end. I am not sure whether this is the cause of the NPE or
what to do to fix it. A corresponding producer-side sample uses
the exact same componentType (including the interface,wsdl) and
there is no problem, but in that case the TrafficAdvisoryNotification-
Component on the target side of the databinding, rather than on the
source side.

Any ideas?




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

Nominate Ant as the release manager was: Re: [DISCUSS] Next version - What should be in it

+1. I would like to nominate Ant too.

Thanks,
Raymond

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

To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 4:32 AM
Subject: Re: [DISCUSS] Next version - What should be in it

How about Ant as release manager for this release?  He has been very
diligent in reviewing previous Tuscany releases with many helpful
comments.  He has a good understanding of the Apache requirements
and process for publishing a release, and I think he is very well
qualified to take this on.

  Simon

Raymond Feng wrote:

Hi,

After evaluating the features I would like to contribute to this release 
in the short timeframe, I don't think I would have enough time to handle 
the release as I'm new to this process. I would appreciate if somebody 
else with more experience volunteers to be the release manager. This way, 
I can learn more and get ready for the next time.

Thanks,
Raymond

- Original Message - From: Luciano Resende 
[EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Friday, April 20, 2007 10:25 AM
Subject: Re: [DISCUSS] Next version - What should be in it

+1 on focusing on the stability and consumability for the core 
functions,
other then helping on simplifying the runtime further and work on a 
Domain
concept, I also want to contribute around having a better integration 
with
App Servers, basically start by bringing back WAR plugin and TC 
integration.

+1 on Raymond as Release Manager

On 4/20/07, Raymond Feng [EMAIL PROTECTED] wrote:

Hi,

Considering that we want to achieve this in about 3 weeks, I agree that 
we

focus on the stability and consumability for the core functions.

Other additional features are welcome. We can decide if they will be 
part

of
the release based on the readiness.

Are any of you going to volunteer to be the release manager? If not, I 
can

give a try.

Thanks,
Raymond

- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, April 18, 2007 6:07 PM
Subject: Re: [DISCUSS] Next version - What should be in it

 Davanum Srinivas wrote:
 Folks,

 Let's keep the ball rolling...Can someone please come up with a
master
 list of extensions, bindings, services, samples which can then 
 help
 decide what's going to get into the next release. Please start a 
 wiki

 page to document the master list. Once we are done documenting the
 list. We can figure out which ones are MUST, which ones are nice to
 have, which ones are out of scope. Then we can work backwards to
 figure out How tightly or loosely coupled each piece is/should be 
 and

 how we could decouple them if necessary using
 interfaces/spi/whatever...

 Quote from Bert Lamb:
 I think there should be a voted upon core set of extensions,
 bindings, services, samples, whatever that should be part of a
 monolithic build.
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html

 Quote from Ant Elder:
 The specifics of what extensions are included in this release is 
 left

out
 of
 this vote and can be decided in the release plan discussion. All 
 this

 vote
 is saying is that all the modules that are to be included in this
next
 release will have the same version and that a top level pom.xml will
 exist
 to enable building all those modules at once.
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html

 Thanks,
 dims

 Hi all,

 I think we have made good progress since we initially started this
 discussion. We have a simpler structure in trunk with a working 
top-down
 build. Samples and integration tests from the integration branch have
been
 integrated back in trunk and most are now working.

 We have a more modular runtime with a simpler extension mechanism. 
 For

 example we have separate modules for the various models, the core
runtime
 and the Java component support. SPIs between the models and the
rest of
 the runtime have been refactored and should become more stable. We
need
to
 do more work to further simplify the core runtime SPIs and improve 
 the

 core runtime but I think this is going in the right direction.

 I'm also happy to see better support for the SCA 1.0 spec, with
support
 for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 APIs. 
 It

 looks like extensions are starting to work again in the trunk, 
including
 Web Services, Java and scripting components. It shouldn't be too
difficult
 to port some of the other extensions - Spring, JMS, JSON-RPC -  to 
 the

 latest code base as well.

 So, the JavaOne conference is in three weeks, would it make sense
to  try
 to have a Tuscany release by then?

 We could integrate in that release what we already have working in
trunk,
 mature and stabilize our SPIs and our extensibility story, and this
would
 be a good foundation for people to use, embed or extend.

 On top of that, I think it would be really cool to do some work to:
 - Make it easier to assemble a distributed SCA domain

[jira] Closed: (TUSCANY-950) CopyHelper::copy() forgets sequence information


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

Caroline Maynard closed TUSCANY-950.


Resolution: Fixed

Problem stated has been fixed.

 CopyHelper::copy() forgets sequence information
 ---

 Key: TUSCANY-950
 URL: https://issues.apache.org/jira/browse/TUSCANY-950
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Caroline Maynard
 Fix For: Cpp-M3

 Attachments: sdoclone-sequences.txt


 An SDO for PHP user has reported the following at 
 http://pecl.php.net/bugs/bug.php?id=9487
 He is using CopyHelper::copy() to copy a seqenced data object. The properties 
 are copied OK, but the unstructured text is forgotten.  So when I inspect the 
 copied DataObject, its properties have the same values as the original. But 
 if I do a getSequence() on it, I get a Sequence object which is empty. That 
 is, neither its properties nor its unstructured text are set. 
 This should be self-explanatory, but I'll create a testcase if you need one.

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

[Tuscany Java CTS] many tests covering the same relatively trivial code path

2007-04-24 Thread kelvin goodson


There are a number of CTS tests in the under review bucket that Tuscany is
failing because the assertions tested prior Tuscany behaviour, rather than
spec constraints. e.g.  SequenceTest.testGetProperty.

These assertions are of the form get property by index and ensure its the
same as getting it by name. and now that Tuscany has stopped exposing EMF
special properties the indices don't match up with the property names any
more. The hard coding of these indices makes the tests fragile.

I could just go round fixing all such instances,  however,  it seems that we
have a lot of occasions where we are testing exactly the same fairly
uninteresting code path,  and I'm pretty sure that this would be the same
for other implementations too.  So I propose to rationalize the number of
times we do this kind of test, so that we keep the level of redundancy in
the tests to a minimum.

Kelvin.

Re: Nominate Ant as the release manager was: Re: [DISCUSS] Next version - What should be in it


+1 I make Simon's words my words too...

On 4/24/07, Raymond Feng [EMAIL PROTECTED] wrote:


+1. I would like to nominate Ant too.

Thanks,
Raymond

- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 4:32 AM
Subject: Re: [DISCUSS] Next version - What should be in it


 How about Ant as release manager for this release?  He has been very
 diligent in reviewing previous Tuscany releases with many helpful
 comments.  He has a good understanding of the Apache requirements
 and process for publishing a release, and I think he is very well
 qualified to take this on.

   Simon

 Raymond Feng wrote:

 Hi,

 After evaluating the features I would like to contribute to this
release
 in the short timeframe, I don't think I would have enough time to
handle
 the release as I'm new to this process. I would appreciate if somebody
 else with more experience volunteers to be the release manager. This
way,
 I can learn more and get ready for the next time.

 Thanks,
 Raymond

 - Original Message - From: Luciano Resende
 [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Friday, April 20, 2007 10:25 AM
 Subject: Re: [DISCUSS] Next version - What should be in it


 +1 on focusing on the stability and consumability for the core
 functions,
 other then helping on simplifying the runtime further and work on a
 Domain
 concept, I also want to contribute around having a better integration
 with
 App Servers, basically start by bringing back WAR plugin and TC
 integration.

 +1 on Raymond as Release Manager

 On 4/20/07, Raymond Feng [EMAIL PROTECTED] wrote:


 Hi,

 Considering that we want to achieve this in about 3 weeks, I agree
that
 we
 focus on the stability and consumability for the core functions.

 Other additional features are welcome. We can decide if they will be
 part
 of
 the release based on the readiness.

 Are any of you going to volunteer to be the release manager? If not,
I
 can
 give a try.

 Thanks,
 Raymond

 - Original Message -
 From: Jean-Sebastien Delfino [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Wednesday, April 18, 2007 6:07 PM
 Subject: Re: [DISCUSS] Next version - What should be in it


  Davanum Srinivas wrote:
  Folks,
 
  Let's keep the ball rolling...Can someone please come up with a
 master
  list of extensions, bindings, services, samples which can then
  help
  decide what's going to get into the next release. Please start a
  wiki
  page to document the master list. Once we are done documenting the
  list. We can figure out which ones are MUST, which ones are nice
to
  have, which ones are out of scope. Then we can work backwards to
  figure out How tightly or loosely coupled each piece is/should be
  and
  how we could decouple them if necessary using
  interfaces/spi/whatever...
 
  Quote from Bert Lamb:
  I think there should be a voted upon core set of extensions,
  bindings, services, samples, whatever that should be part of a
  monolithic build.
 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html
 
  Quote from Ant Elder:
  The specifics of what extensions are included in this release is
  left
 out
  of
  this vote and can be decided in the release plan discussion. All
  this
  vote
  is saying is that all the modules that are to be included in this
 next
  release will have the same version and that a top level pom.xmlwill
  exist
  to enable building all those modules at once.
 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html
 
  Thanks,
  dims
 
 
 
  Hi all,
 
  I think we have made good progress since we initially started this
  discussion. We have a simpler structure in trunk with a working 
 top-down
  build. Samples and integration tests from the integration branch
have
 been
  integrated back in trunk and most are now working.
 
  We have a more modular runtime with a simpler extension mechanism.
  For
  example we have separate modules for the various models, the core
 runtime
  and the Java component support. SPIs between the models and the
 rest of
  the runtime have been refactored and should become more stable. We
 need
 to
  do more work to further simplify the core runtime SPIs and improve
  the
  core runtime but I think this is going in the right direction.
 
  I'm also happy to see better support for the SCA 1.0 spec, with
 support
  for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 APIs.
  It
  looks like extensions are starting to work again in the trunk, 
 including
  Web Services, Java and scripting components. It shouldn't be too
 difficult
  to port some of the other extensions - Spring, JMS, JSON-RPC -  to
  the
  latest code base as well.
 
  So, the JavaOne conference is in three weeks, would it make sense
 to  try
  to have a Tuscany release by then?
 
  We could integrate in that release what we already have working in
 trunk,
  mature and stabilize our SPIs and our extensibility story, and this

Databinding itest locking up?


Following Sebastiens post about the databinding test locking up (he went
ahead and removed it from the itest pom to get the build to work) I tried
the test and, once I had changed the poms to depend on http-jetty as they
used to, I got the same effect of the test hanging. The process is sitting
with port 8080 in the CLOSE_WAIT state which basically means that the client
hasn't closed the socket correctly.

I went in and commented out the line

//   requestMC.getOptions().setProperty(
HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);

In Axis2TargetInvoker.invokeTarget which was instigated by TUSCANY-1218 [1]
and it worked again.  Now Sebastien did point out a fault/feature of the
itest. The way the databinding itests work as checked in is that they only
create one runtime for all the tests that are run. However it neglects to
call SCARuntime.stop() at the end. I have put this change into my local copy
and it still locks up when using REUSE_HTTP_CLIENT.

Anyone else seeing this kind of behaviour. All of the basic web services
tests work on my box and I don't see that the SDO databinding itest (the
test I'm trying at the moment) is doing anything different.

Also did the databinding itests run ok after the TUSCANY-1218 change was
applied. We could be dealing with some combination of the effect of that
change and the changes since then.

I should note that, in the past, I have not experienced the connection
refused error that originated 1218. Is there some kind of system setting
that's being toggled off again by the code change (just a stab in the dark)?

Simon

[1] http://issues.apache.org/jira/browse/TUSCANY-1218

Re: Scoping SDO metadata, was: How to access a composite's data model scope in an application?

2007-04-24 Thread Frank Budinsky

Hi Dave,

The default context binds to the same helpers as all the INSTANCE fields - 
e.g., TypeHelper.INSTANCE == 
HelperProvider.getDefaultContext().getTypeHelper(). HelperContext was a 
last minute addition. At that late stage (and in a point release) we 
couldn't get agreement on how to support multiple scopes - but we knew it 
is a future goal, so we felt it was important to at least set the 
groundwork for people to move away from coding with INSTANCEs and instead 
access their helpers from the context. The remaining unspecified API is 
how to get a HelperContext in a standard way. I think that if we design 
something clean for this in Tuscany, we can later feed it into SDO 3.

Frank

scabooz [EMAIL PROTECTED] wrote on 04/23/2007 07:10:34 PM:

 Hi Frank,
 
 Can you help me understand why defaultContext is a singleton?  I don't 
see 
 it
 described that way in the specs, so I'm hoping you can help me 
understand 
 this.
 
 Dave
 
 
 - Original Message - 
 From: Frank Budinsky [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Monday, April 23, 2007 2:40 PM
 Subject: Re: Scoping SDO metadata, was: How to access a composite's data 

 model scope in an application?
 
 
  Hi Guys,
 
  I finally managed to catch up on this. I think you're heading in the 
wrong
  direction by using HelperProvider.getDefaultContext() because:
 
  1) it's a singleton, and we're trying to get away from singletons:
 
 static HelperContext defaultContext = new DefaultHelperContext();
 
  The fact that the default context in Tuscany has some special 
TCCL-based
  managment (under the covers - thanks to EMF), is a Tuscany-specific
  behavior - but the default context is itself a single object 
(singleton).
 
  2) HelperProvider is an impl class (in package commonj.sdo.impl) ... 
It's
  bad to make that the application API
 
  The reason we added HelperContext to the spec to get away from the
  singleton problems. The default context was needed as an interim step,
  until the spec comes up with other ways to access scoped 
HelperContexts.
  Many of the problems we had with EMF were exactly because we were 
trying
  to replace the global EMF INSTANCEs - e.g., EcoreFactory.eINSTANCE - 
but
  then we ran into problems because there were multiple apps trying to
  control the value. We don't want a repeat of that with the default
  context.
 
  That said, I think that a better way to look at this is that we want a
  pluggable mechanism for managing HelperContexts in Tuscany. Since the
  ability to manage scope-specific context's is a general issue, not 
just
  for SCA, it does seem to make sense to put this into Tuscany/SDO. 
Maybe we
  can feed back our (hopefully successful) result to the spec, so in the
  future there will be proper SDO APIs for this.
 
  For now, however, we're talking about some new SDOUtil methods for 
this.
  For example, what if we provide a HelperContextManager, where you can
  register keyed HelperContexts. The key could be a ClassLoader, Thread, 
or
  anything else. Given such a manager, we could provide some SDOUtil 
methods
  to register and access the HelperContext. Maybe something like this:
 
  HelperContext SDOUtil.getHelperContext(Object key);
 
  and maybe even some convenience methods like this:
 
  HelperContext SDOUtil.getHelperContext(Thread thread);
  HelperContext SDOUtil.getLoaderHelperContext(Class Loader 
classLoader);
 
  These helper methods would be used by clients to access the 
HelperContext.
  The implementation would just use the HelperContextManager to get the
  keyed HelperContext. Maybe we could also provide ways to set up 
chained
  (according to parent CL's, for example) HelperContext's, etc.
 
  Thoughts?
 
  Frank
 
  Fuhwei Lwo [EMAIL PROTECTED] wrote on 04/20/2007 01:36:37 PM:
 
  Raymond,
 
  I agree with your suggestion below. In addition, I think SCA still
  needs to provide an option (injection or API) for the applications
  to explicitly retrieve the data model scope from the Contribution.
  Other databinding technology APIs beside SDO may not have default
  context helper concept.
 
  1) SDO defines the pluggability to supply the default HelperContext.
  2) SCA plugs its own scoping scheme to the SDO default HelperContext.
  The
  HelperContext will be populated based on the Contribution.
  3) Application code will use HelperProvider.getDefaultContext() to
  retrieve
  the default HelperContext.
 
 
  Raymond Feng [EMAIL PROTECTED] wrote: Hi,
 
  Please see my comments inline.
 
  Thanks,
  Raymond
 
  - Original Message - 
  From: Jean-Sebastien Delfino
  To:
  Sent: Friday, April 20, 2007 9:23 AM
  Subject: Re: Scoping SDO metadata, was: How to access a composite's 
data
 
  model scope in an application?
 
 
   Fuhwei Lwo wrote:
   Hi Sebastien,
  
   Here is my understanding of requirements about getting rid of
  import.sdo
   and switching to contribution -
  
   1) A contribution will be created by contribution processor for 
each

[jira] Created: (TUSCANY-1231) Various incorrect namespaces in generated XML

2007-04-24 Thread Matthew Peters (JIRA)

Various incorrect namespaces in generated XML
-

 Key: TUSCANY-1231
 URL: https://issues.apache.org/jira/browse/TUSCANY-1231
 Project: Tuscany
  Issue Type: Bug
  Components: C++ DAS
Affects Versions: Cpp-M3
 Environment: WinXP
Reporter: Matthew Peters


Given the following two xsds, which define an add element in http://Component 
and a PersonType in http://www.test.com/info...

?php
$xmldas = SDO_DAS_XML::create('types.xsd');
$person =
$xmldas-createDataObject('http://www.test.com/info','personType');
$name = $person-createDataObject('name');
$name-first = Will;
$name-last  = Shakespeare;
$add = $xmldas-createDataObject('http://Component','add');
$add-person = $person;
$xdoc   = $xmldas-createDocument('', 'BOGUS', $add);
$xmlstr = $xmldas-saveString($xdoc, 2);
echo $xmlstr;
?

types.xsd:
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; 
  xmlns:ns0=http://www.test.com/info;
  targetNamespace=http://Component;
  elementNameDefault=qualified
  xs:import schemaLocation=person.xsd
namespace=http://www.test.com/info/
  xs:element name=add
xs:complexType
  xs:sequence
xs:element name=person type=ns0:personType
nillable=true/
  /xs:sequence
/xs:complexType
  /xs:element
/xs:schema

person.xsd:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema; 
targetNamespace=http://www.test.com/info; 
xmlns:info=http://www.test.com/info;
complexType name=nameType
sequence
element name=first type=string/element
element name=last type=string/element
/sequence
/complexType
complexType name=personType
sequence
element name=name type=info:nameType/element
/sequence
/complexType  
/schema

... if you now create a document with an 'add' element, create a PersonType 
object and assign meaningful first and last names, and serialise to XML, you 
get:

?xml version=1.0 encoding=UTF-8?
add xmlns=http://Component; xmlns:tns=http://Component; 
xmlns:tns2=http://www.test.com/info; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  person
tns2:name
  firstWill/first
  lastShakespeare/last
/tns2:name
  /person
/add

There are several things wrong with this XML. 

1. name should not be in tns2=http://www.test.com/info, and neither should 
first and last be in the default namespace of http://Component. The 
person.xsd has no elementFormDefault, so the elements below person should all 
be in the no name namespace. 
2.You have to change the person.xsd to see the next thing: put 
ElementNameDefault=qualified in
the person schema, then name, first and last should all now be
coming out in the http://www.test.com/info namespace, but it makes no
difference to the generated XML. 

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

Tomcat errors when trying to build the latest trunk


I'm seeing lots of Tomcat-related test failures when trying to build
the latest trunk code.  I've done a new checkout and cleaned out my
maven repo.  Here's a sample:

Running org.apache.tuscany.binding.axis2.itests.HelloWorldTestCase
log4j:WARN No appenders could be found for logger 
(org.apache.axiom.om.util.StAXUtils).
log4j:WARN Please initialize the log4j system properly.
24-Apr-2007 17:35:17 org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
24-Apr-2007 17:35:18 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
24-Apr-2007 17:35:18 org.apache.catalina.startup.ContextConfig defaultWebConfig
INFO: No default web.xml
24-Apr-2007 17:35:18 org.apache.catalina.startup.DigesterFactory register
WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd
24-Apr-2007 17:35:18 org.apache.catalina.startup.DigesterFactory register
WARNING: Could not get url for 
/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd
24-Apr-2007 17:35:18 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:18 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:19 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.014 sec
Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
Running 
org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase
24-Apr-2007 17:35:19 org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
24-Apr-2007 17:35:19 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
24-Apr-2007 17:35:19 org.apache.catalina.startup.ContextConfig defaultWebConfig
INFO: No default web.xml
24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:23 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:24 org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
SEVERE: Socket accept failed
java.net.SocketException: socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at 
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61)
at 
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:310)
at java.lang.Thread.run(Thread.java:595)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.168 sec  
FAILURE!
testCalculator(org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase)
  Time elapsed: 5.137 sec   ERROR!
java.lang.reflect.UndeclaredThrowableException
at $Proxy6.getGreetings(Unknown Source)
at 
org.apache.tuscany.binding.axis2.itests.HelloWorldOMComponent.getGreetings(HelloWorldOMComponent.java:31)
at 
org.apache.tuscany.binding.axis2.itests.endpoints.AbstractHelloWorldOMTestCase.testCalculator(AbstractHelloWorldOMTestCase.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at

Re: Tomcat errors when trying to build the latest trunk


On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:


I'm seeing lots of Tomcat-related test failures when trying to build
the latest trunk code.  I've done a new checkout and cleaned out my
maven repo.  Here's a sample:

Running org.apache.tuscany.binding.axis2.itests.HelloWorldTestCase
log4j:WARN No appenders could be found for logger (
org.apache.axiom.om.util.StAXUtils).
log4j:WARN Please initialize the log4j system properly.
24-Apr-2007 17:35:17 org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
24-Apr-2007 17:35:18 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
24-Apr-2007 17:35:18 org.apache.catalina.startup.ContextConfigdefaultWebConfig
INFO: No default web.xml
24-Apr-2007 17:35:18 org.apache.catalina.startup.DigesterFactory register
WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd
24-Apr-2007 17:35:18 org.apache.catalina.startup.DigesterFactory register
WARNING: Could not get url for
/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd
24-Apr-2007 17:35:18 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:18 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:19 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.014 sec
Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
Running
org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase
24-Apr-2007 17:35:19 org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
24-Apr-2007 17:35:19 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
24-Apr-2007 17:35:19 org.apache.catalina.startup.ContextConfigdefaultWebConfig
INFO: No default web.xml
24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:23 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
24-Apr-2007 17:35:24 org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
SEVERE: Socket accept failed
java.net.SocketException: socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(
DefaultServerSocketFactory.java:61)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(
JIoEndpoint.java:310)
at java.lang.Thread.run(Thread.java:595)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.168 sec
 FAILURE!
testCalculator(
org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase)  Time
elapsed: 5.137 sec   ERROR!
java.lang.reflect.UndeclaredThrowableException
at $Proxy6.getGreetings(Unknown Source)
at
org.apache.tuscany.binding.axis2.itests.HelloWorldOMComponent.getGreetings
(HelloWorldOMComponent.java:31)
at
org.apache.tuscany.binding.axis2.itests.endpoints.AbstractHelloWorldOMTestCase.testCalculator
(AbstractHelloWorldOMTestCase.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(
OldTestClassRunner.java:35)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)

Re: Tomcat errors when trying to build the latest trunk


You might want to check if you have any http server up or something using
ports 80 or 8080...

On 4/24/07, Simon Laws [EMAIL PROTECTED] wrote:


On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:

 I'm seeing lots of Tomcat-related test failures when trying to build
 the latest trunk code.  I've done a new checkout and cleaned out my
 maven repo.  Here's a sample:

 Running org.apache.tuscany.binding.axis2.itests.HelloWorldTestCase
 log4j:WARN No appenders could be found for logger (
 org.apache.axiom.om.util.StAXUtils).
 log4j:WARN Please initialize the log4j system properly.
 24-Apr-2007 17:35:17 org.apache.catalina.startup.Embedded start
 INFO: Starting tomcat server
 24-Apr-2007 17:35:18 org.apache.catalina.core.StandardEngine start
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
 24-Apr-2007 17:35:18
org.apache.catalina.startup.ContextConfigdefaultWebConfig
 INFO: No default web.xml
 24-Apr-2007 17:35:18 org.apache.catalina.startup.DigesterFactoryregister
 WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd
 24-Apr-2007 17:35:18 org.apache.catalina.startup.DigesterFactoryregister
 WARNING: Could not get url for
 /javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd
 24-Apr-2007 17:35:18 org.apache.coyote.http11.Http11Protocol init
 INFO: Initializing Coyote HTTP/1.1 on http-8080
 24-Apr-2007 17:35:18 org.apache.coyote.http11.Http11Protocol start
 INFO: Starting Coyote HTTP/1.1 on http-8080
 24-Apr-2007 17:35:19 org.apache.catalina.core.StandardWrapper unload
 INFO: Waiting for 1 instance(s) to be deallocated
 24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol destroy
 INFO: Stopping Coyote HTTP/1.1 on http-8080
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.014sec
 Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
 Running

org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase
 24-Apr-2007 17:35:19 org.apache.catalina.startup.Embedded start
 INFO: Starting tomcat server
 24-Apr-2007 17:35:19 org.apache.catalina.core.StandardEngine start
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
 24-Apr-2007 17:35:19
org.apache.catalina.startup.ContextConfigdefaultWebConfig
 INFO: No default web.xml
 24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol init
 INFO: Initializing Coyote HTTP/1.1 on http-8080
 24-Apr-2007 17:35:19 org.apache.coyote.http11.Http11Protocol start
 INFO: Starting Coyote HTTP/1.1 on http-8080
 24-Apr-2007 17:35:23 org.apache.coyote.http11.Http11Protocol destroy
 INFO: Stopping Coyote HTTP/1.1 on http-8080
 24-Apr-2007 17:35:24 org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
 SEVERE: Socket accept failed
 java.net.SocketException: socket closed
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
 at java.net.ServerSocket.implAccept(ServerSocket.java:450)
 at java.net.ServerSocket.accept(ServerSocket.java:421)
 at
 org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(
 DefaultServerSocketFactory.java:61)
 at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(
 JIoEndpoint.java:310)
 at java.lang.Thread.run(Thread.java:595)
 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.168sec
  FAILURE!
 testCalculator(

org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase
)  Time
 elapsed: 5.137 sec   ERROR!
 java.lang.reflect.UndeclaredThrowableException
 at $Proxy6.getGreetings(Unknown Source)
 at

org.apache.tuscany.binding.axis2.itests.HelloWorldOMComponent.getGreetings
 (HelloWorldOMComponent.java:31)
 at

org.apache.tuscany.binding.axis2.itests.endpoints.AbstractHelloWorldOMTestCase.testCalculator
 (AbstractHelloWorldOMTestCase.java:44)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(
 NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(
 DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at junit.framework.TestCase.runTest(TestCase.java:168)
 at junit.framework.TestCase.runBare(TestCase.java:134)
 at junit.framework.TestResult$1.protect(TestResult.java:110)
 at junit.framework.TestResult.runProtected(TestResult.java:128)
 at junit.framework.TestResult.run(TestResult.java:113)
 at junit.framework.TestCase.run(TestCase.java:124)
 at junit.framework.TestSuite.runTest(TestSuite.java:232)
 at junit.framework.TestSuite.run(TestSuite.java:227)
 at org.junit.internal.runners.OldTestClassRunner.run(
 OldTestClassRunner.java:35)
 at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
 JUnit4TestSet.java:62)
 at

Re: Tomcat errors when trying to build the latest trunk


Simon Laws wrote:


On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:



I'm seeing lots of Tomcat-related test failures when trying to build
the latest trunk code.  I've done a new checkout and cleaned out my
maven repo.  Here's a sample:



Is anyone else experiencing this?

   Simon



Hi Simon,

I don't see this but I see the itest lockups later on in the build that
Sebastien also gets.  Did you do a mvn clean also?


It was a fresh checkout so there was no need to do a clean.  The only
things in my local maven repo were the artifacts built by SDO.  I don't
have anything listening on port 80 or 8080.

I did try running the databinding itest with tomcat and it wasn't very 
happy

so switched back to jetty for the time being while chasing the lockup
problem. I know that's not much help to you at the moment but generally
things feel slightly amiss in the web services/app server area to me.


I noticed that these tests now use Tomcat instead of jetty as previously.
How do I switch between Tomcat and jetty?

  Simon



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

Re: Require more context for URLArtifactProcessorExtension.read()


Jean-Sebastien Delfino wrote:

Raymond Feng wrote:

Hi,

I was refering to artifact URI instead of contribution URI. For 
example, if a jar contribution is deployed, the URI of a class named 
a.b.MyClass in the jar will be a/b/MyClass.class.


ContributionContext is one way to pass more context to the 
processors. But I don't think it will go through injection. It should 
be on the method signature of the SPI.


Thanks,
Raymond

- Original Message - From: Luciano Resende 
[EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 17, 2007 1:43 PM
Subject: Re: Require more context for 
URLArtifactProcessorExtension.read()




Hi Raymond

  I'm not sure if the Contribution URI will really work for your
requirements, as of today, the URL that the artifactProcessor 
receives is
the actual artifact URL location, and it's not based on the 
Contribution URI
and also can be normalized based on the contribution package type 
(e.g jar
will have a jar URL). Thinking on the second requirement, if we 
create a

contribution context with some basic contribution information
(e.gcontribution uri, contribution base location, normalized
contribution base
location, and the contribution classloader) and inject it on the
processor, then you would have the necessary information to perform the
necessary actions you need?

  Once we agree on a solution, I can get it implemented.

Thoughts ?

On 4/17/07, Raymond Feng [EMAIL PROTECTED] wrote:


Hi,

I think you already got it right. I want to contribute a processor 
to scan
the classes to figure out available generated SDO factory 
interface/class.

During the read phase, the processor will capture the classname by a
naming pattern. The class will be loaded during resolve phase and 
the

factory will be registered with a HelperContext.

I see two requirements here:
1) read: Pass in the URI of the artifact which can be used to 
derive the

class name
2) resolve: Pass in a contribution classloader which can be used to
resolve
java classes

Thanks,
Raymond

- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 17, 2007 11:22 AM
Subject: Re: Require more context for 
URLArtifactProcessorExtension.read()



 Raymond Feng wrote:
 Hi,

 When I try to add a URLArtifactProcessorExtension to introspect 
java
 classes, I found it impossible to get the class name as only the 
URL  of
 the class file is passed to the read() method. To provide such 
 context,

I
 suggest that we pass in the DeployedArtifact (which contains the 
URL)

 instead of URL to the read() method.

 Do you agree or do you have a better way?

 Thanks,
 Raymond


 Could you give more context as well? :) and describe what you're 
trying

to
 do?

 Are you trying to derive a class name from the file name? Are you 
going

to
 load or read the class file and could you find the class name 
from its

 contents then?

 It's a little difficult to try to answer without more context, 
but in
 general I would prefer for ArtifactProcessors not to have to know 
the
 structure of the Contribution or the DeployedArtifacts that 
represent

it.
 If you need to know the base URL of the contribution and the path 
of  the
 given Artifact inside it, then maybe we could pass these two 
parameters

to
 the read() method, it would be better than passing the whole
 DeployedArtifact and have the read() method dig into it.

 But again, before we do that, could you describe your use case? 
and  then

 hopefully we can find a good solution for it. Thanks.

 --
 Jean-Sebastien


 
-

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



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





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




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




A few thoughts:
- You need the URI of an artifact inside the SCA contribution.
- I indicated before that I needed input/outputStreams as well.
- I think it's useful to have the URL of the contribution to have a 
base URL to load artifacts (for example for WSDLs and XSDs if they do 
import ... location=/aFile.xsd or /aFile.wsdl).


So I suggest read/write(URL contributionURL, String artifactURI, 
Input/OutputStream input/outputStream). In most cases you just use the 
input/outputStream, sometimes you need to know the contributionURL, 
and if you want to know the artifact URL you do new 
URL(contributionURL, artifactURI).


I was thinking that Class loading would be the responsibility of the 
ArtifactResolver. So, we wouldn't need a ClassLoader, we would call 
ArtifactResolver.resolve() to get the Class, like for all other 
artifacts

Re: Require more context for URLArtifactProcessorExtension.read()


I was thinking that Class loading would be the responsibility of the
ArtifactResolver. So, we wouldn't need a ClassLoader, we would call
ArtifactResolver.resolve() to get the Class, like for all other
artifacts resolved in an SCA contribution.


I think that the packageProcessor should be the one creating the necessary
contribution classLoader, but how does the resolver will get a reference to
it ?

I can have it done if you haven't started it yet

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Jean-Sebastien Delfino wrote:
 Raymond Feng wrote:
 Hi,

 I was refering to artifact URI instead of contribution URI. For
 example, if a jar contribution is deployed, the URI of a class named
 a.b.MyClass in the jar will be a/b/MyClass.class.

 ContributionContext is one way to pass more context to the
 processors. But I don't think it will go through injection. It should
 be on the method signature of the SPI.

 Thanks,
 Raymond

 - Original Message - From: Luciano Resende
 [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Tuesday, April 17, 2007 1:43 PM
 Subject: Re: Require more context for
 URLArtifactProcessorExtension.read()


 Hi Raymond

   I'm not sure if the Contribution URI will really work for your
 requirements, as of today, the URL that the artifactProcessor
 receives is
 the actual artifact URL location, and it's not based on the
 Contribution URI
 and also can be normalized based on the contribution package type
 (e.g jar
 will have a jar URL). Thinking on the second requirement, if we
 create a
 contribution context with some basic contribution information
 (e.gcontribution uri, contribution base location, normalized
 contribution base
 location, and the contribution classloader) and inject it on the
 processor, then you would have the necessary information to perform
the
 necessary actions you need?

   Once we agree on a solution, I can get it implemented.

 Thoughts ?

 On 4/17/07, Raymond Feng [EMAIL PROTECTED] wrote:

 Hi,

 I think you already got it right. I want to contribute a processor
 to scan
 the classes to figure out available generated SDO factory
 interface/class.
 During the read phase, the processor will capture the classname by
a
 naming pattern. The class will be loaded during resolve phase and
 the
 factory will be registered with a HelperContext.

 I see two requirements here:
 1) read: Pass in the URI of the artifact which can be used to
 derive the
 class name
 2) resolve: Pass in a contribution classloader which can be used to
 resolve
 java classes

 Thanks,
 Raymond

 - Original Message -
 From: Jean-Sebastien Delfino [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Tuesday, April 17, 2007 11:22 AM
 Subject: Re: Require more context for
 URLArtifactProcessorExtension.read()


  Raymond Feng wrote:
  Hi,
 
  When I try to add a URLArtifactProcessorExtension to introspect
 java
  classes, I found it impossible to get the class name as only the
 URL  of
  the class file is passed to the read() method. To provide such
  context,
 I
  suggest that we pass in the DeployedArtifact (which contains the
 URL)
  instead of URL to the read() method.
 
  Do you agree or do you have a better way?
 
  Thanks,
  Raymond
 
 
  Could you give more context as well? :) and describe what you're
 trying
 to
  do?
 
  Are you trying to derive a class name from the file name? Are you
 going
 to
  load or read the class file and could you find the class name
 from its
  contents then?
 
  It's a little difficult to try to answer without more context,
 but in
  general I would prefer for ArtifactProcessors not to have to know
 the
  structure of the Contribution or the DeployedArtifacts that
 represent
 it.
  If you need to know the base URL of the contribution and the path
 of  the
  given Artifact inside it, then maybe we could pass these two
 parameters
 to
  the read() method, it would be better than passing the whole
  DeployedArtifact and have the read() method dig into it.
 
  But again, before we do that, could you describe your use case?
 and  then
  hopefully we can find a good solution for it. Thanks.
 
  --
  Jean-Sebastien
 
 
 
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 


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




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



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



 A few thoughts:
 - You need the URI of an artifact inside the SCA contribution.
 - I indicated before that I needed input/outputStreams as well.
 - I think it's useful to have the URL of the contribution to have a
 base URL to load artifacts (for

Re: [jira] Updated: (TUSCANY-1218) java.net.ConnectException: Connection refused: connect when building binding-ws-axis2

2007-04-24 Thread Kevin Williams


I am also having trouble with this test case although I am not seeing a
timeout:

Running org.apache.tuscany.sca.itest.SDOWSDLTestCase
java.lang.reflect.InvocationTargetException
   at org.apache.tuscany.binding.axis2.Axis2ServiceBinding.invokeTarget
(Axi
s2ServiceBinding.java:249)
   at
org.apache.tuscany.binding.axis2.Axis2ServiceInOutSyncMessageReceiver
.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:54)
   at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(A
bstractInOutSyncMessageReceiver.java:39)
   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:497)
   at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
uest(HTTPTransportUtils.java:328)

On 4/23/07, Simon Nash [EMAIL PROTECTED] wrote:


Ant,
Thanks for committing this.  I'll do a new checkout and see if
I can recreate the other problem.

   Simon

ant elder wrote:

 I've tried this and it fixes all the problems I've been having with
 building
 the Axis2 binding, before building the binding would usually fail, now
so
 far its worked every time, so I've committed the fix. However, I do now
get
 am intermittent read timeout in the SDOWSDLTestCase itest which looks
 possibly related. This is a new test so I'm not sure if its failing
worse
 than without this fix applied. Could others say the SDOWSDLTestCase is
 working ok or if they're seeing any failures?

 Thanks,

   ...ant

 On 4/21/07, Simon Nash (JIRA) tuscany-dev@ws.apache.org wrote:



  [

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

 ]

 Simon Nash updated TUSCANY-1218:
 

 Attachment: patch-1218

 After extensive investigation including tracing all WinSock API calls,
it
 appears that the problem is caused by client-side connections and
sockets
 not being released when they are no longer in use.  By default,
 commons-httpclient uses SimpleHttpConnectionManager which creates a new
 connection for every request and does not track connections or release
 them
 later.  Setting the Axis2 REUSE_HTTP_CLIENT property causes
 commons-httpclient to use MultiThreadedHttpConnectionManager instead,
 which
 tracks connections and has a shutdown() method that releases all
 connections.

 This patch modifies Axis2TargetInvoker to set REUSE_HTTP_CLIENT.  The
 other part of the fix is to ensure that
 MultiThreadedHttpConenctionManager.shutdown() gets called at the
correct
 time.  For now I have modified Axis2ModuleActivator,
 Axis2BindingBuilder and
 Axis2ReferenceBinding to call this method when the Axis2 binding
 extension
 is unloaded.  This solves the problem for the tests used by the build,
 but
 it isn't a complete solution since shutdown() won't be called when an
 Axis2
 reference binding is removed without the Axis2 extension being
 unloaded.  Further investigation is needed to determine the correct
 point to
 call  the MultiThreadedHttpConenctionManager.shutdown()  method in all
 scenarios.

 I also updated Axis2ServiceBinding to remove the now obsolete @Destroy
 annotation on the stop() method, and I updated the pom.xml for
 binding-ws-axis2 to change the dependency on commons-httpclient from
 runtime
 to compile (needed because of the change to Axis2ReferenceBinding).

 I have tested this change on my machine and it resolves the build
problem
 with no apparent adverse side-effects.

  java.net.ConnectException: Connection refused: connect when building
 binding-ws-axis2
 

-

 
  Key: TUSCANY-1218
  URL:
https://issues.apache.org/jira/browse/TUSCANY-1218
  Project: Tuscany
   Issue Type: Bug
   Components: Java SCA Axis Binding
 Affects Versions: Java-SCA-Next
  Environment: Windows XP
 Reporter: Simon Nash
  Assigned To: Simon Nash
  Fix For: Java-SCA-Next
 
  Attachments: patch-1218
 
 
  When building java/sca from the trunk, the following error occurs:
  ---
   T E S T S
  ---
  Running org.apache.tuscany.binding.axis2.itests.HelloWorldTestCase
  log4j:WARN No appenders could be found for logger (
 org.apache.axiom.om.util.StAXUtils).
  log4j:WARN Please initialize the log4j system properly.
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.52
 sec
  Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase
  Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01
 sec
  Running

org.apache.tuscany.binding.axis2.itests.endpoints.WSDLRelativeURITestCase
  Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
 3.975sec
  Running org.apache.tuscany.binding.axis2.itests.HelloWorldOMTestCase
  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:

Re: Tomcat errors when trying to build the latest trunk

2007-04-24 Thread Kevin Williams


Now, I am getting the Connection refused error:

INFO: Stopping Coyote HTTP/1.1 on http-8586
Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.ContextConfigdefaultWebCon
fig
INFO: No default web.xml
Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8586
Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8586
Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686 sec
 FA
ILURE!
testRequestSession(org.apache.tuscany.http.tomcat.TomcatServerTestCase)
Time el
apsed: 1.082 sec   ERROR!
java.net.ConnectException: Connection refused: connect
   at java.net.PlainSocketImpl.socketConnect(Native Method)
   at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372)
   at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java
:233)
   at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220)
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378)
   at java.net.Socket.connect(Socket.java:536)
   at java.net.Socket.connect(Socket.java:486)
   at java.net.Socket.init(Socket.java:394)
   at java.net.Socket.init(Socket.java:207)
   at
org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio
n(TomcatServerTestCase.java:87)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:43)

On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:


Simon Laws wrote:

 On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:


 I'm seeing lots of Tomcat-related test failures when trying to build
 the latest trunk code.  I've done a new checkout and cleaned out my
 maven repo.  Here's a sample:

 

 Is anyone else experiencing this?

Simon


 Hi Simon,

 I don't see this but I see the itest lockups later on in the build that
 Sebastien also gets.  Did you do a mvn clean also?

It was a fresh checkout so there was no need to do a clean.  The only
things in my local maven repo were the artifacts built by SDO.  I don't
have anything listening on port 80 or 8080.

 I did try running the databinding itest with tomcat and it wasn't very
 happy
 so switched back to jetty for the time being while chasing the lockup
 problem. I know that's not much help to you at the moment but generally
 things feel slightly amiss in the web services/app server area to me.

I noticed that these tests now use Tomcat instead of jetty as previously.
How do I switch between Tomcat and jetty?

   Simon



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

Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)


ant elder wrote:

What are we going to be calling this next SCA release?

We've had M1 and M2 releases, some alpha kernel releases, DAS are talking
about an M3 release and SDO is doing an M3 release although there was 
some
discussion about renaming that to beta1. I think milestone and alpha 
release

names may discourage people from trying a release as it makes it sound
unstable. The spec defined SCA APIs are stable now and we're talking 
about

making stable SPIs for this next release, so the Tuscany externals are
becoming stable and that sounds better than alpha quality to me.

So how about the next Tuscany SCA release is named beta1? and we could 
try

to get DAS and SDO to also follow that naming?

Any comments or alternative name suggestions?

  ...ant



Good idea, beta1 makes sense to me as APIs and SPIs are getting stable, 
as is our support for the SCA assembly XML described in the SCA 1.0 spec.


+1 from me.

--
Jean-Sebastien


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

Build runtime wire/invocation chains for a composite hierarchy


Hi,

I'm trying to indentify all the paths of SCA component interactions which 
require to have runtime wires/invocation chains.


By the SCA spec, there are three cases for the wiring:

1) Component.Reference (A.ref1) --is wired to-- Component.Service (B.svc1)
--
1.1) If both the service and reference are defined by non-composite 
components, then the runtime wire is as simple as A.ref1--B.svc1.


1.2) If the service is defined on a composite component, then it can be 
further resolved to the orginal atomic component service following the 
service promotion chain.


For example, A.ref1 -- B.svc1 (B is implemented by another composite and 
B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 -- C.svc1


1.3) If the reference is defined on a composite component, then it can be 
further resolved to the orginal atomic component reference following the 
reference promotion chain.


For example, A.ref1 -- B.svc1 (A is implemented by another composite and 
A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 -- B.svc1


2) Composite.Reference (Composite1.ref1) --promotes-- Component.Reference 
(B.ref1)

-
If Composite1 is the top-level composite, and the B is a non-composite 
component, then the runtime wire will be: B.ref1 -- Composite1.ref1


If Composite1 is used to implement a component A in Composite2, then we need 
to futher check if A.ref1 is promoted or wired until we hit the end of the 
promotion chain. The final target will be either a composite reference or a 
component service that the out-most reference is wired to. For example, if 
A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 -- 
D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is 
B.ref1 -- Composite2.ref1.


If B is a composite component, then we need to find out the final component 
reference that B.ref1 promotes. For example, it promotes D.ref1, then the 
runtime wire is D.ref1 -- C.ref1


3) Composite.Service (Composite1.svc1) --promotes-- Component.Service 
(A.svc1)

---
The source will be the outmost service on the promotion chain.  For example, 
if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then 
it is Composite2.svc1.


The target will be the innermost service on the promotion chain. For 
example, if A is implemented by Composite3 and Composite3.svc1 promotes 
C.svc1, then it is C.svc1.


* Please note, due to the spec limitation, the composite service cannot 
promote a composite reference directly.


Based on the above scenarios, it seems that we can create runtime wires 
using the following algorithm (assuming multiplicity = 1..1). The key is to 
get a final list of targets and selected bindings.


1) Runtime wire for references: For each of the references (r1) on 
non-composite components, find the outmost reference (r0) on the reference 
promotion chain. Then get the targets and selected bindings from r0. If SCA 
binding is used for a target, it can be further optimized to use the 
orginally promoted component service. The runtime wire should be created 
between the r1 and a target (either a component service with SCA binding or 
a reference binding) from r0.


2) Runtime wire for service promotions: For each of the service1 (s1) on 
non-composite components, find the outmost service (s0, can be the same as 
s1) on the service promotion chain. Create a runtime wire between the 
selected binding of s0 and the component that defines s1. (Can we assume 
that s1 is always local to s0?)


The service/reference promotions make the picture complicated. I hope my 
thought makes sense.


Thanks,
Raymond


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

Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)


+1

As for DAS, as it has dependencies on SDO, I'd propose to follow the same
name convention as SDO, and use beta1 as well.

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


ant elder wrote:
 What are we going to be calling this next SCA release?

 We've had M1 and M2 releases, some alpha kernel releases, DAS are
talking
 about an M3 release and SDO is doing an M3 release although there was
 some
 discussion about renaming that to beta1. I think milestone and alpha
 release
 names may discourage people from trying a release as it makes it sound
 unstable. The spec defined SCA APIs are stable now and we're talking
 about
 making stable SPIs for this next release, so the Tuscany externals are
 becoming stable and that sounds better than alpha quality to me.

 So how about the next Tuscany SCA release is named beta1? and we could
 try
 to get DAS and SDO to also follow that naming?

 Any comments or alternative name suggestions?

   ...ant


Good idea, beta1 makes sense to me as APIs and SPIs are getting stable,
as is our support for the SCA assembly XML described in the SCA 1.0 spec.

+1 from me.

--
Jean-Sebastien


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





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

Re: Tomcat errors when trying to build the latest trunk


On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:


Simon Laws wrote:

 On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:


 I'm seeing lots of Tomcat-related test failures when trying to build
 the latest trunk code.  I've done a new checkout and cleaned out my
 maven repo.  Here's a sample:

 

 Is anyone else experiencing this?

Simon


 Hi Simon,

 I don't see this but I see the itest lockups later on in the build that
 Sebastien also gets.  Did you do a mvn clean also?

It was a fresh checkout so there was no need to do a clean.  The only
things in my local maven repo were the artifacts built by SDO.  I don't
have anything listening on port 80 or 8080.

 I did try running the databinding itest with tomcat and it wasn't very
 happy
 so switched back to jetty for the time being while chasing the lockup
 problem. I know that's not much help to you at the moment but generally
 things feel slightly amiss in the web services/app server area to me.

I noticed that these tests now use Tomcat instead of jetty as previously.
How do I switch between Tomcat and jetty?

   Simon



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

I changed the dependency in the pom from http-tomcat to http-jetty.


Simon

Re: Native M3 Release


Pete Robbins wrote:

The IPMC has found an issue with a missing notice in the SDO C++ source
release being voted on. To fix this I can either remove the offending 
file
or update the Notice text. After re-building the distro to include 
this fix

do I need to hold another vote here for this release?

Cheers,



Pete,

I'm not sure if another vote is required here as the change is very 
minor and documented in [1]. Let's see what the IPMC folks say as you've 
asked the same question on the general-incubator list. I have checked 
the updated RC4 distros anyway (on Linux) and they look OK to me, so if 
there's another vote it gets my +1.


[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg13663.html

--
Jean-Sebastien


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

Re: Tomcat errors when trying to build the latest trunk


[snip]
Simon Laws wrote:


I did try running the databinding itest with tomcat and it wasn't very 
happy


Simon, what exceptions are you getting when running the databinding 
itest with tomcat? do you have a log?


Thanks.

--
Jean-Sebastien


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

Re: Nominate Ant as the release manager was: Re: [DISCUSS] Next version - What should be in it


Luciano Resende wrote:

+1 I make Simon's words my words too...

On 4/24/07, Raymond Feng [EMAIL PROTECTED] wrote:


+1. I would like to nominate Ant too.

Thanks,
Raymond

- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 4:32 AM
Subject: Re: [DISCUSS] Next version - What should be in it


 How about Ant as release manager for this release?  He has been very
 diligent in reviewing previous Tuscany releases with many helpful
 comments.  He has a good understanding of the Apache requirements
 and process for publishing a release, and I think he is very well
 qualified to take this on.

   Simon

 Raymond Feng wrote:

 Hi,

 After evaluating the features I would like to contribute to this
release
 in the short timeframe, I don't think I would have enough time to
handle
 the release as I'm new to this process. I would appreciate if 
somebody

 else with more experience volunteers to be the release manager. This
way,
 I can learn more and get ready for the next time.

 Thanks,
 Raymond

 - Original Message - From: Luciano Resende
 [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Friday, April 20, 2007 10:25 AM
 Subject: Re: [DISCUSS] Next version - What should be in it


 +1 on focusing on the stability and consumability for the core
 functions,
 other then helping on simplifying the runtime further and work on a
 Domain
 concept, I also want to contribute around having a better 
integration

 with
 App Servers, basically start by bringing back WAR plugin and TC
 integration.

 +1 on Raymond as Release Manager

 On 4/20/07, Raymond Feng [EMAIL PROTECTED] wrote:


 Hi,

 Considering that we want to achieve this in about 3 weeks, I agree
that
 we
 focus on the stability and consumability for the core functions.

 Other additional features are welcome. We can decide if they 
will be

 part
 of
 the release based on the readiness.

 Are any of you going to volunteer to be the release manager? If 
not,

I
 can
 give a try.

 Thanks,
 Raymond

 - Original Message -
 From: Jean-Sebastien Delfino [EMAIL PROTECTED]
 To: tuscany-dev@ws.apache.org
 Sent: Wednesday, April 18, 2007 6:07 PM
 Subject: Re: [DISCUSS] Next version - What should be in it


  Davanum Srinivas wrote:
  Folks,
 
  Let's keep the ball rolling...Can someone please come up with a
 master
  list of extensions, bindings, services, samples which can then
  help
  decide what's going to get into the next release. Please start a
  wiki
  page to document the master list. Once we are done 
documenting the

  list. We can figure out which ones are MUST, which ones are nice
to
  have, which ones are out of scope. Then we can work backwards to
  figure out How tightly or loosely coupled each piece 
is/should be

  and
  how we could decouple them if necessary using
  interfaces/spi/whatever...
 
  Quote from Bert Lamb:
  I think there should be a voted upon core set of extensions,
  bindings, services, samples, whatever that should be part of a
  monolithic build.
 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html
 
  Quote from Ant Elder:
  The specifics of what extensions are included in this release is
  left
 out
  of
  this vote and can be decided in the release plan discussion. All
  this
  vote
  is saying is that all the modules that are to be included in 
this

 next
  release will have the same version and that a top level 
pom.xmlwill

  exist
  to enable building all those modules at once.
 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html
 
  Thanks,
  dims
 
 
 
  Hi all,
 
  I think we have made good progress since we initially started 
this

  discussion. We have a simpler structure in trunk with a working 
 top-down
  build. Samples and integration tests from the integration branch
have
 been
  integrated back in trunk and most are now working.
 
  We have a more modular runtime with a simpler extension 
mechanism.

  For
  example we have separate modules for the various models, the core
 runtime
  and the Java component support. SPIs between the models and the
 rest of
  the runtime have been refactored and should become more 
stable. We

 need
 to
  do more work to further simplify the core runtime SPIs and 
improve

  the
  core runtime but I think this is going in the right direction.
 
  I'm also happy to see better support for the SCA 1.0 spec, with
 support
  for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 
APIs.

  It
  looks like extensions are starting to work again in the trunk, 
 including
  Web Services, Java and scripting components. It shouldn't be too
 difficult
  to port some of the other extensions - Spring, JMS, JSON-RPC 
-  to

  the
  latest code base as well.
 
  So, the JavaOne conference is in three weeks, would it make sense
 to  try
  to have a Tuscany release by then?
 
  We could integrate in that release what we already have 
working in

 trunk,
  mature and

Re: Tomcat errors when trying to build the latest trunk


On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


[snip]
Simon Laws wrote:

 I did try running the databinding itest with tomcat and it wasn't very
 happy

Simon, what exceptions are you getting when running the databinding
itest with tomcat? do you have a log?

Thanks.

--
Jean-Sebastien


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

Yep, i copied the start of it below. I'm not looking at  this at the

moment. I glanced at it and assumed I'd missed some extra dependency out in
switching to tomcat. I switched back to jetty where it used to work and am
currently trying to work out why the recent axis changes are now causing
this lockup problem. I can't prove yet that the error below doesn't happen
on Jetty.

24-Apr-2007 20:24:44 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
24-Apr-2007 20:24:44 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
24-Apr-2007 20:24:45 org.apache.axis2.deployment.URLBasedAxisConfiguratorgetAxi
sConfiguration
INFO: No repository found , module will be loaded from classpath
org.apache.tuscany.databinding.TransformationException:
java.lang.RuntimeExcepti
on: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with
uri
'http://apache.org/tuscany/sca/itest/databinding/types' not found.
   at
org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfo
rm(XMLStreamReader2DataObject.java:48)
   at
org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfo
rm(XMLStreamReader2DataObject.java:34)
   at org.apache.tuscany.databinding.impl.MediatorImpl.mediate
(MediatorImpl
.java:83)
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransform
er.transform(Input2InputTransformer.java:169)
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransform
er.transform(Input2InputTransformer.java:46)
   at org.apache.tuscany.databinding.impl.MediatorImpl.mediate
(MediatorImpl
.java:83)
   at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.transf
orm(DataBindingInteceptor.java:189)
   at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:86)
   at org.apache.tuscany.binding.axis2.Axis2ServiceBinding.invokeTarget
(Axi
s2ServiceBinding.java:246)
   at
org.apache.tuscany.binding.axis2.Axis2ServiceInOutSyncMessageReceiver
.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:54)
   at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(A
bstractInOutSyncMessageReceiver.java:39)
   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:497)
   at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
uest(HTTPTransportUtils.java:328)
   at org.apache.axis2.transport.http.AxisServlet.doPost(
AxisServlet.java:2
54)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

Simon

Re: Tomcat errors when trying to build the latest trunk


[snip]
Kevin Williams wrote:

Now, I am getting the Connection refused error:

INFO: Stopping Coyote HTTP/1.1 on http-8586
Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
Apr 24, 2007 12:31:07 PM 
org.apache.catalina.startup.ContextConfigdefaultWebCon

fig
INFO: No default web.xml
Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8586
Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8586
Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686 sec
 FA
ILURE!
testRequestSession(org.apache.tuscany.http.tomcat.TomcatServerTestCase)
Time el
apsed: 1.082 sec   ERROR!
java.net.ConnectException: Connection refused: connect
   at java.net.PlainSocketImpl.socketConnect(Native Method)
   at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372)
   at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java
:233)
   at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220)
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378)
   at java.net.Socket.connect(Socket.java:536)
   at java.net.Socket.connect(Socket.java:486)
   at java.net.Socket.init(Socket.java:394)
   at java.net.Socket.init(Socket.java:207)
   at
org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio
n(TomcatServerTestCase.java:87)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:43)



Kevin,

This one is interesting as it's an isolated Tomcat test case, not even 
involving integration with the Web Service binding. I suspect a timing 
issue, where Tomcat is returning from the start method before it's 
actually ready to accept requests. I'm going to investigate it but have 
question: Are you able to reproduce this problem when running mvn from 
the http-tomcat directory? or are you only running into it when building 
the whole trunk?


Thanks

--
Jean-Sebastien


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

Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)

+1.

Thanks,
Raymond

- Original Message - 
From: Luciano Resende [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 12:07 PM
Subject: Re: Next release name? (was: Re: [DISCUSS] Next version - What 
should be in it)

+1

As for DAS, as it has dependencies on SDO, I'd propose to follow the same
name convention as SDO, and use beta1 as well.

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

ant elder wrote:
 What are we going to be calling this next SCA release?

 We've had M1 and M2 releases, some alpha kernel releases, DAS are
talking
 about an M3 release and SDO is doing an M3 release although there was
 some
 discussion about renaming that to beta1. I think milestone and alpha
 release
 names may discourage people from trying a release as it makes it sound
 unstable. The spec defined SCA APIs are stable now and we're talking
 about
 making stable SPIs for this next release, so the Tuscany externals are
 becoming stable and that sounds better than alpha quality to me.

 So how about the next Tuscany SCA release is named beta1? and we could
 try
 to get DAS and SDO to also follow that naming?

 Any comments or alternative name suggestions?

   ...ant

Good idea, beta1 makes sense to me as APIs and SPIs are getting stable,
as is our support for the SCA assembly XML described in the SCA 1.0 spec.

+1 from me.

--
Jean-Sebastien

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

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

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

Re: Website - Feedback please

2007-04-24 Thread haleh mahbod


Hello,

Sorry for the delay. Got busy with day to day job.
Thanks for your feedback.



 Need diagrams - we had some nice ones from sebastien and from the old

site that we can use in various places

Please go ahead and add diagrams that you see fit.

 Home - Move the page round to make the first thing the statement about
what it
does rather than about incubation.
DONE.


- Have a a breaking new section on the bottom of the first page to report
the last 3 or so significant events, i.e. provide links directly to the
latest releases.

I find this information to be too much on the overview/home page.  Visitor
can find the info on the news and event link or download link.  However, if
this is a common suggestion, I'll add it in.


News and Events
Appears in General and Community

Fixed

Separate upcoming events and news into events and news

Done


SCA
Java SCA
Java SCA Subproject? Why subproject in the title of this page.

Done


 I like the list of modules I think we should go with the module name
from the code and link to a separate
  page for each one. (take a look I've made an example). We can then use
URLs such as
   http://cwiki.apache.org/confluence/display/TUSCANY/binding-ws to refer
directly to the module description(*)

The idea that I was trying to promote with the website was to progressively
disclose information that visitor wants to know about. They choose to learn
more if they want to.  SCA Java page is a high level view of the SCA Java
project. I agree that module information is good. As Ant suggested a better
place for this information might be  the architecture guide  or  developer
guide.

One problem that I see with these module pages is its upkeep and the effort
to provide content. We already have many links to guides that are in need of
content.

  Architecture Guide
  still pointing to the old one

Yes, content needs to be updated by those knowledgeable in this area.


   - I still think there should be a developer guide as it fits well

under

the guide section. So how about
 Guides
  User Guide
Architecture Guide
Developer Guide
 Resources
Source code
Java Doc


Good idea. Adopted this for all the projects.



- SDO
- SDO Java
- has an issue management section under development

It was there. Need to check with SDO team on this one.


- DAS
- seems to be in a slightly different format. We have Java and C++
implementations underway so we could follow the patter of SCA and SDO.

There are different flavors of DAS regardless of  each being implemented in
C++ or Java.
The presentation of that page is more geared towards the type of DAS
(support for end sources) that are available than in what language the DAS
is implemented in.
What is your suggestion for DAS page?


On 4/20/07, ant elder [EMAIL PROTECTED] wrote:


On 4/20/07, Simon Laws [EMAIL PROTECTED] wrote:

snip/

2/ Developer guide
 This comment was just stating a preference. I just liked the idea of
 having
 a user guide and a developer guide. I felt that getting involved
sounded
 like it should be talking about mail lists and irc's etc rather than the
 details of the development process. If people are generally happy with
the
 getting involved then its far more important to get the content there
than
 debate what it's called ;-)


I like having all three -  user guides, developer guides and a getting
involved page. The getting involved page could be a general Tuscany
project
level thing  about the project mailing lists, IRC, Apache conventions etc.
The user and developer guides could be sub-project specific so individual
ones for DAS, SCA, and SDO.

   ...ant

Re: Tomcat errors when trying to build the latest trunk


Hi, Simon.

The exception seems to be caused by missing SDO metadata in the 
HelperContext when the transformation is performed. Can you make sure the 
import.sdo is used to define the SDO types?


Thanks,
Raymond

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

To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 12:30 PM
Subject: Re: Tomcat errors when trying to build the latest trunk



On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


[snip]
Simon Laws wrote:

 I did try running the databinding itest with tomcat and it wasn't very
 happy

Simon, what exceptions are you getting when running the databinding
itest with tomcat? do you have a log?

Thanks.

--
Jean-Sebastien


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

Yep, i copied the start of it below. I'm not looking at  this at the
moment. I glanced at it and assumed I'd missed some extra dependency out 
in

switching to tomcat. I switched back to jetty where it used to work and am
currently trying to work out why the recent axis changes are now causing
this lockup problem. I can't prove yet that the error below doesn't happen
on Jetty.

24-Apr-2007 20:24:44 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
24-Apr-2007 20:24:44 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
24-Apr-2007 20:24:45 
org.apache.axis2.deployment.URLBasedAxisConfiguratorgetAxi

sConfiguration
INFO: No repository found , module will be loaded from classpath
org.apache.tuscany.databinding.TransformationException:
java.lang.RuntimeExcepti
on: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package 
with

uri
'http://apache.org/tuscany/sca/itest/databinding/types' not found.
   at
org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfo
rm(XMLStreamReader2DataObject.java:48)
   at
org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfo
rm(XMLStreamReader2DataObject.java:34)
   at org.apache.tuscany.databinding.impl.MediatorImpl.mediate
(MediatorImpl
.java:83)
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransform
er.transform(Input2InputTransformer.java:169)
   at
org.apache.tuscany.core.databinding.transformers.Input2InputTransform
er.transform(Input2InputTransformer.java:46)
   at org.apache.tuscany.databinding.impl.MediatorImpl.mediate
(MediatorImpl
.java:83)
   at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.transf
orm(DataBindingInteceptor.java:189)
   at
org.apache.tuscany.core.databinding.wire.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:86)
   at 
org.apache.tuscany.binding.axis2.Axis2ServiceBinding.invokeTarget

(Axi
s2ServiceBinding.java:246)
   at
org.apache.tuscany.binding.axis2.Axis2ServiceInOutSyncMessageReceiver
.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:54)
   at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(A
bstractInOutSyncMessageReceiver.java:39)
   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:497)
   at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
uest(HTTPTransportUtils.java:328)
   at org.apache.axis2.transport.http.AxisServlet.doPost(
AxisServlet.java:2
54)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

Simon




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

Re: Require more context for URLArtifactProcessorExtension.read()


Luciano Resende wrote:

I was thinking that Class loading would be the responsibility of the
ArtifactResolver. So, we wouldn't need a ClassLoader, we would call
ArtifactResolver.resolve() to get the Class, like for all other
artifacts resolved in an SCA contribution.


I think that the packageProcessor should be the one creating the 
necessary
contribution classLoader, but how does the resolver will get a 
reference to

it ?

I can have it done if you haven't started it yet



I have started to put together a class that we can use as a key to 
resolve classes, I'll commit it soon and then if you want I leave the 
rest to you :)


With respect to passing a classloader to the DefaultArtifactResolver, 
here's what I think: SimpleRuntimeImpl currently creates a single 
DefaultArtifactResolver, independent of any SCA Contribution. This works 
for now as SimpleRuntimeImpl only handles a single Contribution, but 
what we really need is:

- one ArtifactResolver per Contribution
- one ClassLoader per Contribution
- and the ArtifactResolver can get the Contribution's ClassLoader passed 
to its constructor.


I'm not sure if having the PackageProcessor create the ClassLoader is 
the best solution as the hosting environment needs to have a say with 
respect to which ClassLoader is used for what, but I guess we can start 
with that approach at least now to make progress, and change later when 
we have a better idea of how this fits with the various hosting 
environments.


--
Jean-Sebastien


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

Re: Require more context for URLArtifactProcessorExtension.read()


Comments inline...

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Luciano Resende wrote:
 I was thinking that Class loading would be the responsibility of the
 ArtifactResolver. So, we wouldn't need a ClassLoader, we would call
 ArtifactResolver.resolve() to get the Class, like for all other
 artifacts resolved in an SCA contribution.

 I think that the packageProcessor should be the one creating the
 necessary
 contribution classLoader, but how does the resolver will get a
 reference to
 it ?

 I can have it done if you haven't started it yet


I have started to put together a class that we can use as a key to
resolve classes, I'll commit it soon and then if you want I leave the
rest to you :)

With respect to passing a classloader to the DefaultArtifactResolver,
here's what I think: SimpleRuntimeImpl currently creates a single
DefaultArtifactResolver, independent of any SCA Contribution. This works
for now as SimpleRuntimeImpl only handles a single Contribution, but
what we really need is:
- one ArtifactResolver per Contribution



How are you going to resolve things external to the contribution then ?
Let's say on the case of import/exports ?

- one ClassLoader per Contribution


+1

- and the ArtifactResolver can get the Contribution's ClassLoader passed

to its constructor.



+1

I'm not sure if having the PackageProcessor create the ClassLoader is

the best solution as the hosting environment needs to have a say with
respect to which ClassLoader is used for what, but I guess we can start
with that approach at least now to make progress, and change later when
we have a better idea of how this fits with the various hosting
environments.

--
Jean-Sebastien


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





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

Re: Tomcat errors when trying to build the latest trunk


Jean-Sebastien Delfino wrote:


To switch to Jetty, in modules/binding-ws-axis2/pom.xml change 
tuscany-http-tomcat to tuscany-http-jetty.


I am not seeing these errors on Linux.


I made this change and I got a clean build on Windows.  I'll try to
find out more about why I get so many problems when I use Tomcat.

  Simon



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

Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)


I agree that beta1 sounds good and will encourage people to try
Tuscany because it seems like a stable release (more so than our
previous releases and attempted releases).  And in terms of SCA
spec APIs, I think we are pretty much at beta level currently.
I would also regard the SDO implementation and APIs as being at
beta level.

However... I have some concerns about whether we can truly describe
our current SCA implementation as being at beta level.  If we are
going to put beta on the outside of the box, then we had better make
sure that beta code is inside the box as well.  In the last few
weeks we have been through very significant changes in the codebase.
The progress has been remarkable, and the changes have been very
positive, but there are still a few loose bits hanging out. One
example of this is the lifecycle issues that I raised a few days ago.
Another is the problems that people are currently having with
Tomcat and Web Services.  So I don't think what we have today is
quite at the level of stability, completeness and quality that truly
justifies a beta designation, and realistically I am not sure that
we will be able to get the code to that point in the next week and
be able to put out a beta quality release by JavaOne.

So I think it comes down to whether it is more important to put
something out by JavaOne (in which case I'd be hesitant to call it
beta) or whether it is more important to attain a true beta level
of quality even if that takes a little bit longer.

  Simon

Raymond Feng wrote:


+1.

Thanks,
Raymond

- Original Message - From: Luciano Resende [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, April 24, 2007 12:07 PM
Subject: Re: Next release name? (was: Re: [DISCUSS] Next version - What 
should be in it)




+1

As for DAS, as it has dependencies on SDO, I'd propose to follow the same
name convention as SDO, and use beta1 as well.

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:



ant elder wrote:
 What are we going to be calling this next SCA release?

 We've had M1 and M2 releases, some alpha kernel releases, DAS are
talking
 about an M3 release and SDO is doing an M3 release although there was
 some
 discussion about renaming that to beta1. I think milestone and alpha
 release
 names may discourage people from trying a release as it makes it sound
 unstable. The spec defined SCA APIs are stable now and we're talking
 about
 making stable SPIs for this next release, so the Tuscany externals are
 becoming stable and that sounds better than alpha quality to me.

 So how about the next Tuscany SCA release is named beta1? and we could
 try
 to get DAS and SDO to also follow that naming?

 Any comments or alternative name suggestions?

   ...ant


Good idea, beta1 makes sense to me as APIs and SPIs are getting stable,
as is our support for the SCA assembly XML described in the SCA 1.0 
spec.


+1 from me.

--
Jean-Sebastien


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





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

Re: Require more context for URLArtifactProcessorExtension.read()


More comments inline.

Luciano Resende wrote:

Comments inline...

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Luciano Resende wrote:
 I was thinking that Class loading would be the responsibility of the
 ArtifactResolver. So, we wouldn't need a ClassLoader, we would call
 ArtifactResolver.resolve() to get the Class, like for all other
 artifacts resolved in an SCA contribution.

 I think that the packageProcessor should be the one creating the
 necessary
 contribution classLoader, but how does the resolver will get a
 reference to
 it ?

 I can have it done if you haven't started it yet


I have started to put together a class that we can use as a key to
resolve classes, I'll commit it soon and then if you want I leave the
rest to you :)

With respect to passing a classloader to the DefaultArtifactResolver,
here's what I think: SimpleRuntimeImpl currently creates a single
DefaultArtifactResolver, independent of any SCA Contribution. This works
for now as SimpleRuntimeImpl only handles a single Contribution, but
what we really need is:
- one ArtifactResolver per Contribution



How are you going to resolve things external to the contribution then ?
Let's say on the case of import/exports ?

- one ClassLoader per Contribution


+1



Good question, the short answer is: it depends... :)

My first cut of this email was actually saying or a ClassLoader per 
contribution graph when/if we support contribution dependencies at some 
point, but I removed that sentence before sending it for a number of 
reasons, including:


- Imports/exports do not cover classes at the moment, they cover XML 
namespaces, if we want to cover imports of Java artifacts we'll have to 
introduce a new import.java for example, and clearly define what it means


- Imports/exports do not point to contributions, they point to location 
URIs, which can take any form, can be resolved in a runtime specific 
way, and point to other contributions, or not :)


- An obvious way to support Java imports and Contribution dependency 
graphs for Java artifacts would be to use OSGI, but then maintaining a 
graph of ClassLoaders ourselves would probably get in the way of OSGI, 
and it may be much simpler to let OSGI maintain the ClassLoader graph 
and have our runtime just point to the top bundle ClassLoader, or not :) 
I guess we'll have to figure this out when we look at this integration 
in details again.


- Finally, I think that the hosting environment has a role to play to 
establish, select and maintain ClassLoaders. Different hosting 
environments will probably come with very different ClassLoader 
management schemes.


So I think that there are enough unknowns here to not try to boil the 
ocean with our own homegrown ClassLoader hierarchy management scheme 
right now... and suggest to start simple with one ClassLoader per SCA 
Contribution. We can define the semantics of an import.java extension 
to the spec later, assuming that we even need that, and worry about how 
that maps to ClassLoaders in the various hosting environments then.



- and the ArtifactResolver can get the Contribution's ClassLoader passed

to its constructor.



+1

I'm not sure if having the PackageProcessor create the ClassLoader is

the best solution as the hosting environment needs to have a say with
respect to which ClassLoader is used for what, but I guess we can start
with that approach at least now to make progress, and change later when
we have a better idea of how this fits with the various hosting
environments.

--
Jean-Sebastien


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








--
Jean-Sebastien


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

[jira] Commented: (TUSCANY-952) DAS must support queries that reference tables in different schemas

2007-04-24 Thread Adriano Crestani (JIRA)


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

Adriano Crestani commented on TUSCANY-952:
--

Amita, I was revising your classes and found some problems:

 - The following constructor:

...
public QualifiedColumn(String name, boolean isDatabaseSchemaNameSupported) {
int index = name.indexOf('.');
if ( index == -1 ) {
throw new RuntimeException(Column  + name +  must be qualified 
with a table name and optional schema name);
}
...

If a new QualifiedColumn(table, false) is invoked, it will throw an 
RuntimeException because it doesn't check if on the first condition the 
variable isDatabaseSchemaNameSupported.

I suggest a modification on the first condition:

...
if ( index == -1  !isDatabaseSchemaNameSupported) {
throw new RuntimeException(Column  + name +  must be qualified 
with a table name and optional schema name);
}
...

-

Another doubt on MappingWrapper.addRelationship(Vector parentNames, Vector 
childNames) that you create two VectorQualifiedColumn and add new 
QualifiedColumns are being created with QualifiedColumn(String tableName) 
constructor. This way it will not load the schema name. I commented it on the 
code bellow:

...
public Relationship addRelationship(Vector parentNames, Vector childNames) {
//create vector for each
if(parentNames.size() != childNames.size()){
throw new RuntimeException(Can not for relationship for multiple 
keys, different sizes);
}

Vector parentColumns = new Vector();
Vector childColumns = new Vector();

for(int i=0; iparentNames.size(); i++){
// it should be checked if the schema name is supported and use 
another constructor for it  
QualifiedColumn parent = new 
QualifiedColumn((String)parentNames.get(i));
QualifiedColumn child = new 
QualifiedColumn((String)childNames.get(i));

parentColumns.add(parent);
childColumns.add(child);
}

//all parent columns should be from same table and schema
//all child columns should be from same table and schema
checkTableNames(parentColumns);
checkSchemaNames(parentColumns);

checkTableNames(childColumns);
checkSchemaNames(childColumns);

Relationship r = FACTORY.createRelationship();
//JIRA-952
if(this.config.isDatabaseSchemaNameSupported()){  
 
   // As the QualifiedColumns are being created with 
QualifiedName(String name) constructor, the method getShemaName will always 
return 

r.setName(((QualifiedColumn)childColumns.get(0)).getSchemaName()+.
+((QualifiedColumn)childColumns.get(0)).getTableName());

r.setPrimaryKeyTable(((QualifiedColumn)parentColumns.get(0)).getSchemaName()+.

+((QualifiedColumn)parentColumns.get(0)).getTableName());

r.setForeignKeyTable(((QualifiedColumn)childColumns.get(0)).getSchemaName()+.

+((QualifiedColumn)childColumns.get(0)).getTableName());
}
else{
r.setName(((QualifiedColumn)childColumns.get(0)).getTableName());

r.setPrimaryKeyTable(((QualifiedColumn)parentColumns.get(0)).getTableName());

r.setForeignKeyTable(((QualifiedColumn)childColumns.get(0)).getTableName());
}
...

-

I didn't check all your code yet, I will wait for clarifications ; )

Adriano Crestani

 DAS must support queries that reference tables in different schemas
 -

 Key: TUSCANY-952
 URL: https://issues.apache.org/jira/browse/TUSCANY-952
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Reporter: Kevin Williams
 Fix For: Java-DAS-Mx

 Attachments: DAS-JIRA-952-Apr24-Amita.txt, JIRA-952-Details.doc, 
 JIRA-952-Feb16-Amita.jar, JIRA-952-Mar01-Amita.jar


 The DAS is curently ignorant of database schema designations.  This means the 
 DAS will generate incorrect write statements when it processes the change 
 summary from a data graph that originated from a query that uses schema names 
 that are different from the default schema.

-- 
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-625) [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is omitted from an import


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

Caroline Maynard commented on TUSCANY-625:
--

We're still hoping for solution to this one.

 [SDO for C++] XSDHelperImpl::defineFile is unhelpful when schemaLocation is 
 omitted from an import
 --

 Key: TUSCANY-625
 URL: https://issues.apache.org/jira/browse/TUSCANY-625
 Project: Tuscany
  Issue Type: Improvement
  Components: C++ SDO
Affects Versions: Cpp-M1
Reporter: Caroline Maynard
 Assigned To: Pete Robbins
Priority: Minor
 Fix For: Cpp-M3


 A PHP user is trying to work with a service defined by 
 http://api.urbandictionary.com/soap
 However XSDHelperImpl::defineFile() fails with an SDOTypeNotFoundException:  
   'Type not found :http://schemas.xmlsoap.org/soap/encoding/ Array' 
 I think this is because the required type is defined via an import:
   xsd:import namespace=http://schemas.xmlsoap.org/soap/encoding/; /
 which omits the schemaLocation. 
 Arguably the wsdl in question is a bit defective, and the problem can be 
 bypassed by hand-editing the wsdl to add the schemaLocation attribute. But 
 Tuscany could be a bit more helpful, and try to use the namespace URI when 
 schemaLocation is omitted. 

-- 
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: Tomcat errors when trying to build the latest trunk

2007-04-24 Thread Kevin Williams


Hi Sebastien,
The test runs fines from /http-tomcat.
--Kevin

On 4/24/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


[snip]
Kevin Williams wrote:
 Now, I am getting the Connection refused error:

 INFO: Stopping Coyote HTTP/1.1 on http-8586
 Apr 24, 2007 12:31:07 PM org.apache.catalina.startup.Embedded start
 INFO: Starting tomcat server
 Apr 24, 2007 12:31:07 PM org.apache.catalina.core.StandardEngine start
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
 Apr 24, 2007 12:31:07 PM
 org.apache.catalina.startup.ContextConfigdefaultWebCon
 fig
 INFO: No default web.xml
 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol init
 INFO: Initializing Coyote HTTP/1.1 on http-8586
 Apr 24, 2007 12:31:07 PM org.apache.coyote.http11.Http11Protocol start
 INFO: Starting Coyote HTTP/1.1 on http-8586
 Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.686sec
  FA
 ILURE!
 testRequestSession(org.apache.tuscany.http.tomcat.TomcatServerTestCase)
 Time el
 apsed: 1.082 sec   ERROR!
 java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java
 :233)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378)
at java.net.Socket.connect(Socket.java:536)
at java.net.Socket.connect(Socket.java:486)
at java.net.Socket.init(Socket.java:394)
at java.net.Socket.init(Socket.java:207)
at
 org.apache.tuscany.http.tomcat.TomcatServerTestCase.testRequestSessio
 n(TomcatServerTestCase.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
 (NativeMethodAccessorImpl.
 java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAcces
 sorImpl.java:43)


Kevin,

This one is interesting as it's an isolated Tomcat test case, not even
involving integration with the Web Service binding. I suspect a timing
issue, where Tomcat is returning from the start method before it's
actually ready to accept requests. I'm going to investigate it but have
question: Are you able to reproduce this problem when running mvn from
the http-tomcat directory? or are you only running into it when building
the whole trunk?

Thanks

--
Jean-Sebastien


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

Re: Setting up a Tuscany runtime to run multiple applications


Kapish Aggarwal wrote:

I am interested in setting up a single instance of the Tuscany runtime
to run multiple SCA applications. I noticed that the SimpleRuntime and
SimpleRuntimeInfo classes define a 1:1 relationship between the
runtime and an SCA application. Based on this mechanism, I believe I
can do the following to create a runtime class that can handle
multiple SCA applications:

1) Extend RuntimeInfo to create a information object to reflect the
environment of 1:n runtime:applications.

2) Extend the AbstractRuntime class to create a runtime instance with
the methods and code to start and stop individual applications from a
single runtime.

3) Define a class to manage the Runtime and allow an interface for
starting and stopping applications (much in the manner that
DefaultSCARuntime manages SimpleRuntimeImpl).

Obviously this is a high-level look at how I would implement it. Is
this a good way to go about setting a 1:n environment or is there some
other mechanism I overlooked?

Kapish Aggarwal

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




Hi,

What you're describing looks OK to me. SimpleRuntimeImpl is not meant to 
be used as-is in a multi-application server environment, but you can 
extend AbstractRuntime to create a similar runtime class that will 
integrate multiple-applications. If you look at the code in 
SimpleRuntimeImpl.start(), I think that everything up to the creation of 
the Scope registry can be done once for all applications, the rest of 
this code can be done on an application basis. The ContributionService 
will allow you to load isolated SCA contributions for each application. 
You'll need one instance of ArtifactResolver per application as well. 
ComponentManager will allow you to register your applications under 
different URIs (unless you want to use multiple component managers). 
Finally Component has start/stop methods to allow you to start/stop 
components when an application starts/stops.


Hope this helps.

--
Jean-Sebastien


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

Re: tuscany asynchronous web service call