date:20070626


If the levels of the EMF dependency are not defined transitively via the SDO
dependency then I guess that should be fine.  I had imagined they would have
been picked up indirectly from the beta1 pom.

Regards, Kelvin.

On 26/06/07, ant elder [EMAIL PROTECTED] wrote:

If the 2.2.3 jars work ok with the beta1 code and they're available in a
repo then could we just change the SCA and DAS pom's to exclude the
2.2.2jars and include the
2.2.3 ones?

   ...ant

On 6/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Author: kelvingoodson
 Date: Tue Jun 26 01:38:08 2007
 New Revision: 550739

 URL: http://svn.apache.org/viewvc?view=revrev=550739
 Log:
 Updating the trunk to EMF 2.2.3 -- this doesn't fix the DAS release
 problem because they are based on the SDO beta1,  and so still require

EMF

 2.2.2 to be published somewhere,  but at last it stops the trunk from
 failing.  This update solves part of the issue in TUSCANY-1369

 Modified:
 incubator/tuscany/java/sdo/pom.xml

 Modified: incubator/tuscany/java/sdo/pom.xml
 URL:


http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/pom.xml?view=diffrev=550739r1=550738r2=550739




==

 --- incubator/tuscany/java/sdo/pom.xml (original)
 +++ incubator/tuscany/java/sdo/pom.xml Tue Jun 26 01:38:08 2007
 @@ -75,7 +75,7 @@

  properties
  specVersion2.1/specVersion
 -emfVersion2.2.2/emfVersion
 +emfVersion2.2.3/emfVersion
  sdo.version${version}/sdo.version
  /properties




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

Re: [SDO Java DISCUSS] Contents of the next SDO release

I'd like to take a quick roll call if possible please.

Who if anyone is working on these issues? When do you think they will be
ready by? Is anyone working on an issue not referenced in the attached note
that they want in the 1.0 but haven't said so?

I've been working on the build structure and the samples. In order to have
any chance of being close to getting a release candidate through voting by
mid of next month were going to need your contributions in very soon,
knowing how it usually takes a few of release candidate iterations in
general before a successful PMC vote. Ideally, your contributions
permitting, I'd like to be in a position to build a release candidate in the
middle part of next week.

Regards, Kelvin.

On 11/06/07, kelvin goodson [EMAIL PROTECTED] wrote:

Good suggestion Steffen. If you were able to open a Jira and dump into it
any thoughts you may have had about the details of how you see this
working that would be great. The more detail you put there, the more
likely it is that someone who wants to get their hands dirty would be likely
to pick it up; unless of course you have plans for doing it yourself. As
an aside, it's always interesting to know the background to why a
particular feature is important to someone, so if you felt like commenting
on your scenarios that would benefit from this too, whether in the JIRA
on or the list, that would be great.

For my part here are the things that I'd like to see done ...
- reorganisation of the build to create release distributions in line with
the SCA release format
- review and improvement of the samples and implementation of an
alternative simple approach to running the samples that does not involve
running a maven build
- review and improvement of the website documentation

In addition, some things I'd like to see being done, but I don't see as
absolute prerequisites for a release are ...
- creation of a further sdo sub-project that permits automated exercising
of the sdo plugin and java generator
- more test cases

In terms of JIRA's, we currently have 3 marked for the specific release[1],
rather then
the generic Java-SDO-Next bucket [2] that is the placeholder for Jiras not
assigned to a release.
TUSCANY-1317 http://issues.apache.org/jira/browse/TUSCANY-1317,
TUSCANY-1143 http://issues.apache.org/jira/browse/TUSCANY-1143 ,
TUSCANY-513 http://issues.apache.org/jira/browse/TUSCANY-513

The first is there because the originator marked it for the beta1, which
it didn't make, but it looks well defined, so after the beta1 I changed
the fix release to the 1.0 release, but I don't think I'll have thebandwidth to
cover this.
The second is there because I want it to be, and plan to tackle it.
The third is there because the originator has provided a patch and I'm in
the process of committing it.

In the light of my priorities above, having taken a scan through [2] in
addition to 1143, I plan to look at ...

TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2
TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples,
incorrectly accessing xsd:any content
TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars
TUSCANY-257recently added file Interface2JavaGenerator.java is not
compatible with JDK 1.4

and there are a few others I have my eye on, e.g. 303, if all the above
goes well.

Regards, Kelvin.

[1]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=1status=3status=4component=12311542component=12310660component=12310973component=12310802fixfor=12312521sorter/field=issuekeysorter/order=DESC

[2]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=1status=3status=4component=12310660component=12310973component=12310802fixfor=12312262sorter/field=issuekeysorter/order=DESC

On 09/06/07, Steffen Glomb [EMAIL PROTECTED] wrote:

i would like to see support for typesafe collections in the xsd2java
generator.

regards
Steffen

On 6/8/07, kelvin goodson [EMAIL PROTECTED] wrote:

I'd like to draw the communities attention to this issue again please.

Thanks to David for responding with his requirements and with the fix
for
1223. I have some thoughts that I'm structuring at the moment on
what's
important for a next release from my perspective that I'll post
soon, but
in general I'm just keen to get the good stuff that we have added
recently
out in a release that, as I said before from my perspective, warrants
the
title of 1.0. With the Summer holiday season coming up, I'd like
to do
this soon so that I can sun myself on a beach without that niggling
feeling
of things that ought to have been done ;-)

What say you we put a stake in the ground of aiming for a SDO 1.0release to
be at the IPMC ratification stage by mid-July?

So to that end I ask again, if you have requirements that you feel are
fundamental to the next release please raise them now; with the
caveat of

[VOTE] Fuhwei Lwo for Tuscany Committer


I'd like to propose Fuhwei Lwo as a Tuscany Committer.

According to my gmail archive he has, since mid of 2006, posted 114 times to
tusany-dev, 79 of those times resulting from interactions with JIRA issue
management.

He has raised 34 JIRAs (see [1])

The gmail search  -- from:fuhwei [jira] Attachment: shows that
Fuhwei has attached around 27 patches to JIRAs.

The JIRAs he raises, the comments he makes and the solutions he provides
demonstrate in depth knowledge of SDO and clearly he will be a strong asset
for the community.

Please vote to give Fuhwei this well deserved status

Regards, Kelvin.

[1]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC

Sample with SDO Databinding over web service

2007-06-26 Thread scyip12

I've been running into all kinds of problems trying to get a simple example 
going using a webapp, SDO objects generated from a wsdl and webservice binding. 
Is there a sample (or anyone have existing working code) in this kind of 
format?  I thought it would be a common basic scenario, but I didn't see any 
SDO databinding samples around.  Would appreciate any sort of guidance.

[DISCUSS] Geronimo-Tuscany integration

2007-06-26 Thread Vamsavardhana Reddy


Hi,

Myself and Manu have done some work (a small PoC) on Geronimo Tuscany
integration.  As a first step, we have created a plugin for Geronimo
that will let the user to deploy standalone tuscany modules into
Geronimo and use the deployed services by looking up in JNDI.  I have
put the code in Geronimo Sandbox at
https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/.

Going forward, we have the following in mind:
A) Write a deploymentwatcher so that Tuscany modules can be bundled as
part of J2EE artifacts.
B) Extend the current deployer to enable Tuscany Modules deployed in
Geronimo to access resources like datasources from Geronimo

Some of the questions we have are:
1.  Should we use this plugin approach and host the plugin separatley
or intergrate Tuscany to be bundled as part of the Geronimo
distribution?
2.  Should we have support for bundling Tuscany composites in WAR,
EJB-JAR and EAR?  Or should we provide for adding a separate Tuscany
module in EAR?
3.  Where should we maintain the integration code?

Your comments and suggestions will be very helpful in taking it further.

Thanks and best regards,
Vamsi

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

Re: [VOTE] Fuhwei Lwo for Tuscany Committer

2007-06-26 Thread Frank Budinsky

Absolutely +1 from me!

Frank.

kelvin goodson [EMAIL PROTECTED] wrote on 06/26/2007 07:10:23 
AM:

 I'd like to propose Fuhwei Lwo as a Tuscany Committer.
 
 According to my gmail archive he has, since mid of 2006, posted 114 
times to
 tusany-dev, 79 of those times resulting from interactions with JIRA 
issue
 management.
 
 He has raised 34 JIRAs (see [1])
 
 The gmail search  -- from:fuhwei [jira] Attachment: shows 
that
 Fuhwei has attached around 27 patches to JIRAs.
 
 The JIRAs he raises, the comments he makes and the solutions he provides
 demonstrate in depth knowledge of SDO and clearly he will be a strong 
asset
 for the community.
 
 Please vote to give Fuhwei this well deserved status
 
 Regards, Kelvin.
 
 [1]
 http://issues.apache.org/jira/secure/IssueNavigator.jspa?
 
reset=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC


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

Re: [VOTE] Fuhwei Lwo for Tuscany Committer


+1 from me of course

On 26/06/07, kelvin goodson [EMAIL PROTECTED] wrote:


I'd like to propose Fuhwei Lwo as a Tuscany Committer.

According to my gmail archive he has, since mid of 2006, posted 114 times
to tusany-dev, 79 of those times resulting from interactions with JIRA issue
management.

He has raised 34 JIRAs (see [1])

The gmail search  -- from:fuhwei [jira] Attachment: shows
that Fuhwei has attached around 27 patches to JIRAs.

The JIRAs he raises, the comments he makes and the solutions he provides
demonstrate in depth knowledge of SDO and clearly he will be a strong asset
for the community.

Please vote to give Fuhwei this well deserved status

Regards, Kelvin.

[1] 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC

[CTS] safeguarding setUp() methods against failure due to existing types

2007-06-26 Thread Andy Grove


CTS test setUp() methods generally make use of the
TestHelper.createHelperContext method to create a new context. I agree
that this is the correct design. However, SDO 2.1 does not require
implementations to support multiple contexts - only a default context
is mandated. Therefore I am planning to add some additional code to
some setUp() methods so they do not attemp to create types if those
types already exist in the HelperContext provided by the TestHelper.

This approach will ensure that the CTS works equally well for
implementations that support multiple contexts as well as
implementations that only support a single default context.

If anyone has any objections, please let me know.

Thanks,

Andy.

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

Re: [CTS] safeguarding setUp() methods against failure due to existing types

2007-06-26 Thread Frank Budinsky

Hi Andy,

That sounds like a reasonable approach to me.

Thanks,
Frank.

[EMAIL PROTECTED] wrote on 06/26/2007 09:21:23 AM:

 CTS test setUp() methods generally make use of the
 TestHelper.createHelperContext method to create a new context. I agree
 that this is the correct design. However, SDO 2.1 does not require
 implementations to support multiple contexts - only a default context
 is mandated. Therefore I am planning to add some additional code to
 some setUp() methods so they do not attemp to create types if those
 types already exist in the HelperContext provided by the TestHelper.
 
 This approach will ensure that the CTS works equally well for
 implementations that support multiple contexts as well as
 implementations that only support a single default context.
 
 If anyone has any objections, please let me know.
 
 Thanks,
 
 Andy.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


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

[jira] Updated: (TUSCANY-1381) DAS config file with default namespace will not work

2007-06-26 Thread Amita Vadhavkar (JIRA)


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

Amita Vadhavkar updated TUSCANY-1381:
-

Attachment: workingExampleJune26.jar

Tried the original config.xml you have provided with a few minor changes
and it worked with latest RDB DAS. I am not sure why M2 has problems
But if possible please see if you can take the latest code from 
(trunk) https://svn.apache.org/repos/asf/incubator/tuscany/java/das
as DAS has come a long way after M2. I would like to help in case
there are any problems in using code to build RDB DAS.

I did try your config.xml in the new J2SE Sample available in trunk.
I am trying to attach the 2 changed/added files from das\samples\customer (J2SE 
sample)
(1-config.xml , 2-Caller program to use this config.xml-CustomerClient.java) 
and it worked fine.

In this latest code from trunk, there are a bunch of new features implemented,
on their way to get released, like below. Would you like to try these too?

*DAS uses overqualified update by default
Currently in the DAS we either use a user-defined version column or do not use 
any concurrency control. We have enough information to build an overqualified 
update in cases where a version column is not defined. For example, if a field 
name is changed from Bob to John, we would generate a query such as:
UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
If the statement does not update any rows in the database, the DAS will throw a 
concurrency control exception. 
This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB columns, so an 
exception should be thrown in that case indicating that a version column must 
be defined. 

*DAS Configuration supports ConnectionInfo for J2SE environment
So far the DAS allowed users to specify a JDBC Connection for the DAS to 
utilize by either providing a JDBC Connection explicitly or providing a JNDI 
name in the config file. Now DAS supports DriverManager info to be provided to 
allow similar, config-based set up, in a J2SE environment.

*Creation and initialization of database for DAS samples
So far, the DAS samples provided canned database with them. This feature is an 
useful utility which supports an external configuration based creation and 
initialization of database when sample is loaded for the first time. User can 
design the database schema using the external configuration.

*DAS supports queries that reference tables in multiple schema
So far DAS did not support multiple database schema. This feature allows DAS to 
execute all commands for tables in different schema.

*Advanced DAS features Demo
This is not a new feature in itself but a new sample demonstrating multiple 
advanced features in DAS like optimistic concurrency control, column converter, 
result set shape...New features will keep getting added to this in future.


 DAS config file with default namespace will not work
 

 Key: TUSCANY-1381
 URL: https://issues.apache.org/jira/browse/TUSCANY-1381
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-M2
Reporter: wangful
 Attachments: workingExampleJune26.jar


 Hi, 
 If I use the following xml file as the DAS config file, there will be errors:
 DAS das = 
 DAS.FACTORY.createDAS(Thread.currentThread().getContextClassLoader().getResourceAsStream(config.xml),
  conn);
 Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;
   Command name=AllCustomers SQL=select * from MYCUSTOMER 
 kind=Select
   ResultDescriptor columnName=ID tableName=MYCUSTOMER 
 columnType=commonj.sdo.Long/
   ResultDescriptor columnName=Name tableName=MYCUSTOMER 
 columnType=commonj.sdo.String/
   /Command
   
   Table tableName=MYCUSTOMER
   Column columnName=ID primaryKey=true /
   Column columnName=NAME /
   /Table
   
 /Config
 The error is: 
 Exception in thread main java.lang.RuntimeException: 
 org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 'Command' 
 not found. (http:///temp.xml, 25, 76)
   at 
 org.apache.tuscany.das.rdb.util.ConfigUtil.loadConfig(ConfigUtil.java:54)
   at org.apache.tuscany.das.rdb.impl.DASImpl.init(DASImpl.java:100)
   at 
 org.apache.tuscany.das.rdb.impl.DASFactoryImpl.createDAS(DASFactoryImpl.java:39)
   at TestDAS.main(TestDAS.java:52)
 It seems the default namespace can't work.  But if I add prefix for the 
 namespace as below, it will work.
 c:Config xmlns:c=http:///org.apache.tuscany.das.rdb/config.xsd;
   Command name=AllCustomers SQL=select * from MYCUSTOMER 
 kind=Select
   ResultDescriptor columnName=ID tableName=MYCUSTOMER 
 columnType=commonj.sdo.Long/
   ResultDescriptor columnName=Name tableName=MYCUSTOMER 
 columnType=commonj.sdo.String/
   /Command

Re: [LDAP DAS] Can Read and Write EDataGraph Instances

2007-06-26 Thread Ole Ersoy


Thanks Luciano,

Here's the Sandbox location:

svn checkout 
https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.ldap.parent

Just check it out and run:
mvn eclipse:clean eclipse:eclipse

The tests run against ApacheDS embedded, so all that is needed is to checkout 
and build the latest ApacheDS build.

svn checkout 
http://svn.apache.org/repos/asf/directory/apacheds/trunk-with-dependencies

Cheers,
- Ole

P.S.
It reads DataGraphs, but I still need to update the cross references, thus the 
only thing tested so far is restoring containment references.

Luciano Resende wrote:

Very great news, Is this available in your sandbox ? Could you share
the link again, for the ones interested on taking a quick look at it ?

For the LDAP Server dependencies/requirements, are there any
instructions on running the DAS and connecting to the LDAP server ?

On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote:

Hey Guys,

The LDAP DAS can now read and write EDataGraph instances to ApacheDS.  
Now I need to start working on handling updates and deletions.  If 
anyone wants to see the code so far, please let me know and I'll check 
it in.


Cheers,
- Ole


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

Permission denied when trying to commit changes

2007-06-26 Thread Andy Grove

I am trying to submit my first change now that I have committer status but I'm 
getting a 403 Forbidden error.

Authentication realm: https://svn.apache.org:443 ASF Committers
Username: myusername
Password for 'myusername': **
svn: Commit failed (details follow):
svn: MKACTIVITY of '/repos/asf/!svn/act/20b54094-59ad-2e4b-b6f4-9b67020e49ce': 
403 Forbidden (https://svn.apache.org)

I used the following URL when running the checkout command:

https://svn.apache.org/repos/asf/incubator/tuscany/java

Can anyone give me any pointers to what the problem might be? I have changed 
both my SSH and SVN passwords from the initially supplied password. 

Thanks,

Andy Grove
Product Architect, HydraSDO
Rogue Wave Software

Re: Permission denied when trying to commit changes

2007-06-26 Thread ant elder


Probably dims needs to update your karma. I've not seen the response back
from root for you id yet, you may need to just wait a little longer.

  ...ant

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


I am trying to submit my first change now that I have committer status but
I'm getting a 403 Forbidden error.

Authentication realm: https://svn.apache.org:443 ASF Committers
Username: myusername
Password for 'myusername': **
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/repos/asf/!svn/act/20b54094-59ad-2e4b-b6f4-9b67020e49ce': 403 Forbidden (
https://svn.apache.org)

I used the following URL when running the checkout command:

https://svn.apache.org/repos/asf/incubator/tuscany/java

Can anyone give me any pointers to what the problem might be? I have
changed both my SSH and SVN passwords from the initially supplied password.

Thanks,

Andy Grove
Product Architect, HydraSDO
Rogue Wave Software

[jira] Created: (TUSCANY-1383) Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations
---

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


Im investigating using TuscanySCA (C++ version) with a container other 
than Axis. To do this, the container needs to be able to obtain the 
WSDL operations, types, etc loaded by Tuscany. I would like to propose 
extending some of the Tuscany APIs to allow them to be queried, since 
currently you can only do a find with a known operation name. These 
query operations could be done either by returning an iterator to the
internal map, or by just returning a list of map's value strings. The
second option would probably be safer and more thread-safe. 

Here are the additions that I propose adding:

runtime/core/src/tuscany/sca/model/Composite.h
   std::liststd::string getIncludedComposites(); 
   Composite* findIncludedComposite(const std::string compositeName);
   std::liststd::string Composite::getWSDLNamespaces();
   Change 
 std::vectorComposite* includes;
   To 
 std::mapstd::string, Composite includes;

runtime/core/src/tuscany/sca/model/WSDLDefinition.h
   std::liststd::string WSDLDefinition::getPortTypes();
   std::liststd::string WSDLDefinition::getOperations( const std::string 
portTypeName );

The suggested usage of and rationale behind these additions is as follows:

Once the projects have been loaded by calling:
   tuscany::sca::SCARuntime::initializeSharedRuntime( .. )

The system composite can then be obtained by calling:
   tuscany::sca::model::Composite* SCARuntime::getSystem();

The system composite doesnt usually contain much other than included 
composites, so first iterate
over the composites included in the system composite with these additions to 
the Composite class:
   std::liststd::string compositeList = 
systemComposite-getIncludedComposites();
   tuscany::sca::model::Composite* includedComposite = 
findIncludedComposite(const std::string compositeName);

In order to make this easier, the tuscany::sca::model::Composite::includes data 
member should be changed from a
vector to a map, which would map from the composite name to the composite. As 
it is now, it would be necessary to
return the actual includes vector, which isnt generally a good idea since users 
could inadvertantly corrupt it.

For each included composite, this addition to the Composite class would allow 
you to get all of the 
WSDL namespaces loaded for a Composite.
   std::liststd::string wsdlNSList = includedComposite-getWSDLNamespaces();

The WSDLDefinition can then be obtained by calling:
   WSDLDefinition* wsdlDef = includedComposite-findWSDLDefinition( 
wsdlNamespace );

Then, for each WSDLDefinition, you can iterate over all of the WSDL PortTypes 
and PortType operations
with these additions to the WSDLDefinition class:
   std::liststd::string wsdlPortTypeList = wsdlDef-getPortTypes();
   std::liststd::string wsdlPortTypeOpList = wsdlDef-getOperations( 
portTypeName );

Now get the WSDLOperation:
   WSDLOperation wsdlOp = wsdlDef-findOperation( portTypeName, operName );

Im not currently a TuscanySCA contributor, so can someone please submit the 
attached patch?

Thanks


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


-- 
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-1384) SequenceAddOpenTest.setUp() needs to check if type exists before creating it

2007-06-26 Thread Andy Grove (JIRA)

SequenceAddOpenTest.setUp() needs to check if type exists before creating it


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


SequenceAddOpenTest.setUp() needs to check if type exists before creating it so 
that the test does not fail against implementations that cannot provide a new 
HelperContext for each run.

I intend to fix this in the next couple of days.

-- 
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-1383) Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations


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

Brady Johnson updated TUSCANY-1383:
---

Attachment: Composite_h_jira1383

Attaching Composite.h

 Tuscany SCA native/C++ : Ability to query the runtime for its loaded 
 operations
 ---

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

 Attachments: Composite_h_jira1383, WSDLDefinition_h_jira1383


 Im investigating using TuscanySCA (C++ version) with a container other 
 than Axis. To do this, the container needs to be able to obtain the 
 WSDL operations, types, etc loaded by Tuscany. I would like to propose 
 extending some of the Tuscany APIs to allow them to be queried, since 
 currently you can only do a find with a known operation name. These 
 query operations could be done either by returning an iterator to the
 internal map, or by just returning a list of map's value strings. The
 second option would probably be safer and more thread-safe. 
 Here are the additions that I propose adding:
 runtime/core/src/tuscany/sca/model/Composite.h
std::liststd::string getIncludedComposites(); 
Composite* findIncludedComposite(const std::string compositeName);
std::liststd::string Composite::getWSDLNamespaces();
Change 
  std::vectorComposite* includes;
To 
  std::mapstd::string, Composite includes;
 runtime/core/src/tuscany/sca/model/WSDLDefinition.h
std::liststd::string WSDLDefinition::getPortTypes();
std::liststd::string WSDLDefinition::getOperations( const std::string 
 portTypeName );
 The suggested usage of and rationale behind these additions is as follows:
 Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime( .. )
 The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();
 The system composite doesnt usually contain much other than included 
 composites, so first iterate
 over the composites included in the system composite with these additions to 
 the Composite class:
std::liststd::string compositeList = 
 systemComposite-getIncludedComposites();
tuscany::sca::model::Composite* includedComposite = 
 findIncludedComposite(const std::string compositeName);
 In order to make this easier, the tuscany::sca::model::Composite::includes 
 data member should be changed from a
 vector to a map, which would map from the composite name to the composite. As 
 it is now, it would be necessary to
 return the actual includes vector, which isnt generally a good idea since 
 users could inadvertantly corrupt it.
 For each included composite, this addition to the Composite class would allow 
 you to get all of the 
 WSDL namespaces loaded for a Composite.
std::liststd::string wsdlNSList = includedComposite-getWSDLNamespaces();
 The WSDLDefinition can then be obtained by calling:
WSDLDefinition* wsdlDef = includedComposite-findWSDLDefinition( 
 wsdlNamespace );
 Then, for each WSDLDefinition, you can iterate over all of the WSDL PortTypes 
 and PortType operations
 with these additions to the WSDLDefinition class:
std::liststd::string wsdlPortTypeList = wsdlDef-getPortTypes();
std::liststd::string wsdlPortTypeOpList = wsdlDef-getOperations( 
 portTypeName );
 Now get the WSDLOperation:
WSDLOperation wsdlOp = wsdlDef-findOperation( portTypeName, operName );
 Im not currently a TuscanySCA contributor, so can someone please submit the 
 attached patch?
 Thanks
 
 Brady Johnson
 Rogue Wave Software - [EMAIL PROTECTED]
 Lead Software Developer - HydraSCA

