If thats the case I can fix our build so that we ship our own admin service for Data services with the same name. This will of course inherit most of the functions from WSAS. I'll get it done soon.
Thanks, Keith. Tyrell Perera wrote: > The service name is hard coded in a javascript file and cannot be > changed unless we bring the whole front-end to our svn. > > The 3rd option then, would be to get rid of the original service > provided by the dataservices solution and replace it with our own, which > inherits most of the stuff except read/write from the original pojo > service. > > > Tyrell > > > Keith Chapman wrote: >> Wouldn't this cause problems if two data services r saved concurrently? >> So i don't think we can use either of these approaches. We may have to >> put in our own service to do this. Can you change the service URL at the >> front end? > >> Thanks, >> Keith. > >> Tyrell Perera wrote: >>> Keith, >>> >>> There is a way to set the repo where the actual dataservice config files >>> reside. The property is >>> >>> DBConstants.DB_SERVICE_REPO (org.wso2.ws.dataservice.DBConstants line 168) >>> >>> I see 2 ways to set this property; >>> >>> 1. If we can set this property at the time of the Mashup Server >>> initialization, the Data Service Admin will pick it up from there and >>> will hopefully prevent storing the file in a wrong location (as it does >>> at present). >>> >>> or >>> >>> 2. Since our storage strategy is user based, I can try setting this >>> config property from the JSP itself. At the JSP level I already know >>> which user is creating the Data Service and will be able to infer the >>> repo location using this information. >>> >>> Thoughts ? >>> >>> Tyrell >>> >>> >>> >> _______________________________________________ >> Mashup-dev mailing list >> [email protected] >> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev > > > > _______________________________________________ Mashup-dev mailing list [email protected] http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
