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

Reply via email to