On Sun, May 8, 2011 at 11:12 AM, Afkham Azeez <az...@wso2.com> wrote:
> We have discussed this extensively. The proper solution is to add a > parameter to axis2.xml which specifies the behavior of the transports > element not being present in the services.xml. Either this could mean, > expose on all transports, or don't expose on any transports. IIRC the idea was to make it configurable what 'all transports' mean. > If this is don't expose on any transport, the services.xml should declare > the transports on which this service has to be exposed. In either case, the > user's existing services will not simply work OOTB without some changes. > Agreed. However I'm not too concerned about user defined services at this point. User knows through which transports a service needs to be exposed and he can use the features provided in our UI (service-mgt, transport-mgt) to configure the services to fit his exact needs. If a service needs to be exposed over a transport like VFS or mail, he can add the required parameters to the service. If he doesn't, service will only be exposed over HTTP/S which is not bad either. The problem is with our built-in admin services. User has no control over these. So trying to expose them over transports for which they are not configured isn't correct. Thanks, Hiranya > _______________________________________________ > Carbon-dev mailing list > Carbon-dev@wso2.org > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev