Supun .... why users want to specify an endpoint in-lined does user not like to specify a name ?
or does user not like to define an endpoint and use it by referring <endpoint key="same name"/> because the defined endpoint is only used and not reused by many ... therefore , <endpoint key="same "/> is a little bit redundant ... ? If the case is the second one , making endpoint name mandatory is acceptable. if the case can be either one or two and user has enabled one of operations for which a unique id is required ( stats , clustering, etc) , then the making endpoint name mandatory is acceptable... we can throw an error and exit as a one of system operation can not be done as there is no enough information. If the reason is only case one .... no option ..we have to generate a meaningful yet unique name .. In any other case , we can only recommend to use an name for an endpoint because a properly given name would be helpful to debug ,etc ... For this case , we can only document Thanks Indika On Fri, Apr 30, 2010 at 9:32 PM, Supun Kamburugamuva <supu...@gmail.com>wrote: > Sorry I'm bit late to the conversation. I think the proper solution would > be to force the user to have a name for each and every endpoint. This is a > best practice in a production deployment. The name helps to understand > endpoint behavior. For example when an endpoint is suspended user cannot > identify it easily if it doesn't have a name. So it is good if we can > enforce this at the synapse level. > > Thanks, > Supun... > > > On Tue, Apr 27, 2010 at 2:44 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: > >> +1 >> >> Ruwan >> >> >> On Tue, Apr 27, 2010 at 10:55 AM, Hiranya Jayathilaka < >> hiranya...@gmail.com> wrote: >> >>> Here's a little progress update. I have realized that it is difficult to >>> generate descriptive and context sensitive names for endpoints on the fly. >>> Reason is given an endpoint we cannot determine it's parent. We can do that >>> for proxy services, but for sequences it is almost impossible. Therefore we >>> will have to stick to the UUIDs at least for the moment. >>> >>> However I was able to get the concept of endpoint anonymity implemented >>> without changing the top level Endpoint interface. All the endpoint >>> serializers work with the AbstractEndpoint level, so I added the necessary >>> methods there. If the user hasn't explicitly specified a name for an >>> endpoint it is considered anonymous. The system will generate names for such >>> endpoints but they will not be displayed in the serialization. >>> >>> I have raised SYNAPSE-627 to keep track of this. >>> >>> Thanks, >>> Hiranya >>> >>> >>> On Mon, Apr 26, 2010 at 5:34 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: >>> >>>> +1 >>>> >>>> Ruwan >>>> >>>> >>>> On Mon, Apr 26, 2010 at 5:28 PM, Hiranya Jayathilaka < >>>> hiranya...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Apr 26, 2010 at 5:04 PM, Ruwan Linton >>>>> <ruwan.lin...@gmail.com>wrote: >>>>> >>>>>> Hiranya, >>>>>> >>>>>> Lets introduce an internal flag to the endpoint so that the builder >>>>>> and the serializer pair sets and checks respectively to make the >>>>>> generated >>>>>> name transparent from the users configuration. >>>>>> >>>>>> To address the issue of having different, UUID's on different server >>>>>> start sessions, we could compute the endpoint name by looking at the >>>>>> parent >>>>>> sequence name, for example like "main_ep_1" and so forth. >>>>>> >>>>> >>>>> That makes sense. Shall we add following two methods to the Endpoint >>>>> interface then? >>>>> >>>>> public boolean isAnonymous(); >>>>> public void setAnonymous(); >>>>> >>>>> Anonymous endpoints will also get a generated name but that will not be >>>>> shown to the user in the serialization. >>>>> >>>>> Thanks, >>>>> Hiranya >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Ruwan >>>>>> >>>>>> >>>>>> On Mon, Apr 26, 2010 at 4:52 PM, Hiranya Jayathilaka < >>>>>> hiranya...@gmail.com> wrote: >>>>>> >>>>>>> Devs, >>>>>>> >>>>>>> Currently Synapse generates names for anonymous endpoints. For an >>>>>>> example take the following sequence: >>>>>>> >>>>>>> <sequence name="foo"> >>>>>>> <send> >>>>>>> <endpoint> >>>>>>> <address uri="some address"/> >>>>>>> </endpoint> >>>>>>> </send> >>>>>>> </sequence> >>>>>>> >>>>>>> Synapse will generate a UUID and set that as the name of the >>>>>>> endpoint. This is required since all endpoints must have names in >>>>>>> clustered >>>>>>> deployments. However generating names causes the serialization to be >>>>>>> different from the original input XML. As a result we currently have a >>>>>>> bunch >>>>>>> of test failures in the trunk. Any idea how to resolve this problem? >>>>>>> >>>>>>> Thanks >>>>>>> -- >>>>>>> Hiranya Jayathilaka >>>>>>> Software Engineer; >>>>>>> WSO2 Inc.; http://wso2.org >>>>>>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ruwan Linton >>>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >>>>>> >>>>>> WSO2 Inc.; http://wso2.org >>>>>> email: ru...@wso2.com; cell: +94 77 341 3097 >>>>>> blog: http://ruwansblog.blogspot.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Hiranya Jayathilaka >>>>> Software Engineer; >>>>> WSO2 Inc.; http://wso2.org >>>>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Ruwan Linton >>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >>>> WSO2 Inc.; http://wso2.org >>>> email: ru...@wso2.com; cell: +94 77 341 3097 >>>> blog: http://ruwansblog.blogspot.com >>>> >>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Software Engineer; >>> WSO2 Inc.; http://wso2.org >>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >> >> >> >> -- >> Ruwan Linton >> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >> WSO2 Inc.; http://wso2.org >> email: ru...@wso2.com; cell: +94 77 341 3097 >> blog: http://ruwansblog.blogspot.com >> > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > >
