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

Reply via email to