-- 
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-1383) Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations


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

Brady Johnson updated TUSCANY-1383:
---

Attachment: WSDLDefinition_h_jira1383

Attaching WSDLDefinition.h

 Tuscany SCA native/C++ : Ability to query the runtime for its loaded 
 operations
 ---

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

 Attachments: Composite_h_jira1383, WSDLDefinition_h_jira1383


 Im investigating using TuscanySCA (C++ version) with a container other 
 than Axis. To do this, the container needs to be able to obtain the 
 WSDL operations, types, etc loaded by Tuscany. I would like to propose 
 extending some of the Tuscany APIs to allow them to be queried, since 
 currently you can only do a find with a known operation name. These 
 query operations could be done either by returning an iterator to the
 internal map, or by just returning a list of map's value strings. The
 second option would probably be safer and more thread-safe. 
 Here are the additions that I propose adding:
 runtime/core/src/tuscany/sca/model/Composite.h
std::liststd::string getIncludedComposites(); 
Composite* findIncludedComposite(const std::string compositeName);
std::liststd::string Composite::getWSDLNamespaces();
Change 
  std::vectorComposite* includes;
To 
  std::mapstd::string, Composite includes;
 runtime/core/src/tuscany/sca/model/WSDLDefinition.h
std::liststd::string WSDLDefinition::getPortTypes();
std::liststd::string WSDLDefinition::getOperations( const std::string 
 portTypeName );
 The suggested usage of and rationale behind these additions is as follows:
 Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime( .. )
 The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();
 The system composite doesnt usually contain much other than included 
 composites, so first iterate
 over the composites included in the system composite with these additions to 
 the Composite class:
std::liststd::string compositeList = 
 systemComposite-getIncludedComposites();
tuscany::sca::model::Composite* includedComposite = 
 findIncludedComposite(const std::string compositeName);
 In order to make this easier, the tuscany::sca::model::Composite::includes 
 data member should be changed from a
 vector to a map, which would map from the composite name to the composite. As 
 it is now, it would be necessary to
 return the actual includes vector, which isnt generally a good idea since 
 users could inadvertantly corrupt it.
 For each included composite, this addition to the Composite class would allow 
 you to get all of the 
 WSDL namespaces loaded for a Composite.
std::liststd::string wsdlNSList = includedComposite-getWSDLNamespaces();
 The WSDLDefinition can then be obtained by calling:
WSDLDefinition* wsdlDef = includedComposite-findWSDLDefinition( 
 wsdlNamespace );
 Then, for each WSDLDefinition, you can iterate over all of the WSDL PortTypes 
 and PortType operations
 with these additions to the WSDLDefinition class:
std::liststd::string wsdlPortTypeList = wsdlDef-getPortTypes();
std::liststd::string wsdlPortTypeOpList = wsdlDef-getOperations( 
 portTypeName );
 Now get the WSDLOperation:
WSDLOperation wsdlOp = wsdlDef-findOperation( portTypeName, operName );
 Im not currently a TuscanySCA contributor, so can someone please submit the 
 attached patch?
 Thanks
 
 Brady Johnson
 Rogue Wave Software - [EMAIL PROTECTED]
 Lead Software Developer - HydraSCA

-- 
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-1383) Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations


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

Brady Johnson updated TUSCANY-1383:
---

Attachment: Composite_cpp_jira1383

Ataching Composite.cpp

 Tuscany SCA native/C++ : Ability to query the runtime for its loaded 
 operations
 ---

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

 Attachments: Composite_cpp_jira1383, Composite_h_jira1383, 
 WSDLDefinition_cpp_jira1383, WSDLDefinition_h_jira1383


 Im investigating using TuscanySCA (C++ version) with a container other 
 than Axis. To do this, the container needs to be able to obtain the 
 WSDL operations, types, etc loaded by Tuscany. I would like to propose 
 extending some of the Tuscany APIs to allow them to be queried, since 
 currently you can only do a find with a known operation name. These 
 query operations could be done either by returning an iterator to the
 internal map, or by just returning a list of map's value strings. The
 second option would probably be safer and more thread-safe. 
 Here are the additions that I propose adding:
 runtime/core/src/tuscany/sca/model/Composite.h
std::liststd::string getIncludedComposites(); 
Composite* findIncludedComposite(const std::string compositeName);
std::liststd::string Composite::getWSDLNamespaces();
Change 
  std::vectorComposite* includes;
To 
  std::mapstd::string, Composite includes;
 runtime/core/src/tuscany/sca/model/WSDLDefinition.h
std::liststd::string WSDLDefinition::getPortTypes();
std::liststd::string WSDLDefinition::getOperations( const std::string 
 portTypeName );
 The suggested usage of and rationale behind these additions is as follows:
 Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime( .. )
 The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();
 The system composite doesnt usually contain much other than included 
 composites, so first iterate
 over the composites included in the system composite with these additions to 
 the Composite class:
std::liststd::string compositeList = 
 systemComposite-getIncludedComposites();
tuscany::sca::model::Composite* includedComposite = 
 findIncludedComposite(const std::string compositeName);
 In order to make this easier, the tuscany::sca::model::Composite::includes 
 data member should be changed from a
 vector to a map, which would map from the composite name to the composite. As 
 it is now, it would be necessary to
 return the actual includes vector, which isnt generally a good idea since 
 users could inadvertantly corrupt it.
 For each included composite, this addition to the Composite class would allow 
 you to get all of the 
 WSDL namespaces loaded for a Composite.
std::liststd::string wsdlNSList = includedComposite-getWSDLNamespaces();
 The WSDLDefinition can then be obtained by calling:
WSDLDefinition* wsdlDef = includedComposite-findWSDLDefinition( 
 wsdlNamespace );
 Then, for each WSDLDefinition, you can iterate over all of the WSDL PortTypes 
 and PortType operations
 with these additions to the WSDLDefinition class:
std::liststd::string wsdlPortTypeList = wsdlDef-getPortTypes();
std::liststd::string wsdlPortTypeOpList = wsdlDef-getOperations( 
 portTypeName );
 Now get the WSDLOperation:
WSDLOperation wsdlOp = wsdlDef-findOperation( portTypeName, operName );
 Im not currently a TuscanySCA contributor, so can someone please submit the 
 attached patch?
 Thanks
 
 Brady Johnson
 Rogue Wave Software - [EMAIL PROTECTED]
 Lead Software Developer - HydraSCA

-- 
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-1383) Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations


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

Brady Johnson updated TUSCANY-1383:
---

Attachment: WSDLDefinition_cpp_jira1383

Attaching WSDLDefinition.cpp

 Tuscany SCA native/C++ : Ability to query the runtime for its loaded 
 operations
 ---

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

 Attachments: Composite_cpp_jira1383, Composite_h_jira1383, 
 WSDLDefinition_cpp_jira1383, WSDLDefinition_h_jira1383


 Im investigating using TuscanySCA (C++ version) with a container other 
 than Axis. To do this, the container needs to be able to obtain the 
 WSDL operations, types, etc loaded by Tuscany. I would like to propose 
 extending some of the Tuscany APIs to allow them to be queried, since 
 currently you can only do a find with a known operation name. These 
 query operations could be done either by returning an iterator to the
 internal map, or by just returning a list of map's value strings. The
 second option would probably be safer and more thread-safe. 
 Here are the additions that I propose adding:
 runtime/core/src/tuscany/sca/model/Composite.h
std::liststd::string getIncludedComposites(); 
Composite* findIncludedComposite(const std::string compositeName);
std::liststd::string Composite::getWSDLNamespaces();
Change 
  std::vectorComposite* includes;
To 
  std::mapstd::string, Composite includes;
 runtime/core/src/tuscany/sca/model/WSDLDefinition.h
std::liststd::string WSDLDefinition::getPortTypes();
std::liststd::string WSDLDefinition::getOperations( const std::string 
 portTypeName );
 The suggested usage of and rationale behind these additions is as follows:
 Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime( .. )
 The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();
 The system composite doesnt usually contain much other than included 
 composites, so first iterate
 over the composites included in the system composite with these additions to 
 the Composite class:
std::liststd::string compositeList = 
 systemComposite-getIncludedComposites();
tuscany::sca::model::Composite* includedComposite = 
 findIncludedComposite(const std::string compositeName);
 In order to make this easier, the tuscany::sca::model::Composite::includes 
 data member should be changed from a
 vector to a map, which would map from the composite name to the composite. As 
 it is now, it would be necessary to
 return the actual includes vector, which isnt generally a good idea since 
 users could inadvertantly corrupt it.
 For each included composite, this addition to the Composite class would allow 
 you to get all of the 
 WSDL namespaces loaded for a Composite.
std::liststd::string wsdlNSList = includedComposite-getWSDLNamespaces();
 The WSDLDefinition can then be obtained by calling:
WSDLDefinition* wsdlDef = includedComposite-findWSDLDefinition( 
 wsdlNamespace );
 Then, for each WSDLDefinition, you can iterate over all of the WSDL PortTypes 
 and PortType operations
 with these additions to the WSDLDefinition class:
std::liststd::string wsdlPortTypeList = wsdlDef-getPortTypes();
std::liststd::string wsdlPortTypeOpList = wsdlDef-getOperations( 
 portTypeName );
 Now get the WSDLOperation:
WSDLOperation wsdlOp = wsdlDef-findOperation( portTypeName, operName );
 Im not currently a TuscanySCA contributor, so can someone please submit the 
 attached patch?
 Thanks
 
 Brady Johnson
 Rogue Wave Software - [EMAIL PROTECTED]
 Lead Software Developer - HydraSCA

-- 
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: DAS C++ Status


Hey, very good, once this is available under the wiki, you probably
should also send an e-mail to the user list.

On 6/25/07, Adriano Crestani [EMAIL PROTECTED] wrote:

Added DAS C++ GettingStarted.html document and the first DAS C++ sample
under revision 550697.

Adriano Crestani

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

 DAS is no longer needing the config.xsd to read xml configuration files
 since revision 544749.

 Adriano Crestani

 On 5/30/07, Adriano Crestani  [EMAIL PROTECTED] wrote:
 
  Since revision 542742, DAS C++ is only working with SDO on trunk, and
  not with SDO C++ M3.
 
  Adriano Crestani
 
  On 5/29/07, Adriano Crestani  [EMAIL PROTECTED] wrote:
  
   Added support to one to many relationship under revision 542742
  
   Adriano Crestani
  
   On 5/28/07, Adriano Crestani  [EMAIL PROTECTED] wrote:
   
Added support to set up the framework via config xml under revision
542124.
   
Adriano Crestani
   
On 5/22/07, haleh mahbod  [EMAIL PROTECTED] wrote:

 Thank you for the explanation.

 On 5/21/07, Adriano Crestani  [EMAIL PROTECTED] wrote:
 
  Yes, it's intergrated with Tuscany SDO C++.
 
  Next step is to implement a sample for it.
 
  I intend to add some info on wiki before the first release.
 
  Regards,
  Adriano Crestani
 
  On 5/21/07, haleh mahbod [EMAIL PROTECTED]  wrote:
  
   Hi Adriano,
  
   Is this integrated with SDO C++?  Is there a sample for it?
   Can more information be added to the home page and  user
 guide[1]?
  
  
   [1]
  
http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=46512

  
   Haleh
  
   On 5/20/07, Adriano Crestani [EMAIL PROTECTED] 
 wrote:
   
Actually is being developed the Tuscany DAS C++. So far, the
 framework
   can
perform the following:
   
- Convetion Over Configuration(COC):
   
   - DAS assumes that a column named xxx_id is a FK to the
 column
  named
   id on table xxx.
   - If no PK column is found on the ResultSet, it sets the
 column
  named
   id as PK, if exists.
   - The COCs defined above are, actually, case sensitive
 and, for
   example, a column named ID will not be set as PK
   
   
- The das is using the ResultSet metadata(column name,
 column data
  type
and
column table) to generate the sdo graph and popule it. The
 DAS
   guarantees
the table object uniqueness on graph basing on the table PK,
 so the
   first
table retrieved by the ResultSet will be taken, and any
 other table
containing the same PK ignored:
   
   
   - A table may contain a simple PK or a composite one.
   - If no PK is defined for the table, the DAS tries to
 find one
  using
   COC.
   - If the table has a composite PK and not all the columns
 that
   compound the PK are contained on the ResultSet, the DAS
 ignores the
defined
   composite PK and tries to find another PK using COC as
 defined
  above.
   - If no PK is found using COC, the DAS sets all columns
 on
  ResultSet
   as PK.
   
- Setting the references on graph objects basing on table
  relationships.
   
   - Actually, there may be up to 1 relationship between 2
 tables.
   - The columns data that compound the FK are not created
 on the
  graph.
   - The DAS accepts simple or composite relationships.
   - If not all the columns, PK or FK, that compound the
 relationship
   are
   on the ResultSet, the relationship is ignored and the
 remaining FK
   are
   loaded onto graph.
   
- Actually, the DAS config can only be set from code.
   
- There are also implemented some testcases.
   
- DAS is only supporting the following SQL types: INTEGER,
 REAL, CHAR,
VARCHAR, FLOAT, DOUBLE.
   
Next steps:
   
- Read the config from a xml file.
   
- To implement a sample that reads some data from a database
 and print
   on
console.
   
- Implement support for more SQL types.
   
   
Comments and suggestions will be appreciated : )
   
Any volunteer would be helpful ; )
   
   
Regards,
   
Adriano Crestani
   
  
 

   
   
  
 





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

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

RE: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

2007-06-26 Thread Brady Johnson


Hello all,

I made a jira incident for this TUSCANY-1383.

I'm not able to get the test suite to work. Seems like it has some very
basic compilation issues (see below). I tried with a clean environment,
right out of the box, and that didn't work either. Can someone else try
it out and confirm if the test suite is broken.

 g++ -DHAVE_CONFIG_H -I. -I. -I../..
-I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/extensio
ns/cpp/include
-I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/include
-I/nfs/homes/bjohnson/tuscany_cpp/tuscany_sdo_cpp-1.0-incubator-M3-src/d
eploy/include -g -O2 -MT TestImpl.lo -MD -MP -MF .deps/TestImpl.Tpo -c
TestImpl.cpp  -fPIC -DPIC -o .libs/TestImpl.o
TestImpl.cpp: In member function `virtual bool
TestImpl::compareWithFile(commonj::sdo::DataObjectPtr, std::string)':
TestImpl.cpp:46: error: `Composite' was not declared in this scope
TestImpl.cpp:46: error: `composite' was not declared in this scope
TestImpl.cpp:46: error: `getInstance' is not a member of
`tuscany::sca::SCARuntime'
TestImpl.cpp:57: error: `Utils' has not been declared
TestImpl.cpp:57: error: `compareDataObjects' was not declared in this
scope
TestImpl.cpp:61: error: `Utils' has not been declared
TestImpl.cpp:61: error: `printDO' was not declared in this scope
TestImpl.cpp:63: error: `Utils' has not been declared
make[2]: *** [TestImpl.lo] Error 1


Thanks


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


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 20, 2007 12:28 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany SCA native/C++ : Ability to query the runtime for
its loaded operations

Brady,

Welcome aboard! The best way to proceed is to open a Jira (
https://issues.apache.org/jira/browse/TUSCANY) describing what you are
trying to achieve then attach a patch to the Jira. It's usually a good
idea to post on tuscany_dev when you submit a patch as some of us filter
off Jira messages and don't immediately see them. Then... some kindly
committer can apply and test the patch and, if all is well, commit it to
subversion.

What you are proposing sounds very reasonable so I will look out for a
Jira and patch.

Cheers,


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

 Hello all,

 Im investigating using TuscanySCA (C++ version) with a container other

 than Axis. To do this, the container needs to be able to obtain the 
 WSDL operations, etc loaded by Tuscany. I would like to propose 
 extending some of the Tuscany APIs to allow them to be queried, since 
 currently you can only do a find with an operation name. These query 
 operations could be done either by returning an iterator to the 
 internal map, or by just returning a list of map's value strings. The 
 second option would probably be safer and more thread-safe. Below are 
 the extensions that I propose adding:

 runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::liststd::string Composite::getNamespaces();

 runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
std::liststd::string WSDLDefinition::getPortTypes();
std::liststd::string WSDLDefinition::getOperations( const 
 std::string portTypeName );

 If its decided to allow the internal map to be iterated over, the 
 interface would look something like this:
 runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::mapstd::string, WSDLDefinition*::const_iterator 
 Composite::getNamespacesIteratorBegin();
std::mapstd::string, WSDLDefinition*::const_iterator 
 Composite::getNamespacesIteratorEnd();

 Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime()

 The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();

 With the system composite, the extension to the Composite class would 
 allow you to get all of the WSDL namespaces loaded. Then for each 
 namespace, the WSDLDefinition can be obtained by calling:
WSDLDefinition* Composite::findWSDLDefinition(const std::string 
 wsdlNamespace);

 Then, for each WSDLDefinition, all of the WSDL PortTypes can be 
 obtained by calling the getPortTypes() method above. Then for each 
 PortType, the actual operations can be retreived by calling the 
 getOperations() method above.

 Im not currently a TuscanySCA contributor, so what would it take to 
 get these changes in?

 Thanks

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




--
Pete

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

Re: svn commit: r550739 - /incubator/tuscany/java/sdo/pom.xml


The EMF 2.2.2 are back into maven repos, we should be ok for now.

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

You can stop them being picked up transitively with:

dependency
groupIdorg.apache.tuscany.sdo/groupId
artifactIdtuscany-sdo-impl/artifactId
version1.0-incubating-SNAPSHOT/version
exclusions
   exclusion
  groupIdorg.eclipse.emf/groupId
  artifactIdcommon/artifactId
   /exclusion
... and all the other emf dependencies ...
  /exclusions

Just tried this, unfortunately it doesn't seem like you can do that for
maven plugins so as we're using the tuscany-sdo-plugin in both SCA and DAS
that continues to want the 2.2.2 jars.

So looks like the next DAS and SCA releases are blocked till either the
2.2.2 jars become available in some public repository or there's a new SDO
release using the 2.2.3 ones.

   ...ant

On 6/26/07, kelvin goodson [EMAIL PROTECTED] wrote:

 If the levels of the EMF dependency are not defined transitively via the
 SDO dependency then I guess that should be fine.  I had imagined they would
 have been picked up indirectly from the beta1 pom.

 Regards, Kelvin.

 On 26/06/07, ant elder [EMAIL PROTECTED] wrote:
  If the 2.2.3 jars work ok with the beta1 code and they're available in a
  repo then could we just change the SCA and DAS pom's to exclude the
  2.2.2jars and include the
  2.2.3 ones?
 
 ...ant
 
  On 6/26/07, [EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:
  
   Author: kelvingoodson
   Date: Tue Jun 26 01:38:08 2007
   New Revision: 550739
  
   URL: http://svn.apache.org/viewvc?view=revrev=550739
   Log:
   Updating the trunk to EMF 2.2.3 -- this doesn't fix the DAS release
   problem because they are based on the SDO beta1,  and so still require
 EMF
   2.2.2 to be published somewhere,  but at last it stops the trunk from
   failing.  This update solves part of the issue in TUSCANY-1369
  
   Modified:
   incubator/tuscany/java/sdo/pom.xml
  
   Modified: incubator/tuscany/java/sdo/pom.xml
   URL:
  
 
http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/pom.xml?view=diffrev=550739r1=550738r2=550739
  
  
 ==

   --- incubator/tuscany/java/sdo/pom.xml (original)
   +++ incubator/tuscany/java/sdo/pom.xml Tue Jun 26 01:38:08 2007
   @@ -75,7 +75,7 @@
  
properties
specVersion2.1/specVersion
   -emfVersion2.2.2/emfVersion
   +emfVersion2.2.3/emfVersion
 sdo.version${version}/sdo.version
/properties
  
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 





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

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

Re: Added a Spring based sample, was: 0.91 release?


Jean-Sebastien Delfino wrote:

Jean-Sebastien Delfino wrote:

[snip]
Venkata Krishnan wrote:

Hi

So here is a list of things that will be included for the 0.91 release.

- binding-ajax (has sample to demonstrate this)
- extension-helper (the scripting extensions demonstrate this)
- binding-ejb
- binding-feed (the bigbank demo uses this)
- implementation-resource   (the bigbank demo uses this)
- implementation-spring  (no sample, no demos, but interesting to 
have and

hope Sebastien is able to contribute a sample for this).

As far as demos and samples are concerned I intend to include only 
the ones
that have READMEs.  So if you folks can help me fix READMEs for the 
ones

that need to be included and that don't have this, that will be very
helpful.

Finally, may I request that any improvements or changes which any of 
you
wish to be a included in the release be done on the branch and then 
also
merged with the trunk immediately.  I hope we don't have large ones 
;-).


Thanks.



I have added a sample showing how to use the implementation-resource 
extension under [1]. I can add merge it into the 0.91 branch in a day 
or two after people get a chance to review it if you think it's 
useful to have in the release. It doesn't have a README yet, I'll try 
to add one tomorrow.


I'm still working on a Spring sample as well, it will be a variation 
of the simple-bigbank sample.


[1] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/ 





I have added a Spring sample under [2]. This is a variation of the 
simple-bigbank sample that uses a nested Spring assembly using 
implementation.spring instead of a nested SCA assembly using 
implementation.composite.


Here are the relevant XML snippets.

The original SCA simple-bigbank:

BigBank.composite

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://bigbank;
xmlns:a=http://account;
xmlns:s=http://stockquote;
name=BigBank

   component name=AccountServiceComponent
   implementation.composite name=a:Account/
   reference name=stockQuoteService 
target=StockQuoteServiceComponent/

   /component

   component name=StockQuoteServiceComponent
   implementation.composite name=s:StockQuote/
   /component

/composite


Account.composite

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://account;
name=Account
 service name=AccountService 
promote=AccountServiceComponent/


   component name=AccountServiceComponent
   implementation.java class=bigbank.account.AccountServiceImpl/
   reference name=accountDataService 
target=AccountDataServiceComponent/

   property name=currencyUSD/property
   /component

   component name=AccountDataServiceComponent
   implementation.java 
class=bigbank.accountdata.AccountDataServiceImpl/

   /component
  reference name=stockQuoteService 
promote=AccountServiceComponent/stockQuoteService/


/composite


The SCA + Spring based spring-bigbank:

BigBank.composite

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://bigbank;
xmlns:s=http://stockquote;
name=BigBank

   component name=AccountServiceComponent
   implementation.spring location=Account-spring-context.xml/
   reference name=stockQuoteService 
target=StockQuoteServiceComponent/

   /component

   component name=StockQuoteServiceComponent
   implementation.composite name=s:StockQuote/
   /component

/composite


Account-spring-context.xml

beans xmlns=http://www.springframework.org/schema/beans;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xmlns:sca=http://www.springframework.org/schema/sca;
  xsi:schemaLocation=http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd;


   bean id=AccountServiceBean 
class=bigbank.account.AccountServiceImpl

   property name=accountDataService ref=AccountDataServiceBean/
   property name=stockQuoteService ref=stockQuoteService/
   property name=currency value=USD/
   /bean

   bean id=AccountDataServiceBean 
class=bigbank.accountdata.AccountDataServiceImpl

   /bean

/beans



[2] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/spring-bigbank/ 





I improved the sample a bit to show how to declare proper SCA services 
and references in a Spring assembly, using the Spring SCA extension 
elements.


Account-spring-context.xml now looks like this:

beans xmlns=http://www.springframework.org/schema/beans;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xmlns:sca=http://www.springframework.org/schema/sca;
  xsi:schemaLocation=
  http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/sca 
http://www.springframework.org/schema/sca/spring-sca.xsd;


   sca:service name=AccountService
   type=bigbank.account.AccountService

Re: [EMF Artifacts] Working with cat.pdx.edu


Hey Ole, the eclipse EMF artifacts are now available on the repos, i
just had a sucessful build from the DAS beta1 branch.

On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote:

I have not heard back from them yet either.  How about this:

We rsync this repository to a tuscany server.  Make the repository web 
accessible.  Add the additional artifacts manually.  We just need to add the 
pom.xml and the jar as shown here:

http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/

Which contains:
http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/codegen-2.2.0-RC2a.jar
http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/codegen-2.2.0-RC2a.pom

So to add the codegen dependency needed we would just have make following URLs 
work as well:
http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0/codegen-2.2.0.jar
http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0/codegen-2.2.0.pom

So we if had the artifacts on a Tuscany server then we just add the following 
files below the /emf directory:

codegen/2.2.0/codegen-2.2.0.jar
codegen/2.2.0/codegen-2.2.0.pom

Then we could also request that this repository be synced with IBiblio.  
Thoughts?

Cheers,
- Ole



Luciano Resende wrote:
 Just tried (already including cat.pdx.edu), and these are the missing
 dependencies :


 Missing:
 --
 1) org.eclipse.emf:codegen:jar:2.2.2

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.eclipse.emf
 -DartifactId=codegen \
  -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1)
 org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1
2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1
3) org.eclipse.emf:codegen:jar:2.2.2

 2) org.eclipse.emf:codegen-ecore:jar:2.2.2

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.eclipse.emf
 -DartifactId=codegen-ecore \
  -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1)
 org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1
2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1
3) org.eclipse.emf:codegen-ecore:jar:2.2.2

 3) org.eclipse.emf:ecore-xmi:jar:2.2.2

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.eclipse.emf
 -DartifactId=ecore-xmi \
  -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1)
 org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1
2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1
3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1
4) org.eclipse.emf:ecore-xmi:jar:2.2.2

 4) org.eclipse.emf:ecore-change:jar:2.2.2

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.eclipse.emf
 -DartifactId=ecore-change \
  -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1)
 org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1
2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1
3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1
4) org.eclipse.emf:ecore-change:jar:2.2.2

 5) org.eclipse.emf:common:jar:2.2.2

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.eclipse.emf
 -DartifactId=common \
  -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1)
 org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1
2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1
3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1
4) org.eclipse.emf:common:jar:2.2.2

 --
 5 required artifacts are missing.

 for artifact:
  org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1


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


 On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote:

Tuscany - ServiceMix integration, was: servicemix-sca now compiling


[snip]
Guillaume Nodet wrote:

Copying tuscany dev list ...



The discussion is now continuing on the servicemix-dev list:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02159.html

--
Jean-Sebastien


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

Re: Permission denied when trying to commit changes

2007-06-26 Thread Davanum Srinivas


Andy,

Please try now. Sorry for the delay.

-- dims

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

Probably dims needs to update your karma. I've not seen the response back
from root for you id yet, you may need to just wait a little longer.

   ...ant

On 6/26/07, Andy Grove [EMAIL PROTECTED] wrote:
 I am trying to submit my first change now that I have committer status but
I'm getting a 403 Forbidden error.

 Authentication realm: https://svn.apache.org:443 ASF Committers
 Username: myusername
 Password for 'myusername': **
 svn: Commit failed (details follow):
 svn: MKACTIVITY of
