Ruwan
> but JMX management and error notifications like suspensions and so forth > cannot be controlled if those endpoints are inlined in, say send mediator. > The JMX management and all that are only possible for declared endpoint > I am not sure this ... I have not looked the endpoint code for a long time..But as remind , It should just need a name and does not depend on in-lined / declared > The only enforcement that we can do to get rid of all that is to disable > the ability to have inlined endpoints, but I am strongly -1 on this > approach, since it reduces a usability a lot. > > Also, please note that we do not sacrifice correctness by any means hear, > if we do this enforcement, we loose the usability and if we keep this as it > is then again what we will loose is the usability, but the usability > reduction on the first approach is huge with compared to doing this change. > > Hence, I am -1 on enforcing a name for inlined endpoints or disabling the > ability to have inlined endpoints. > > Thanks, > Ruwan > > I also do not like to remove in-lined endpoints.... but ....making endpoint name mandatory brings advantages than disadvantages to a user even he may not be aware at first time the importance of a meaningful name. Thanks Indika > On Tue, May 4, 2010 at 5:22 PM, indika kumara <indika.k...@gmail.com>wrote: > >> I too agree with supun ... >> >> The usability may depend on the answer for 'Why does a user like in-lined >> configurations? '. That is why I really needed a good answer from real >> users... >> >> The correctness is come first and the most important quality attribute >> than other quality attributes. Irrespective of the criticality of the >> operation that depends on the name of the endpoint, the operation should be >> worked correctly. At least, if any operation that needs the name of the >> endpoint is enabled, then we should validate the uniqueness of the endpoint >> name. >> >> Thanks >> Indika >> >> On Tue, May 4, 2010 at 12:06 PM, Supun Kamburugamuva >> <supu...@gmail.com>wrote: >> >>> >>> >>> On Sun, May 2, 2010 at 5:44 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: >>> >>>> >>>> >>>> On Sun, May 2, 2010 at 11:24 AM, Hiranya Jayathilaka < >>>> hiranya...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva < >>>>> supu...@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka < >>>>>> hiranya...@gmail.com> wrote: >>>>>> >>>>>>> Hi Supun, >>>>>>> >>>>>>> On Fri, Apr 30, 2010 at 9:02 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. >>>>>>> >>>>>>> >>>>>>> I think we should be a little more flexible here. Most users will >>>>>>> appreciate the ability to define in-line endpoints anonymously. It's a >>>>>>> usability thing. >>>>>>> >>>>>>> >>>>>> Here I'm not suggesting to remove the support for anonymous endpoints. >>>>>> My suggestion was to force a name to every endpoint regardless of weather >>>>>> they are defined in-line or separately. >>>>>> >>>>> >>>>> Supun, this is exactly what I think we shouldn't be doing. If we are >>>>> forcing the user to define names for each and every endpoint, then we are >>>>> actually getting rid of the support for anonymous endpoints. >>>>> >>>> >>>> +1 >>>> >>>> We should try our best to keep the simple case as simple. Anonymous >>>> endpoints are very usable from the users point of view, and at least 70-80% >>>> of the users are not enabling clustering, if we are to enforce a name for >>>> every endpoint regardless whether it is inlined or not, we are making the >>>> simple case hard from the user point of view. >>>> >>>> My belief is doing the correct thing is important than the usability at >>> least when the usability degradation is minimal. I think that is the exact >>> reason why we are trying to make the synapse language schema compliant now. >>> >>> Also forcing a name for an inline endpoint is not that user un-friendly. >>> To define an endpoint user has to do many things. So I think just including >>> the name attribute is not a big user un-friendly thing compared to all the >>> things user has to do already. >>> >>> My concerns about name generation are not only with clustering. Lets say >>> an anonymous endpoint got suspended or received a time-out error. How can >>> the user know which endpoint got suspended or received the error? >>> >>> Also lets say user wants to do JMX monitoring. How can he distinguish the >>> different endpoints? >>> >>> I think synapse language should always force the production best >>> practices and I think having a meaningful name to an endpoint is a >>> production best practice that every deployment should do. >>> >>> Thanks, >>> Supun.. >>> >>> >>>> Thanks, >>>> Ruwan >>>> >>>> >>>>> >>>>> Thanks, >>>>> Hiranya >>>>> >>>>> >>>>>> >>>>>> Even now user can do this. But system doesn't enforce this, and we >>>>>> have to generate a name. So my suggestion was to make the name attribute >>>>>> of >>>>>> the endpoint mandatory. >>>>>> >>>>>> Thanks, >>>>>> Supun.. >>>>>> >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> +1... But it should only be a best practice. If the user does not >>>>>>> want to bother with endpoint management stuff then forcing him to set >>>>>>> names >>>>>>> for each and every endpoint is not necessary (Needless to say, a large >>>>>>> config would have dozens and dozens of endpoints - so it's not an easy >>>>>>> job >>>>>>> either). Also other than these management capabilities, names of the >>>>>>> in-line >>>>>>> endpoints don't have any other usage either. You cannot refer to them >>>>>>> from >>>>>>> other sequences etc using the specified name. >>>>>>> >>>>>>> If the problem is with clustering scenarios, they will work just >>>>>>> fine, since we are generating names for unnamed, in-line endpoints. >>>>>>> >>>>>>> Thanks, >>>>>>> Hiranya >>>>>>> >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Software Engineer, WSO2 Inc >>>>>> http://wso2.org >>>>>> supunk.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 >>> >>> >>> >> > > > -- > 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 >
