Yaws is ideal for embedding within another larger erlang application. Many typical erlang applications are control applications in need of a webgui specific to the actual application.
In order to run Yaws inside another application, we need to perform the following steps.
Either integrate Yaws into the build system of the larger
application, or specifically provide the ebin path to Yaws
for the larger application.
Provide the application environment {embedded,
true} to Yaws.
Since the containing application typically has its configuration data
fed from internal databases or other sources, it's usually not feasible
to let Yaws read its configuration data from
/etc/yaws/yaws.conf when it's running in embedded mode.
To solve this, when Yaws is started in embedded mode, it doesn't read
its configuration from /etc/yaws/yaws.conf, but rather it
expects the larger application to feed its configuration through the
function call yaws_api:setconf(GC, Groups). The two
arguments to this function are:
GC, which is a #gconf{} record
Groups, which is a list of lists of #sconf
records
The details of these records are unimportant, and we'll talk more
about the yaws_api:setconf function later. First, let's
discuss two ways applications can start Yaws in embedded mode.
When not embedded, Yaws starts and runs as a regular application, but typically an application embedding Yaws wants to control it under its own supervisor(s). This means that an embedding application requires access to the Yaws supervisor child specifications. The exact list of Yaws child specifications depends on how the application intends to configure Yaws.
The yaws_api:embedded_start_conf/1,2,3,4 functions return
the information an application needs to configure Yaws and start it under
application supervisors. There are four variants of this function:
yaws_api:embedded_start_conf/1 takes a single
argument, which is the document root path for the web server. This
variant uses default values for the #gconf{} and
#sconf{} records.
yaws_api:embedded_start_conf/2 takes a document
root, same as the first variant above, and also a server configuration
list. Such a list is either a list of properties for a single web
server, or a list of property lists for multiple servers. We'll explain
more about server configuration lists later, but for now note that
they're used to create suitable #sconf{} record
values. This variant uses a default value of the #gconf{}
record.
yaws_api:embedded_start_conf/3 takes a document
root and a server configuration list, same as the second variant above,
and also a global configuration list. Such a list is a property list
that provides global configuration settings for the embedded Yaws
instance, and is used to create a suitable #gconf{} record
value. We'll explain more about global configuration lists
later.
yaws_api:embedded_start_conf/4, the final variant,
takes the same 3 arguments as the previous variant and also takes a
string to identify the embedded Yaws instance.
The values returned from these functions are described later.
A global configuration list is a property list that provides global
configuration settings for an embedded Yaws instance. Each property is a
tuple consisting of property name and value. Allowed property names are
those of the field names of the #gconf{} record type; see
yaws.hrl for more details. An example global configuration
list is shown below:
[{logdir, "/var/log/my_server"},
{ebin_dir, ["/example1/ebin", "/example2/ebin"]},
{id, "my_server"}].
A server configuration list is a property list that provides
configuration settings for a given web server instance. Because Yaws
supports multiple servers simultaneously listening for requests, it's
possible to supply a list of server configuration lists so that multiple
servers can be configured in a single yaws_api:setconf
function call. Each element in a server configuration list is a tuple
consisting of property name and value. Allowed property names are those
of the field names of the #sconf{} record type; see
yaws.hrl for more details. An example server configuration
list is shown below:
[{docroot, "/var/yaws/www"},
{port, 8080},
{listen, {127,0,0,1}},
{appmods, [{"/", my_appmod}]}].
You can often determine the correct embedded server configuration by
first creating a yaws.conf file specifying the desired
configuration, running a stand-alone Yaws using it, and then dumping the
server's configuration by executing the command yaws
--running-config. Still, some elements of the embedded server
configuration list are non-obvious. For example, to enable basic auth,
you need to specify an auth proplist for each target
directory. For example, to enable basic auth on "/":
Docroot = "/var/yaws/www",
Realm = "testrealm",
SConfList = [{docroot, Docroot},
{port, 8080},
{listen, {0,0,0,0}},
{auth, [{docroot, Docroot},
{dir, "/"},
{realm, Realm},
{type, "Basic"},
{headers, ["WWW-Authenticate: Basic realm=\"", Realm,
["\"\r\n"]]},
{users, [{"foo","bar"}]}]}],
If you want to enable auth on multiple directories, specify a
{auth, AuthProplist} element for each one.
Other elements, such as dir_listings,
access_log, and deflate, are also non-obvious
for embedded configuration because they're specified as part of the
#sconf.flags element. You can find the server configuration
flags, along with preprocessor macros for setting them on an
#sconf{} record, in the yaws.hrl include
file.
The yaws_api:embedded_start_conf/1,2,3,4 functions return
{ok, SCList, GC, ChildSpecs}. The latter three elements of
this tuple are described below.
SCList is a list of #sconf{} records
created using the values from the passed-in server configuration
lists
GC is a #gconf{} record created using
the values from the passed-in global configuration list
ChildSpecs is a list of supervisor child
specifications for the components of Yaws the application wants to
start
Below is an example of using the
yaws_api:embedded_start_conf/1,2,3,4 functions. It follows
the steps of obtaining the embedded configuration and child
specifications, starting the Yaws children under its own supervisor, and
then setting the Yaws configuration.
Id = "my_server",
GconfList = [{logdir, "/var/log/my_server"},
{ebin_dir, ["/example1/ebin", "/example2/ebin"]},
{id, Id}],
Docroot = "/var/yaws/www",
SconfList = [{docroot, Docroot},
{port, 8080},
{listen, {127,0,0,1}},
{appmods, [{"/", my_appmod}]}],
{ok, SCList, GC, ChildSpecs} =
yaws_api:embedded_start_conf(Docroot, SconfList, GconfList, Id),
%% assume our supervisor is registered as my_sup
[supervisor:start_child(my_sup, Ch) || Ch <- ChildSpecs],
%% now configure Yaws
yaws_api:setconf(GC, SCList),
The four functions yaws:start_embedded/1,2,3,4 start Yaws
in embedded mode using application:start. This approach
differs from the one above in that the embedding application need not
start any Yaws components under its own supervisors, nor does it need to
explicitly call yaws:setconf to set the Yaws
configuration. This approach is slightly simpler but also gives the
embedding application less control over Yaws.
The arguments for these four functions are identical to those for the
yaws_api:embedded_start_conf/1,2,3,4 functions described
earlier.
See the example below:
%%
%% Check with inet:i(). that you are listening to port 8000!
%%
1> yaws:start_embedded("/home/tobbe/docroot").
%%
%% Alternative ways
%%
1> yaws:start_embedded("/home/tobbe/docroot",
[{servername, "sej"}, {listen, {0,0,0,0}}]).
1> yaws:start_embedded("/home/tobbe/docroot",
[{servername, "sej"}, {auth_log, false},
{listen, {0,0,0,0}}],
[{copy_errlog, false}]).
If you need more control on how to setup Yaws in embedded mode, use
the yaws_api:embedded_start_conf functions instead.
We provide a minimal example that embeds Yaws in a small Erlang function.
The ybed module is very small and is named ybed.erl. It has an
accompanying simple supervisor named ybed_sup.erl.
If you compile both modules, you can run them as shown below:
1> {ok, Sup} = ybed_sup:start_link().
{ok,<0.40.0>}
2>
=INFO REPORT==== 12-Apr-2010::02:42:09 ===
Yaws: Listening to 0.0.0.0:8888 for <1> virtual servers:
- http://foobar:8888 under /tmp
2>
The actual web server runs inside the larger application. The
configuration of the web server was programmatically fed into Yaws from the
surrounding application, in this case, the ybed.erl module. Note also
how the Yaws children are started under the same ybed_sup.erl
supervisor as the code in the ybed module itself. The
ybed serves only to start the Yaws children that need to
be run under its supervisor, after which it exits normally. For this reason,
its child specification uses the temporary restart strategy,
since it need run only once in the lifetime of its supervisor.
The #sconf{} record, which is constructed by the program
that starts and configures Yaws, contains a field,
SC#sconf.opaque.
This field is passed into the #arg{} record, so that any
application specific configuration data which is needed by the
.yaws pages that make up the web GUI application, is easily
available there.
In essence, if we construct the #sconf as
SC#sconf{opaque = {mystruct, foobar},
.....
A .yaws web page can then do:
out(Arg) -> MyStruct = Arg#arg.opaque .....
thus passing data from the surrounding applications configuration
routines down to each .yaws web page.
Another important fact to consider when choosing whether to run your
Yaws application as an embedded yaws app or not is that all the Yaws
control functions are disabled when we use Yaws as an embedded web server,
including capabilities such as yaws --ls and yaws
--stop. Embedding thusassumes that you already have support for this
type of functionality in your application.
Finally, an interesting appmod definition that may apply to many
embedded yaws installations is the / appmod with a set of
exclude dirs. Here is an example server configuration list:
[...
{appmods, [{"/", myapp, [["js"], ["top", "static"], ["icons"]]}]},
...].
or in #sconf{} record terms:
SC#sconf{.....
appmods = {"/", myapp, [["js"], ["top", "static"], ["icons"]]},
....