'/repos/asf/!svn/act/20b54094-59ad-2e4b-b6f4-9b67020e49ce':
403 Forbidden ( https://svn.apache.org)

 I used the following URL when running the checkout command:

 https://svn.apache.org/repos/asf/incubator/tuscany/java

 Can anyone give me any pointers to what the problem might be? I have
changed both my SSH and SVN passwords from the initially supplied password.

 Thanks,

 Andy Grove
 Product Architect, HydraSDO
 Rogue Wave Software






--
Davanum Srinivas :: http://davanum.wordpress.com

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

DAS Beta1 distros


I have built DAS distros that are intend to be the DAS beta1 RC and
they are available for a quick review at :

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

I still need to make a final review to the distros and provide an
updated release notes.

Please let me know if you find any problems, I'll give it a day for
people to comment on these distros, and will then cut a release
candidate based on the das-beta1 branch.

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

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

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

2007-06-26 Thread Pete Robbins


There is no test suite for C++ SCA. The code under Test is not
maintained as far as I am aware and is not part of the distributions.

For testing we build/run the samples.

Cheers,

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


Hello all,

I made a jira incident for this TUSCANY-1383.

I'm not able to get the test suite to work. Seems like it has some very
basic compilation issues (see below). I tried with a clean environment,
right out of the box, and that didn't work either. Can someone else try
it out and confirm if the test suite is broken.

 g++ -DHAVE_CONFIG_H -I. -I. -I../..
-I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/extensio
ns/cpp/include
-I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/include
-I/nfs/homes/bjohnson/tuscany_cpp/tuscany_sdo_cpp-1.0-incubator-M3-src/d
eploy/include -g -O2 -MT TestImpl.lo -MD -MP -MF .deps/TestImpl.Tpo -c
TestImpl.cpp  -fPIC -DPIC -o .libs/TestImpl.o
TestImpl.cpp: In member function `virtual bool
TestImpl::compareWithFile(commonj::sdo::DataObjectPtr, std::string)':
TestImpl.cpp:46: error: `Composite' was not declared in this scope
TestImpl.cpp:46: error: `composite' was not declared in this scope
TestImpl.cpp:46: error: `getInstance' is not a member of
`tuscany::sca::SCARuntime'
TestImpl.cpp:57: error: `Utils' has not been declared
TestImpl.cpp:57: error: `compareDataObjects' was not declared in this
scope
TestImpl.cpp:61: error: `Utils' has not been declared
TestImpl.cpp:61: error: `printDO' was not declared in this scope
TestImpl.cpp:63: error: `Utils' has not been declared
make[2]: *** [TestImpl.lo] Error 1


Thanks


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


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 20, 2007 12:28 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany SCA native/C++ : Ability to query the runtime for
its loaded operations

Brady,

Welcome aboard! The best way to proceed is to open a Jira (
https://issues.apache.org/jira/browse/TUSCANY) describing what you are
trying to achieve then attach a patch to the Jira. It's usually a good
idea to post on tuscany_dev when you submit a patch as some of us filter
off Jira messages and don't immediately see them. Then... some kindly
committer can apply and test the patch and, if all is well, commit it to
subversion.

What you are proposing sounds very reasonable so I will look out for a
Jira and patch.

Cheers,


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

 Hello all,

 Im investigating using TuscanySCA (C++ version) with a container other

 than Axis. To do this, the container needs to be able to obtain the
 WSDL operations, etc loaded by Tuscany. I would like to propose
 extending some of the Tuscany APIs to allow them to be queried, since
 currently you can only do a find with an operation name. These query
 operations could be done either by returning an iterator to the
 internal map, or by just returning a list of map's value strings. The
 second option would probably be safer and more thread-safe. Below are
 the extensions that I propose adding:

 runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::liststd::string Composite::getNamespaces();

 runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
std::liststd::string WSDLDefinition::getPortTypes();
std::liststd::string WSDLDefinition::getOperations( const
 std::string portTypeName );

 If its decided to allow the internal map to be iterated over, the
 interface would look something like this:
 runtime/core/src/tuscany/sca/model/Composite.h/cpp
std::mapstd::string, WSDLDefinition*::const_iterator
 Composite::getNamespacesIteratorBegin();
std::mapstd::string, WSDLDefinition*::const_iterator
 Composite::getNamespacesIteratorEnd();

 Once the projects have been loaded by calling:
tuscany::sca::SCARuntime::initializeSharedRuntime()

 The system composite can then be obtained by calling:
tuscany::sca::model::Composite* SCARuntime::getSystem();

 With the system composite, the extension to the Composite class would
 allow you to get all of the WSDL namespaces loaded. Then for each
 namespace, the WSDLDefinition can be obtained by calling:
WSDLDefinition* Composite::findWSDLDefinition(const std::string
 wsdlNamespace);

 Then, for each WSDLDefinition, all of the WSDL PortTypes can be
 obtained by calling the getPortTypes() method above. Then for each
 PortType, the actual operations can be retreived by calling the
 getOperations() method above.

 Im not currently a TuscanySCA contributor, so what would it take to
 get these changes in?

 Thanks

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




--
Pete

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





--
Pete

Re: Permission denied when trying to commit changes

2007-06-26 Thread Andy Grove


Excellent! All working now.

Thanks,

Andy.


On 6/26/07, Davanum Srinivas [EMAIL PROTECTED] wrote:

Andy,

Please try now. Sorry for the delay.

-- dims

On 6/26/07, ant elder [EMAIL PROTECTED] wrote:
 Probably dims needs to update your karma. I've not seen the response back
 from root for you id yet, you may need to just wait a little longer.

...ant

 On 6/26/07, Andy Grove [EMAIL PROTECTED] wrote:
  I am trying to submit my first change now that I have committer status but
 I'm getting a 403 Forbidden error.
 
  Authentication realm: https://svn.apache.org:443 ASF Committers
  Username: myusername
  Password for 'myusername': **
  svn: Commit failed (details follow):
  svn: MKACTIVITY of
 '/repos/asf/!svn/act/20b54094-59ad-2e4b-b6f4-9b67020e49ce':
 403 Forbidden ( https://svn.apache.org)
 
  I used the following URL when running the checkout command:
 
  https://svn.apache.org/repos/asf/incubator/tuscany/java
 
  Can anyone give me any pointers to what the problem might be? I have
 changed both my SSH and SVN passwords from the initially supplied password.
 
  Thanks,
 
  Andy Grove
  Product Architect, HydraSDO
  Rogue Wave Software
 




--
Davanum Srinivas :: http://davanum.wordpress.com

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





--
Thanks,

Andy Grove.

Office: +44 1245 225447
Mobile: +44 7775 688081

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

RE: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

2007-06-26 Thread Brady Johnson


Ok, that's comforting to know. I did run the samples and they work with
my additions. I also exercised the additions with a ProjectLoader driver
that I wrote, and they also worked as expected. 

Thanks


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



-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 26, 2007 11:08 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany SCA native/C++ : Ability to query the runtime for
its loaded operations

There is no test suite for C++ SCA. The code under Test is not
maintained as far as I am aware and is not part of the distributions.

For testing we build/run the samples.

Cheers,

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

 Hello all,

 I made a jira incident for this TUSCANY-1383.

 I'm not able to get the test suite to work. Seems like it has some 
 very basic compilation issues (see below). I tried with a clean 
 environment, right out of the box, and that didn't work either. Can 
 someone else try it out and confirm if the test suite is broken.

  g++ -DHAVE_CONFIG_H -I. -I. -I../..
 -I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/extens
 io
 ns/cpp/include
 -I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/includ
 e 
 -I/nfs/homes/bjohnson/tuscany_cpp/tuscany_sdo_cpp-1.0-incubator-M3-src
 /d eploy/include -g -O2 -MT TestImpl.lo -MD -MP -MF .deps/TestImpl.Tpo

 -c TestImpl.cpp  -fPIC -DPIC -o .libs/TestImpl.o
 TestImpl.cpp: In member function `virtual bool 
 TestImpl::compareWithFile(commonj::sdo::DataObjectPtr, std::string)':
 TestImpl.cpp:46: error: `Composite' was not declared in this scope
 TestImpl.cpp:46: error: `composite' was not declared in this scope
 TestImpl.cpp:46: error: `getInstance' is not a member of 
 `tuscany::sca::SCARuntime'
 TestImpl.cpp:57: error: `Utils' has not been declared
 TestImpl.cpp:57: error: `compareDataObjects' was not declared in this 
 scope
 TestImpl.cpp:61: error: `Utils' has not been declared
 TestImpl.cpp:61: error: `printDO' was not declared in this scope
 TestImpl.cpp:63: error: `Utils' has not been declared
 make[2]: *** [TestImpl.lo] Error 1


 Thanks

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


 -Original Message-
 From: Pete Robbins [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, June 20, 2007 12:28 PM
 To: tuscany-dev@ws.apache.org
 Subject: Re: Tuscany SCA native/C++ : Ability to query the runtime for

 its loaded operations

 Brady,

 Welcome aboard! The best way to proceed is to open a Jira (
 https://issues.apache.org/jira/browse/TUSCANY) describing what you are

 trying to achieve then attach a patch to the Jira. It's usually a good

 idea to post on tuscany_dev when you submit a patch as some of us 
 filter off Jira messages and don't immediately see them. Then... some 
 kindly committer can apply and test the patch and, if all is well, 
 commit it to subversion.

 What you are proposing sounds very reasonable so I will look out for a

 Jira and patch.

 Cheers,


 On 20/06/07, Brady Johnson [EMAIL PROTECTED] wrote:
 
  Hello all,
 
  Im investigating using TuscanySCA (C++ version) with a container 
  other

  than Axis. To do this, the container needs to be able to obtain the 
  WSDL operations, etc loaded by Tuscany. I would like to propose 
  extending some of the Tuscany APIs to allow them to be queried, 
  since currently you can only do a find with an operation name. These

  query operations could be done either by returning an iterator to 
  the internal map, or by just returning a list of map's value 
  strings. The second option would probably be safer and more 
  thread-safe. Below are the extensions that I propose adding:
 
  runtime/core/src/tuscany/sca/model/Composite.h/cpp
 std::liststd::string Composite::getNamespaces();
 
  runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
 std::liststd::string WSDLDefinition::getPortTypes();
 std::liststd::string WSDLDefinition::getOperations( const 
  std::string portTypeName );
 
  If its decided to allow the internal map to be iterated over, the 
  interface would look something like this:
  runtime/core/src/tuscany/sca/model/Composite.h/cpp
 std::mapstd::string, WSDLDefinition*::const_iterator 
  Composite::getNamespacesIteratorBegin();
 std::mapstd::string, WSDLDefinition*::const_iterator 
  Composite::getNamespacesIteratorEnd();
 
  Once the projects have been loaded by calling:
 tuscany::sca::SCARuntime::initializeSharedRuntime()
 
  The system composite can then be obtained by calling:
 tuscany::sca::model::Composite* SCARuntime::getSystem();
 
  With the system composite, the extension to the Composite class 
  would allow you to get all of the WSDL namespaces loaded. Then for 
  each namespace, the WSDLDefinition can be obtained by calling:
 WSDLDefinition* Composite::findWSDLDefinition(const

Re: Supporting callbacks across Web Services

2007-06-26 Thread Simon Nash


I am making good progress with getting callbacks working across the
Web Service binding.  In the process of doing this I have learned a lot
about SCA callbacks and the Tuscany runtime.  So far the code changes
I have made are all fairly minor, and working out what is needed has
been a good learning experience.

My changes are divided into two categories:
 1. fixing some bugs in the core runtime framework for supporting
callbacks when bindings are involved
 2. reinstating the code in the Web Service binding that handles
callbacks.

I see the latter as a temporary solution only and I intend to look
into how to make callbacks using WS-Addressing which would be the
correct way to fully support SCA callback semantics.

I have now run into an architecture/design issue and I'd like to
explain it and get some reactions.

My frst attempt to find the binding interface information for a
callback was to use a naming convention that the callback interface
PortType name must be interfacenameCallback, where interfacename
is the name of the PortType for the regular interface.  I did this
because I thought the Web Service binding spec did not provide enough
information to obtain the callback interface from the SCDL.  It turns
out that the spec does have a way to provide this information.
A reference that uses a bidirectional interface can be defined as:

 reference name=myService target=MyServiceComponent
 interface.java interface=simplecallback.MyService
 callbackInterface=simplecallback.MyServiceCallback/
 binding.ws 
wsdlElement=http://simplecallback#wsdl.port(MyServiceSoapService/MyServiceSoapPort)/
 callback
 binding.ws 
wsdlElement=http://simplecallback#wsdl.binding(MyServiceCallbackSoapBinding)/
 /callback
 /reference

where the callback binding interface is specified in the binding
element within the callback element.

Now we come to the issue that I mentioned earlier.  The forward binding
and the callback binding in the above SCDL are different bindings.
In the model, they would be represented as:
 reference myService
 interface contract
 forward binding interface
 callback binding interface
 forward binding.ws
 binding interface
 (other forward bindings)
 callback
 callback binding.ws
 binding interface
 (other callback bindings)

Now contrast this with the model we currently have in Tuscany.  We would
need to represent the above as:
 reference myService
 interface contract
 forward binding interface
 callback binding interface
 binding.ws
 binding interface contract
 forward binding interface
 callback binding interface
 (other bindings)

The problem with the latter is that there's no place to put the callback
binding.  In the example above, they are both Web Service bindings, but
they don't have to be.  The forward and callback binding types could be
different (e.g., Web Service for forward calls and JMS for callbacks),
and the Tuscany core runtime should support this.  Of course, having this
kind of a mixture would require suitable enablement in the binding
providers as well.  But even if the forward and callback bindings are
both Web Service bindings, we will need to have two distinct bindings
for these when we move to the correct WS-Addressing implementation.

At the moment I'm proceeding under the assumption that Tuscany should
implement the spec in this area, so in my testbed I'm changing the
model from the latter to the former.  This will have some minor impact
in various parts of the code (and probably one or two SPIs) so I'd welcome
comments and opinions on whether this is the correct path to follow.

  Simon

scabooz wrote:


Simon,

I think it great that you're trying to tackle this problem and it seems 
like

You're on the right track.  My only suggestion (at this point) is to first
get the runtime back to where it was before .90 from the perspective
of the SCA app, if that's possible.

Only one comment embedded below.

Dave


- Original Message - From: Matthew Sykes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, June 19, 2007 8:44 AM
Subject: Re: Supporting callbacks across Web Services


I did notice that the code that is responsible for creating the 
callback wires / invocation chains out of createWires on the service 
side is currently commented out in the CompositeActivatorImpl.  When 
that code is uncommented I found that the callback proxy was injected 
as there were callback wires associated with the service.  Even when 
the proxy is injected, the rest of the issues you've raised still come 
into play.


I'm interested in the progress you make here as I'm also trying to 
figure out how to make callbacks work when the callback target is not 
local to the composite containing the service.  Right now it seems 
that callbacks only work when the reference and service are associated 
with components in the

Re: Tuscany SCA native/C++ : Ability to query the runtime for its loaded operations

2007-06-26 Thread Pete Robbins


Good stuff. It may be a few days before I can test/apply this.

Cheers,

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


Ok, that's comforting to know. I did run the samples and they work with
my additions. I also exercised the additions with a ProjectLoader driver
that I wrote, and they also worked as expected.

Thanks


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



-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 26, 2007 11:08 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany SCA native/C++ : Ability to query the runtime for
its loaded operations

There is no test suite for C++ SCA. The code under Test is not
maintained as far as I am aware and is not part of the distributions.

For testing we build/run the samples.

Cheers,

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

 Hello all,

 I made a jira incident for this TUSCANY-1383.

 I'm not able to get the test suite to work. Seems like it has some
 very basic compilation issues (see below). I tried with a clean
 environment, right out of the box, and that didn't work either. Can
 someone else try it out and confirm if the test suite is broken.

  g++ -DHAVE_CONFIG_H -I. -I. -I../..
 -I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/extens
 io
 ns/cpp/include
 -I/nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_latest/sca/deploy/includ
 e
 -I/nfs/homes/bjohnson/tuscany_cpp/tuscany_sdo_cpp-1.0-incubator-M3-src
 /d eploy/include -g -O2 -MT TestImpl.lo -MD -MP -MF .deps/TestImpl.Tpo

 -c TestImpl.cpp  -fPIC -DPIC -o .libs/TestImpl.o
 TestImpl.cpp: In member function `virtual bool
 TestImpl::compareWithFile(commonj::sdo::DataObjectPtr, std::string)':
 TestImpl.cpp:46: error: `Composite' was not declared in this scope
 TestImpl.cpp:46: error: `composite' was not declared in this scope
 TestImpl.cpp:46: error: `getInstance' is not a member of
 `tuscany::sca::SCARuntime'
 TestImpl.cpp:57: error: `Utils' has not been declared
 TestImpl.cpp:57: error: `compareDataObjects' was not declared in this
 scope
 TestImpl.cpp:61: error: `Utils' has not been declared
 TestImpl.cpp:61: error: `printDO' was not declared in this scope
 TestImpl.cpp:63: error: `Utils' has not been declared
 make[2]: *** [TestImpl.lo] Error 1


 Thanks

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


 -Original Message-
 From: Pete Robbins [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, June 20, 2007 12:28 PM
 To: tuscany-dev@ws.apache.org
 Subject: Re: Tuscany SCA native/C++ : Ability to query the runtime for

 its loaded operations

 Brady,

 Welcome aboard! The best way to proceed is to open a Jira (
 https://issues.apache.org/jira/browse/TUSCANY) describing what you are

 trying to achieve then attach a patch to the Jira. It's usually a good

 idea to post on tuscany_dev when you submit a patch as some of us
 filter off Jira messages and don't immediately see them. Then... some
 kindly committer can apply and test the patch and, if all is well,
 commit it to subversion.

 What you are proposing sounds very reasonable so I will look out for a

 Jira and patch.

 Cheers,


 On 20/06/07, Brady Johnson [EMAIL PROTECTED] wrote:
 
  Hello all,
 
  Im investigating using TuscanySCA (C++ version) with a container
  other

  than Axis. To do this, the container needs to be able to obtain the
  WSDL operations, etc loaded by Tuscany. I would like to propose
  extending some of the Tuscany APIs to allow them to be queried,
  since currently you can only do a find with an operation name. These

  query operations could be done either by returning an iterator to
  the internal map, or by just returning a list of map's value
  strings. The second option would probably be safer and more
  thread-safe. Below are the extensions that I propose adding:
 
  runtime/core/src/tuscany/sca/model/Composite.h/cpp
 std::liststd::string Composite::getNamespaces();
 
  runtime/core/src/tuscany/sca/model/WSDLDefinition.h/cpp
 std::liststd::string WSDLDefinition::getPortTypes();
 std::liststd::string WSDLDefinition::getOperations( const
  std::string portTypeName );
 
  If its decided to allow the internal map to be iterated over, the
  interface would look something like this:
  runtime/core/src/tuscany/sca/model/Composite.h/cpp
 std::mapstd::string, WSDLDefinition*::const_iterator
  Composite::getNamespacesIteratorBegin();
 std::mapstd::string, WSDLDefinition*::const_iterator
  Composite::getNamespacesIteratorEnd();
 
  Once the projects have been loaded by calling:
 tuscany::sca::SCARuntime::initializeSharedRuntime()
 
  The system composite can then be obtained by calling:
 tuscany::sca::model::Composite* SCARuntime::getSystem();
 
  With the system composite, the extension to the Composite class
  would allow you to get all of the WSDL namespaces loaded. Then for
  each namespace, the

Re: Notification implementation

2007-06-26 Thread Ignacio Silva-Lepe


Hi Jean-Sebastien,

Apologies for the tardiness, I was away and without connectivity for a
couple
of days.
Responses in line.


On 6/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Ignacio Silva-Lepe wrote:
 I have been playing with the idea of a notification component
 implementation
 type that would serve as a vehicle to incorporate pub/sub interactions
 into
 SCA/Tuscany. Within a single composite or domain, producers and
consumers
 would be explicitly wired to and from a notification component (ie, a
 component with an implementation.notification). In addition, to enable
 produ-
 cers and consumers to exchange messages across domains or even across
 composites, a binding.notification could be used by composite references
 and services.
 I would like to create a couple of new modules in trunk to host code to
 support
 implementation.notification and binding.notification. If people are ok
 with
 it, I would
 like to do this in the next few days.
 Thoughts?


That sounds useful to me. I have a few questions:

Could you describe here how an application developer would program a
notification component? Will the component implement a fixed
notification interface or will this support user defined business
interfaces? Are notification methods just one-way methods?



A notification component would be specified for a given 'space' of messages,
denoted by the interface in a corresponding notification component type,
which in turn is referred to by the notification component's implementation.
This interface is app-specific and defines the makeup of the messages being
exchanged. At least initially, notification methods are intended to be
one-way.

What are you proposing for implementation and binding element? what

would they look like? How do you declare what you're going to publish
and how does a component declare a subscription? Do you have a sample
composite that you could paste here?



The proposed elements would be implementation.notification and
binding.notification. A component becomes a publisher or producer by using
a reference to a notification component, and a component declares a
subscription
by defining a service that is wired from a notification component.

Here's a sample composite for a 'local' notification use case, ie, where
producers
and consumers are contained in the same composite (or domain) and explicitly
wired to/from the notification component:


composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
  name=TrafficAdvisoryNotificationLocalComposite

   component name=TrafficAdvisoryProducer
   implementation.java class=
org.apache.tuscany.sca.implementation.notification.TrafficAdvisoryProducer
/
   reference name=destination
target=TrafficAdvisoryNotificationComponent/
   /component

   component name=TrafficAdvisoryNotificationComponent
   implementation.notification name=TrafficAdvisoryNotification/
   !-- Never use  1 reference elements here !! --
   reference name=TrafficAdvisoryNotificationReference
  multiplicity=0..n
  target=TrafficAdvisoryConsumer1
TrafficAdvisoryConsumer2/
   /component

   component name=TrafficAdvisoryConsumer1
   implementation.java class=
org.apache.tuscany.sca.implementation.notification.TrafficAdvisoryConsumer
/
   property name=nameConsumer1/property
   /component

   component name=TrafficAdvisoryConsumer2
   implementation.java class=
org.apache.tuscany.sca.implementation.notification.TrafficAdvisoryConsumer
/
   property name=nameConsumer2/property
   /component

/composite

and here's the corresponding component type:

componentType xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:xsd=
http://www.w3.org/2001/XMLSchema;
service name=TrafficAdvisoryNotificationService
  interface.java interface=
org.apache.tuscany.sca.implementation.notification.TrafficAdvisory/
/service

reference name=TrafficAdvisoryNotificationReference
   multiplicity=0..n
  interface.java interface=
org.apache.tuscany.sca.implementation.notification.TrafficAdvisory/
/reference
/componentType

Are you thinking of flowing notifications over various protocols already

supported by Tuscany? or adding a new protocol through this new binding?



I think the simplest case is to flow notifications as literal xml over http,
so that's
what I am working on prototyping.

Thanks


--
Jean-Sebastien


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

Re: Supporting callbacks across Web Services

2007-06-26 Thread Simon Nash


I thought of a slightly different approach that would be closer
to the current code.

  reference myService
  interface contract
  forward binding interface
  callback binding interface
  forward binding.ws
  binding interface contract
  forward binding interface
  null callback binding interface
  (other forward bindings)
  callback binding.ws
  binding interface contract
  null forward binding interface
  callback binding interface
  (other callback bindings)

I'll see how I get on with this.

  Simon

Simon Nash wrote:


I am making good progress with getting callbacks working across the
Web Service binding.  In the process of doing this I have learned a lot
about SCA callbacks and the Tuscany runtime.  So far the code changes
I have made are all fairly minor, and working out what is needed has
been a good learning experience.

My changes are divided into two categories:
 1. fixing some bugs in the core runtime framework for supporting
callbacks when bindings are involved
 2. reinstating the code in the Web Service binding that handles
callbacks.

I see the latter as a temporary solution only and I intend to look
into how to make callbacks using WS-Addressing which would be the
correct way to fully support SCA callback semantics.

I have now run into an architecture/design issue and I'd like to
explain it and get some reactions.

My frst attempt to find the binding interface information for a
callback was to use a naming convention that the callback interface
PortType name must be interfacenameCallback, where interfacename
is the name of the PortType for the regular interface.  I did this
because I thought the Web Service binding spec did not provide enough
information to obtain the callback interface from the SCDL.  It turns
out that the spec does have a way to provide this information.
A reference that uses a bidirectional interface can be defined as:

 reference name=myService target=MyServiceComponent
 interface.java interface=simplecallback.MyService
 callbackInterface=simplecallback.MyServiceCallback/
 binding.ws 
wsdlElement=http://simplecallback#wsdl.port(MyServiceSoapService/MyServiceSoapPort)/ 


 callback
 binding.ws 
wsdlElement=http://simplecallback#wsdl.binding(MyServiceCallbackSoapBinding)/ 


 /callback
 /reference

where the callback binding interface is specified in the binding
element within the callback element.

Now we come to the issue that I mentioned earlier.  The forward binding
and the callback binding in the above SCDL are different bindings.
In the model, they would be represented as:
 reference myService
 interface contract
 forward binding interface
 callback binding interface
 forward binding.ws
 binding interface
 (other forward bindings)
 callback
 callback binding.ws
 binding interface
 (other callback bindings)

Now contrast this with the model we currently have in Tuscany.  We would
need to represent the above as:
 reference myService
 interface contract
 forward binding interface
 callback binding interface
 binding.ws
 binding interface contract
 forward binding interface
 callback binding interface
 (other bindings)

The problem with the latter is that there's no place to put the callback
binding.  In the example above, they are both Web Service bindings, but
they don't have to be.  The forward and callback binding types could be
different (e.g., Web Service for forward calls and JMS for callbacks),
and the Tuscany core runtime should support this.  Of course, having this
kind of a mixture would require suitable enablement in the binding
providers as well.  But even if the forward and callback bindings are
both Web Service bindings, we will need to have two distinct bindings
for these when we move to the correct WS-Addressing implementation.

At the moment I'm proceeding under the assumption that Tuscany should
implement the spec in this area, so in my testbed I'm changing the
model from the latter to the former.  This will have some minor impact
in various parts of the code (and probably one or two SPIs) so I'd welcome
comments and opinions on whether this is the correct path to follow.

  Simon

scabooz wrote:


Simon,

I think it great that you're trying to tackle this problem and it 
seems like
You're on the right track.  My only suggestion (at this point) is to 
first

get the runtime back to where it was before .90 from the perspective
of the SCA app, if that's possible.

Only one comment embedded below.

Dave


- Original Message - From: Matthew Sykes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, June 19, 2007 8:44 AM
Subject: Re: Supporting callbacks across Web Services


I did notice that the code that is responsible for creating the 
callback wires / invocation

[jira] Updated: (TUSCANY-1385) Duplicate namespace was serialized when SDO QName property value containing existing namespace

2007-06-26 Thread Fuhwei Lwo (JIRA)


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

Fuhwei Lwo updated TUSCANY-1385:


Attachment: 1385.patch

 Duplicate namespace was serialized when SDO QName property value containing 
 existing namespace
 --

 Key: TUSCANY-1385
 URL: https://issues.apache.org/jira/browse/TUSCANY-1385
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-1.0

 Attachments: 1385.patch


 If SDO QName property has value like 
 http://www.w3.org/2001/XMLSchema-instance#anyURI;, the serialized XML would 
 have duplicate xmlns:xsi - one from existing XML stream and the other one was 
 newly created.
 composite xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

-- 
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-1385) Duplicate namespace was serialized when SDO QName property value containing existing namespace

2007-06-26 Thread Fuhwei Lwo (JIRA)

Duplicate namespace was serialized when SDO QName property value containing 
existing namespace
--

 Key: TUSCANY-1385
 URL: https://issues.apache.org/jira/browse/TUSCANY-1385
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
 Environment: WinXP
Reporter: Fuhwei Lwo
 Fix For: Java-SDO-1.0
 Attachments: 1385.patch

If SDO QName property has value like 
http://www.w3.org/2001/XMLSchema-instance#anyURI;, the serialized XML would 
have duplicate xmlns:xsi - one from existing XML stream and the other one was 
newly created.

composite xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

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


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

Re: [VOTE] Fuhwei Lwo for Tuscany Committer

2007-06-26 Thread Mike Edwards


+1 from me

Yours, Mike.

kelvin goodson wrote:

I'd like to propose Fuhwei Lwo as a Tuscany Committer.

According to my gmail archive he has, since mid of 2006, posted 114 
times to

tusany-dev, 79 of those times resulting from interactions with JIRA issue
management.

He has raised 34 JIRAs (see [1])

The gmail search  -- from:fuhwei [jira] Attachment: shows 
that

Fuhwei has attached around 27 patches to JIRAs.

The JIRAs he raises, the comments he makes and the solutions he provides
demonstrate in depth knowledge of SDO and clearly he will be a strong asset
for the community.

Please vote to give Fuhwei this well deserved status

Regards, Kelvin.

[1]
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC 





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

Re: Geronimo/Tuscany integration

Raymond is away for one more week, so I'll try to answer some of these 
questions.



Manu George wrote:

Hi Raymond/Jay,

 I would like to join this effort. I would like to discuss what
is expected of the deep integration. I will just list down my
understanding of both the current and proposed integrations

Understanding of the Current Integration

1) TuscanyContextListener creates an SCA domain when the servlet is
created and then destroys it when the servlet is destroyed.
2) During SCA domain creation it looks up the composites and deploys
them in the domain
Creates a webapp module activator for registering servlet hosts.
3) Finally we have a servlet that forwards requests to the servlet
registered with the Tuscany Servlet Host.
4) An SCADomain is created for each application and we can lookup the
services from the SCADomain.
5) During SCADomain creation a runtime is also created for the 
DefaultSCADomain.

7) All tuscany classes are loaded repeatedly for each application in
separate classloaders.
8) A runtime is created per application


