Re: New proposal to make DAS/SDO HOW TO

[Katja]

Hi!

Is it possible to add a Timestamp or DateTime column to the database? I am very 
interested in how to access these columns with DAS and MySQL because I have not 
succeeded in doing this.

Thanks,
Katja

 Original-Nachricht 
Datum: Thu, 16 Nov 2006 03:44:18 -0400
Von: Adriano Crestani [EMAIL PROTECTED]
An: tuscany-dev@ws.apache.org
Betreff: Re: New proposal to make DAS/SDO HOW TO

 Willian, I created these tables, that will possible be used in the
 shopping
 cart app. It's simple, but I think a howto sample must be simple. And if
 you
 want to add anything, feel free ; )
 
 CREATE TABLE CART (
 ID INTEGER,
 PRIMARY KEY (ID)
 );
 
 CREATE TABLE ITEM (
 ID INTEGER,
 ITEM VARCHAR(30),
 UNITS INTEGER,
 CART_ID INTEGER,
 PRIMARY KEY (ID),
 FOREIGN KEY (CART_ID) REFERENCES CART(ID)
 );
 
 
 
 On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Hey Guys
 
 Very good to see some progress and some contents being generated. I
  agree
  with you guys when you say this is becoming more like a user guide,
  instead
  of a How To, and building it describing a new scenario would probably
 make
  things more clear, altough let's try to keep it simple on the beginning,
  otherwise we are going to get a White paper :)
 
 I think we should describe actions that you would take when trying to
  create an application and describe how you would do it (e.g Now we need
 to
  execute a query to read the list of products, and this is how you would
 do
  using DAS), and point the user to further documentation in case it
  needs/want to know more about the specific feature (e.g if they want to
  learn the whole syntax/xsd of the das config file).
 
 I think couple things should not be covered on the How to :
- How to build a war file
- How to create a database (altough you might provide the SQL
  statements to create the tables you would use or at least describe the
 DB
  schema)
 
 Now, talking about what should be in this how-to
- We could start very simple... 1 product table, and one simple
 jsp
  that gives you a list of the products available
- Using MySQL is good, altough this how to should not really be
  database dependent, right ? we could point it to any database, and you
  guys
  could maybe elaborate on what change would be necessary to do this :)
 
 Also, I think this how to does not necessarily need to produce a
  working
  application, as it's intended to show how people would use DAS. If we
 want
  to spend time creating an application, I'd suggest doing this as another
  task, and finish the one I have started as part of
  http://issues.apache.org/jira/browse/TUSCANY-800
 
  Let me know if you have any further questions... let's continue to
  updating
  the wiki, and please let me know when you guys want me to take a look
 and
  provide a feedback on the contents...
 
  BTW, others are welcome to voice their opinion on what direction we
 should
  take here...
 
 
  - Luciano Resende
  Apache Tuscany
 
 
  On 11/15/06, Adriano Crestani [EMAIL PROTECTED] wrote:
  
   I've decribed the XML configuration file, but it's still looking like
 a
   user
   guide than a howto. I think the CompanyWeb sample is to simple and
  doesn't
   cover well all the DAS features. So lets make this Shopping Cart
   application
   trying to use all the DAS features. Then we will be able to do a very
   useful
   howto.
  
 My propose is that this app must have at least:
  
- 1 functionality that requires a SQL command with arguments.
 Then
  we
   cover how to deal with arguments in SQL commands.
  
   - 1 table that has one autoincrement key column to cover the
   genarated
   attribute on the howto.
  
   - 1 table that requires a concurrency control to cover the
   concurrency
   attribute on the howto.
  
  - 1 table containing a foreign key to cover how to explicit in the
  XML
   configuration file the link between two tables. There will probabily
 be
  a
   foreign key in its database anyway. ; )
  
   I think also a good idea to use the MySql as the database server, once
   it's
   the most used server on webapps ; )
  
   We must discuss how will be the Shopping Cart GUI, it must be simple
  once
   it's not the focus of our howto. I think a simple html genarated by a
  jsp
   is
   enough. ; )
  
   Adriano Crestani
  
   On 11/15/06, Willian Yabusame Maja [EMAIL PROTECTED] wrote:
   
Hello Tuscany Community!
   
Adriano Crestani and I are working together on a HelloWorld DAS
  How
To. I have uploaded what we have done so far to
   
  
 
 http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp
   
We were using the CompanyWeb sample application to make this
step-by-step how-to and teach how to use the DAS/SDO Features. We
 are
   not
liking what this is becoming, as it's looking more like a
   user-gide/readme
then really a how-to, 

Re: New proposal to make DAS/SDO HOW TO

[Luciano Resende]

Won't the Cart x Item relationship be a many to many relationship ?
Currently, one item can only be in one cart, right ?
You probably looking for something like this

CREATE TABLE CART (
  ID INTEGER PRIMARY KEY,
  SUB_TOTAL DOUBLE,
  TAX DOUBLE,
  TOTAL DOUBLE
);

CREATE TABLE ITEM (
  ID INTEGER,
  DESC VARCHAR(30),
  UNITS INTEGER,
  PRICE DOUBLE
);

CREATE TABLE CART_ITEM(
  CART_ID INTEGER,
  ITEM_ID INTEGER,
  QUANTITY INTEGER,
  FOREIGN KEY (CART_ID) REFERENCES CART(ID),
  FOREIGN KEY (ITEM_ID) REFERENCES ITEM(ID)
)



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

On 11/15/06, Adriano Crestani [EMAIL PROTECTED] wrote:


Willian, I created these tables, that will possible be used in the
shopping
cart app. It's simple, but I think a howto sample must be simple. And if
you
want to add anything, feel free ; )

CREATE TABLE CART (
ID INTEGER,
PRIMARY KEY (ID)
);

CREATE TABLE ITEM (
ID INTEGER,
ITEM VARCHAR(30),
UNITS INTEGER,
CART_ID INTEGER,
PRIMARY KEY (ID),
FOREIGN KEY (CART_ID) REFERENCES CART(ID)
);



On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:

 Hey Guys

Very good to see some progress and some contents being generated. I
 agree
 with you guys when you say this is becoming more like a user guide,
 instead
 of a How To, and building it describing a new scenario would probably
make
 things more clear, altough let's try to keep it simple on the beginning,

 otherwise we are going to get a White paper :)

I think we should describe actions that you would take when trying to
 create an application and describe how you would do it (e.g Now we need
to
 execute a query to read the list of products, and this is how you would
do
 using DAS), and point the user to further documentation in case it
 needs/want to know more about the specific feature (e.g if they want to
 learn the whole syntax/xsd of the das config file).

I think couple things should not be covered on the How to :
   - How to build a war file
   - How to create a database (altough you might provide the SQL
 statements to create the tables you would use or at least describe the
DB
 schema)

Now, talking about what should be in this how-to
   - We could start very simple... 1 product table, and one simple
jsp
 that gives you a list of the products available
   - Using MySQL is good, altough this how to should not really be
 database dependent, right ? we could point it to any database, and you
 guys
 could maybe elaborate on what change would be necessary to do this :)

Also, I think this how to does not necessarily need to produce a
 working
 application, as it's intended to show how people would use DAS. If we
want
 to spend time creating an application, I'd suggest doing this as another
 task, and finish the one I have started as part of
 http://issues.apache.org/jira/browse/TUSCANY-800

 Let me know if you have any further questions... let's continue to
 updating
 the wiki, and please let me know when you guys want me to take a look
and
 provide a feedback on the contents...

 BTW, others are welcome to voice their opinion on what direction we
should
 take here...


 - Luciano Resende
 Apache Tuscany


 On 11/15/06, Adriano Crestani  [EMAIL PROTECTED] wrote:
 
  I've decribed the XML configuration file, but it's still looking like
a
  user
  guide than a howto. I think the CompanyWeb sample is to simple and
 doesn't
  cover well all the DAS features. So lets make this Shopping Cart
  application
  trying to use all the DAS features. Then we will be able to do a very
  useful
  howto.
 
My propose is that this app must have at least:
 
   - 1 functionality that requires a SQL command with arguments.
Then
 we
  cover how to deal with arguments in SQL commands.
 
  - 1 table that has one autoincrement key column to cover the
  genarated
  attribute on the howto.
 
  - 1 table that requires a concurrency control to cover the
  concurrency
  attribute on the howto.
 
 - 1 table containing a foreign key to cover how to explicit in the
 XML
  configuration file the link between two tables. There will probabily
be
 a
  foreign key in its database anyway. ; )
 
  I think also a good idea to use the MySql as the database server, once
  it's
  the most used server on webapps ; )
 
  We must discuss how will be the Shopping Cart GUI, it must be simple
 once
  it's not the focus of our howto. I think a simple html genarated by a
 jsp
  is
  enough. ; )
 
  Adriano Crestani
 
  On 11/15/06, Willian Yabusame Maja [EMAIL PROTECTED] wrote:
  
   Hello Tuscany Community!
  
   Adriano Crestani and I are working together on a HelloWorld DAS
 How
   To. I have uploaded what we have done so far to
  
 
 
http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp

  
   We were using the CompanyWeb sample application to make this
   step-by-step how-to and teach how to use the 

Re: Bundles and OSGi

[Jeremy Boynes]

On 11/15/06, Hawkins, Joel [EMAIL PROTECTED] wrote:


-Original Message-
From: Wengatz, Nicole [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 15, 2006 10:23 AM
To: Hawkins, Joel
Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert
Subject: RE: Bundles and OSGi

I performed now some tests with BuddyClassLoader. The core bundle gets
an entry 'Eclipse-BuddyPolicy: registered'
and the other bundles register at the core bundle. If the core bundle
requires classes it searches in the registered
buddies. The performance seems to bad a little bit worser (but still in
milliseconds). After the core bundle loaded a class
from one of the other bundles (e.g. B) you cannot refresh bundle B. If
you would like to update bundle B you have to
refresh the core and again all bundles get refreshed.
BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse
guys are planning to bring it into OSGI R4.1.



This worries me a little as I would not like to think that the only
OSGi implementation that was supported was Eclipse's. When is 4.1 due
and/or does, for example, Felix offer something similar to this?

--
Jeremy

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

Re: New proposal to make DAS/SDO HOW TO

[Adriano Crestani]

Yes, it's many to many, I just thought in a simple way to do this, where the
user would define its own items. But many to many is OK ; ).

On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:


Won't the Cart x Item relationship be a many to many relationship ?
Currently, one item can only be in one cart, right ?
You probably looking for something like this

CREATE TABLE CART (
   ID INTEGER PRIMARY KEY,
   SUB_TOTAL DOUBLE,
   TAX DOUBLE,
   TOTAL DOUBLE
);

CREATE TABLE ITEM (
   ID INTEGER,
   DESC VARCHAR(30),
   UNITS INTEGER,
   PRICE DOUBLE
);

CREATE TABLE CART_ITEM(
   CART_ID INTEGER,
   ITEM_ID INTEGER,
   QUANTITY INTEGER,
   FOREIGN KEY (CART_ID) REFERENCES CART(ID),
   FOREIGN KEY (ITEM_ID) REFERENCES ITEM(ID)
)



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

On 11/15/06, Adriano Crestani [EMAIL PROTECTED] wrote:

 Willian, I created these tables, that will possible be used in the
 shopping
 cart app. It's simple, but I think a howto sample must be simple. And if
 you
 want to add anything, feel free ; )

 CREATE TABLE CART (
 ID INTEGER,
 PRIMARY KEY (ID)
 );

 CREATE TABLE ITEM (
 ID INTEGER,
 ITEM VARCHAR(30),
 UNITS INTEGER,
 CART_ID INTEGER,
 PRIMARY KEY (ID),
 FOREIGN KEY (CART_ID) REFERENCES CART(ID)
 );



 On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Hey Guys
 
 Very good to see some progress and some contents being generated. I
  agree
  with you guys when you say this is becoming more like a user guide,
  instead
  of a How To, and building it describing a new scenario would probably
 make
  things more clear, altough let's try to keep it simple on the
beginning,

  otherwise we are going to get a White paper :)
 
 I think we should describe actions that you would take when trying
to
  create an application and describe how you would do it (e.g Now we
need
 to
  execute a query to read the list of products, and this is how you
would
 do
  using DAS), and point the user to further documentation in case it
  needs/want to know more about the specific feature (e.g if they want
to
  learn the whole syntax/xsd of the das config file).
 
 I think couple things should not be covered on the How to :
- How to build a war file
- How to create a database (altough you might provide the SQL
  statements to create the tables you would use or at least describe the
 DB
  schema)
 
 Now, talking about what should be in this how-to
