Hi,
This issue was driving me nuts.. It costs me so much time to update
these policy files (re-deploy/restart server). I even ended up with
around 100 policy files whereas I only need about 10 (for different
gwt app's against the same backend), but I didn't dare to clean them
as I didn't know
Hi,
I am a bit lost here.
I mean, I don't really understand why I even need these policy files and why
they aren't more flexible in usage (maybe even optional).
If I am correct, it's there for security reasons, it's used to indicate
which objects are allowed to be (de)serialized.
But what if I
dear all!
what we do is at compilation time, with ant, to move the policy files
to the package of the server side implementation of the service, and
to use following loader:
/**
* We do not want that the server goes to fetch files from the
servlet context, so we keep the .gwt.prc files
All necessary information is comming in the RPC call. If you take a
look into RemoteContextSerializationPolicy you can see how the HTTP
connection is initiated. You don't have to take care about where are
RPCs located because the call itself will tell you.
The drawback of remote context is that
I gave the above remote context some more thoughts, and it's not an
option:
- I run in the following environments: dev, test, acceptance,
production and build.
The dev and build environments are the ones that give me problems as I
run GWTTestCase's in these mode's with a proxy servlet to forward
I've messed with no server mode and serialization files a bit but
unfortunately my situation is somewhat simpler so I don't think what
I've done is directly applicable. I'm using GWT 2.0 so some of this
may does not apply if you are using earlier versions.
I have an simpler situation than you do
Thanks for your thoughts Alex.
The solution is a bit like discussed above with Ladislav.
I am still not so happy about retrieving this rpc files from different
locations in different environments and also having to configure a
HTTP context in the build/dev environment to be able to retrieve the
well, you may have as many client contexts as you wish. In local
context configuration you need to copy RPC files to the server - and
that is what you apparently don't want. But in remote context these
RPC files are generated on the client (by ProxyCreator), they remain
there and server is able to
He,
to fetch them using HTTP connection to appropriate client.
Indeed, that doesn't sound that bad, but I will need to maintan a mapping
between the moduleBaseUrl that I receive in the backend and the actual http
url of the module location where I can find the policy file. And these
mappings are
Hi Ed,
maybe this will give you some relevant answers:
http://code.google.com/p/acris/wiki/SeparateClientAndServer ,
especially the part Accessing RPC files from server. There is a
solution how to access RPC files in no-server mode remotely also.
On 22. Feb, 11:17 h., Ed post2edb...@hotmail.com
Hi Ladislav,
Thanks for your response.
I do almost the same thing as Acris does, I only have my files located in
the classpath (I also use GWT-SL to read my policy files)..
But Acris also doesn't solve the problem of having all these policy files
scattered around and assumes that you have them
11 matches
Mail list logo
