On Nov 9, 2007 11:31 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > On Nov 9, 2007 11:18 AM, ant elder <[EMAIL PROTECTED]> 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 > > > I think, given where we are now and the list of potential features, that > we should aim to cut the branch to build the first RC at the start of > December (say Monday 3rd?) . That gives us 3 weeks or so for feature work > from now and enough time before Christmas starts to hit us to get an RC > together and through the voting process for a pre-Christmas 1.1 release. > > Simon >
Sound good to me. ...ant