- We could start very simple... 1 product table, and one simple
 jsp
  that gives you a list of the products available
- Using MySQL is good, altough this how to should not really be
  database dependent, right ? we could point it to any database, and you
  guys
  could maybe elaborate on what change would be necessary to do this :)
 
 Also, I think this how to does not necessarily need to produce a
  working
  application, as it's intended to show how people would use DAS. If we
 want
  to spend time creating an application, I'd suggest doing this as
another
  task, and finish the one I have started as part of
  http://issues.apache.org/jira/browse/TUSCANY-800
 
  Let me know if you have any further questions... let's continue to
  updating
  the wiki, and please let me know when you guys want me to take a look
 and
  provide a feedback on the contents...
 
  BTW, others are welcome to voice their opinion on what direction we
 should
  take here...
 
 
  - Luciano Resende
  Apache Tuscany
 
 
  On 11/15/06, Adriano Crestani  [EMAIL PROTECTED] wrote:
  
   I've decribed the XML configuration file, but it's still looking
like
 a
   user
   guide than a howto. I think the CompanyWeb sample is to simple and
  doesn't
   cover well all the DAS features. So lets make this Shopping Cart
   application
   trying to use all the DAS features. Then we will be able to do a
very
   useful
   howto.
  
 My propose is that this app must have at least:
  
- 1 functionality that requires a SQL command with arguments.
 Then
  we
   cover how to deal with arguments in SQL commands.
  
   - 1 table that has one autoincrement key column to cover the
   genarated
   attribute on the howto.
  
   - 1 table that requires a concurrency control to cover the
   concurrency
   attribute on the howto.
  
  - 1 table containing a foreign key to cover how to explicit in
the
  XML
   configuration file the link between two tables. There will probabily
 be
  a
   foreign key in its database anyway. ; )
  
   I think also a good idea to use the MySql as the database server,
once
   it's
   the most used server on webapps ; )
  
   We must discuss how will be the Shopping Cart GUI, it must be simple
  once
   it's not the focus of our howto. I think a simple html genarated by
a
  jsp
   is
   enough. ; )
  
   Adriano Crestani
  
   On 11/15/06, Willian Yabusame Maja [EMAIL PROTECTED] wrote:
   
Hello Tuscany Community!
   
  

Harmonizing Ruby support in Tuscany

[Andrew Borley]

Hi all,

I was recently asked to chat with a few people about the Ruby support
in Tuscany, so I spent a bit of time looking at the support we provide
in both the C++ and Java sides of Tuscany.
There are a few differences that, in the absence of a spec, we should
try to fix up so that we've at least got a consistent Tuscany story.
(I'm not saying these are worth holding back M2 for - just thought I'd
document them so we can get some discussion going).

1) implementation.rb element in SCDL.
In Tuscany Java, a component is defined like:
component name=HelloWorldComponent
  rb:implementation.rb script=HelloWorld.rb class=Helloworld
 xmlns:rb=http://tuscany.apache.org/xmlns/rb/1.0/
/component

Whereas, in Tuscany C++ it is:
component name=HelloWorldComponent
  implementation.ruby script=HelloWorld.rb class=Helloworld/
/component

These are pretty similar aside from the element name
(implementation.rb vs. implementation.ruby) and the fact that Java
have their own namespace whereas C++ use the SCA namespace
http://www.osoa.org/xmlns/sca/1.0 namespace. My own preference is
implementation.ruby and a tuscany namespace
(http://tuscany.apache.org/xmlns/ruby/1.0 or similar).

I couldn't find a schema for Java's implementation.rb, C++'s is at
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/xsd/sca-implementation-ruby.xsd
The C++ schema doesn't actually include the script attribute used
above (preferring module instead) - script is supported in the
implementation. We should decide on a single schema for the
implementation.ruby element.


2) Interface definitions
Tuscany Java requires a WSDL or Java interface to be specified for a
Ruby component via a componentType file or in a $SCA variable in the
Ruby script, e.g:
$SCA = {
  'javaInterface' = 'helloworld.HelloWorldService'
}
Tuscany C++ does not require any interface specification, instead
attempting to invoke a specified method but failing if the method name
does not exist or the wrong number of parameters are supplied.

I remember that there are currently restrictions in the Java runtime
that mean an interface is required, but it would be cool if we didn't
force Ruby scripters to write that Java or WSDL interface.
C++ should support the use of a WSDL interface to allow Ruby
components to be remotable. Perhaps we need a Ruby2WSDL tool that
could work via annotations or the $SCA variable?


3) Ruby Client API
I don't think Tuscany Java has a client API for Ruby. In C++ there is
a client API library that matches the C++ client API, so that the SCA
runtime can be loaded and invoked from a Ruby script as follows:

require(tuscany_sca_ruby)

hello = SCA::locateService(HelloWorldComponent)

x = hello.sayHello(Everyone)
print x, \n

Should we create a Java version of this API so that Java components
can be called from Ruby, etc?


4) Data type support
Tuscany C++ maps the basic C++ data types to the Ruby int, float,
boolean, string, etc internal types. SDO is also supported via a
conversion to a REXML Document object. Other types will currently
cause an exception to be thrown.
Tuscany Java uses the JRuby conversion facilities to convert any Java
object (including the Java basic types) to the correct Ruby type. I
think SDOs (and other user-defined Java objects) are available inside
the Ruby script via the JRuby JavaProxy (which dynamically maps a Java
object to a Ruby object), so an SDO object inside Ruby is actually a
real Java SDO object.

We should probably have the data type conversions documented somewhere
so people understand what gets mapped to what and what data types are
supported.


On the subject of a spec, do people think OSOA.org should be working
on CI specs for Ruby and scripting languages in general? The SCA for
PHP folk have some documentation, but don't really talk about
specifications on the PHP mailing lists as it tends to be a turn-off
for the PHP community, who (IMO) like things to be a bit looser and
free-flowing.

What do people think?

Cheers
Andy

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

[jira] Created: (TUSCANY-933) XSD2Java Generator still generates EMF codes with -noEMF option on

[Fuhwei Lwo (JIRA)]

XSD2Java Generator still generates EMF codes with -noEMF option on
--

 Key: TUSCANY-933
 URL: http://issues.apache.org/jira/browse/TUSCANY-933
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Affects Versions: Java-Mx
Reporter: Fuhwei Lwo


This problem only occurred when base64Binary type was defined in the XSD.  The 
codegen tool would generate codes using EMF to handle base64Binary type.

public void initializeMetaData()
  {
if (isInitialized) return;
isInitialized = true;

// Obtain other dependent packages
ModelFactoryImpl theModelPackageImpl = 
(ModelFactoryImpl)FactoryBase.getStaticFactory(ModelFactoryImpl.NAMESPACE_URI);
XMLTypeFactoryImpl theXMLTypePackage = 
(XMLTypeFactoryImpl)FactoryBase.getStaticFactory(bXMLTypeFactoryImpl.NAMESPACE_URI/b);
Property property = null;

// Add supertypes to classes

// Initialize classes and features; add operations and parameters
initializeType(testTypeType, TestType.class, TestType);

property = (Property)testTypeType.getProperties().get(TestTypeImpl.NAME);
initializeProperty(property, theModelPackageImpl.getString(), Name, null, 
1, 1, TestType.class, false, false, false);

property = 
(Property)testTypeType.getProperties().get(TestTypeImpl.BASE64_VALUE);
initializeProperty(property, btheXMLTypePackage.getBase64Binary()/b, 
Base64Value, null, 1, 1, TestType.class, false, false, false);

property = 
(Property)testTypeType.getProperties().get(TestTypeImpl.HEX_VALUE);
initializeProperty(property, theModelPackageImpl.getBytes(), HexValue, 
null, 1, 1, TestType.class, false, false, false);

createXSDMetaData(theModelPackageImpl);
  }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

RE: Bundles and OSGi

[Hawkins, Joel]

Hi Jeremy,

I think this investigation is geared more towards optimization for a
particular platform, rather than exclusive support. I agree with you
that our base target should be the OSGi R4 spec, which currently has
broad support in the OSGi community. What Nicole is investigating are
possible mechanisms for generating OSGi bundles 'on the fly', so that we
can install extensions into an OSGi runtime without necessarily
requiring them to be pre-packaged (with full-blown OSGi manifests). This
is one of Jim's requests - support for a common extension packaging
format regardless of the target runtime. Specialization for a particular
OSGi implementation (i.e. using BuddyClassLoaders) doesn't seem
unreasonable in that context, so long as we support the general case as
well.

Of course, if the SCA spec were to embrace and extend the OSGi manifest
format... :-) 

Cheers,
Joel

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy
Boynes
Sent: Thursday, November 16, 2006 6:45 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Bundles and OSGi

On 11/15/06, Hawkins, Joel [EMAIL PROTECTED] wrote:

 -Original Message-
 From: Wengatz, Nicole [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 15, 2006 10:23 AM
 To: Hawkins, Joel
 Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert
 Subject: RE: Bundles and OSGi

 I performed now some tests with BuddyClassLoader. The core bundle gets
 an entry 'Eclipse-BuddyPolicy: registered'
 and the other bundles register at the core bundle. If the core bundle
 requires classes it searches in the registered
 buddies. The performance seems to bad a little bit worser (but still
in
 milliseconds). After the core bundle loaded a class
 from one of the other bundles (e.g. B) you cannot refresh bundle B. If
 you would like to update bundle B you have to
 refresh the core and again all bundles get refreshed.
 BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse
 guys are planning to bring it into OSGI R4.1.


This worries me a little as I would not like to think that the only
OSGi implementation that was supported was Eclipse's. When is 4.1 due
and/or does, for example, Felix offer something similar to this?

--
Jeremy

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

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

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

RE: Bundles and OSGi

[Wengatz, Nicole]

Hi Jeremy,

This worries me a little as I would not like to think that the only
OSGi 
implementation that was supported was Eclipse's. When is 4.1 due and/or
does,
for example, Felix offer something similar to this?
BuddyClassLoading is an alternative to the dynamic import feature. 
It's currently only supported in Eclipse, but the Equinox team is
planning to contribute
the design specifications for the upcoming OSGi R4.1 release, see:
http://wiki.eclipse.org/index.php/OSGi_R4.1_work

Therefore I expect that Felix is going to support it as well.

But it seems that there is no need to use it for Tuscany, we can
probably use
required-bundle or dynamic imports.

For the generation of bundles 'on the fly' we should hava a look to the
Spring-OSGi
integration and the maven support.

Best regards
Nicole

-Original Message-
From: Hawkins, Joel [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 16, 2006 2:45 PM
To: tuscany-dev@ws.apache.org
Subject: RE: Bundles and OSGi

Hi Jeremy,

I think this investigation is geared more towards optimization for a
particular platform, rather than exclusive support. I agree with you
that our base target should be the OSGi R4 spec, which currently has
broad support in the OSGi community. What Nicole is investigating are
possible mechanisms for generating OSGi bundles 'on the fly', so that we
can install extensions into an OSGi runtime without necessarily
requiring them to be pre-packaged (with full-blown OSGi manifests). This
is one of Jim's requests - support for a common extension packaging
format regardless of the target runtime. Specialization for a particular
OSGi implementation (i.e. using BuddyClassLoaders) doesn't seem
unreasonable in that context, so long as we support the general case as
well.

Of course, if the SCA spec were to embrace and extend the OSGi manifest
format... :-) 

Cheers,
Joel

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy
Boynes
Sent: Thursday, November 16, 2006 6:45 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Bundles and OSGi

On 11/15/06, Hawkins, Joel [EMAIL PROTECTED] wrote:

 -Original Message-
 From: Wengatz, Nicole [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 15, 2006 10:23 AM
 To: Hawkins, Joel
 Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert
 Subject: RE: Bundles and OSGi

 I performed now some tests with BuddyClassLoader. The core bundle gets

 an entry 'Eclipse-BuddyPolicy: registered'
 and the other bundles register at the core bundle. If the core bundle 
 requires classes it searches in the registered buddies. The 
 performance seems to bad a little bit worser (but still
in
 milliseconds). After the core bundle loaded a class from one of the 
 other bundles (e.g. B) you cannot refresh bundle B. If you would like 
 to update bundle B you have to refresh the core and again all bundles 
 get refreshed.
 BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse

 guys are planning to bring it into OSGI R4.1.


This worries me a little as I would not like to think that the only OSGi
implementation that was supported was Eclipse's. When is 4.1 due and/or
does, for example, Felix offer something similar to this?

--
Jeremy

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

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

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


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

Re: Wiki or website for doc?

[Dan Murphy]

I was looking at the Java SDO wiki...
there is a lot of overlap between the web site and the wiki... should we
clean up the wiki and link to the web site where appropriate (get rid of the
duplication) ?

Thanks in advance
Dan

Re: New proposal to make DAS/SDO HOW TO

[Willian Maja]

I don't know if it's possible to read TimeStamp, but I'll try. And thanks 
for the idea :).


Willian Yabusame Maja


From: Katja [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: New proposal to make DAS/SDO HOW TO
Date: Thu, 16 Nov 2006 09:14:28 +0100

Hi!

Is it possible to add a Timestamp or DateTime column to the database? I am 
very interested in how to access these columns with DAS and MySQL because I 
have not succeeded in doing this.


Thanks,
Katja

 Original-Nachricht 
Datum: Thu, 16 Nov 2006 03:44:18 -0400
Von: Adriano Crestani [EMAIL PROTECTED]
An: tuscany-dev@ws.apache.org
Betreff: Re: New proposal to make DAS/SDO HOW TO

 Willian, I created these tables, that will possible be used in the
 shopping
 cart app. It's simple, but I think a howto sample must be simple. And if
 you
 want to add anything, feel free ; )

 CREATE TABLE CART (
 ID INTEGER,
 PRIMARY KEY (ID)
 );

 CREATE TABLE ITEM (
 ID INTEGER,
 ITEM VARCHAR(30),
 UNITS INTEGER,
 CART_ID INTEGER,
 PRIMARY KEY (ID),
 FOREIGN KEY (CART_ID) REFERENCES CART(ID)
 );



 On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Hey Guys
 
 Very good to see some progress and some contents being generated. I
  agree
  with you guys when you say this is becoming more like a user guide,
  instead
  of a How To, and building it describing a new scenario would probably
 make
  things more clear, altough let's try to keep it simple on the 
beginning,

  otherwise we are going to get a White paper :)
 
 I think we should describe actions that you would take when trying 
