Is it possible to create a proxy object in the client code without using any request context?
I want this behavior because I want to send the object to the server multiple times and I cant do so if its associated to single request context.
You can create your proxy with one RequestContext and send it. Once the response is received, the object is frozen and no longer attached to a RequestContext, you can thus send it with another RequestContext (as before, you'll have to wait for the response before being able to use it yet another RequestContext).
I'll investigate if these constraints can be relaxed in a future version of GWT.
Related
I'm running ServiceStack version 4.x and I've created a custom Request Filter Attribute (it inherits from RequestFilterAttribute).
I have some class methods using this custom attribute with ApplyTo parameter. Whenever I use normal HTTP calls the filter gets executed perfectly, the problem comes when one of my services calls internaly a method from another service, the filter then is not executed.
According to the documentation that can be found here:
Order of operations
For non HTTP calls, Request filters with priority >= 0 will be executed right before Action filters.
I have no idea why this is not working, maybe is a bug on the implementation or I misunderstood the documentation.
Any idea how to solve this or a workaround?
Note the non-HTTP Global Request Filters is linked to the Messaging Global Request and Response Filters docs which refer to the MQ Request Filters, i.e:
appHost.GlobalMessageRequestFilters
appHost.GlobalMessageResponseFilters
Only the appHost.PreRequestFilters are executed everywhere, i.e. for every Raw HTTP Handler, HTTP or MQ Service, etc.
I'm working on a GWT project which calls the server via RPC. A typical RPC calls the Server and passes some information and then recieves the answer as an ArrayList.Now we noticed that with a growing database we should use pagination to not overcharge the client with to many objects.
The problem is that there are at the moment many existing methods which are using RPC and each of them would must be modified to provide the necessary information for pagination (Count of Objects,Current Position ) . If i would change every method i would have to edit the Synchronous Interface,the Asynchronous Interface, and the Server and Client class which are using/implementing them.
I tried to create a generic Wrapper class, but i couldn't make it suitable for out project,because each object must be casted back in the original type. Is there a way with less effort to provide pagination without editing many methods?
I am new to GWT and am able to work around with GWT RPC but have problem in understanding how the control flow takes place internally. How it gets translated to AJAX?
Can we use new() instead of GWT.create(someService.class) to make an RPC call?
Why does Google not just use Async version instead of creating 2 interfaces?
What happens internally when we use
TaskService Async = GWT.create(TaskService.class);
I have read that it chooses the browser specific hashname.js file but am not understanding the complete control flow. Also How is the Callback Object used.
Can someone explain the control flow by pointing out the essentials?
UPDATE : #Thomas Broyer, Everything I understood... Just confirming that in case GWT.create() there is a .rpc file in the client side which helps in the deferred(late/runtime) binding. Is that correct?
GWT.create() will in this case call a GWT generator; it'll generate a class implementing the Async interface (and that's why you only have to declare an interface and you never implement it yourself).
See RPC Plumbing Diagram.
Using a generator (or selecting a specific implementation, but in the case of GWT-RPC, a generator is used) is called deferred binding.
So, no, you cannot use new.
As to why there are 2 interfaces, this is so that GWT can check that your server-side code (synchronous) is consistent with your client-side code (async). The reason you call GWT.create on the synchronous interface and it returns an implementation of the async one is legacy. I bet they wouldn't do it that way, were they to re-implement GWT-RPC from scratch.
The generated class will be responsible of serializing the call (method name and arguments) and make an AJAX request (using a RequestBuilder); and then deserialize the response (either of the type declared, or an exception)
Because calls are asynchronous, the callback is used to, well, call your code back when the server responds, after deserialization takes place (so either calling onSuccess with the decoded object, or onFailure with the decoded exception).
See Getting Used to Asynchronous Calls
Does anyone know if it is possible to write to the response stream in OpenRasta rather than returning an object as a response resource? Alternatively, am I able to implement an HTTP handler but still leverage OpenRasta's URL rewriting?
Thanks
Chris
You can always keep an http handler on the side to do specialized things, but that ties you to asp.net and will prevent your code from being portable on other hosts. If that's something you're ok with, any handler that's registered for a specific route will get executed before openrasta on asp.net.
that said, codecs are the ones writing to the response stream, so provided you have a custom IMediaTypeWriter you can write the resource instance on a stream whichever way you want.
Say for example that you returned an IEnumerable from your handler, as those get deferred executed, you can just start the enumeration of those in your custom codec without any problem.
If I have a client app sending requests to my web service, one after another, will the web service be able to handle each request made and not override previous request because of a new request made? I want all requests to be handled and not replaced for another. Will I be able to do this with the multiple requests all coming from the same client
I have no idea why the other answer is so long to what is essentially a simple question about the basics but the answer is yes.
Each request is independent of others, unless you specifically program some sort of crossover into the server (e.g. a static cross-thread list used by every request or a more complex structure).
It is easier to encounter crossover on the client side, if using an asynchronous pattern that gives results via events - you need to make sure you got the result to the correct request (generally done by providing some token as the "custom state" variable, which you can use to determine the original request in the response handler).
The answer depends on your architecture.
For example, if the server is multi-threaded, and the business logic part is stateless, then on the server the requests won't override, as each thread will call a function and return the result.
On the client side, your best bet is to have each request sent from a different thread, so that that thread blocks until it gets its response, then the processing can go on fine.
If you have a different design, please describe it.
UPDATE: Based on the new info here is something you may want to look at:
http://weblogs.java.net/blog/2006/02/01/can-i-call-you-back-asynchronous-web-services
I am curious how, or if, you are doing asynchronous webservice calls. Generally webservices seem to block, but if you are making these calls so fast then I can only assume asynchronicity.
So, the webservice can store the answers on the server-side, so there is a stateful class that stores results in a dictionary, by IP address. The client then polls for answers, so, ideally, if you send a request, you should be able to get back an array of answers as a response. If you have sent all the requests and are still waiting for more responses, then poll. You should be able, again, to get an array of answers, to cut down on wasted bandwidth.
The better approach is to have your client also be a server, so that you send the request, with the IP address:port for the callback, so the server would make a oneway response to the client. But, this is more complicated, but it cuts down on wasting bandwidth.
Update 2: This is being done without checking it, so there is probably errors:
#WebMethod
public ResponseModel[] AnswerQuestion(QuestionModel[] question) {
// Get the IP address of the client
AnswerController ac = new AnswerController(question, ipaddress);
return mypackage.myclass.StaticAnswers.GetAnswers(ipaddress);
// return an array
}
#WebMethod
public ResponseModel[] GetAnswers() {
return mypackage.myclass.StaticAnswers.GetAnswers(ipaddress);
}
OK, this should give a rough idea.
There is no assumptions in AnswerController. It should know everything it needs to do the job, as it will be stateless, so, it refers to no global variables that can change, only const and perhaps static variables.
The StaticAnswers class is static and just stores answers, with the lookup being ipaddress, for speed.
It will return the answers in an appropriate array.
When you have sent the last question then just call GetAnswers until you have gotten back everything. You may need to keep track of how many have been sent, and how many have been received, on the client side.
This isn't ideal, and is a very rough sketch, but hopefully it will give you something to work with.