To clarify my proposal for an early January release, since many people
are out over the Christmas and New Year period, in order to release in
early January we would need to have a release candidate by December 21.
This would give us an extended review period for the RC (for those who
will have a bit of time to look at this over the holidays), and we could
begin voting on the release when most people return on January 2.
Simon
Raymond Feng wrote:
+1 for Simon Laws as the release manager.
+1 on Simon Nash's proposal to have an early-January 1.1 release.
I would like to get some basic transaction support into the 1.1 release.
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Friday, November 09, 2007 4:07 AM
Subject: Re: [DISCUSS] Java SCA Release 1.1 was: Re: Re: [DISCUSS]
Tuscany SCA Roadmap and next releases
+1 for Simon as RM.
I added a few things to the list that I'd like to get done for 1.1.
I think the distribution/packaging changes for better modularity and
daployability are very important and I'd like to see these in 1.1.
I think it's more realistic to aim for an early January release date
rather than trying to get something out in December just before the
holidays. Also, December releases tend not to get immediate pickup
and adoption because of people being out for the holidays.
Simon
ant elder wrote:
On Nov 5, 2007 3:54 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
On 10/23/07, wang feng <[EMAIL PROTECTED]> wrote:
hi Jean-Sebastien,
Please see my comments below.
Thanks,
wangfeng
On 2007-10-20, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
wang feng wrote:
Hi all,
We have used Tuscany 1.0 in our product and found some features is
important to us.
Thanks a lot for contributing here and helping us understand what
you'd
like to see in Tuscany!
I have a few questions to make sure I understand what you're looking
for.
- Support hot deployable on contribution and composite.
This should be have a recursive algorithm to update the correlated
component when it has been referenced.
Can you give a brief description of the type of hot deployment that
you're trying to support? It does not have to be very detailed but
maybe
just an outline or an example showing what your contributions and
composites look like and the steps that you'd like to go through to
redeploy them.
In particular I'd like to understand if you want to redeploy imported
contributions (imported by <import> in sca-contribution.xml), nested
composites, and what you'd like to be able to update in the
contributions and composites, classes? component configuration?
bindings? wiring? etc.
My use case like that(there are three contributions):
contribution A export composite A,
contribution B import composite A used by composite B and export
composite
B,
contribution C import composite B
If we update composite A in contribution A,the sca runtime should be
update the correlated contribution B and C and the component's
relationship should be rewiring.
- Support SDO namespace when using websservice.
Deploy a service to webservice,a schema file used in SDO and have
sdo
namespace such as commonj.sdo/java or commonj.sdo/xml,we should
support
the feature when parsing the wsdl.
Could you provide an example WSDL and XSD?
My wsdl file like this:
<wsdl:definitions xmlns:apachesoap="http://xml.apache.org/xml-soap";
xmlns:sdoJava="commonj.sdo/java" xmlns:soapenc="
http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tns="
http://com.primeton.eos/com/primeton/eos/newcomponent"; xmlns:wsdl="
http://schemas.xmlsoap.org/wsdl/"; xmlns:wsdlsoap="
http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd="
http://www.w3.org/2001/XMLSchema"; targetNamespace="
http://com.primeton.eos/com/primeton/eos/newcomponent";>
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema";
targetNamespace="
http://com.primeton.eos/com/primeton/eos/newcomponent";>
<import
namespace="http://schemas.xmlsoap.org/soap/encoding/
"/>
<complexType name="SdoJava_java_util_List"
sdoJava:instanceClass="java.util.List"/>
<complexType name="ArrayOf_soapenc_string">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="soapenc:string[]"/>
</restriction>
</complexContent>
</complexType>
<complexType name="SdoJava_java_lang_String"
sdoJava:instanceClass="java.lang.String"/>
<complexType name="SdoJava_stockquote_StockQuoteService"
sdoJava:instanceClass="stockquote.StockQuoteService"/>
<complexType
name="ArrayOf_soapenc_stockquote_StockQuoteService">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="tns:SdoJava_stockquote_StockQuoteService[]"/>
</restriction>
</complexContent>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="newcomponent.newbiz1OutputMessage">
<wsdl:part name="out1" type="xsd:string"></wsdl:part>
<wsdl:part name="out2" type="xsd:string"></wsdl:part>
</wsdl:message>
<wsdl:message name="newcomponent.newbiz1InputMessage">
<wsdl:part name="param1"
type="tns:ArrayOf_soapenc_stockquote_StockQuoteService"></wsdl:part>
<wsdl:part name="param2" type="xsd:string"></wsdl:part>
</wsdl:message>
<wsdl:message name="newcomponent.newbiz.bizxOutputMessage">
<wsdl:part name="out1"
type="tns:SdoJava_java_lang_String"></wsdl:part>
</wsdl:message>
<wsdl:message name="newcomponent.newbiz.bizxInputMessage">
<wsdl:part name="param1"
type="tns:SdoJava_java_util_List"></wsdl:part>
<wsdl:part name="param2"
type="tns:ArrayOf_soapenc_string"></wsdl:part>
</wsdl:message>
<wsdl:portType name="newcomponent">
<wsdl:operation name="newbiz">
<wsdl:input message="tns:
newcomponent.newbiz.bizxInputMessage
"></wsdl:input>
<wsdl:output message="tns:
newcomponent.newbiz.bizxOutputMessage"></wsdl:output>
</wsdl:operation>
<wsdl:operation name="newbiz1">
<wsdl:input message="tns:newcomponent.newbiz1InputMessage
"></wsdl:input>
<wsdl:output message="tns:newcomponent.newbiz1OutputMessage
"></wsdl:output>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
When I use the wsdl file to describe a service's interface,the console
show a warning as below.
[WARNING] Component service interface incompatible with service
interface:
test/HelloInterfaceImpl null
- Support load contribution as a osgi bundle.
Are you looking for something different from the OSGi bundle
contribution support already in the 1.0 release (as in
itest/itest-contribution-osgi for example)?
Sorry for the misunderstanding.
I meaned that the sca runtime should be run in a osgi runtime and the
classloader should be different for every contribution.
I have already found there were some discussion on the mail list.
Thanks,
wangfeng
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Now that 1.0.1 is well on the way I'd like to suggest that we start to
think about our next feature release (1.1). I just had a look back
at the
roadmap page that Raymond created [1] and tried to mark things that I'd
seen
going past on the the mail list either as done or as being worked
on. We
need to decide what we want in and when we want to get the release out.
There's a lot left on the list and also items that have been raised
on the
list since the page was created and in the spirit of trying to get
us in
the
right shape to get a release done I'd like to volunteer as the release
manager.
Regards
Simon
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
+1 to the 1.1 release and for Simon as RM.
What sort of time frame are you thinking? There's a few things I'd
like to
try get in 1.1 but the main one would be the JMS binding and it will
probably take at least a few weeks to get that ready.
...ant
...ant
---------------------------------------------------------------------
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]