to
  create an application and describe how you would do it (e.g Now we 
need

 to
  execute a query to read the list of products, and this is how you 
would

 do
  using DAS), and point the user to further documentation in case it
  needs/want to know more about the specific feature (e.g if they want 
to

  learn the whole syntax/xsd of the das config file).
 
 I think couple things should not be covered on the How to :
- How to build a war file
- How to create a database (altough you might provide the SQL
  statements to create the tables you would use or at least describe the
 DB
  schema)
 
 Now, talking about what should be in this how-to
- We could start very simple... 1 product table, and one simple
 jsp
  that gives you a list of the products available
- Using MySQL is good, altough this how to should not really be
  database dependent, right ? we could point it to any database, and you
  guys
  could maybe elaborate on what change would be necessary to do this :)
 
 Also, I think this how to does not necessarily need to produce a
  working
  application, as it's intended to show how people would use DAS. If we
 want
  to spend time creating an application, I'd suggest doing this as 
another

  task, and finish the one I have started as part of
  http://issues.apache.org/jira/browse/TUSCANY-800
 
  Let me know if you have any further questions... let's continue to
  updating
  the wiki, and please let me know when you guys want me to take a look
 and
  provide a feedback on the contents...
 
  BTW, others are welcome to voice their opinion on what direction we
 should
  take here...
 
 
  - Luciano Resende
  Apache Tuscany
 
 
  On 11/15/06, Adriano Crestani [EMAIL PROTECTED] wrote:
  
   I've decribed the XML configuration file, but it's still looking 
like

 a
   user
   guide than a howto. I think the CompanyWeb sample is to simple and
  doesn't
   cover well all the DAS features. So lets make this Shopping Cart
   application
   trying to use all the DAS features. Then we will be able to do a 
very

   useful
   howto.
  
 My propose is that this app must have at least:
  
- 1 functionality that requires a SQL command with arguments.
 Then
  we
   cover how to deal with arguments in SQL commands.
  
   - 1 table that has one autoincrement key column to cover the
   genarated
   attribute on the howto.
  
   - 1 table that requires a concurrency control to cover the
   concurrency
   attribute on the howto.
  
  - 1 table containing a foreign key to cover how to explicit in 
the

  XML
   configuration file the link between two tables. There will probabily
 be
  a
   foreign key in its database anyway. ; )
  
   I think also a good idea to use the MySql as the database server, 
once

   it's
   the most used server on webapps ; )
  
   We must discuss how will be the Shopping Cart GUI, it must be simple
  once
   it's not the focus of our howto. I think a simple html genarated by 
a

  jsp
   is
   enough. ; )
  
   Adriano Crestani
  
   On 11/15/06, Willian Yabusame Maja [EMAIL PROTECTED] wrote:
   
Hello Tuscany Community!
   
Adriano Crestani and I are working together on a HelloWorld 
DAS

  How
To. I have uploaded what we have done so far to
   
  
 
 

Re: Spec APIs in Tuscany distros (was Re: svn commit: r475086)

[Simon Nash]

Jeremy Boynes wrote:


On 11/15/06, Simon Nash [EMAIL PROTECTED] wrote:


Having a separate source distro for the SCA spec API makes sense
to me.  I see that your download page
   http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/
has already been updated to add this.

I'm not so convinced that we should be delivering spec API files
for commonj timer and work manager as part of the Tuscany SCA
source distros.  These are APIs that we are using rather than
APIs that we are implementing.  At the present time, we need to
provide these files so that the SCA kernel can build, but I think
we should be looking to eliminate them from our source distro
as soon as possible and reference another source for these.



If one's available that would be good - we originally used the one
from Geronimo but that had problems and once fixed didn't fit our
release schedule. BTW we do have an implementation of work manager
thanks to Meeraj.


The Tuscany SCA javadoc distro currently has the commonj APIs as
well as the SCA APIs and the Tuscany APIs.  I think we should
remove the commonj APIs from this javadoc but retain the SCA APIs
and the Tuscany APIs.



We're distributing per-module javadoc through maven as that fits the
expectations of the IDEs - see previous discussion on this. We could
mirror the spec javadoc on the download site. I don't think we should
mix spec doc with tuscany doc (api/spi) as it breaks our modularity
story.


I don't understand how this would break modularity.  Users of the
Tuscany api/spi javadoc will always need the spec javadoc as well.
Packaging them together enables Tuscany SCA developers to get all
this javadoc with a single download rather than needing to do
multiple downloads and manually combine the results.  For those who
need separate per-module javadoc because of IDE requirements,
it will be available from maven.

  Simon


--
Jeremy

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





--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


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

Re: How can I clone a ServiceContract

[Rajith Attapattu]

Hi Folks,

Raymond suggested that in order for me to get the data binding to work, I
need to clone the ServiceContract and then set the data binding type.
I see that I cannot clone the ServiceContract using the clone() method.

So it means that I need to create ServiceContract from scratch. What is the
best way to approach this??

Suggestions are most welcomed.

Regards,

Rajith

Re: Harmonizing Ruby support in Tuscany

[Jim Marino]

Hi Andy,

Comments inline...

Jim

On Nov 16, 2006, at 4:27 AM, Andrew Borley wrote:


Hi all,

I was recently asked to chat with a few people about the Ruby support
in Tuscany, so I spent a bit of time looking at the support we provide
in both the C++ and Java sides of Tuscany.
There are a few differences that, in the absence of a spec, we should
try to fix up so that we've at least got a consistent Tuscany story.
(I'm not saying these are worth holding back M2 for - just thought I'd
document them so we can get some discussion going).

1) implementation.rb element in SCDL.
In Tuscany Java, a component is defined like:
component name=HelloWorldComponent
  rb:implementation.rb script=HelloWorld.rb class=Helloworld
 xmlns:rb=http://tuscany.apache.org/xmlns/rb/1.0/
/component

Whereas, in Tuscany C++ it is:
component name=HelloWorldComponent
  implementation.ruby script=HelloWorld.rb class=Helloworld/
/component

These are pretty similar aside from the element name
(implementation.rb vs. implementation.ruby) and the fact that Java
have their own namespace whereas C++ use the SCA namespace
http://www.osoa.org/xmlns/sca/1.0 namespace. My own preference is
implementation.ruby and a tuscany namespace
(http://tuscany.apache.org/xmlns/ruby/1.0 or similar).

That seems reasonable. We shouldn't use the SCA namespace since there  
is not a spec for it.



I couldn't find a schema for Java's implementation.rb, C++'s is at
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/ 
extensions/ruby/xsd/sca-implementation-ruby.xsd

The C++ schema doesn't actually include the script attribute used
above (preferring module instead) - script is supported in the
implementation. We should decide on a single schema for the
implementation.ruby element.


2) Interface definitions
Tuscany Java requires a WSDL or Java interface to be specified for a
Ruby component via a componentType file or in a $SCA variable in the
Ruby script, e.g:
$SCA = {
  'javaInterface' = 'helloworld.HelloWorldService'
}
Tuscany C++ does not require any interface specification, instead
attempting to invoke a specified method but failing if the method name
does not exist or the wrong number of parameters are supplied.

I remember that there are currently restrictions in the Java runtime
that mean an interface is required, but it would be cool if we didn't
force Ruby scripters to write that Java or WSDL interface.
C++ should support the use of a WSDL interface to allow Ruby
components to be remotable. Perhaps we need a Ruby2WSDL tool that
could work via annotations or the $SCA variable?

It would be nice if the author doesn't need to specify Java or WSDL.  
I also think the runtime should not require tooling to be run or  
force users to generate things. Perhaps there can be a ruby.idl  
implementation that introspects the Ruby artifact and handles this  
transparently? I imagine WSDL (and Java) is a turn-off to Ruby people.


3) Ruby Client API
I don't think Tuscany Java has a client API for Ruby. In C++ there is
a client API library that matches the C++ client API, so that the SCA
runtime can be loaded and invoked from a Ruby script as follows:

require(tuscany_sca_ruby)

hello = SCA::locateService(HelloWorldComponent)

x = hello.sayHello(Everyone)
print x, \n

Should we create a Java version of this API so that Java components
can be called from Ruby, etc?

In the Java spec locateService is really for non-managed code, e.g.  
code that is not contained within a component. While a component can  
use locateService, when it does so it is behaving like non-managed  
code and things such as policy are not attached. When someone does  
locateService in the Java runtime, the proxy they receive will not  
have any client-side policy attached. I personally prefer an  
injection-based approach to things.


4) Data type support
Tuscany C++ maps the basic C++ data types to the Ruby int, float,
boolean, string, etc internal types. SDO is also supported via a
conversion to a REXML Document object. Other types will currently
cause an exception to be thrown.
Tuscany Java uses the JRuby conversion facilities to convert any Java
object (including the Java basic types) to the correct Ruby type. I
think SDOs (and other user-defined Java objects) are available inside
the Ruby script via the JRuby JavaProxy (which dynamically maps a Java
object to a Ruby object), so an SDO object inside Ruby is actually a
real Java SDO object.

We should probably have the data type conversions documented somewhere
so people understand what gets mapped to what and what data types are
supported.


On the subject of a spec, do people think OSOA.org should be working
on CI specs for Ruby and scripting languages in general? The SCA for
PHP folk have some documentation, but don't really talk about
specifications on the PHP mailing lists as it tends to be a turn-off
for the PHP community, who (IMO) like things to be a bit looser and
free-flowing.

What do people think?
I think it would 

Re: New proposal to make DAS/SDO HOW TO

[Willian Maja]

Hi Katja,

   I've just tested to read Date column, and it works. I'm going to paste 
my code here for you:


This will be the test table, it's just a simple table with a DateTime 
Column.


CREATE TABLE test (ID integer not null AUTO_INCREMENT, date_column date);
INSERT INTO test (date_column) VALUES (06-11-16);

Now you should create your Das connection. In my code example I'll not use 
XML configuration. I'm going to create the Command:


   Command read = das.createCommand(select * from test); //Create the 
 Command

   DataObject root = read.executeQuery();
   DataObject row = root.getDataObject(teste[1]); // Get the first 
row from test table;
   System.out.println(row.getDate(date_column)); // Print the 
DateTime



I think this will help you :).

Bye.





From: Katja [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: New proposal to make DAS/SDO HOW TO
Date: Thu, 16 Nov 2006 09:14:28 +0100

Hi!

Is it possible to add a Timestamp or DateTime column to the database? I am 
very interested in how to access these columns with DAS and MySQL because I 
have not succeeded in doing this.


Thanks,
Katja

 Original-Nachricht 
Datum: Thu, 16 Nov 2006 03:44:18 -0400
Von: Adriano Crestani [EMAIL PROTECTED]
An: tuscany-dev@ws.apache.org
Betreff: Re: New proposal to make DAS/SDO HOW TO

 Willian, I created these tables, that will possible be used in the
 shopping
 cart app. It's simple, but I think a howto sample must be simple. And if
 you
 want to add anything, feel free ; )

 CREATE TABLE CART (
 ID INTEGER,
 PRIMARY KEY (ID)
 );

 CREATE TABLE ITEM (
 ID INTEGER,
 ITEM VARCHAR(30),
 UNITS INTEGER,
 CART_ID INTEGER,
 PRIMARY KEY (ID),
 FOREIGN KEY (CART_ID) REFERENCES CART(ID)
 );



 On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:
 
  Hey Guys
 
 Very good to see some progress and some contents being generated. I
  agree
  with you guys when you say this is becoming more like a user guide,
  instead
  of a How To, and building it describing a new scenario would probably
 make
  things more clear, altough let's try to keep it simple on the 
beginning,

  otherwise we are going to get a White paper :)
 
 I think we should describe actions that you would take when trying 
to
  create an application and describe how you would do it (e.g Now we 
need

 to
  execute a query to read the list of products, and this is how you 
would

 do
  using DAS), and point the user to further documentation in case it
  needs/want to know more about the specific feature (e.g if they want 
to

  learn the whole syntax/xsd of the das config file).
 
 I think couple things should not be covered on the How to :
- How to build a war file
- How to create a database (altough you might provide the SQL
  statements to create the tables you would use or at least describe the
 DB
  schema)
 
 Now, talking about what should be in this how-to
- We could start very simple... 1 product table, and one simple
 jsp
  that gives you a list of the products available
- Using MySQL is good, altough this how to should not really be
  database dependent, right ? we could point it to any database, and you
  guys
  could maybe elaborate on what change would be necessary to do this :)
 
 Also, I think this how to does not necessarily need to produce a
  working
  application, as it's intended to show how people would use DAS. If we
 want
  to spend time creating an application, I'd suggest doing this as 
another

  task, and finish the one I have started as part of
  http://issues.apache.org/jira/browse/TUSCANY-800
 
  Let me know if you have any further questions... let's continue to
  updating
  the wiki, and please let me know when you guys want me to take a look
 and
  provide a feedback on the contents...
 
  BTW, others are welcome to voice their opinion on what direction we
 should
  take here...
 
 
  - Luciano Resende
  Apache Tuscany
 
 
  On 11/15/06, Adriano Crestani [EMAIL PROTECTED] wrote:
  
   I've decribed the XML configuration file, but it's still looking 
like

 a
   user
   guide than a howto. I think the CompanyWeb sample is to simple and
  doesn't
   cover well all the DAS features. So lets make this Shopping Cart
   application
   trying to use all the DAS features. Then we will be able to do a 
very

   useful
   howto.
  
 My propose is that this app must have at least:
  
- 1 functionality that requires a SQL command with arguments.
 Then
  we
   cover how to deal with arguments in SQL commands.
  
   - 1 table that has one autoincrement key column to cover the
   genarated
   attribute on the howto.
  
   - 1 table that requires a concurrency control to cover the
   concurrency
   attribute on the howto.
  
  - 1 table containing a foreign key to cover how to explicit in 
the

  XML
   configuration file the link between two tables. There 

Re: New proposal to make DAS/SDO HOW TO

[Katja]

Hi Willian!

Thank you for the example! You tested with a Date-Column, that worked in my 
application, too, because no conversion between the column and the data object 
value is necessary.

With DateTime a converter is needed:
SDO format: 2006-11-16T17:22
MySQL format: 2006-11-16 17:22

The bigbank sample has a DateConverter for this issue, but this does only work 
with Derby and not with MySQL. I don't know why. I posted the error last time: 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10725.html

It would be great, if you could test again with a DateTime or Timestamp column 
and tell me your solution.

Thanks,
Katja



 Original-Nachricht 
Datum: Thu, 16 Nov 2006 16:08:48 +
Von: Willian Maja [EMAIL PROTECTED]
An: tuscany-dev@ws.apache.org
Betreff: Re: New proposal to make DAS/SDO HOW TO

 Hi Katja,
 
 I've just tested to read Date column, and it works. I'm going to paste
 my code here for you:
 
 This will be the test table, it's just a simple table with a DateTime 
 Column.
 
 CREATE TABLE test (ID integer not null AUTO_INCREMENT, date_column date);
 INSERT INTO test (date_column) VALUES (06-11-16);
 
 Now you should create your Das connection. In my code example I'll not use
 XML configuration. I'm going to create the Command:
 
 Command read = das.createCommand(select * from test); //Create
 the 
   Command
 DataObject root = read.executeQuery();
 DataObject row = root.getDataObject(teste[1]); // Get the first 
 row from test table;
 System.out.println(row.getDate(date_column)); // Print the 
 DateTime
 
 
 I think this will help you :).
 
 Bye.
 
 
 
 
 From: Katja [EMAIL PROTECTED]
 Reply-To: tuscany-dev@ws.apache.org
 To: tuscany-dev@ws.apache.org
 Subject: Re: New proposal to make DAS/SDO HOW TO
 Date: Thu, 16 Nov 2006 09:14:28 +0100
 
 Hi!
 
 Is it possible to add a Timestamp or DateTime column to the database? I
 am 
 very interested in how to access these columns with DAS and MySQL because
 I 
 have not succeeded in doing this.
 
 Thanks,
 Katja
 
  Original-Nachricht 
 Datum: Thu, 16 Nov 2006 03:44:18 -0400
 Von: Adriano Crestani [EMAIL PROTECTED]
 An: tuscany-dev@ws.apache.org
 Betreff: Re: New proposal to make DAS/SDO HOW TO
 
   Willian, I created these tables, that will possible be used in the
   shopping
   cart app. It's simple, but I think a howto sample must be simple. And
 if
   you
   want to add anything, feel free ; )
  
   CREATE TABLE CART (
   ID INTEGER,
   PRIMARY KEY (ID)
   );
  
   CREATE TABLE ITEM (
   ID INTEGER,
   ITEM VARCHAR(30),
   UNITS INTEGER,
   CART_ID INTEGER,
   PRIMARY KEY (ID),
   FOREIGN KEY (CART_ID) REFERENCES CART(ID)
   );
  
  
  
   On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:
   
Hey Guys
   
   Very good to see some progress and some contents being generated.
 I
agree
with you guys when you say this is becoming more like a user guide,
instead
of a How To, and building it describing a new scenario would
 probably
   make
things more clear, altough let's try to keep it simple on the 
 beginning,
otherwise we are going to get a White paper :)
   
   I think we should describe actions that you would take when
 trying 
 to
create an application and describe how you would do it (e.g Now we 
 need
   to
execute a query to read the list of products, and this is how you 
 would
   do
using DAS), and point the user to further documentation in case it
needs/want to know more about the specific feature (e.g if they want
 to
learn the whole syntax/xsd of the das config file).
   
   I think couple things should not be covered on the How to :
  - How to build a war file
  - How to create a database (altough you might provide the SQL
statements to create the tables you would use or at least describe
 the
   DB
schema)
   
   Now, talking about what should be in this how-to
  - We could start very simple... 1 product table, and one
 simple
   jsp
that gives you a list of the products available
  - Using MySQL is good, altough this how to should not really
 be
database dependent, right ? we could point it to any database, and
 you
guys
could maybe elaborate on what change would be necessary to do this
 :)
   
   Also, I think this how to does not necessarily need to produce a
working
application, as it's intended to show how people would use DAS. If
 we
   want
to spend time creating an application, I'd suggest doing this as 
 another
task, and finish the one I have started as part of
http://issues.apache.org/jira/browse/TUSCANY-800
   
Let me know if you have any further questions... let's continue to
updating
the wiki, and please let me know when you guys want me to take a
 look
   and
provide a feedback on the contents...
   
BTW, others are welcome to voice their opinion on 

Re: Re: Please review of the Tuscany SCA Java M2 release candidate

[Raymond Feng]

Hi,

The source archives are created by an ant script which exports the source 
tree from the SVN repository and zips it up. Maven2 resource filitering is 
not in the process at all.


Is there any way to handle this?

BTW, is the title from ${pom.name} mandatory for NOTICE?

Thanks,
Raymond

- Original Message - 
From: Jeremy Boynes [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Wednesday, November 15, 2006 7:14 PM
Subject: Re: Re: Please review of the Tuscany SCA Java M2 release candidate



Also the top of the NOTICE reads ${pom.name} so it looks like
filtering is not being applied properly.
--
Jeremy

On 11/15/06, Jeremy Boynes [EMAIL PROTECTED] wrote:

Couple of things on the binary distro

We need to update the NOTICE file to include the EPL now that we are
redistributing the EMF jars.

I'd also suggest adding to each section in the NOTICE which jars the
notice and license apply to.
--
Jeremy

On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote:
 Hi,

 I have refreshed the distros for our M2 release candidate at
 http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. It 
 contains

 the following update:

 1) Move to axis2 1.1 release as well as the corresponding axiom, 
 XmlSchema

 and other dependencies.
 2) Add two additional source distros for SCA and CommonJ specs

 I have also uploaded the latest SNAPSHOT versions of M2 artifacts to
 http://people.apache.org/repo/m2-snapshot-repository.

 Please review the contents before we tag the branch and submit it for 
 PPMC

 vote. Your help will be greatly appreciated.

 Thanks,
 Raymond



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




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

Re: Please review of the Tuscany SCA Java M2 release candidate

[Rick]

Per filtering, I think this in regard to binary generation, and copying of those 
files in to the jars. But I don't know how or if that applies to the source disto.

May I ask why the need for the ${pom.name} in the NOTICE?

Raymond Feng wrote:

Hi,

The source archives are created by an ant script which exports the 
source tree from the SVN repository and zips it up. Maven2 resource 
filitering is not in the process at all.


Is there any way to handle this?

BTW, is the title from ${pom.name} mandatory for NOTICE?

Thanks,
Raymond

- Original Message - From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, November 15, 2006 7:14 PM
Subject: Re: Re: Please review of the Tuscany SCA Java M2 release candidate



Also the top of the NOTICE reads ${pom.name} so it looks like
filtering is not being applied properly.
--
Jeremy

On 11/15/06, Jeremy Boynes [EMAIL PROTECTED] wrote:

Couple of things on the binary distro

We need to update the NOTICE file to include the EPL now that we are
redistributing the EMF jars.

I'd also suggest adding to each section in the NOTICE which jars the
notice and license apply to.
--
Jeremy

On 11/14/06, Raymond Feng [EMAIL PROTECTED] wrote:
 Hi,

 I have refreshed the distros for our M2 release candidate at
 http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. It 
 contains

 the following update:

 1) Move to axis2 1.1 release as well as the corresponding axiom,  
XmlSchema

 and other dependencies.
 2) Add two additional source distros for SCA and CommonJ specs

 I have also uploaded the latest SNAPSHOT versions of M2 artifacts to
 http://people.apache.org/repo/m2-snapshot-repository.

 Please review the contents before we tag the branch and submit it 
for  PPMC

 vote. Your help will be greatly appreciated.

 Thanks,
 Raymond



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




-
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] Created: (TUSCANY-934) XSD2JavaGenerator -noEMF option does not work with abstract classes.

[Brian Murray (JIRA)]

XSD2JavaGenerator -noEMF option does not work with abstract classes.


 Key: TUSCANY-934
 URL: http://issues.apache.org/jira/browse/TUSCANY-934
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Reporter: Brian Murray


SDOUtil.registerStaticTypes() fails when the statically generated classes were 
created from an XSD that includes an abstract Type and the -noEMF option is 
used.  The absence of abstract=true in the XSD or not using -noEMF during the 
XSD2JavaGenerate will allow the registerStaticTypes() to complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Harmonizing Ruby support in Tuscany

[Jean-Sebastien Delfino]

[snip]


The C++ schema doesn't actually include the script attribute used
above (preferring module instead) - script is supported in the
implementation.


Andy, good catch. I added the missing script attribute to the schema 
(under revision r475824).


Script is not used in place of module:
- script indicates the Ruby script to load, a Ruby script can contain a 
number of Ruby modules and classes

- module refers to the Ruby module implementing your component
- class refers to a Ruby class implementing your component

--
Jean-Sebastien


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

Re: [Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]

[William A. Rowe, Jr.]

Justin Erenkrantz wrote:
 On 11/14/06, Henri Yandell [EMAIL PROTECTED] wrote:
 Thanks, I withdraw my -1.
 
 Ditto.  -- justin

Heh - we had no -1 to withdraw, I agreed with you Justin that lazy
concensus is wrong, but we hadn't put a -1 to the actual release.

That's why I replied to your note and not to Henri's :)

Oh - and congratulations Tuscany folk!

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

Re: New proposal to make DAS/SDO HOW TO

[Willian Maja]

I think I didn't understand what you want. But i tested using TimeStamp and 
DateTime:


  CREATE TABLE test (ID integer not null AUTO_INCREMENT, timestamp 
timestamp, datetime datetime, primary key (ID));


  INSERT INTO test VALUES ();

This will create the following row:

  |  1   | 2006-11-16 14:10:24.0|NULL


Now I will read the timestamp:

Command read = das.createCommand(select * from test);
DataObject root = read.executeQuery();
DataObject node = root.getDataObject(test[1]);
java.util.Date date = node.getDate(timestamp); // You must use 
java.util.Date, not java.sql.Date


System.out.println(date.getHours()); // Print the hours
System.out.println(date.getMonth()); // Print the month
System.out.println(node.getDate(date)); // Print the TimeStamp 
ex:2006-11-16 14:12:23.0



To save DateTime I used the following code:
//Continuing the last code, I'm going to save the TimeStamp in the 
DateTime column

   node.setDate(datetime, date);
   das.applyChanges(root);

Now the row 1 from the test table will be:

|  1   | 2006-11-16 14:10:24.0|2006-11-16 14:10:24.0


I read/updated the row with datetime and timestamp column.
If this wasn't what you want, please send me the code you want to make work 
with SDO/Mysql.






From: Katja [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: New proposal to make DAS/SDO HOW TO
Date: Thu, 16 Nov 2006 17:29:58 +0100

Hi Willian!

Thank you for the example! You tested with a Date-Column, that worked in my 
application, too, because no conversion between the column and the data 
object value is necessary.


With DateTime a converter is needed:
SDO format: 2006-11-16T17:22
MySQL format: 2006-11-16 17:22

The bigbank sample has a DateConverter for this issue, but this does only 
work with Derby and not with MySQL. I don't know why. I posted the error 
last time: 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10725.html


It would be great, if you could test again with a DateTime or Timestamp 
column and tell me your solution.


Thanks,
Katja



 Original-Nachricht 
Datum: Thu, 16 Nov 2006 16:08:48 +
Von: Willian Maja [EMAIL PROTECTED]
An: tuscany-dev@ws.apache.org
Betreff: Re: New proposal to make DAS/SDO HOW TO

 Hi Katja,

 I've just tested to read Date column, and it works. I'm going to 
paste

 my code here for you:

 This will be the test table, it's just a simple table with a DateTime
 Column.

 CREATE TABLE test (ID integer not null AUTO_INCREMENT, date_column 
date);

 INSERT INTO test (date_column) VALUES (06-11-16);

 Now you should create your Das connection. In my code example I'll not 
use

 XML configuration. I'm going to create the Command:

 Command read = das.createCommand(select * from test); //Create
 the
   Command
 DataObject root = read.executeQuery();
 DataObject row = root.getDataObject(teste[1]); // Get the 
first

 row from test table;
 System.out.println(row.getDate(date_column)); // Print the
 DateTime


 I think this will help you :).

 Bye.




 From: Katja [EMAIL PROTECTED]
 Reply-To: tuscany-dev@ws.apache.org
 To: tuscany-dev@ws.apache.org
 Subject: Re: New proposal to make DAS/SDO HOW TO
 Date: Thu, 16 Nov 2006 09:14:28 +0100
 
 Hi!
 
 Is it possible to add a Timestamp or DateTime column to the database? I
 am
 very interested in how to access these columns with DAS and MySQL 
because

 I
 have not succeeded in doing this.
 
 Thanks,
 Katja
 
  Original-Nachricht 
 Datum: Thu, 16 Nov 2006 03:44:18 -0400
 Von: Adriano Crestani [EMAIL PROTECTED]
 An: tuscany-dev@ws.apache.org
 Betreff: Re: New proposal to make DAS/SDO HOW TO
 
   Willian, I created these tables, that will possible be used in the
   shopping
   cart app. It's simple, but I think a howto sample must be simple. 
And

 if
   you
   want to add anything, feel free ; )
  
   CREATE TABLE CART (
   ID INTEGER,
   PRIMARY KEY (ID)
   );
  
   CREATE TABLE ITEM (
   ID INTEGER,
   ITEM VARCHAR(30),
   UNITS INTEGER,
   CART_ID INTEGER,
   PRIMARY KEY (ID),
   FOREIGN KEY (CART_ID) REFERENCES CART(ID)
   );
  
  
  
   On 11/16/06, Luciano Resende [EMAIL PROTECTED] wrote:
   
Hey Guys
   
   Very good to see some progress and some contents being 
generated.

 I
agree
with you guys when you say this is becoming more like a user 
guide,

instead
of a How To, and building it describing a new scenario would
 probably
   make
things more clear, altough let's try to keep it simple on the
 beginning,
otherwise we are going to get a White paper :)
   
   I think we should describe actions that you would take when
 trying
 to
