Kris McQueen
|
c32d6e7524
|
Template id is not a required parameter when listing templates. The proper serialized name for the async job id is jobid, not id. Sadly, ctxAccoutId != ctxAccountId, ugh, no wonder the UserContext wasn't getting set up correctly. Clean up some miscellaneous unnecessary casts.
|
2010-09-21 17:00:50 -07:00 |
|
Kris McQueen
|
e2e0e76063
|
More work on serializing responses. Now responses have to have the name set on them, and the name will eventually be serialized to the JSON/XML response the way it used to work for commands themselves [the result of cmd.getName() was written to the response string]. For list respones, we wrap the individual objects in a ListResponse object that has the name of the response, and the individual objects have the object name so that accounts will be something like <listaccountsresponse><account><...></account><account><...></account></listaccountsresponse>.
|
2010-09-17 17:13:04 -07:00 |
|
Kris McQueen
|
4a73639d67
|
Fix up setting the response object correctly after dispatching the api method call. Begin working on the serialization of the responses which don't include the command name just yet, that's coming.
|
2010-09-17 14:56:55 -07:00 |
|
Kris McQueen
|
3f6a438d92
|
Refactoring the AsyncJobManager to queue jobs appropriately if there is a need to synchronize execution on an object, e.g. a router. API developers can now call command.synchronizeCommand(String, Long) to force the command to be synchronized on a particular object type [the string arg] with a particular id [the long arg]. When synchronizeCommand() is invoked, an exception maybe thrown by the framework (AsyncCommandQueued exception) to force the business logic to abort. The command will then be queued and invoked at the appropriate time. The synchronizeCommand() is re-entrant and will be a no-op if the command has already been queued and is now ready for execution.
|
2010-09-16 19:05:06 -07:00 |
|
Kris McQueen
|
dbb2897626
|
Unexposed parameters can now be assigned to commands. This are for internal use of the command, and will be serialized/deserialized during execution/response phases, but will not be accepted as part of the API request. Also create a DB utility file for the API to use which delegates requests to the DAOs. Mostly this utility class will look up objects by ID, and it allows the removal of similar methods from ManagementServer, thereby reducing some of the clutter in ManagementServer.
|
2010-09-14 14:54:04 -07:00 |
|
Kris McQueen
|
f4caf145c3
|
Refactoring dispatching API commands from the scheduled async job. Instead of calling an executor, the dispatcher invokes the method on the manager directly. After the command is executed the response is serialized to the async job table so it can be queried later. Also serialize a response for async create commands that includes the id of the object being created.
|
2010-09-13 18:28:19 -07:00 |
root
|
76e5cf3321
|
renamed dao methods to correctly reflect what they do
|
2010-09-09 18:01:50 -07:00 |
Manuel Amador (Rudd-O)
|
05c020e1f6
|
Source code committed
|
2010-08-11 09:13:29 -07:00 |