interpreting javascript with RESTful servlet

I am using a rest service to return an html string to a calling application; when I directly place a javascript function (using script tag) within the html that is returned the browser is able to interpret what it receives and the function can be executed. However, when I only include a reference to a javascript function (ie. using a script tag to include a .js file) rather than the function itself then the function is not included in the returned html (just the literal reference to the .js file) and it won't execute on the browser.

Inasmuch as web services aren't really intended to return markup to browsers this doesn't surprise me, but assuming I have a good reason for wanting to do this is there a way to force the REST servlet to interpret/include javascript the same way, say, a jsp page would if it received a get request? Basically I want it to pull in the javascript function I am referencing and include it in the string that it returns.

thanks

If the returned HTML is assembled manually (so to speak), then it should be possible for the server code to read the contents of the .js file -and include it in the response- without too much difficulty.

If would get trickier if there was some kind of framework that generates the response.

yes you are right, the problem though is I am including a (large) jquery function, which has dependencies on other jquery functions (in other .js files), so it would be awful nice if I could get the container to do it. one thought I had was if I could write a restful JSP (instead of a servlet) then the container would automatically include any referenced js files.

I see. Client-side JavaScript code can cause additional script files to be loaded like this:
<script type="text/javascript"> var url = "http://www.myserver.com/mywebapp/myscript.js"; var script = document.createElement("script"); script.setAttribute("src", url); script.setAttribute("type", "text/javascript"); document.body.appendChild(script); </script>
This may cause timing problems, though, since the loading (and eventual execution) of the script will take place when the currently executing code has finished running (or at best concurrent to it with no control over which gets run first). You may have to add some callback-like features to the newly-loaded code so that execution can resume once its loaded.