create an application and describe how you would do it (e.g Now we
 need
   to
execute a query to read the list of products, and this is how you
 would
   do

Firewalls and the Spring Container

[Hawkins, Joel]

Hi all,
 
I'm doing some integration with the Spring Container and OSGi, and am
having some troubles running behind my company's firewall. What I get is
the following schema validation error when trying to load an application
context:
 
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of
element 'beans'.
 
According to google, I'm not alone:
http://forum.springframework.org/archive/index.php/t-28199.html
 
I noticed that the SpringRC3 jar does have the spring.schemas properties
file that specifies a local location for the beans schema, etc. After
ensuring that this properties file was visible to the appropriate
classloader, everything worked great, except for the fact that the
Spring 2.0 schema are not provided as part of the RC3 release. This has
apparently been remedied under RC4, but I can't find an RC4 jar in the
usual maven locations.  So, a few questions.
 
1.  Is the RC3 jar something that Tuscany manufactured, or am I not
looking in the right places for an R4?
2.  I replaced the Spring RC3 jar with the jars from the current
(RC4?) distribution, and everything 'appears' to work. Would it be
possible to migrate to the RC4 version of Spring?
3.  Is there anything I can do to help with this? Raise a JIRA?
Contribute an RC4 jar as a patch (it appears to be the sum of all of the
distro jars)? 
 
Thanks,
Joel Hawkins
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. 

RE: Firewalls and the Spring Container

[Meeraj Kunnumpurath]

 

 -Original Message-
 From: Hawkins, Joel [mailto:[EMAIL PROTECTED] 
 Sent: 16 November 2006 18:21
 To: tuscany-dev@ws.apache.org
 Subject: Firewalls and the Spring Container
 
 Hi all,
  
 I'm doing some integration with the Spring Container and 
 OSGi, and am having some troubles running behind my 
 company's firewall. What I get is the following schema 
 validation error when trying to load an application
 context:
  
 org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the 
 declaration of element 'beans'.
  
 According to google, I'm not alone:
 http://forum.springframework.org/archive/index.php/t-28199.html
  
 I noticed that the SpringRC3 jar does have the 
 spring.schemas properties file that specifies a local 
 location for the beans schema, etc. After ensuring that this 
 properties file was visible to the appropriate classloader, 
 everything worked great, except for the fact that the Spring 
 2.0 schema are not provided as part of the RC3 release. This 
 has apparently been remedied under RC4, but I can't find an 
 RC4 jar in the usual maven locations.  So, a few questions.
  
 1.   Is the RC3 jar something that Tuscany manufactured, or am I not
 looking in the right places for an R4?
 2.   I replaced the Spring RC3 jar with the jars from the current
 (RC4?) distribution, and everything 'appears' to work. Would 
 it be possible to migrate to the RC4 version of Spring?
Haven't they released 2.0 final already?
 3.   Is there anything I can do to help with this? Raise a JIRA?
 Contribute an RC4 jar as a patch (it appears to be the sum 
 of all of the distro jars)? 
  
 Thanks,
 Joel Hawkins
 The contents of this e-mail are intended for the named 
 addressee only. It contains information that may be 
 confidential. Unless you are the named addressee or an 
 authorized designee, you may not copy or use it, or disclose 
 it to anyone else. If you received it in error please notify 
 us immediately and then destroy it. 
 
 This message has been checked for all email viruses by MessageLabs

*

You can find us at www.voca.com

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

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


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

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

Re: Firewalls and the Spring Container

[Jim Marino]

On Nov 16, 2006, at 10:21 AM, Hawkins, Joel wrote:


Hi all,

I'm doing some integration with the Spring Container and OSGi, and am
having some troubles running behind my company's firewall. What I  
get is
the following schema validation error when trying to load an  
application

context:

org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the  
declaration of

element 'beans'.

According to google, I'm not alone:
http://forum.springframework.org/archive/index.php/t-28199.html

I noticed that the SpringRC3 jar does have the spring.schemas  
properties

file that specifies a local location for the beans schema, etc. After
ensuring that this properties file was visible to the appropriate
classloader, everything worked great, except for the fact that the
Spring 2.0 schema are not provided as part of the RC3 release. This  
has

apparently been remedied under RC4, but I can't find an RC4 jar in the
usual maven locations.  So, a few questions.

1.  Is the RC3 jar something that Tuscany manufactured, or am I not
looking in the right places for an R4?
I originally grabbed this from Spring when 2.0 was in development. As  
Meeraj mentioned, 2.0 should be out.

2.  I replaced the Spring RC3 jar with the jars from the current
(RC4?) distribution, and everything 'appears' to work. Would it be
possible to migrate to the RC4 version of Spring?
3.  Is there anything I can do to help with this? Raise a JIRA?
Contribute an RC4 jar as a patch (it appears to be the sum of all  
of the

distro jars)?

That would be great. Could we go against 2.0 final?


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



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

Re: Harmonizing Ruby support in Tuscany

[Andrew Borley]

On 11/16/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

[snip]

 The C++ schema doesn't actually include the script attribute used
 above (preferring module instead) - script is supported in the
 implementation.

Andy, good catch. I added the missing script attribute to the schema
(under revision r475824).

Script is not used in place of module:
- script indicates the Ruby script to load, a Ruby script can contain a
number of Ruby modules and classes
- module refers to the Ruby module implementing your component
- class refers to a Ruby class implementing your component



Ah, OK - thanks for clearing that up. Do you know if the Java
implementation supports the script, module and class attributes?

Andy

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

Re: Spec APIs in Tuscany distros (was Re: svn commit: r475086)

[Jeremy Boynes]

On 11/16/06, Simon Nash [EMAIL PROTECTED] wrote:

I don't understand how this would break modularity.


Because it couples together the release lifecycles of  two very
independent modules.


Users of the
Tuscany api/spi javadoc will always need the spec javadoc as well.


I'm not sure that that is true. I am sure that the converse isn't
(users of the spec will not always need tuscany docs).


Packaging them together enables Tuscany SCA developers to get all
this javadoc with a single download rather than needing to do
multiple downloads and manually combine the results.  For those who
need separate per-module javadoc because of IDE requirements,
it will be available from maven.

   Simon

 --
 Jeremy

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




--
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   [EMAIL PROTECTED]
Tel. +44-1962-815156   Fax +44-1962-818999


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




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

Re: Clarifying the scope of a conversation

[Ignacio Silva-Lepe]

After looking at (the previous) version 0.9 of the CI spec
and a discussion with Jim and Mike Rowley on the
conversational services section, I am going to try to
summarize my current understanding, Jim, Mike, please
jump in if I mis-state or forget to mention something here.

A conversation is indicated by a @Conversational
annotation on an interface and a @Scope annotation on an
implementation. The interface annotation denotes the
contract with a client. The implementation annotation
pertains to the maintenance of its instance state with
two basic cases: (1) when the @Scope is conversational
then the container keeps track of instance state, as well as
handling conversation id creation and propagation, (2) when
the @Scope is not conversational (i.e., it is stateless,
request, or composite), the implementation must keep track
of its state, based on the conversation id, which is still
handled by the container. Notice that all this seems to apply
to Java interfaces only. Similar statements should also
apply to WSDL interfaces as well, which is after all another
way to specify a contract with a client. It is also worth
mentioning that it does not seem to make sense to
annotate an implementation as having conversational when
it does not implement a conversational interface. Otherwise,
it would not be clear what conversation id to maintain its
instances for.

A conversation is an interaction between two parties: a client
and a service components. Each conversation is indicated
by a (possibly distinct) conversation id. Depending on whether
the service component is remotable or not, a conversation id
is auto-propagated to it by the container. That is, in a
conversation A-B, where B is defined by a conversational
interface, if B is remotable then a new conversation id is created
if one did not exist between A and B, regardless of whether A
is conversational or not, or remotable or not. But if B is not
remotable and A is conversational, then when there was no
prior conversation between A and B, and A invokes B as part
of a conversation with a client, then A propagates the
conversation id from that client.
Using the example in Fig. 1, Sec 1.5.2 of the 0.9 CI spec, the
following pattern is illustrated: A-B-C-A. Here, B and C
are non-remotable and conversational, which means that any
conversation id from A is propagated from A to B to C and
from A to C, meaning that A uses the same instance of C as
B does. In particular, if A is conversational and invoked by a
client, then it propagates the client's id as above. If a is non-
conversational and it invokes B and C in sequence, then
it would still propagate the same conversation id to both.

A service component implementation can also use a
@Conversation annotation (previously called @Session) to
indicate conversation attributes such as maxIdleTime and
maxAge. These attributes apply to each instance of the
component (i.e., for each individual conversation). Notice
that if two components participate in the same conversation
(by virtue of having the same id propagated to them) they
may still time out independently as given by their respective
attribute values. For instance, in the example of Fig. 1 above,
B may have a maxIdleTime of 100ms and C 500ms. If the
conversation initially touches B but does not touch it again
for at least 100ms, then B will time out regardless of whether
the conversation continues to touch C. And when the
conversation tries to touch B again, an exception is thrown.

Ok, this does not claim to be a complete replacement of
Sec. 1.5.2, but it tries to clarify some of the main elements
of it. The intention is to try to have a more concrete basis
on which to start implementing conversational services in
Tuscany. As the work progresses and people participate in
the discussion we may be able to come up with a (more)
complete understanding that we can feed back to the spec.



On 11/15/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:


So, are the multiple complementation instances also of one
or more types? You don't seem to be saying otherwise.
I guess this is probably motivated by transactions, with a
conversation id playing the role of a transaction context?

It may be useful to try to attach (some of) these properties
to the conversation id, although if we really have more than
one service component type (or perhaps even if there is just
one) then there is no single set of properties. For instance,
if I can tell that there is a single maxAge value for a
conversation, then then the conversation id (or context) can
be a good place to maintain this value and enforce it at each
client and service instance.

I am kind of thinking out loud here, but I am trying to make
sense of requirements like starting a new conversation at a
reference invoke after a conversation has ended.

Thoughts?

 On 11/15/06, Jim Marino [EMAIL PROTECTED] wrote:


 On Nov 15, 2006, at 8:02 AM, Ignacio Silva-Lepe wrote:

  The CI spec seems to imply that a conversation involves a 

[jira] Commented: (TUSCANY-934) XSD2JavaGenerator -noEMF option does not work with abstract classes.

[Kapil Katyal (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-934?page=comments#action_12450535 
] 

Kapil Katyal commented on TUSCANY-934:
--

The generated FactoryImpl class needs to include the following lines in the 
generated createMetaData method:

abstract_Type = createType(false, ABSTRACT);
createProperty(true, abstract_Type, AbstractImpl.FIRST_NAME);
createProperty(true, abstract_Type, AbstractImpl.LAST_NAME);

Once those lines were added, the test case passed.  

If no one else is working on this, I can modify the template files so that 
abstract types are supported in the -noEMF option.

-Kapil

 XSD2JavaGenerator -noEMF option does not work with abstract classes.
 

 Key: TUSCANY-934
 URL: http://issues.apache.org/jira/browse/TUSCANY-934
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Tools
Reporter: Brian Murray

 SDOUtil.registerStaticTypes() fails when the statically generated classes 
 were created from an XSD that includes an abstract Type and the -noEMF option 
 is used.  The absence of abstract=true in the XSD or not using -noEMF 
 during the XSD2JavaGenerate will allow the registerStaticTypes() to complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-932) Invoking DataObject.isSet(String path) with invalid path would result in NPE

[Frank Budinsky (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-932?page=comments#action_12450551 
] 

Frank Budinsky commented on TUSCANY-932:


Actually, this is one of the clarifications in the 2.1 spec. It says this:

The isSet(path) method will never throw exceptions. In the case where the path 
does not exist, the function returns the value of false.

So this is a bug that we need to fix for SDO 2.1.

 Invoking DataObject.isSet(String path) with invalid path would result in NPE
 

 Key: TUSCANY-932
 URL: http://issues.apache.org/jira/browse/TUSCANY-932
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-Mx
Reporter: Fuhwei Lwo

 The 2.1 spec didn't mention what outcome should be when invoking 
 DataObject.isSet(String path) with an invalid path so I am not sure whether 
 NPE is acceptable.
 The spec did mention bold?Note that attempts to modify read-only 
 properties (using set, unset or delete) cause an exception./bold

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (TUSCANY-935) SDO path accessors need to support names that contain .

[Frank Budinsky (JIRA)]

SDO path accessors need to support names that contain .
-

 Key: TUSCANY-935
 URL: http://issues.apache.org/jira/browse/TUSCANY-935
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Frank Budinsky


This issue keeps coming up. The . character is commonly used in industrial 
schemas, so we need to make it work. I propose handling it as follows:

Given a property name like foo.0:

1. first simply check if there is a property with the specified name.
2. if a property with that name isn't found, then find the last . character 
in the name.
3. if it is followed by digits, then use the substring from 0 to the . as the 
property name, and the number after the dot as an index.

The only case this breaks is when there is both an isMany property named foo 
and another property named someting like foo.0 in the same type. I think this 
is an unlikely corner case, that we can live with.

We'll also need to propose this behavior be clarified in the spec.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist

[Greg Dritschler (JIRA)]

HttpSessionScopeContainer requires a session to exist
-

 Key: TUSCANY-936
 URL: http://issues.apache.org/jira/browse/TUSCANY-936
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Priority: Minor


In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP 
session.  (Look at the class LazyHTTPSessionId to see how it worked.)  Now the 
HttpSessionScopeContainer requires a preexisting session.  If a session does 
not exist, a NullPointerException occurs when it tries to look up the instance 
using a null key.

InstanceWrapper ctx = wrappers.get(key);

The problem can be circumvented by creating a session in the web app client.  
JSPs have sessions by default.  Servlets can call getSession(true) to ensure a 
session exists before invoking an SCA component that requires session scope.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Harmonizing Ruby support in Tuscany

[Venkata Krishnan]

On 11/17/06, Andrew Borley [EMAIL PROTECTED] wrote:


On 11/16/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
 [snip]

  The C++ schema doesn't actually include the script attribute used
  above (preferring module instead) - script is supported in the
  implementation.

 Andy, good catch. I added the missing script attribute to the schema
 (under revision r475824).

 Script is not used in place of module:
 - script indicates the Ruby script to load, a Ruby script can contain a
 number of Ruby modules and classes
 - module refers to the Ruby module implementing your component
 - class refers to a Ruby class implementing your component


Ah, OK - thanks for clearing that up. Do you know if the Java
implementation supports the script, module and class attributes?

Andy




The java one supports script and class attributes.

- Venkat

-

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

[jira] Commented: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist

[Jim Marino (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-936?page=comments#action_12450646 
] 

Jim Marino commented on TUSCANY-936:


It looks like the session scope container has not been completely integrated 
into the web app runtime and LazyHTTPSessionId was left out. To fix this:

1. Copy over LazyHTTPSessionId from the old code base 
2. In TuscanyRequestListener,  line 61:

runtime.httpRequestStarted(session == null ? null : session.getId());

Instead of passing in a null id, pass in an insance of LazyHTTPSessionId.

3. HttpSessionScopeContainer.getInstanceWrapper() needs to check the id if it 
is an instanceof LazyHTTPSessionId and call getId() on it, and doing a lookup 
on the value returned.

Note calling Servlet.getSession(true) will cause sessions to be created even if 
they are not accessed which may be a performance issue so it is probably best 
that this fix is done. 


 HttpSessionScopeContainer requires a session to exist
 -

 Key: TUSCANY-936
 URL: http://issues.apache.org/jira/browse/TUSCANY-936
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Priority: Minor

 In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP 
 session.  (Look at the class LazyHTTPSessionId to see how it worked.)  Now 
 the HttpSessionScopeContainer requires a preexisting session.  If a session 
 does not exist, a NullPointerException occurs when it tries to look up the 
 instance using a null key.
 InstanceWrapper ctx = wrappers.get(key);
 The problem can be circumvented by creating a session in the web app client.  
 JSPs have sessions by default.  Servlets can call getSession(true) to ensure 
 a session exists before invoking an SCA component that requires session scope.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

DAS Testscases with MySQL and CONMGT.SERVERSTATUS

[Luciano Resende]

I was trying to run DAS junit tests against a MySQL database and found
couple issues that i'll track with TUSCANY-937

I also had a question, why do we have to drop and recreate the
CONMGT.SERVERSTATUS table ? This was causing me failures with a simple user
that had all GRANTS in the dastest database.

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

Re: DAS Container - First part ready for review....

[Jim Marino]

If I understood your question correctly, DAS allows a 1:1 and 1:N
relationship,
An application could have multiple components using the same config  
file,
or could split the config file based on the components model... but  
the

choice is really made by the app developer.

This sounds similar to the model JPA has with PersistenceUnit and  
Hibernate has with a SessionFactory. If I decide to share the  
configuration, does DAS process the configuration once and put it is  
some object? For example, JPA has an EntityManagerFactory which  
processes a configuration. The factory is used to create an  
EntityManager which is used by a JPA client.


In the JPA integration work, the EntityManagerFactory is created and  
cached as a system component in the application composite.  Something  
similar could be done with DAS if this model fits.


Jim


- Luciano




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

Re: New proposal to make DAS/SDO HOW TO

[Adriano Crestani]

I've started to create the Shopping Cart and I made this so far:

ShoppingCartConfig.xml

?xml version=1.0 encoding=ASCII?
Config xsi:noNamespaceSchemaLocation=
http:///org.apache.tuscany.das.rdb/config.xsd; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;

   Command name=all carts SQL=SELECT * FROM CART kind=Select/

   Command name=all carts x items SQL=SELECT * FROM CART_ITEM
kind=Select/

   Command name=get cart item SQL=SELECT * from CART_ITEM WHERE CART_ID
= ? AND ITEM_ID = ? kind=Select/

   Command name=get cart items SQL=SELECT * from CART_ITEM WHERE
CART_ID = ? kind=Select/

   Command name=get items SQL=select * FROM ITEM  kind=Select/

   Command name=get item SQL=select * FROM ITEM WHERE ID = ?
kind=Select/

   Command name=get cart SQL=select * FROM CART WHERE ID = ?
kind=Select/


   Table tableName=CART
   Column columnName=ID primaryKey=true generated=true/
   /Table


/Config


ShoppingCart.java

import commonj.sdo.DataObject;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.Iterator;
import org.apache.tuscany.das.rdb.*;

public class ShoppingCart {

   public void newCart() {
   DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());
   Command command = das.getCommand(all carts);
   DataObject allCarts = command.executeQuery();

   DataObject newCart = allCarts.createDataObject(CART);
   allCarts.getList(CART).add(newCart);
   das.applyChanges(allCarts);

   }

   public void newItem() {
   DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());
   Command command = das.getCommand(all items);
   DataObject allItems = command.executeQuery();

   DataObject newItem = allItems.createDataObject(ITEM);
   allItems.getList(ITEM).add(newItem);

   das.applyChanges(allItems);

   }

   public boolean confirmOrder(int cartId) {
   DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());
   Command command = das.getCommand(get cart items);
   DataObject cartItems = command.executeQuery();
   ArrayList array = new ArrayList(cartItems.getList(CART_ITEM));

   // check if there are enough items in stock in case another cart,
that contains
   // the same item, was ordered before
   for (Iterator it = array.iterator(); it.hasNext();) {
   DataObject cartXItem = (DataObject) it.next();
   int quantity = cartXItem.getInt(QUANTITY);
   int itemId = cartXItem.getInt(ITEM_ID);

   command = das.getCommand(get item);
   command.setParameter(1, new Integer(itemId));
   DataObject item = command.executeQuery();
   int units = item.getInt(UNITS);

   if (quantity  units) {
   return false;
   }

   item.setInt(UNITS, units - quantity);

   }

   command = das.getCommand(get cart);
   command.setParameter(1, new Integer(cartId));
   DataObject cart = command.executeQuery();
   cart.getDataObject(CART[1]).setInt(CONFIRMED, 1);

   das.applyChanges(cartItems);
   return true;

   }

   public void addCartItem(int cartId, int itemId, int quantity) {
   DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());

   Command command = das.getCommand(all carts x items);
   DataObject allCartsXItems = command.executeQuery();
   DataObject newCartXItem = allCartsXItems.createDataObject
(CART_ITEM);

   newCartXItem.setInt(QUANTITY, quantity);
   newCartXItem.setInt(CART_ID, cartId);
   newCartXItem.setInt(ITEM_ID, itemId);

   allCartsXItems.getList(CART_ITEM).add(newCartXItem);
   das.applyChanges(allCartsXItems);

   }

   public void removeCartItem(int cartId, int itemId) {
   DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml),
getConnection());

   Command command = das.getCommand(all cart items);
   command.setParameter(1, new Integer(cartId));
   command.setParameter(2, new Integer(itemId));

   DataObject cartItem = command.executeQuery();
   cartItem.getDataObject(CART_ITEM[1]).delete();

   das.applyChanges(cartItem);

   }

  private java.sql.Connection getConnection() {
   try {
   Class.forName(com.mysql.jdbc.Driver);
   } catch(ClassNotFoundException e) {
   e.printStackTrace();
   return null;
   }
   try {
   java.sql.Connection con = DriverManager.getConnection(

jdbc:mysql://localhost:3306/shoppingcart,tuscany,tuscany);
   con.setAutoCommit(false);
   return con;
   } catch(SQLException e) {
   e.printStackTrace();
   return null;
   }
   }

}

TABLES:

CREATE TABLE CART (
 ID 

Re: New proposal to make DAS/SDO HOW TO

[Luciano Resende]

I think that what you have can generate most of the how-to...  you should
start formatting it on the Wiki.
Also, I think we don't need the application itself as a result of the
how-to, right ?

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

On 11/16/06, Adriano Crestani [EMAIL PROTECTED] wrote:


I've started to create the Shopping Cart and I made this so far:

ShoppingCartConfig.xml

?xml version=1.0 encoding=ASCII?
Config xsi:noNamespaceSchemaLocation=
http:///org.apache.tuscany.das.rdb/config.xsd; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;

Command name=all carts SQL=SELECT * FROM CART kind=Select/

Command name=all carts x items SQL=SELECT * FROM CART_ITEM
kind=Select/

Command name=get cart item SQL=SELECT * from CART_ITEM WHERE
CART_ID
= ? AND ITEM_ID = ? kind=Select/

Command name=get cart items SQL=SELECT * from CART_ITEM WHERE
CART_ID = ? kind=Select/

Command name=get items SQL=select * FROM ITEM  kind=Select/

Command name=get item SQL=select * FROM ITEM WHERE ID = ?
kind=Select/

Command name=get cart SQL=select * FROM CART WHERE ID = ?
kind=Select/


Table tableName=CART
Column columnName=ID primaryKey=true generated=true/
/Table


/Config


ShoppingCart.java

import commonj.sdo.DataObject;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.Iterator;
import org.apache.tuscany.das.rdb.*;

public class ShoppingCart {

public void newCart() {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());
Command command = das.getCommand(all carts);
DataObject allCarts = command.executeQuery();

DataObject newCart = allCarts.createDataObject(CART);
allCarts.getList(CART).add(newCart);
das.applyChanges(allCarts);

}

public void newItem() {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());
Command command = das.getCommand(all items);
DataObject allItems = command.executeQuery();

DataObject newItem = allItems.createDataObject(ITEM);
allItems.getList(ITEM).add(newItem);

das.applyChanges(allItems);

}

public boolean confirmOrder(int cartId) {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());
Command command = das.getCommand(get cart items);
DataObject cartItems = command.executeQuery();
ArrayList array = new ArrayList(cartItems.getList(CART_ITEM));

// check if there are enough items in stock in case another cart,
that contains
// the same item, was ordered before
for (Iterator it = array.iterator(); it.hasNext();) {
DataObject cartXItem = (DataObject) it.next();
int quantity = cartXItem.getInt(QUANTITY);
int itemId = cartXItem.getInt(ITEM_ID);

command = das.getCommand(get item);
command.setParameter(1, new Integer(itemId));
DataObject item = command.executeQuery();
int units = item.getInt(UNITS);

if (quantity  units) {
return false;
}

item.setInt(UNITS, units - quantity);

}

command = das.getCommand(get cart);
command.setParameter(1, new Integer(cartId));
DataObject cart = command.executeQuery();
cart.getDataObject(CART[1]).setInt(CONFIRMED, 1);

das.applyChanges(cartItems);
return true;

}

public void addCartItem(int cartId, int itemId, int quantity) {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());

Command command = das.getCommand(all carts x items);
DataObject allCartsXItems = command.executeQuery();
DataObject newCartXItem = allCartsXItems.createDataObject
(CART_ITEM);

newCartXItem.setInt(QUANTITY, quantity);
newCartXItem.setInt(CART_ID, cartId);
newCartXItem.setInt(ITEM_ID, itemId);

allCartsXItems.getList(CART_ITEM).add(newCartXItem);
das.applyChanges(allCartsXItems);

}

public void removeCartItem(int cartId, int itemId) {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());

Command command = das.getCommand(all cart items);
command.setParameter(1, new Integer(cartId));
command.setParameter(2, new Integer(itemId));

DataObject cartItem = command.executeQuery();
cartItem.getDataObject(CART_ITEM[1]).delete();

das.applyChanges(cartItem);

}

   private java.sql.Connection getConnection() {
try {
Class.forName(com.mysql.jdbc.Driver);
} catch(ClassNotFoundException e) {

Re: Clarifying the scope of a conversation

[Pete Robbins]

This is a fairly confusing area and I welcome your efforts to clarify this.

On 16/11/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:


After looking at (the previous) version 0.9 of the CI spec
and a discussion with Jim and Mike Rowley on the
conversational services section, I am going to try to
summarize my current understanding, Jim, Mike, please
jump in if I mis-state or forget to mention something here.

A conversation is indicated by a @Conversational
annotation on an interface and a @Scope annotation on an
implementation. The interface annotation denotes the
contract with a client. The implementation annotation
pertains to the maintenance of its instance state with
two basic cases: (1) when the @Scope is conversational
then the container keeps track of instance state, as well as
handling conversation id creation and propagation, (2) when
the @Scope is not conversational (i.e., it is stateless,
request, or composite),



What are the definitions of thes different scopes? I thought the
implementation scope was tied to the lifecycle of a service/component?

the implementation must keep track

of its state, based on the conversation id, which is still
handled by the container. Notice that all this seems to apply
to Java interfaces only. Similar statements should also
apply to WSDL interfaces as well, which is after all another
way to specify a contract with a client. It is also worth
mentioning that it does not seem to make sense to
annotate an implementation as having conversational when
it does not implement a conversational interface. Otherwise,
it would not be clear what conversation id to maintain its
instances for.

A conversation is an interaction between two parties: a client
and a service components. Each conversation is indicated
by a (possibly distinct) conversation id. Depending on whether
the service component is remotable or not, a conversation id
is auto-propagated to it by the container. That is, in a
conversation A-B, where B is defined by a conversational
interface, if B is remotable then a new conversation id is created
if one did not exist between A and B, regardless of whether A
is conversational or not, or remotable or not. But if B is not
remotable and A is conversational, then when there was no
prior conversation between A and B, and A invokes B as part
of a conversation with a client, then A propagates the
conversation id from that client.
Using the example in Fig. 1, Sec 1.5.2 of the 0.9 CI spec, the
following pattern is illustrated: A-B-C-A. Here, B and C
are non-remotable and conversational, which means that any
conversation id from A is propagated from A to B to C and
from A to C, meaning that A uses the same instance of C as
B does. In particular, if A is conversational and invoked by a
client, then it propagates the client's id as above. If a is non-
conversational and it invokes B and C in sequence, then
it would still propagate the same conversation id to both.

A service component implementation can also use a
@Conversation annotation




Do you mean interface here rather than implementation? You state above that
the @Conversation annotation is on the interface.

(previously called @Session) to

indicate conversation attributes such as maxIdleTime and
maxAge. These attributes apply to each instance of the
component (i.e., for each individual conversation). Notice
that if two components participate in the same conversation
(by virtue of having the same id propagated to them) they
may still time out independently as given by their respective
attribute values. For instance, in the example of Fig. 1 above,
B may have a maxIdleTime of 100ms and C 500ms. If the
conversation initially touches B but does not touch it again
for at least 100ms, then B will time out regardless of whether
the conversation continues to touch C. And when the
conversation tries to touch B again, an exception is thrown.

Ok, this does not claim to be a complete replacement of
Sec. 1.5.2, but it tries to clarify some of the main elements
of it. The intention is to try to have a more concrete basis
on which to start implementing conversational services in
Tuscany. As the work progresses and people participate in
the discussion we may be able to come up with a (more)
complete understanding that we can feed back to the spec.



On 11/15/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:

 So, are the multiple complementation instances also of one
 or more types? You don't seem to be saying otherwise.
 I guess this is probably motivated by transactions, with a
 conversation id playing the role of a transaction context?

 It may be useful to try to attach (some of) these properties
 to the conversation id, although if we really have more than
 one service component type (or perhaps even if there is just
 one) then there is no single set of properties. For instance,
 if I can tell that there is a single maxAge value for a
 conversation, then then the conversation id (or context) can
 be a good place to 

Re: Clarifying the scope of a conversation

[Jim Marino]

On Nov 16, 2006, at 1:26 PM, Ignacio Silva-Lepe wrote:


After looking at (the previous) version 0.9 of the CI spec
and a discussion with Jim and Mike Rowley on the
conversational services section, I am going to try to
summarize my current understanding, Jim, Mike, please
jump in if I mis-state or forget to mention something here.

A conversation is indicated by a @Conversational
annotation on an interface and a @Scope annotation on an
implementation.
This may be nit-picking but the conversation is only indicated by  
@Conversational; @Scope is just used as a way for an implementation  
to specify to the container how it should manage its state (or not in  
the case of stateless).



The interface annotation denotes the
contract with a client. The implementation annotation
pertains to the maintenance of its instance state with
two basic cases: (1) when the @Scope is conversational
then the container keeps track of instance state, as well as
handling conversation id creation and propagation, (2) when
the @Scope is not conversational (i.e., it is stateless,
request, or composite), the implementation must keep track
of its state, based on the conversation id, which is still
handled by the container. Notice that all this seems to apply
to Java interfaces only. Similar statements should also
apply to WSDL interfaces as well, which is after all another
way to specify a contract with a client.
Yes we need a way to attach that to WSDL. I believe this has already  
been raised as an issue.

It is also worth
mentioning that it does not seem to make sense to
annotate an implementation as having conversational when
it does not implement a conversational interface. Otherwise,
it would not be clear what conversation id to maintain its
instances for.

A conversation is an interaction between two parties: a client
and a service components. Each conversation is indicated
by a (possibly distinct) conversation id. Depending on whether
the service component is remotable or not, a conversation id
is auto-propagated to it by the container. That is, in a
conversation A-B, where B is defined by a conversational
interface, if B is remotable then a new conversation id is created
if one did not exist between A and B, regardless of whether A
is conversational or not, or remotable or not. But if B is not
remotable and A is conversational, then when there was no
prior conversation between A and B, and A invokes B as part
of a conversation with a client, then A propagates the
conversation id from that client.
Using the example in Fig. 1, Sec 1.5.2 of the 0.9 CI spec, the
following pattern is illustrated: A-B-C-A. Here, B and C
are non-remotable and conversational, which means that any
conversation id from A is propagated from A to B to C and
from A to C, meaning that A uses the same instance of C as
B does. In particular, if A is conversational and invoked by a
client, then it propagates the client's id as above. If a is non-
conversational and it invokes B and C in sequence, then
it would still propagate the same conversation id to both.

A service component implementation can also use a
@Conversation annotation (previously called @Session) to
indicate conversation attributes such as maxIdleTime and
maxAge. These attributes apply to each instance of the
component (i.e., for each individual conversation). Notice
that if two components participate in the same conversation
(by virtue of having the same id propagated to them) they
may still time out independently as given by their respective
attribute values. For instance, in the example of Fig. 1 above,
B may have a maxIdleTime of 100ms and C 500ms. If the
conversation initially touches B but does not touch it again
for at least 100ms, then B will time out regardless of whether
the conversation continues to touch C. And when the
conversation tries to touch B again, an exception is thrown.

Ok, this does not claim to be a complete replacement of
Sec. 1.5.2, but it tries to clarify some of the main elements
of it. The intention is to try to have a more concrete basis
on which to start implementing conversational services in
Tuscany. As the work progresses and people participate in
the discussion we may be able to come up with a (more)
complete understanding that we can feed back to the spec.



On 11/15/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:


So, are the multiple complementation instances also of one
or more types? You don't seem to be saying otherwise.
I guess this is probably motivated by transactions, with a
conversation id playing the role of a transaction context?

It may be useful to try to attach (some of) these properties
to the conversation id, although if we really have more than
one service component type (or perhaps even if there is just
one) then there is no single set of properties. For instance,
if I can tell that there is a single maxAge value for a
conversation, then then the conversation id (or context) can
be a good place to maintain this value and enforce it 

Re: Clarifying the scope of a conversation

[Jim Marino]

On Nov 16, 2006, at 11:11 PM, Pete Robbins wrote:

This is a fairly confusing area and I welcome your efforts to  
clarify this.


On 16/11/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:


After looking at (the previous) version 0.9 of the CI spec
and a discussion with Jim and Mike Rowley on the
conversational services section, I am going to try to
summarize my current understanding, Jim, Mike, please
jump in if I mis-state or forget to mention something here.

A conversation is indicated by a @Conversational
annotation on an interface and a @Scope annotation on an
implementation. The interface annotation denotes the
contract with a client. The implementation annotation
pertains to the maintenance of its instance state with
two basic cases: (1) when the @Scope is conversational
then the container keeps track of instance state, as well as
handling conversation id creation and propagation, (2) when
the @Scope is not conversational (i.e., it is stateless,
request, or composite),



What are the definitions of thes different scopes? I thought the
implementation scope was tied to the lifecycle of a service/component?

the implementation must keep track
The definition of scopes was originally in the Java CI spec, then it  
was removed with the intention of putting it in Assembly. The spec  
group then decided it need to go back to the individual language  
specs. I haven't had the chance to update the Java spec but I intend  
to do so over the next few days. I'll post a write-up on the wiki for  
feedback comments.


Jim

of its state, based on the conversation id, which is still
handled by the container. Notice that all this seems to apply
to Java interfaces only. Similar statements should also
apply to WSDL interfaces as well, which is after all another
way to specify a contract with a client. It is also worth
mentioning that it does not seem to make sense to
annotate an implementation as having conversational when
it does not implement a conversational interface. Otherwise,
it would not be clear what conversation id to maintain its
instances for.

A conversation is an interaction between two parties: a client
and a service components. Each conversation is indicated
by a (possibly distinct) conversation id. Depending on whether
the service component is remotable or not, a conversation id
is auto-propagated to it by the container. That is, in a
conversation A-B, where B is defined by a conversational
interface, if B is remotable then a new conversation id is created
if one did not exist between A and B, regardless of whether A
is conversational or not, or remotable or not. But if B is not
remotable and A is conversational, then when there was no
prior conversation between A and B, and A invokes B as part
of a conversation with a client, then A propagates the
conversation id from that client.
Using the example in Fig. 1, Sec 1.5.2 of the 0.9 CI spec, the
following pattern is illustrated: A-B-C-A. Here, B and C
are non-remotable and conversational, which means that any
conversation id from A is propagated from A to B to C and
from A to C, meaning that A uses the same instance of C as
B does. In particular, if A is conversational and invoked by a
client, then it propagates the client's id as above. If a is non-
conversational and it invokes B and C in sequence, then
it would still propagate the same conversation id to both.

A service component implementation can also use a
@Conversation annotation




Do you mean interface here rather than implementation? You state  
above that

the @Conversation annotation is on the interface.

(previously called @Session) to

indicate conversation attributes such as maxIdleTime and
maxAge. These attributes apply to each instance of the
component (i.e., for each individual conversation). Notice
that if two components participate in the same conversation
(by virtue of having the same id propagated to them) they
may still time out independently as given by their respective
attribute values. For instance, in the example of Fig. 1 above,
B may have a maxIdleTime of 100ms and C 500ms. If the
conversation initially touches B but does not touch it again
for at least 100ms, then B will time out regardless of whether
the conversation continues to touch C. And when the
conversation tries to touch B again, an exception is thrown.

Ok, this does not claim to be a complete replacement of
Sec. 1.5.2, but it tries to clarify some of the main elements
of it. The intention is to try to have a more concrete basis
on which to start implementing conversational services in
Tuscany. As the work progresses and people participate in
the discussion we may be able to come up with a (more)
complete understanding that we can feed back to the spec.



On 11/15/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:

 So, are the multiple complementation instances also of one
 or more types? You don't seem to be saying otherwise.
 I guess this is probably motivated by transactions, with a
 conversation id 

Re: Clarifying the scope of a conversation

[Pete Robbins]

On 17/11/06, Jim Marino [EMAIL PROTECTED] wrote:



On Nov 16, 2006, at 11:11 PM, Pete Robbins wrote:

 This is a fairly confusing area and I welcome your efforts to
 clarify this.

 On 16/11/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:

 After looking at (the previous) version 0.9 of the CI spec
 and a discussion with Jim and Mike Rowley on the
 conversational services section, I am going to try to
 summarize my current understanding, Jim, Mike, please
 jump in if I mis-state or forget to mention something here.

 A conversation is indicated by a @Conversational
 annotation on an interface and a @Scope annotation on an
 implementation. The interface annotation denotes the
 contract with a client. The implementation annotation
 pertains to the maintenance of its instance state with
 two basic cases: (1) when the @Scope is conversational
 then the container keeps track of instance state, as well as
 handling conversation id creation and propagation, (2) when
 the @Scope is not conversational (i.e., it is stateless,
 request, or composite),


 What are the definitions of thes different scopes? I thought the
 implementation scope was tied to the lifecycle of a service/component?

 the implementation must keep track
The definition of scopes was originally in the Java CI spec, then it
was removed with the intention of putting it in Assembly. The spec
group then decided it need to go back to the individual language
specs. I haven't had the chance to update the Java spec but I intend
to do so over the next few days. I'll post a write-up on the wiki for
feedback comments.



Great! I'm trying to find the right words for the C++ CI spec and trying to
keep as close to Java as possible. Currently I have @Scope Stateless or
Composite on an implementation and the @Conversational on an interface.


Jim

 of its state, based on the conversation id, which is still
 handled by the container. Notice that all this seems to apply
 to Java interfaces only. Similar statements should also
 apply to WSDL interfaces as well, which is after all another
 way to specify a contract with a client. It is also worth
 mentioning that it does not seem to make sense to
 annotate an implementation as having conversational when
 it does not implement a conversational interface. Otherwise,
 it would not be clear what conversation id to maintain its
 instances for.

 A conversation is an interaction between two parties: a client
 and a service components. Each conversation is indicated
 by a (possibly distinct) conversation id. Depending on whether
 the service component is remotable or not, a conversation id
 is auto-propagated to it by the container. That is, in a
 conversation A-B, where B is defined by a conversational
 interface, if B is remotable then a new conversation id is created
 if one did not exist between A and B, regardless of whether A
 is conversational or not, or remotable or not. But if B is not
 remotable and A is conversational, then when there was no
 prior conversation between A and B, and A invokes B as part
 of a conversation with a client, then A propagates the
 conversation id from that client.
 Using the example in Fig. 1, Sec 1.5.2 of the 0.9 CI spec, the
 following pattern is illustrated: A-B-C-A. Here, B and C
 are non-remotable and conversational, which means that any
 conversation id from A is propagated from A to B to C and
 from A to C, meaning that A uses the same instance of C as
 B does. In particular, if A is conversational and invoked by a
 client, then it propagates the client's id as above. If a is non-
 conversational and it invokes B and C in sequence, then
 it would still propagate the same conversation id to both.

 A service component implementation can also use a
 @Conversation annotation



 Do you mean interface here rather than implementation? You state
 above that
 the @Conversation annotation is on the interface.

 (previously called @Session) to
 indicate conversation attributes such as maxIdleTime and
 maxAge. These attributes apply to each instance of the
 component (i.e., for each individual conversation). Notice
 that if two components participate in the same conversation
 (by virtue of having the same id propagated to them) they
 may still time out independently as given by their respective
 attribute values. For instance, in the example of Fig. 1 above,
 B may have a maxIdleTime of 100ms and C 500ms. If the
 conversation initially touches B but does not touch it again
 for at least 100ms, then B will time out regardless of whether
 the conversation continues to touch C. And when the
 conversation tries to touch B again, an exception is thrown.

 Ok, this does not claim to be a complete replacement of
 Sec. 1.5.2, but it tries to clarify some of the main elements
 of it. The intention is to try to have a more concrete basis
 on which to start implementing conversational services in
 Tuscany. As the work progresses and people participate in
 the discussion we may be able to come up 

Re: Clarifying the scope of a conversation

[Jim Marino]

 the implementation must keep track
The definition of scopes was originally in the Java CI spec, then it
was removed with the intention of putting it in Assembly. The spec
group then decided it need to go back to the individual language
specs. I haven't had the chance to update the Java spec but I intend
to do so over the next few days. I'll post a write-up on the wiki for
feedback comments.



Great! I'm trying to find the right words for the C++ CI spec and  
trying to
keep as close to Java as possible. Currently I have @Scope  
Stateless or
Composite on an implementation and the @Conversational on an  
interface.


We also have request, which is basically the time a request  
breaches the runtime and is synchronously serviced. For the Java  
runtime we also have a custom scope HTTPSession. The conversation  
model is a bit complex so I'm going to try to think about how we can  
either simplify it or explain it better. When I get to post something  
on the wiki, I send a note and we can iterate on the write-up.


Jim

 of its state, based on the conversation id, which is still
 handled by the container. Notice that all this seems to apply
 to Java interfaces only. Similar statements should also
 apply to WSDL interfaces as well, which is after all another
 way to specify a contract with a client. It is also worth
 mentioning that it does not seem to make sense to
 annotate an implementation as having conversational when
 it does not implement a conversational interface. Otherwise,
 it would not be clear what conversation id to maintain its
 instances for.

 A conversation is an interaction between two parties: a client
 and a service components. Each conversation is indicated
 by a (possibly distinct) conversation id. Depending on whether
 the service component is remotable or not, a conversation id
 is auto-propagated to it by the container. That is, in a
 conversation A-B, where B is defined by a conversational
 interface, if B is remotable then a new conversation id is created
 if one did not exist between A and B, regardless of whether A
 is conversational or not, or remotable or not. But if B is not
 remotable and A is conversational, then when there was no
 prior conversation between A and B, and A invokes B as part
 of a conversation with a client, then A propagates the
 conversation id from that client.
 Using the example in Fig. 1, Sec 1.5.2 of the 0.9 CI spec, the
 following pattern is illustrated: A-B-C-A. Here, B and C
 are non-remotable and conversational, which means that any
 conversation id from A is propagated from A to B to C and
 from A to C, meaning that A uses the same instance of C as
 B does. In particular, if A is conversational and invoked by a
 client, then it propagates the client's id as above. If a is non-
 conversational and it invokes B and C in sequence, then
 it would still propagate the same conversation id to both.

 A service component implementation can also use a
 @Conversation annotation



 Do you mean interface here rather than implementation? You state
 above that
 the @Conversation annotation is on the interface.

 (previously called @Session) to
 indicate conversation attributes such as maxIdleTime and
 maxAge. These attributes apply to each instance of the
 component (i.e., for each individual conversation). Notice
 that if two components participate in the same conversation
 (by virtue of having the same id propagated to them) they
 may still time out independently as given by their respective
 attribute values. For instance, in the example of Fig. 1 above,
 B may have a maxIdleTime of 100ms and C 500ms. If the
 conversation initially touches B but does not touch it again
 for at least 100ms, then B will time out regardless of whether
 the conversation continues to touch C. And when the
 conversation tries to touch B again, an exception is thrown.

 Ok, this does not claim to be a complete replacement of
 Sec. 1.5.2, but it tries to clarify some of the main elements
 of it. The intention is to try to have a more concrete basis
 on which to start implementing conversational services in
 Tuscany. As the work progresses and people participate in
 the discussion we may be able to come up with a (more)
 complete understanding that we can feed back to the spec.



 On 11/15/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote:
 
  So, are the multiple complementation instances also of one
  or more types? You don't seem to be saying otherwise.
  I guess this is probably motivated by transactions, with a
  conversation id playing the role of a transaction context?
 
  It may be useful to try to attach (some of) these properties
  to the conversation id, although if we really have more than
  one service component type (or perhaps even if there is just
  one) then there is no single set of properties. For instance,
  if I can tell that there is a single maxAge value for a
  conversation, then then the conversation id (or context) can
  be a good place to maintain this