Correct. I'm assuming that you're talking about the current Webapp 
integration.


As a heads up the SCADomain class is probably going to change a bit to 
load a subset of components deployed to an actual SCA domain. The idea 
is to distribute an SCA domain across runtimes, each runtime running one 
or more domain level SCA components (and components nested in their 
composites).




Understanding/Doubts about the proposed Integration.

1) Each SCA application will have an SCA module which will be a jar
with an SCDL in META-INF. This jar can also be part of an EAR. . There
will be a Tuscany deployer that will take care of deploying the SCA
modules. Should WAR files be also able to contain SCA jars?


Will the application developer be exposed to this? If it's the case then 
it looks like a new programming / packaging  model, different from SCA :)


An SCA application developer normally packages application artifacts in 
an SCA contribution (a form of archive described in the SCA assembly 
spec) and the .composite (SCDL) files are not necessarily under 
META-INF. in fact usually we place them with the other development 
artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application 
developer wouldn't have to learn a different packaging model to run his 
SCA components on Geronimo. Will there be a way to deploy an SCA 
contribution to Geronimo natively without having to repackage it in a 
J2EE archive?



2) Each App will have an SCA Domain which will be instantiated when
the application starts. Is this assumption correct or can there be
multiple SCADomains per app?


The objects deployed to an SCA domain and which run on an SCA runtime 
are SCA components. There is no concept of an App like a J2EE App in SCA 
at the moment.


Components can be implemented by a simple Java class, a BPEL process, a 
script, etc. or a Composite. A Composite describes an assembly of 
Components, allowing for nested composition of components. An SCA domain 
is described by a composite, describing the assembly of top level 
components in an administration domain. The SCA domain composite does 
not necessarily have to written to a single .composite file since it has 
to be distributed, but it is effectively modeled as a composite.


So to go back to your question, objects that run on an SCA runtime are 
SCA components, and each component belongs to a single SCA Domain composite.


Now with respect to instances of the SCADomain class, I was thinking 
about two options:


(a) one instance of SCADomain per component running on the server, 
loaded with a subset of the distributed SCA domain composite 
representing that component and enough information about its peer 
components for it to locate and wire to them.


(b) a single SCADomain object per Geronimo server, loaded with all the 
components running on the server. This will save a little bit of memory, 
at the expense of more synchronization work.


I'd suggest to start with option (a) as it's the model that needs to be 
supported when SCA components run on different physical machines as 
well, and I'm actually not sure that we'll get any real performance gain 
with (b) over (a) if we do (a) right.



3) The Tuscany classes are loaded only once and then shared between
the different SCA applications.


+1


4) There will be multiple domains instantiated from different
applications and there should be a server wide domain registry where
applications can look up and invoke different composites from domains
different from their own. (Can this be Global JNDI/Gbean refs or is
there something specific in tuscany).


An SCA domain is a domain of administration typically containing 
multiple servers. Wiring and lookups are assumed to work within the 
context of a single domain. We could imagine a Geronimo server hosting 
components from multiple SCA administration domains, but I'm not sure 
that it's going to be a very common scenario.

[jira] Created: (TUSCANY-1386) TuscanySCA C++: The usage of the std::map operator[] in Composite::findWSDLDefinition() could cause problems

TuscanySCA C++: The usage of the std::map operator[] in 
Composite::findWSDLDefinition() could cause problems


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


The std::mapK,V::operator[] will insert a blank object of type V if the key 
is not found in the map.

The method Composite::findWSDLDefinition() simply returns 
wsdlDefinitions[wsdlNamespace]
which will insert an entry in the map. This could cause problems if the map was 
previously empty.
This could also cause problems if type V is not a pointer, which it is in this 
case.


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


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


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

