jooby
getting started
public class MyApp extends Jooby {
{
use(new Jackson()); // 1. JSON serializer.
// 2. Define a route
get("/", req
-> {
Map
model = ...;
return model;
}
}
public static void main(String[] args) {
run(MyApp::new, args); // 3. Done!
}
}
application.conf
Jooby delegate configuration management to TypeSafe Config.
By default Jooby looks for an application.conf
. If
you want to specify a different file or location, you can do it with
#conf(String).
TypeSafe Config uses a hierarchical model to
define and override properties.
A
Jooby.Module might provides his own set of properties through the
Jooby.Module#config() method. By default, this method returns an empty config object.
For example:
use(new M1());
use(new M2());
use(new M3());
Previous example had the following order (first-listed are higher priority):
- arguments properties
- System properties
- application.conf
- M3 properties
- M2 properties
- M1 properties
Command line argmuents or system properties takes precedence over any application specific
property.
env
Jooby defines one mode or environment: dev. In Jooby, dev
is special and some modules could apply special settings while running in dev.
Any other env is usually considered a prod
like env. But that depends on module
implementor.
An environment
can be defined in your .conf
file using the
application.env
property. If missing, Jooby set the env
for you to
dev.
There is more at
Env please read the
Env javadoc.
modules: the jump to full-stack framework
Jooby.Module are quite similar to a Guice modules except that the configure
callback has been complementing with
Env and
Config.
public class MyModule implements Jooby.Module {
public void configure(Env env, Config config, Binder binder) {
}
}
From the configure callback you can bind your services as you usually do in a Guice app.
There is more at
Jooby.Module so please read the
Jooby.Module javadoc.
path patterns
Jooby supports Ant-style path patterns:
Some examples:
-
com/t?st.html - matches
com/test.html but also
com/tast.html or
com/txst.html
-
com/*.html - matches all
.html files in the
com directory
com/
**/test.html
- matches all
test.html files underneath the
com path
-
**/
* - matches any path at any level.
-
* - matches any path at any level, shorthand for
**/
*.
variables
Jooby supports path parameters too:
Some examples:
/user/{id}
- /user/* and give you access to the id
var.
/user/:id
- /user/* and give you access to the id
var.
/user/{id:\\d+}
- /user/[digits] and give you access to the numeric
id
var.
routes
Routes perform actions in response to a server HTTP request.
Routes are executed in the order they are defined, for example:
get("/", (req, rsp)
-> {
log.info("first"); // start here and go to second
});
get("/", (req, rsp)
-> {
log.info("second"); // execute after first and go to final
});
get("/", (req, rsp)
-> {
rsp.send("final"); // done!
});
Previous example can be rewritten using
Route.Filter:
get("/", (req, rsp, chain)
-> {
log.info("first"); // start here and go to second
chain.next(req, rsp);
});
get("/", (req, rsp, chain)
-> {
log.info("second"); // execute after first and go to final
chain.next(req, rsp);
});
get("/", (req, rsp)
-> {
rsp.send("final"); // done!
});
Due to the use of lambdas a route is a singleton and you should NOT use global variables. For
example this is a bad practice:
List
names = new ArrayList
< >(); // names produces side effects
get("/", (req, rsp)
-> {
names.add(req.param("name").value();
// response will be different between calls.
rsp.send(names);
});
mvc routes
A Mvc route use annotations to define routes:
use(MyRoute.class);
...
// MyRoute.java
@Path("/")
public class MyRoute {
@GET
public String hello() {
return "Hello Jooby";
}
}
Programming model is quite similar to JAX-RS/Jersey with some minor differences and/or
simplifications.
To learn more about Mvc Routes, please check
org.jooby.mvc.Path,
org.jooby.mvc.Produces
org.jooby.mvc.Consumes javadoc.
static files
Static files, like: *.js, *.css, ..., etc... can be served with:
assets("assets/**");
Classpath resources under the /assets
folder will be accessible from client/browser.
lifecyle
We do provide
#onStart(Throwing.Consumer) and
#onStop(Throwing.Consumer) callbacks.
These callbacks are executed are application startup or shutdown time:
onStart(() -> );
onStop(() ->
log.info("Bye!");
});
}
}
From life cycle callbacks you can access to application services:
onStart(registry -> );
}
}