problem with server-originated DMI methods

[csillag]

I am using DMI operations with my DS.
One of the parameters of my method is a HttpServletRequest, which is passed automatically.

This works fine when the DSRequests come in via HTTP, but does not work when I create them on the server side.

When I do this, I get an exception, since the the reflection-using argument adapter and invoker can not find the required arguments.

I understand that no HttpServletRequest is available this time, but I need to get this information somehow to the method.

Getting a null would be just fine...

* * *

If I remove the attribute, then the DMI call succeeds, but I do not have the HttpServletRequest (and session), which I need.

How can I solve this?

[csillag]

One thing that comes to mind is to use different DMI functions (and thus, different operation bindings, with different operation ids) for the server-originated DSRequests.

To do this, I need to set operationIDs either for the client-originated request, or for the server-originated ones.

Am I on the right track?

A)
The cliens-side ones are mostly generated by DataBound components. How can I influence what OperationID will be osed for the DSRequest generated by them?

B)
On the server side, I create DSRequests with the available constructor, but I do not see an API for setting the operation id, only for getting it. How can I set it?

To go on, I will have to solve either A) or B). How do I do this?

[csillag]

On the server side, I create DSRequests with the available constructor, but I do not see an API for setting the operation id, only for getting it. How can I set it?

There _is_ a setter for operationId, it's just missing from the JavaDoc. (Which seems to be very often the case with server-side JavaDoc.)

[Isomorphic]

On the client-side, use setFetchOperation(), in general set[operationType]Operation() to configure the operationId a DataBoundComponent will use for each operationType it uses (eg a ListGrid may issue all 4 types).

On the server-side, we can't meaningfully synthesize an httpServletRequest if there isn't a servlet involved, so yes, you would either create a separate operationBinding or provide the information required from the httpServletRequest some other way.

Yes, dsRequest.setOperationId() is a supported API. If you see any other API you believe is supported but which is not documented, let us know.

[csillag]

On the server-side, we can't meaningfully synthesize an httpServletRequest if there isn't a servlet involved

You could still give me a null pointer, which is much better than an exception that I can not catch.

so yes, you would either create a separate operationBinding or provide the information required from the httpServletRequest some other way.

I have started to add OperationIDs to the server-side generated DSRequests, and this stops the DMI being invoked at all.

This somewhat surprised me, because I assumed that I need to specify the wanted OperationId in the OperationBinding in the DS XML, and currently none is specified, so I expected all DSRequests to be captured.

Does no specified operationId mean the this OperationBinding will only apply to the requests with no set operationId?

[Isomorphic]

How exactly are you getting an NPE? We can make sure the case is caught and reported more cleanly.

If you set an operationId, only an operationBinding with that operationId will be used. operationBindings with no operationId are used for requests that do not have an operationId specified.

Be sure, if you are iteratively changing the .ds.xml file and trying out new code, that you are restarting your servlet engine if you see anything strange. Hot deploy is flaky in some versions of Eclipse.

[csillag]

How exactly are you getting an NPE? We can make sure the case is caught and reported more cleanly.

I am not getting an NPE, I am getting this:

java.lang.Exception:
Unable to assign a required or optional argument to slot #2 taking type:
javax.servlet.http.HttpServletRequest of method: public
com.isomorphic.datasource.DSResponse
com.nolmecolindor.indi.engine.server.database.Operations.executeLoggedOperation(com.isomorphic.datasource.DSRequest,javax.servlet.http.HttpServletRequest)
throws java.lang.Exception No remaining optional arguments match this
type and all required arguments passed by the client have already been
assigned.
com.isomorphic.base.Reflection.adaptArgsAndInvoke(Reflection.java:858)
com.isomorphic.datasource.DataSourceDMI.execute(DataSourceDMI.java:444)
com.isomorphic.datasource.DataSourceDMI.execute(DataSourceDMI.java:62)
com.isomorphic.datasource.DSRequest.execute(DSRequest.java:1216)
com.nolmecolindor.indi.engine.server.consistency.FunDataTask.run(FunDataTask.java:61)
com.nolmecolindor.indi.engine.server.IndiServerApp.init(IndiServerApp.java:16)
com.nolmecolindor.sgweet.server.utils.SgweetServer.loadUserApp(SgweetServer.java:67)
com.nolmecolindor.sgweet.server.utils.SgweetServer.parseDataFromFirstClient(SgweetServer.java:110)
com.nolmecolindor.sgweet.server.communication.SgweetServiceImpl.mirrorData(SgweetServiceImpl.java:38)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:562)
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:49)
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
org.mortbay.jetty.Server.handle(Server.java:324)
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

If you set an operationId, only an operationBinding with that operationId will be used. operationBindings with no operationId are used for requests that do not have an operationId specified.

This is fine, just counter-intuitive :)
(By default, I assumed that the specification of an operationBinding works like some kind of criteria, so if something is not referenced, thet it's not matched against. Now I know that this is not true.)

Be sure, if you are iteratively changing the .ds.xml file and trying out new code, that you are restarting your servlet engine if you see anything strange. Hot deploy is flaky in some versions of Eclipse.

Thank you for the warning, but I do hot deploy for .ds.xml files, for a variety of reasons:
- They are not directly placed in the war directory, but are copied from the public directory of an inherited GWT module. Currently, eclipse (or the google eclipse plugin) does not seem to hot-deploy changed files from the public directories of inherited modules, so I need to explicitly stop and start the GWT project in order to get them refreshed. (Restart is not enough.)
- I do not edit .ds.xml files directly; I edit something I call ProtoDS (.protods.xml), from which I generate the .ds.xml on the fly. (These ProtoDS XML files contain what the DS XML will contain, plus a bunch of custom goodness I use for declaratively configure various aspects of my application.) This generation process (which I call DS enhancment) only runs once, when the server is started, so editing them while running is pointless.