xitrum
When there's a request comes in, action extending Action will be run directly on the current Netty IO thread.
When there's a request comes in, action extending Action will be run directly on the current Netty IO thread. This gives maximum speed when the action is simple and nonblocking.
See also FutureAction and ActorAction.
An actor will be created when there's request.
An actor will be created when there's request. It will be stopped when: - The connection is closed - The response has been sent by respondText, respondView etc.
For chunked response, it is not stopped right away. It is stopped when the last chunk is sent.
See also Action and FutureAction.
This is the interface for cache implementations of Xitrum.
This is the interface for cache implementations of Xitrum. All methods do not take callbacks, because cache should be fast. The point of using cache is to become faster. There's no point in using a slow cache.
Actions extending FutureAction will be run asynchronously in a future.
Actions extending FutureAction will be run asynchronously in a future. The execution context is xitrum.Config.actorSystem.dispatcher.
See also Action and ActorAction.
If you don't care about the class name where the log is made, without having to extend this trait, you can call like this directly: xitrum.Log.debug("msg"), xitrum.Log.info("msg") etc.
By default all non-GET requests are checked for anti-CSRF token.
By default all non-GET requests are checked for anti-CSRF token. Make your controller (normally APIs for machines, e.g. smartphones) extend this trait if you want to skip the check. Subclasses of the controller will also not be checked.
An actor will be created when there's new SockJS session.
An actor will be created when there's new SockJS session. It will be stopped when the session is closed.
An actor will be created when there's request.
An actor will be created when there's request. It will be stopped when: - The connection is closed - WebSocket close frame is received or sent
This represents things in xitrum.conf.
To innclude xitrum.js in your view, use: url[xitrum.js].
See config/xitrum.properties
Dual config means the config can be in either one of the 2 forms:
Dual config means the config can be in either one of the 2 forms:
config { key = a.b.c }
Or:
config { key { "a.b.c" { option1 = value1 option2 = value2 } } }
This is a convenient helper to let you call like this directly: xitrum.Log.debug("msg"), xitrum.Log.info("msg") etc.
This is a convenient helper to let you call like this directly: xitrum.Log.debug("msg"), xitrum.Log.info("msg") etc.
If you do care about the class name where the log is made, use trait xitrum.Log.
Pong is automatically sent by Xitrum, don't send it yourself.
Path to the root directory of the current project.
Path to the root directory of the current project. If you're familiar with Rails, this is the same as Rails.root.
Things that are usually used by application developers are put in this package for convenience, because when they want to use XXX, they can simply write:
import xitrum.XXXTo avoid polluting this namespace, things that are utilities should be put in package xitrum.util, not here.
Annotations and validators are put to package xitrum.annation and xitrum.validator because there are many of them. It's better for application developers to write: