Hi Mike Pls see my comments below;
[EMAIL PROTECTED] wrote: > > I would just like to say, this seems non-intuitive. > > If I have a service tag with a name attribute, I expect the name > specified in the tag to determine the name of my service, not the > arbitrary name of my archive file (which may have versioning > information attached to it). We had this behavior some times ago and we removed that. And now I think its the right way I mean we have to set the service name as the value specified by name attribute. > > Now, if the name attribute is optional then I could understand using > the name of the archive file in the absence of the name attribute. > > My expectation is that the purpose of the services.xml file is > configuration of my services. As such, I would expect any information > in the services.xml to take precedence over arbitrary environment > features like the name of my archive file. can u please create a JIRA , so that I will not forget this > > * > Mike McAngus* > Associate Chief Engineer, Enterprise Architecture > Wendy's International, Inc. > One Dave Thomas Boulevard > Dublin, OH 43017 > 614-764-6776 > > > > *Deepal Jayasinghe* > > 05/16/2006 09:11 AM > Please respond to > [email protected] > > > > To > [email protected] > cc > > Subject > Re: runtime lifecycle implementation semantics > > > > > > > > > > Hi Tony > pls see my comment blow; > > Tony Dean wrote: > > >Deepal, > > > >My wsdl contains: > > > ><service name="WebServiceMaker"> > > ... > ></service> > > > >My services.xml contains: > > > ><service name="WebServiceMaker" scope="application"> > > ... > ></service> > > > >Hence you should be able to associate the service name with the wsdl > service. That's what I thought you were doing in .9x. It seems to > have changed in 1.0. > > > > > We have not changed that. What we have done is if the root element of > the services.xml is <service> then we ignore the name attribute and set > the name as the archive name. If the root element is <serviceGroup> > then the name of the service will be the name of the name attribute. > So change your services.xml to following format and then there wont be > any dependencies on archive file name > <serviceGroup> > <service name="WebServiceMaker" scope="application"> > ... > > </service> > > <serviceGroup> > > >Why are you dependent upon the name of the archive? I changed the > name of the archive (in my case the name of the exploded directory) to > WebServiceMaker (it was SASWebServiceMaker) and it is working as I > expect now. > > > >Thanks. > > > >-----Original Message----- > >From: Deepal Jayasinghe [mailto:[EMAIL PROTECTED] > >Sent: Monday, May 15, 2006 1:02 PM > >To: Tony Dean > >Cc: [email protected] > >Subject: Re: runtime lifecycle implementation semantics > > > >btw what is the name of service archive file , service name always be > the name of the archive file if the services.xml has only one service. > >So wsdl service name should be equal to the name of the service. > > - if the service name is foo.aar (services.xml exactly look like > yours) > > - then wsdl service element should look like > > > > > > > ><service name="foo"> > > <port name="WebServiceMakerPort" > binding="tns:WebServiceMakerBinding"> > > <soap:address location="$WEBSVC_URL$"/> </port> > > > > > > > >Tony Dean wrote: > > > > > > > >>Also, do you know why > >>http://localhost:8080/axis2/services/SASWebServiceMaker?wsdl is > >>returning > >> > >>- <error> > >> <description>Unable to generate WSDL for this service</description> > >> <reason>Either user has not dropped the wsdl into META-INF or > >>operations use message receivers other than RPC.</reason> > >> </error> > >> > >>I'm using RawXMLINOutMessageReceiver. > >> > >>meta-inf/services.xml > >> > >><service name="WebServiceMaker" scope="application"> > >> <description>SAS BI Web Services (WebServiceMaker)</description> > >> <parameter locked="xsd:false" > >>name="ServiceClass">com.sas.web.services.maker.axis2.WebServiceMakerPor > >>tTypeSkeleton</parameter> > >> <operation name="MakeWebService"> > >> <messageReceiver > >>class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/> > >> </operation> > >> <operation name="ListWebServices"> > >> <messageReceiver > >>class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/> > >> </operation> > >></service> > >> > >>meta-inf/service.wsdl > >> > >><?xml version="1.0" encoding="utf-8"?> > >><definitions name="WebServiceMaker" > >> xmlns="http://schemas.xmlsoap.org/wsdl/"; > >> > > targetNamespace="http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"; > >> > > xmlns:tns="http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"; > >> > > xmlns:typesns="http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"; > >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";> > >> > >> <types> > >> <schema xmlns="http://www.w3.org/2001/XMLSchema"; > >> > targetNamespace="http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"; > >> > xmlns:tns="http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"; > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >> elementFormDefault="qualified"> > >> > >> <complexType name="StringArrayType"> > >> <sequence> > >> <element name="string" type="string" minOccurs="0" > maxOccurs="unbounded"/> > >> </sequence> > >> </complexType> > >> > >> <element name="MakeWebService" type="tns:MakeWebServiceType"/> > >> <complexType name="MakeWebServiceType"> > >> <sequence> > >> <element name="omrURI" type="string"/> > >> <element name="omrUserID" type="string"/> > >> <element name="omrPassword" type="string"/> > >> <element name="storedProcessPaths" > type="tns:StringArrayType"/> > >> <element name="serviceName" type="string"/> > >> </sequence> > >> </complexType> > >> > >> <element name="MakeWebServiceResponse" > type="tns:MakeWebServiceResponseType"/> > >> <complexType name="MakeWebServiceResponseType"> > >> <sequence> > >> <element name="MakeWebServiceResult" type="string"/> > >> </sequence> > >> </complexType> > >> > >> <element name="ListWebServices" type="tns:ListWebServicesType"/> > >> <complexType name="ListWebServicesType"/> > >> > >> <element name="ListWebServicesResponse" > type="tns:ListWebServicesResponseType"/> > >> <complexType name="ListWebServicesResponseType"> > >> <sequence> > >> <element name="ListWebServicesResult" > type="tns:StringArrayType"/> > >> </sequence> > >> </complexType> > >> > >> <element name="FaultException" type="tns:FaultException"/> > >> <complexType name="FaultException"> > >> <sequence> > >> <element name="ExceptionMessage" type="string" > minOccurs="0" maxOccurs="unbounded"/> > >> </sequence> > >> </complexType> > >> > >> </schema> > >> </types> > >> > >> <message name="MakeWebServiceRequest"> > >> <part name="parameters" element="typesns:MakeWebService"/> > >> </message> > >> <message name="MakeWebServiceResponse"> > >> <part name="parameters" element="typesns:MakeWebServiceResponse"/> > >> </message> > >> <message name="ListWebServicesRequest"> > >> <part name="parameters" element="typesns:ListWebServices"/> > >> </message> > >> <message name="ListWebServicesResponse"> > >> <part name="parameters" element="typesns:ListWebServicesResponse"/> > >> </message> > >> <message name="FaultException"> > >> <part name="fault" element="typesns:FaultException"/> > >> </message> > >> > >> <portType name="WebServiceMakerPortType"> > >> <operation name="MakeWebService"> > >> <input message="tns:MakeWebServiceRequest"/> > >> <output message="tns:MakeWebServiceResponse"/> > >> <fault name="fault" message="tns:FaultException"/> > >> </operation> > >> <operation name="ListWebServices"> > >> <input message="tns:ListWebServicesRequest"/> > >> <output message="tns:ListWebServicesResponse"/> > >> </operation> > >> </portType> > >> > >> <binding name="WebServiceMakerBinding" > type="tns:WebServiceMakerPortType"> > >> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"; > style="document"/> > >> <operation name="MakeWebService"> > >> <soap:operation soapAction=""/> > >> <input> > >> <soap:body use="literal"/> > >> </input> > >> <output> > >> <soap:body use="literal"/> > >> </output> > >> <fault name="fault"> > >> <soap:fault name="fault" use="literal"/> > >> </fault> > >> </operation> > >> <operation name="ListWebServices"> > >> <soap:operation soapAction=""/> > >> <input> > >> <soap:body use="literal"/> > >> </input> > >> <output> > >> <soap:body use="literal"/> > >> </output> > >> </operation> > >> </binding> > >> > >> <service name="WebServiceMaker"> > >> <port name="WebServiceMakerPort" > binding="tns:WebServiceMakerBinding"> > >> <soap:address location="$WEBSVC_URL$"/> > >> </port> > >> </service> > >></definitions> > >> > >> > >> > >>-----Original Message----- > >>From: Deepal Jayasinghe [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, May 11, 2006 12:07 AM > >>To: Tony Dean > >>Subject: Re: runtime lifecycle implementation semantics > >> > >>Service scope will be equal to the scope of the service. The life > time of the service is the life time of the service context. > >> > >>Tony Dean wrote: > >> > >> > >> > >> > >> > >>>Deepal, > >>> > >>>I forgot to ask. How do you configure the service context scope? > I assume in service.xml. Thanks. > >>> > >>>-----Original Message----- > >>>From: Deepal Jayasinghe [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, May 09, 2006 11:45 AM > >>>To: [email protected] > >>>Subject: Re: runtime lifecycle implementation semantics > >>> > >>>Hi Tony > >>>pls see my in line comments > >>> > >>>Tony Dean wrote: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>Hi , > >>>> > >>>>Could you please answer a few questions about lifecycle and > runtime contexts? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>Life cycle of a service is determine by its scope , you can deploy a > >>>service in one of the following scopes > >>> - request scope : life time of the service will be the life time of > >>>request processing > >>> - transport scope : The life time of the service will be the life > >>>time of the transport session and most of the time transport session > >>>is manged by cookies > >>> - soap session scope : The scope maintained using service group id. > >>>- application scope : The life time of the service will be the life > >>>time of the system > >>> > >>>Here the service impl class will be stored in ServiceContext , so > for each scope you will be having service context and its life time > vary depending on the scope. > >>>for example , > >>>- if the service is deployed in application scope , then there will > be only one servicecontex for that service , o.w there can be multiple > service context for a given service on a given time. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>You have addressed the issue of service lifecycle by providing > init(ServiceContext) and destroy(ServiceContext) callbacks that are > called during service initialization and service destruction, > respectively. Now as I understand it you also have a > setOperationContext(OperationContext) callback that is called on every > service invocation to provide an operation context. > >>>> > >>>>>From the operation context, I can get the message context in one > of two way it seems: > >>>> > >>>>Map map = operationContext.getMessageContexts(); > >>>> > >>>>In this case, I'm not sure what to do with multiple message > contexts. Can you explain the need for a map? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>Operation context is to represent a given MEP (Message Exchange > >>>Patterns) , for a given MEP there can be multiple messages so there > can be multiple message contexts as well. That is why you can see a > Map in operation context. It should be note that each message in a > given mep has a unique name. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>MessageContext context = operationContext.getMessageContext(String); > >>>> > >>>>In this case, I'm not sure what input String is designating. Can > you explain? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>The value of the string is the corresponding message label or the > name in a given mep. For an example if the MEP is in-out , then the > value could be "in" or "out" > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>If there is documentation, please direct me to it. I could not > gather enough information from your javadoc. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>I am very sorry for that :( > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>The reason that I need the message context in the first place is > so that I can create a detailed SOAP fault if an exception occurs: > >>>> > >>>> > >>>>messageContext.setProperty(SOAP12Constants.SOAP_FAULT_CODE_LOCAL_NAM > >>>>E, soapFaultCode); > >>>> > >>>>messageContext.setProperty(SOAP12Constants.SOAP_FAULT_REASON_LOCAL_NA > >>>>ME, soapFaultReason); > >>>> > >>>>messageContext.setProperty(SOAP12Constants.SOAP_FAULT_DETAIL_LOCAL_NA > >>>>M > >>>>E, soapFaultDetail); > >>>> > >>>>Maybe there is a better way to create custom, detailed faults now > so that I do not need to set message context properties. Please let > me know that as well. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>I think Chinthaka can answer this better than me :) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>Thank you for your time! > >>>> > >>>>-Tony > >>>> > >>>>Tony Dean > >>>>SAS Institute Inc. > >>>>919.531.6704 > >>>>[EMAIL PROTECTED] > >>>> > >>>>SAS... The Power to Know > >>>>http://www.sas.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>-- > >>>Thanks, > >>>Deepal > >>>................................................................ > >>>~Future is Open~ > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>-- > >>Thanks, > >>Deepal > >>................................................................ > >>~Future is Open~ > >> > >> > >> > >> > >> > >> > >> > >> > > > >-- > >Thanks, > >Deepal > >................................................................ > >~Future is Open~ > > > > > > > > > > > > > > > > -- > Thanks, > Deepal > ................................................................ > ~Future is Open~ > > > -- Thanks, Deepal ................................................................ ~Future is Open~