Re: DAS Beta1 distros

2007-06-26 Thread haleh mahbod


I downloaded bin distribution. There is no readme for samples.  Shouldn't
readme be included with sample distribution under bin?

On 6/26/07, Luciano Resende [EMAIL PROTECTED] wrote:


I have built DAS distros that are intend to be the DAS beta1 RC and
they are available for a quick review at :

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

I still need to make a final review to the distros and provide an
updated release notes.

Please let me know if you find any problems, I'll give it a day for
people to comment on these distros, and will then cut a release
candidate based on the das-beta1 branch.

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

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

[jira] Updated: (TUSCANY-1386) TuscanySCA C++: The usage of the std::map operator[] in Composite::findWSDLDefinition() could cause problems


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

Brady Johnson updated TUSCANY-1386:
---

Attachment: Composite_cpp_jira1386

Attaching fix that uses map::find() instead of map::operator[]

 TuscanySCA C++: The usage of the std::map operator[] in 
 Composite::findWSDLDefinition() could cause problems
 

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

 Attachments: Composite_cpp_jira1386


 The std::mapK,V::operator[] will insert a blank object of type V if the key 
 is not found in the map.
 The method Composite::findWSDLDefinition() simply returns 
 wsdlDefinitions[wsdlNamespace]
 which will insert an entry in the map. This could cause problems if the map 
 was previously empty.
 This could also cause problems if type V is not a pointer, which it is in 
 this case.
 
 Brady Johnson
 Lead Software Developer - HydraSCA
 Rogue Wave Software - [EMAIL PROTECTED]

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


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

[jira] Created: (TUSCANY-1387) Missing sample readme in binary distributions

Missing sample readme in binary distributions
-

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




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


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

[jira] Created: (TUSCANY-1388) Missing LICENSE, README and NOTICE on DAS distributions

Missing LICENSE, README and NOTICE on DAS distributions
---

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


This is due to file renaming... need to fix the assembly that copy these files 
to the distribution

-- 
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: DAS Beta1 distros


Thanks Haleh, I also noticed that, after I renamed the README, LICENSE
and NOTICE, these files were not being included on the
distributions... I have created JIRAS, and will update the distros
once these issues are fixed.

On 6/26/07, haleh mahbod [EMAIL PROTECTED] wrote:

I downloaded bin distribution. There is no readme for samples.  Shouldn't
readme be included with sample distribution under bin?

On 6/26/07, Luciano Resende [EMAIL PROTECTED] wrote:

 I have built DAS distros that are intend to be the DAS beta1 RC and
 they are available for a quick review at :

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

 I still need to make a final review to the distros and provide an
 updated release notes.

 Please let me know if you find any problems, I'll give it a day for
 people to comment on these distros, and will then cut a release
 candidate based on the das-beta1 branch.

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

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






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

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

TuscanySCA C++: The usage of the std::map::operator[] in Composite::findWSDLDefinition() could cause problems

2007-06-26 Thread Brady Johnson

The std::mapK,V operator[] will insert a blank object of type V if the
key is not found in the map. 
 
The method Composite::findWSDLDefinition() simply returns
wsdlDefinition[wsdlNamespace] which will insert an entry in the map. If
the map was previously empty, this could cause problems. In this case V
is a pointer, but if it were'nt you could run into other problems as
well.
 
I would like to suggest that Composite::findWSDLDefinition() is changed
to use the method map::find() instead of map::operator[].
 
I created a JIRA for this and included a patch.
 
https://issues.apache.org/jira/browse/TUSCANY-1386
 
Thanks
 

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

[jira] Assigned: (TUSCANY-1388) Missing LICENSE, README and NOTICE on DAS distributions


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

Luciano Resende reassigned TUSCANY-1388:


Assignee: Luciano Resende

 Missing LICENSE, README and NOTICE on DAS distributions
 ---

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


 This is due to file renaming... need to fix the assembly that copy these 
 files to the distribution

-- 
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-1387) Missing sample readme in binary distributions


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

Luciano Resende updated TUSCANY-1387:
-

Fix Version/s: (was: Java-SDO-beta1)
   Java-DAS-beta1

 Missing sample readme in binary distributions
 -

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




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


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

[jira] Resolved: (TUSCANY-1388) Missing LICENSE, README and NOTICE on DAS distributions


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

Luciano Resende resolved TUSCANY-1388.
--

   Resolution: Fixed
Fix Version/s: Java-DAS-Next

Fixed in trunk and beta1 branch

 Missing LICENSE, README and NOTICE on DAS distributions
 ---

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


 This is due to file renaming... need to fix the assembly that copy these 
 files to the distribution

-- 
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-1387) Missing sample readme in binary distributions


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

Luciano Resende resolved TUSCANY-1387.
--

   Resolution: Fixed
Fix Version/s: Java-DAS-Next

Fixed in trunk and beta1 branch

 Missing sample readme in binary distributions
 -

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




-- 
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: DAS Beta1 distros


I have fixed the legal files and sample readme files and already
refreshed the distro on the link below :

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


On 6/26/07, Luciano Resende [EMAIL PROTECTED] wrote:

Thanks Haleh, I also noticed that, after I renamed the README, LICENSE
and NOTICE, these files were not being included on the
distributions... I have created JIRAS, and will update the distros
once these issues are fixed.

On 6/26/07, haleh mahbod [EMAIL PROTECTED] wrote:
 I downloaded bin distribution. There is no readme for samples.  Shouldn't
 readme be included with sample distribution under bin?

 On 6/26/07, Luciano Resende [EMAIL PROTECTED] wrote:
 
  I have built DAS distros that are intend to be the DAS beta1 RC and
  they are available for a quick review at :
 
 http://people.apache.org/~lresende/tuscany/das-beta1-distribution/
 
  I still need to make a final review to the distros and provide an
  updated release notes.
 
  Please let me know if you find any problems, I'll give it a day for
  people to comment on these distros, and will then cut a release
  candidate based on the das-beta1 branch.
 
  --
  Luciano Resende
  Apache Tuscany Committer
  http://people.apache.org/~lresende
  http://lresende.blogspot.com/
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



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




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

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

Re: [DISCUSS] Geronimo-Tuscany integration


Comments inline.

Vamsavardhana Reddy wrote:

Hi,

Myself and Manu have done some work (a small PoC) on Geronimo Tuscany
integration.  As a first step, we have created a plugin for Geronimo
that will let the user to deploy standalone tuscany modules into
Geronimo and use the deployed services by looking up in JNDI.  I have
put the code in Geronimo Sandbox at
https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/.


Great! I started to look at it, I'll try to get it running but it may 
take a few days before I get to it.


Which version of Geronimo should I use? M6 or Trunk? the full J2EE 
server or is Little-G sufficient?




Going forward, we have the following in mind:
A) Write a deploymentwatcher so that Tuscany modules can be bundled as
part of J2EE artifacts.


More on this below in my answer to your question (2).


B) Extend the current deployer to enable Tuscany Modules deployed in
Geronimo to access resources like datasources from Geronimo


Will the datasources be used internally by a Data Access component 
runtime (like the Tuscany DAS extension) or an ODE/BPEL component 
integration runtime (which I think uses a database) for example?


Or are you thinking about exposing the datasources to application code, 
and if it's the case, what will an application developer have to write 
to use them?




Some of the questions we have are:
1.  Should we use this plugin approach and host the plugin separatley
or intergrate Tuscany to be bundled as part of the Geronimo
distribution?


The plugin approach looks OK to me, but maybe somebody from the Geronimo 
project could give a more educated opinion?



2.  Should we have support for bundling Tuscany composites in WAR,
EJB-JAR and EAR?  Or should we provide for adding a separate Tuscany
module in EAR?


This is similar to a question you had in a previous thread, see question 
(1) in [1].


I had the following scenarios in mind, with my application developer hat on:

(a) I develop SCA components, assemble them in a composite, package them 
in an SCA contribution. I don't really know what a WAR or an EAR is, I'm 
just using the SCA programming model and packaging model. I deploy my 
SCA contribution to Geronimo and run it there.


(b) I'm assembling SCA components, some of them developed using the SCA 
programming model (Java components, BPEL components or composite 
components for example) and I want to re-use an EJB module in my 
assembly, allowing other SCA components to talk to its session beans 
using the SCA programming model. That EJB module does not know anything 
about SCA, it only uses the EJB programming model.


(c) I want to use a Web app in my SCA assembly and call SCA components 
from it. I should be able to declare an SCA component representing my 
Web app, wire that component to other SCA components in the assembly, 
and then magically the wired references will be available as proxies for 
use in my JSPs, allowing me to call an SCA component using a simple 
jsp:useBean tag.


(d) I want to bundle SCA components directly inside the Web app. IMO 
this scenario raises a number of issues as it introduces a mixed Webapp 
/ SCA programming model which is not really specified, limits the 
ability of components to expose services through non-Webapp-friendly 
bindings (I'm not sure how a component in a Webapp could expose a JMS 
service for example), and does not give a clear status to individual 
JSPs, I'm not sure if they would be declared as components or not for 
example...


To summarize:
(a) is about running SCA components on Geronimo
(b) is about using EJB modules as SCA components, it is described in an 
OSOA white paper at [2]
(c) is about providing access to SCA components to Web apps, described 
in [2] as well
(d) I'm not sure what this one is about :), Assembly of Enterprise 
applications in [2] briefly touches on it, maybe others on the list can 
help clarify this one.


I would suggest to start with scenarios (a) and (c) which, if I 
understand correctly, would not need to bundle SCA composites in J2EE 
archives, at least not in a way visible to the application developer.


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19312.html
[2] http://www.osoa.org/pages/viewpage.action?pageId=3980


3.  Where should we maintain the integration code?



I'd suggest to continue at 
https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ 
for now.


Thoughts?


Your comments and suggestions will be very helpful in taking it further.

Thanks and best regards,
Vamsi



--
Jean-Sebastien


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

[jira] Created: (TUSCANY-1389) published DTD for composite XML Schema needed/useful

2007-06-26 Thread James Tomkinson (JIRA)

published DTD for composite XML Schema needed/useful


 Key: TUSCANY-1389
 URL: https://issues.apache.org/jira/browse/TUSCANY-1389
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA 
Samples
Affects Versions: Java-SCA-0.90
 Environment: java
Reporter: James Tomkinson
Priority: Minor


Samples should supply a DOCTYPE in *.composite xml files, that points to a 
stored DTD, so that XML editing tools can be used to create/edit/validate XML 
schema.   This will enhance productivity/accuracy.

!DOCTYPE hibernate-configuration PUBLIC
-//Hibernate/Hibernate Configuration DTD 3.0//EN

http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd;

-- 
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-1389) published DTD for composite XML Schema needed/useful

2007-06-26 Thread James Tomkinson (JIRA)


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

James Tomkinson updated TUSCANY-1389:
-

Description: 
Samples should supply a DOCTYPE in *.composite xml files, that points to a 
stored DTD, so that XML editing tools can be used to create/edit/validate XML 
schema.   This will enhance productivity/accuracy.

Example for Hibernate:
!DOCTYPE hibernate-configuration PUBLIC
-//Hibernate/Hibernate Configuration DTD 3.0//EN

http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd;

  was:
Samples should supply a DOCTYPE in *.composite xml files, that points to a 
stored DTD, so that XML editing tools can be used to create/edit/validate XML 
schema.   This will enhance productivity/accuracy.

!DOCTYPE hibernate-configuration PUBLIC
-//Hibernate/Hibernate Configuration DTD 3.0//EN

http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd;


 published DTD for composite XML Schema needed/useful
 

 Key: TUSCANY-1389
 URL: https://issues.apache.org/jira/browse/TUSCANY-1389
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA 
 Samples
Affects Versions: Java-SCA-0.90
 Environment: java
Reporter: James Tomkinson
Priority: Minor

 Samples should supply a DOCTYPE in *.composite xml files, that points to a 
 stored DTD, so that XML editing tools can be used to create/edit/validate XML 
 schema.   This will enhance productivity/accuracy.
 Example for Hibernate:
 !DOCTYPE hibernate-configuration PUBLIC
   -//Hibernate/Hibernate Configuration DTD 3.0//EN
   
 http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd;

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

Bigger fonts on Tuscany web site?