Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Merge branch 'gh-pages' of https://github.com/vert-x/vertx-mods into …

…gh-pages
  • Loading branch information...
commit ed5e5d52e679e2de1029862f3f535f19884855fe 2 parents 8503b39 + 5e37548
@purplefox purplefox authored
View
BIN  mods/com.campudus.session-manager-v1.1.1/mod.zip
Binary file not shown
View
236 mods/com.campudus.session-manager-v1.2.0/README.md
@@ -0,0 +1,236 @@
+# Session Manager
+
+This module allows to store data in a session. Sessions can time out after a specified amount of time. The stored information of timed out sessions will be deleted.
+
+The latest version of this module can be found in the [campudus/vertx-session-manager repository](https://github.com/campudus/vertx-session-manager).
+
+## Dependencies
+
+This module requires the scala language module (org.scala-lang.scala-library-v2.9.2) to work. It is built against Vert.x 1.3.1.
+
+It uses either SharedData maps provided by Vert.x or a MongoDB to save its information, depending on your configuration (see below).
+
+If you want to use MongoDB, the [Vert.x MongoDB Persistor](https://github.com/vert-x/mod-mongo-persistor) is required.
+
+## Name
+
+The module name is `com.campudus.session-manager`.
+
+## Configuration
+
+The session manager module takes the following configuration:
+
+ {
+ "address": <address>,
+ "timeout": <timeout>,
+ "cleaner": <cleanerAddress>,
+ "prefix": <prefix>,
+ "map-timeouts": <sharedMap>,
+ "map-sessions": <sharedMap>,
+ "mongo-sessions": {
+ "address": <mongoAddress>,
+ "collection-name": <collection-name>
+ }
+ }
+
+For example:
+
+ {
+ "address": "test.session-manager",
+ "timeout": 15 * 60 * 1000,
+ "cleaner": "test.session-cleanup",
+ "prefix": "session-client."
+ }
+
+A short description about each field:
+* `address` The main address for the module. Every module has a main address. Defaults to `campudus.session`.
+* `timeout` How long sessions should be stored. If a timeout occurs, the session will be deleted and is not available anymore. The timeout is set as a long value in milliseconds. Defaults to `30 * 60 * 1000`, i.e. 30 Minutes.
+* `cleaner` As soon as a session gets destroyed, it will be sent to this address. This is useful for cleanup purposes. Since you can only store basic information in the session like a shopping-cart id, you can delete the shopping-cart in your database with the provided session, for example. If the cleaner address is null, the session won't be sent anywhere. Defaults to `null`.
+* `prefix` An address prefix where clients can listen on with their session id. If their session timed out or got killed, they will receive a message on `<prefix><sessionId>`. Defaults to `campudus.sessions.`
+* `map-timeouts` The name of the shared map to be used to save timer-ids. Defaults to `com.campudus.vertx.sessionmanager.timeouts`.
+* `map-sessions` The name of the shared map to be used for the session storage. Defaults to `com.campudus.vertx.sessionmanager.sessions`.
+* `mongo-sessions` The configuration, when using MongoDB. If this is set, the session manager won't use SharedData and just use the MongoDB.
+ * `address`: The main address of the MongoDB Persistor.
+ * `collection`: The name of the collection, in which the session data should be stored.
+
+## Operations
+
+The module supports a few operations. If you want to let clients use the session manager directly, be careful which commands you let them use.
+
+Operations are sent by specifying an `action` String and required and optional parameters. If a required parameter is missing, the server will reply with an error message in this format:
+
+ {
+ "status" : "error",
+ "error" : "KIND_OF_ERROR",
+ "message" : "Some kind of descriptive text, what went wrong exactly"
+ }
+
+The session manager can also _raise_ errors to the client directly, sending an error message to `campudus.session.94b1a3fe-16df-4ab2-ac10-aae67ad2c46d` for example, if the prefix is set to `campudus.sessions.`. If you provide an action which the session manager does not know, it will reply with error `UNKNOWN_COMMAND`.
+
+### start
+
+Starts a session and provides the caller with a session id.
+
+To start a session, send a JSON message to the modules main address:
+
+ {
+ "action": "start"
+ }
+
+The session manager will reply with a sessionId inside the data, looking like this:
+
+ {
+ "sessionId": "94b1a3fe-16df-4ab2-ac10-aae67ad2c46d"
+ }
+
+You now have created a session which will timeout in 30 minutes, if you didn't change the default timeout. With this id, you can store and retrieve data.
+
+### destroy
+
+Destroys a session immediately.
+
+This is useful if you want to log out a client for example. All destroyed session data will be sent to the `cleaner` address, if you specified it in the configuration. The client will receive a message at `<prefix><sessionId>`, that its session was killed.
+
+To destroy a session, send a JSON message to the modules main address:
+
+ {
+ "action": "destroy",
+ "sessionId": <sessionId>
+ }
+
+Where `sessionId` is the id of the session, which should be destroyed.
+
+An example would be:
+
+ {
+ "action": "destroy",
+ "sessionId": "94b1a3fe-16df-4ab2-ac10-aae67ad2c46d"
+ }
+
+This would delete all information about session `94b1a3fe-16df-4ab2-ac10-aae67ad2c46d` from the shared data and send all the previously stored information to the `cleaner` address. If you set up `prefix` in the config to `session.`, a message in this format will be sent to that address:
+
+ {
+ "status": "SESSION_KILL"
+ }
+
+If an administrator kills the session of a client, the client can be notified via a registered handler on that address.
+
+As soon as the session is destroyed, the server will reply with
+
+ {
+ "sessionDestroyed": true
+ }
+
+It will always reply with this message, to inform you that the work was done and the session is gone. It will do so even if the `sessionId` didn't exist before. If you did not specify a `sessionId` at all, it will reply with error `SESSIONID_MISSING`.
+
+### clear
+
+This command destroys all sessions immediately. Every session gets sent to the `cleaner` address and an error `SESSION_KILL` is sent to `<prefix><sessionId>`.
+
+You should be very careful not to let everyone use this command:
+
+ {
+ "action": "clear"
+ }
+
+It works analog to the `destroy` action. As soon as the work is done, the server will reply with:
+
+ {
+ "cleared": true
+ }
+
+### heartbeat
+
+Sends a heartbeat to the server, resetting the timeout of the session. If you don't want to loose your session information but don't use `get` or `set` commands often enough, you can send this command to prevent the automatic deletion of the session.
+
+ {
+ "action": "heartbeat",
+ "sessionId": <sessionId>
+ }
+
+You have to provide a valid `sessionId`, otherwise the heartbeat will reply with error `SESSIONID_MISSING`.
+
+### get
+
+Gets some data from the session storage. You can get multiple fields with one command.
+
+ {
+ "action": "get",
+ "sessionId": <sessionId>,
+ "fields": [<field1>, <field2>, <field3>, ...]
+ }
+
+* `sessionId` is required and results in a `SESSIONID_MISSING` error, if not set. If the session is set but could not be found, a `SESSION_GONE` error is raised (i.e. sent to the session handler directly).
+* `fields` is required, too, and replies with a `FIELDS_MISSING` error, when omitted. If one of the fields cannot be found, the result of that field will be null.
+
+### put
+
+Stores data in the session. You provide a JsonObject and it gets stored in the session.
+
+ {
+ "action": "put"
+ "sessionId": <sessionId>
+ "data": <JsonObject>
+ }
+
+As soon as the session manager saved the data in the session, it will reply with `"sessionDataSaved": true`. There can be three kinds of errors:
+* `sessionId` was omitted: The session manager replies with error `SESSIONID_MISSING`.
+* `data` was not provided: The session manager replies with error `DATA_MISSING`.
+* `data` is not a JsonObject: The session manager replies with error `WRONG_DATA_TYPE`.
+
+If you send a key in `data` which already existed in the session storage, it will be overwritten by the value provided in the `data` object.
+
+### status (access statistics or check session matches)
+
+The session manager can also provide you some statistics about itself. You can access these tools by sending `status` as action and provide a `report` field.
+
+If you want to get a report, which doesn't exist the session manager will reply with a `UNKNOWN_REPORT_REQUEST` error.
+
+#### connections
+
+This report shows how many sessions are stored in the session storage right now.
+
+ {
+ "action": "status",
+ "report": "connections"
+ }
+
+It will result in a message like this:
+
+ {
+ "openSessions": 16
+ }
+
+
+
+#### matches
+
+This report shows the session ids, which match the specified information. This can be used in a chat-application to find out whether a specific nickname is already in use for example. This template will make use of the feature:
+
+ {
+ "action": "status",
+ "report": "matches",
+ "data": <JsonObject>
+ }
+
+The `match` object behaves like the matcher in the event bus bridge. You set a subset of an object and if it matches with one of the stored sessions, the matching stored sessions will be replied by the session manager.
+
+Here is an example to look for sessions which have stored the fields `race` with value `human` and `power` set to 5:
+
+ {
+ "action": "status",
+ "report": "matches",
+ "data": {
+ "race": "human",
+ "power": 5
+ }
+ }
+
+This would assemble a list of session ids and reply them back to the caller in this manner:
+
+ {
+ "matches": true,
+ "sessions": ["", ""]
+ }
+
+If there were no matches, the `sessions` list is empty and `matches` is false.
View
BIN  mods/com.campudus.session-manager-v1.2.0/mod.zip
Binary file not shown
View
282 mods/com.campudus.session-manager-v1.2.1/README.md
@@ -0,0 +1,282 @@
+# Session Manager
+
+This module allows to store data in a session. Sessions can time out after a specified amount of time. The stored information of timed out sessions will be deleted.
+
+The latest version of this module can be found in the [campudus/vertx-session-manager repository](https://github.com/campudus/vertx-session-manager).
+
+## Dependencies
+
+This module requires the scala language module (org.scala-lang.scala-library-v2.10.0) to work. It is built against Vert.x 1.3.1.
+
+It uses either SharedData maps provided by Vert.x or a MongoDB to save its information, depending on your configuration (see below).
+
+If you want to use MongoDB, the [Vert.x MongoDB Persistor](https://github.com/vert-x/mod-mongo-persistor) is required.
+
+## Name
+
+The module name is `com.campudus.session-manager`.
+
+## Configuration
+
+The session manager module takes the following configuration:
+
+ {
+ "address": <address>,
+ "timeout": <timeout>,
+ "cleaner": <cleanerAddress>,
+ "prefix": <prefix>,
+ "map-timeouts": <sharedMap>,
+ "map-sessions": <sharedMap>,
+ "mongo-sessions": {
+ "address": <mongoAddress>,
+ "collection-name": <collection-name>
+ }
+ }
+
+For example:
+
+ {
+ "address": "test.session-manager",
+ "timeout": 15 * 60 * 1000,
+ "cleaner": "test.session-cleanup",
+ "prefix": "session-client."
+ }
+
+A short description about each field:
+* `address` The main address for the module. Every module has a main address. Defaults to `campudus.session`.
+* `timeout` How long sessions should be stored. If a timeout occurs, the session will be deleted and is not available anymore. The timeout is set as a long value in milliseconds. Defaults to `30 * 60 * 1000`, i.e. 30 Minutes.
+* `cleaner` As soon as a session gets destroyed, it will be sent to this address. This is useful for cleanup purposes. Since you can only store basic information in the session like a shopping-cart id, you can delete the shopping-cart in your database with the provided session, for example. If the cleaner address is null, the session won't be sent anywhere. Defaults to `null`.
+* `prefix` An address prefix where clients can listen on with their session id. If their session timed out or got killed, they will receive a message on `<prefix><sessionId>`. Defaults to `campudus.sessions.`
+* `map-timeouts` The name of the shared map to be used to save timer-ids. Defaults to `com.campudus.vertx.sessionmanager.timeouts`.
+* `map-sessions` The name of the shared map to be used for the session storage. Defaults to `com.campudus.vertx.sessionmanager.sessions`.
+* `mongo-sessions` The configuration, when using MongoDB. If this is set, the session manager won't use SharedData and just use the MongoDB.
+ * `address`: The main address of the MongoDB Persistor.
+ * `collection`: The name of the collection, in which the session data should be stored.
+
+## Operations
+
+The module supports a few operations. If you want to let clients use the session manager directly, be careful which commands you let them use.
+
+Operations are sent by specifying an `action` String and required and optional parameters. If a required parameter is missing, you sent an incorrect action or something similar, the server will reply with an error message in this format:
+
+ {
+ "status" : "error",
+ "error" : "KIND_OF_ERROR",
+ "message" : "Some kind of descriptive text, what went wrong exactly"
+ }
+
+The session manager can also _raise_ errors to the client directly, sending an error message to `campudus.session.94b1a3fe-16df-4ab2-ac10-aae67ad2c46d` for example, if the prefix is set to `campudus.sessions.`. If you provide an action which the session manager does not know, it will reply with error `UNKNOWN_COMMAND`.
+
+### start
+
+Starts a session and provides the caller with a session id.
+
+To start a session, send a JSON message to the modules main address:
+
+ {
+ "action": "start"
+ }
+
+The session manager will reply with a sessionId inside the data, looking like this:
+
+ {
+ "status": "ok",
+ "sessionId": "94b1a3fe-16df-4ab2-ac10-aae67ad2c46d"
+ }
+
+You now have created a session which will timeout in 30 minutes, if you didn't change the default timeout. With this id, you can store and retrieve data.
+
+### destroy
+
+Destroys a session immediately.
+
+This is useful if you want to log out a client for example. All destroyed session data will be sent to the `cleaner` address, if you specified it in the configuration. The client will receive a message at `<prefix><sessionId>`, that its session was killed.
+
+To destroy a session, send a JSON message to the modules main address:
+
+ {
+ "action": "destroy",
+ "sessionId": <sessionId>
+ }
+
+Where `sessionId` is the id of the session, which should be destroyed.
+
+An example would be:
+
+ {
+ "action": "destroy",
+ "sessionId": "94b1a3fe-16df-4ab2-ac10-aae67ad2c46d"
+ }
+
+This would delete all information about session `94b1a3fe-16df-4ab2-ac10-aae67ad2c46d` from the shared data and send all the previously stored information to the `cleaner` address. If you set up `prefix` in the config to `session.`, a message in this format will be sent to that address:
+
+ {
+ "status": "SESSION_KILL"
+ }
+
+If an administrator kills the session of a client, the client can be notified via a registered handler on that address.
+
+As soon as the session is destroyed, the server will reply with
+
+ {
+ "status": "ok",
+ "sessionDestroyed": true
+ }
+
+It will always reply with this message, to inform you that the work was done and the session is gone. It will do so even if the `sessionId` didn't exist before. If you did not specify a `sessionId` at all, it will reply with error `SESSIONID_MISSING`.
+
+### clear
+
+This command destroys all sessions immediately. Every session gets sent to the `cleaner` address and an error `SESSION_KILL` is sent to `<prefix><sessionId>`.
+
+You should be very careful not to let everyone use this command:
+
+ {
+ "action": "clear"
+ }
+
+It works analog to the `destroy` action. As soon as the work is done, the server will reply with:
+
+ {
+ "status": "ok",
+ "cleared": true
+ }
+
+### heartbeat
+
+Sends a heartbeat to the server, resetting the timeout of the session. If you don't want to loose your session information but don't use `get` or `set` commands often enough, you can send this command to prevent the automatic deletion of the session.
+
+ {
+ "action": "heartbeat",
+ "sessionId": <sessionId>
+ }
+
+You have to provide a valid `sessionId`, otherwise the heartbeat will reply with error `SESSIONID_MISSING`. If the heartbeat could be delivered, it will reply with a message including the configurated timeout like this:
+
+ {
+ "status": "ok",
+ "timeout": 900000
+ }
+
+### get
+
+Gets some data from the session storage. You can get multiple fields with one command.
+
+ {
+ "action": "get",
+ "sessionId": <sessionId>,
+ "fields": [<field1>, <field2>, <field3>, ...]
+ }
+
+* `sessionId` is required and results in a `SESSIONID_MISSING` error, if not set. If the session is set but could not be found, a `SESSION_GONE` error is raised (i.e. sent to the session handler directly).
+* `fields` is required, too, and replies with a `FIELDS_MISSING` error, when omitted. If one of the fields cannot be found, the result of that field will be null.
+
+Here is a small example:
+
+ {
+ "action": "get",
+ "sessionId": "94b1a3fe-16df-4ab2-ac10-aae67ad2c46d",
+ "fields": ["nickname", "browser"]
+ }
+
+Would result in (if you did the `put` example before ;)):
+
+ {
+ "status": "ok",
+ "data": {
+ "nickname": "TheAwesomeGorilla",
+ "browser": "Mozilla Firefox 19"
+ }
+ }
+
+### put
+
+Stores data in the session. You provide a JsonObject and it gets stored in the session.
+
+ {
+ "action": "put",
+ "sessionId": <sessionId>,
+ "data": <JsonObject>
+ }
+
+As soon as the session manager saved the data in the session, it will reply with `"sessionSaved": true`. There can be three kinds of errors:
+* `sessionId` was omitted: The session manager replies with error `SESSIONID_MISSING`.
+* `data` was not provided: The session manager replies with error `DATA_MISSING`.
+* `data` is not a JsonObject: The session manager replies with error `WRONG_DATA_TYPE`.
+
+If you send a key in `data` which already existed in the session storage, it will be overwritten by the value provided in the `data` object.
+
+Here is a small example:
+
+ {
+ "action": "put",
+ "sessionId": "94b1a3fe-16df-4ab2-ac10-aae67ad2c46d",
+ "data": {
+ "nickname": "TheAwesomeGorilla",
+ "browser": "Mozilla Firefox 19"
+ }
+ }
+
+Would result in:
+
+ {
+ "status": "ok",
+ "sessionSaved": true
+ }
+
+### status (access statistics or check session matches)
+
+The session manager can also provide you some statistics about itself. You can access these tools by sending `status` as action and provide a `report` field.
+
+If you want to get a report, which doesn't exist the session manager will reply with a `UNKNOWN_REPORT_REQUEST` error.
+
+#### connections
+
+This report shows how many sessions are stored in the session storage right now.
+
+ {
+ "action": "status",
+ "report": "connections"
+ }
+
+It will result in a message like this:
+
+ {
+ "status": "ok",
+ "openSessions": 16
+ }
+
+
+
+#### matches
+
+This report shows the session ids, which match the specified information. This can be used in a chat-application to find out whether a specific nickname is already in use for example. This template will make use of the feature:
+
+ {
+ "action": "status",
+ "report": "matches",
+ "data": <JsonObject>
+ }
+
+The `match` object behaves like the matcher in the event bus bridge. You set a subset of an object and if it matches with one of the stored sessions, the matching stored sessions will be replied by the session manager.
+
+Here is an example to look for sessions which have stored the fields `race` with value `human` and `power` set to 5:
+
+ {
+ "action": "status",
+ "report": "matches",
+ "data": {
+ "race": "human",
+ "power": 5
+ }
+ }
+
+This would assemble a list of session ids and reply them back to the caller in this manner:
+
+ {
+ "status": "ok",
+ "matches": true,
+ "sessions": ["", ""]
+ }
+
+If there were no matches, the `sessions` list is empty and `matches` is false.
View
BIN  mods/com.campudus.session-manager-v1.2.1/mod.zip
Binary file not shown
View
159 mods/com.jetdrone.mod-redis-io-v1.0/README.md
@@ -0,0 +1,159 @@
+Redis busmod for Vert.x
+=============================
+
+This module allows data to be saved, retrieved, searched for, and deleted in a Redis. Redis is an open source, BSD
+licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings,
+hashes, lists, sets and sorted sets. To use this module you must have a Redis server instance running on your network.
+
+[![Build Status](https://travis-ci.org/pmlopes/mod-redis-io.png?branch=master)](https://travis-ci.org/pmlopes/mod-redis-io)
+
+## Dependencies
+
+This module requires a Redis server to be available on the network.
+
+## Name
+
+The module name is `com.jetdrone.mod-redis-io`.
+
+## Configuration
+
+The module takes the following configuration:
+
+ {
+ "address": <address>,
+ "host": <host>,
+ "port": <port>,
+ "encoding": <charset>,
+ "binary": <boolean>
+ }
+
+For example:
+
+ {
+ "address": "test.my_redis",
+ "host": "localhost",
+ "port": 6379
+ }
+
+Let's take a look at each field in turn:
+
+* `address` The main address for the module. Every module has a main address. Defaults to `vertx.mod-redis-io`.
+* `host` Host name or ip address of the Redis instance. Defaults to `localhost`.
+* `port` Port at which the Redis instance is listening. Defaults to `6379`.
+* `encoding` The character encoding for string conversions (e.g.: `UTF-8`, `ISO-8859-1`, `US-ASCII`). Defaults to the platform default.
+* `binary` To be implemented. In this case messages are expected to be in binary format.
+
+## Usage
+
+Simple example:
+
+```groovy
+ def eb = vertx.eventBus()
+ def config = new JsonObject()
+
+ config.putString("address", address)
+ config.putString("host", "localhost")
+ config.putNumber("port", 6379)
+
+ container.deployModule("com.jetdrone.mod-redis-io", config, 1)
+
+ eb.send(address, [command: 'get', key: 'mykey']) { reply ->
+ if (reply.body.status.equals('ok') {
+ // do something with reply.body.value
+ } else {
+ println('Error #{reply.body.message}')
+ }
+ }
+```
+
+Simple example with pub/sub mode:
+
+```groovy
+ def eb = vertx.eventBus()
+ def pubConfig = new JsonObject()
+ pubConfig.putString("address", 'redis.pub')
+ def subConfig = new JsonObject()
+ subConfig.putString("address", 'redis.sub')
+
+ container.deployModule("com.jetdrone.mod-redis-io", pubConfig, 1)
+ container.deployModule("com.jetdrone.mod-redis-io", subConfig, 1)
+
+ // register a handler for the incoming message the naming the Redis module will use is base address + '.' + redis channel
+ eb.registerHandler("redis.sub.ch1", new Handler<Message<JsonObject>>() {
+ @Override
+ void handle(Message<JsonObject> received) {
+ // do whatever you need to do with your message
+ def value = received.body.getField('value')
+ // the value is a JSON doc with the following properties
+ // channel - The channel to which this message was sent
+ // pattern - Pattern is present if you use psubscribe command and is the pattern that matched this message channel
+ // message - The message payload
+ }
+ });
+
+ // on sub address subscribe to channel ch1
+ eb.send('redis.sub', [command: 'subscribe', channel: 'ch1']) { subscribe ->
+ }
+
+ // on pub address publish a message
+ eb.send('redis.pub', [command: 'publish', channel: 'ch1', message: 'Hello World!']) { publish ->
+ }
+```
+
+
+### Sending Commands
+
+Each Redis command is exposed as a json document on the `EventBus`. All commands take a field `command` and an arbitrary
+amount of extra fields as described on the main redis documentation site.
+
+An example would be:
+
+ {
+ command: "get",
+ key: "mykey"
+ }
+
+When the command completes successfuly the response would be:
+
+ {
+ status: "ok",
+ "value": "the value stored on redis"
+ }
+
+If an error occurs a reply is returned:
+
+ {
+ "status": "error",
+ "message": <message>
+ }
+
+Where `message` is an error message.
+
+For a list of Redis commands, see [Redis Command Reference](http://redis.io/commands)
+
+At the moment, commands can be specified only in lowercase. Minimal parsing is done on the replies.
+Commands that return a single line reply return `java.lang.String`, integer replies return `java.lang.Number`,
+"bulk" replies return an array of `java.lang.String` using the specified encoding, and "multi bulk" replies return a
+array of `java.lang.String` again using the specified encoding. `hgetall` is returns a `JsonObject`.
+
+## Friendlier hash commands
+
+Most Redis commands take a single String or an Array of Strings as arguments, and replies are sent back as a single
+String or an Array of Strings. When dealing with hash values, there are a couple of useful exceptions to this.
+
+### command hgetall
+
+The reply from an `hgetall` command will be converted into a JSON Object. That way you can interact with the responses
+using JSON syntax which is handy for the EventBus communication.
+
+### command hmset
+
+Multiple values in a hash can be set by supplying an object.Note however that key and value will be coerced to strings.
+NOTE: Not implemented yet!!!
+
+## Pub/Sub
+
+As demonstrated with the source code example above, the module can work in pub/sub mode too. The basic idea behind it is
+that you need to register a new handler for the address: `mod-redis-io-address.your_real_redis_address` At this moment
+all commands to `subscribe`, `psubscribe`, `unsubscribe` and `pusubscribe` will send the received messages to the right
+address.
View
BIN  mods/com.jetdrone.mod-redis-io-v1.0/mod.zip
Binary file not shown
View
6 mods/li.chee.rest-storage-v0.1/README.md
@@ -0,0 +1,6 @@
+# Persistence for REST resources in the filesystem or a redis database
+
+See the [project repository](https://github.com/lbovet/vertx-rest-storage) for more information
+
+This is v0.1, which is built with vert.x `v1.3.1.final`, you will need a version of "de.marx-labs.redis-client" compatible with vert.x 1.3. There is one here: https://github.com/lbovet/vert.x-busmod-redis
+
View
BIN  mods/li.chee.rest-storage-v0.1/mod.zip
Binary file not shown
View
4 mods/org.scala-lang.scala-library-v2.10.0/README.md
@@ -0,0 +1,4 @@
+vertx-scala-mod
+===============
+
+Provides the scala library version 2.10.0 for other vertx modules.
View
BIN  mods/org.scala-lang.scala-library-v2.10.0/mod.zip
Binary file not shown
Please sign in to comment.
Something went wrong with that request. Please try again.