From: Claes W. <kl...@gm...> - 2005-02-18 20:37:40
|
New release 1.53 (and also never announced 1.52) Go get relnotes at http://yaws.hyber.org Cheers /klacke |
From: Mikael K. <mik...@cr...> - 2005-02-19 10:26:50
|
The new feature that makes it possible to do config changes without stopping a running system (that was introduced in version 1.51), is it for embedded Yaws, or can it be done for a standalone server as well? Regards Mikael Fri 18 Feb 2005 21:37 Claes Wikstrom wrote: > New release 1.53 (and also never announced 1.52) > > Go get relnotes at http://yaws.hyber.org > > Cheers > > /klacke |
From: Claes W. <kl...@gm...> - 2005-02-19 15:32:07
|
On Sat, 19 Feb 2005 11:31:39 +0100, Mikael Karlsson <mik...@cr...> wrote: > The new feature that makes it possible to do config changes > without stopping a running system (that was introduced in > version 1.51), is it for embedded Yaws, or can it be done > for a standalone server as well? Both /klacke |
From: Mikael K. <mik...@cr...> - 2005-02-27 17:03:20
|
Sat 19 Feb 2005 16:32, Claes Wikstrom: > <mik...@cr...> wrote: > > The new feature that makes it possible to do config changes > > without stopping a running system (that was introduced in > > version 1.51), is it for embedded Yaws, or can it be done > > for a standalone server as well? > > Both > > /klacke Great! Thanks. /Mikael Has anybody looked at the possibility to add new apps to a running server in a structured "java servlet" fashion. What I had in mind is something like: Application handler Background Erlang/OTP has quite an extensive support for deployment of Erlang distributions and release upgrades. New OTP based frameworks like Yaws and J-EAI could benefit from some extra ways to handle deployment of web applications. It would be good if developers could make independent OTP/Yaws (J-EAI?) web applications that could be deployed independently on the same Yaws/J-EAI webserver. Much like java servlets are deployed on servlet containers or ASP .NET applications can be deployed. This problem has to some extent been addressed for inets in the OTP webtool application. Proposal Either Yaws itself is extended to include such a support or another framework like J-EAI runs Yaws in embedded mode and takes care of deployment/undeployment of new applications. Maybe there are other solutions? What it could look like: A developer makes an application like any OTP app, but has also a fixed directory structure with a yaws dir under the /priv dir for {.yaws,.html} files and configuration info (yaws.xml) in the /priv dir: myapp/ ebin/ src/ priv/ yaws.xml - configuration yaws/ - .html and .yaws files The yaws.xml configuration file would contain information to be set using yaws setconf/2 function (appmods, opaque, realm etc.), and also search path for the files in the yaws directory. The application could be added to the first virtual server (default) or to a named/indexed server. Server path for the .html/.yaws files would be (default): http://www.defaultserver.domain/myapp and appmods paths would be appended: http://www.defaultserver.domain/myapp/appmodpath1 The directory myapp/ebin would be added to the Erlang search path, and the files in the myapp/yaws directory would be recursively copied to the docroot/myapp directory unless anything else was given in yaws.xml configuration file. Maybe symbolic links could be used instead of copying, but I am not sure what the security issues may be considering relative document paths. Mnesia could be used for storing the new configurations. A registry would be very handy indeed. :-) Support for undeployment (removal) of the application is needed as well as ordinary OTP application start/stop. All applications are stored under one main directory configured for the framework application: jeaiapps/ myapp/ my2ndapp/ uzwapp/ In this way can the application handler scan all directories for configuration files at startup. If this is made with J-EAI the concept could probably be generalized to be used for other appapps and not only yaws: myapp/ ebin/ src/ priv/ yaws.xml yaws/ jabber.xml jabber/ appapp2.xml appapp2/ jeai.xml and so Forth. Outstanding questions Scalability and distributed deployment. If one need to run the Yaws/J-EAI framework distributed over several nodes the deployment of new apps would need to rely on the OTP release handler (I guess). The problem as far as I understand it is that you can only upgrade an existing application and not add new (or remove old) applications with the release handler. Also copying the priv/yaws files could be a problem since some nodes may run on the same machines and other on different machines. References 1. ASP .NET Web - http://www.asp.net/ 2. J2EE Tutorial - http://java.sun.com/j2ee/1.4/docs/tutorial/doc - Chapter 3: Getting started with web applications 3. webtool - http://www.erlang.se/doc/doc-5.4/lib/webtool-0.8.2/doc/html/webtool_chapter.html |
From: Claes W. <kl...@gm...> - 2005-03-14 20:07:11
|
On Sun, 27 Feb 2005 18:08:42 +0100, Mikael Karlsson <mik...@cr...> wrote: > Has anybody looked at the possibility to add new apps to a running server > in a structured "java servlet" fashion. > What I had in mind is something like: > > Application handler ...... I think this is indeed possible to implement. _But_ I think it should be implemented outside yaws, using embedded mode and work as a package that is using yaws. Use it's own set of config files etc. It may very well (highly likely) that yaws needs to be hacked in order to implement it well, but so be it. So, if you want to build this, please go ahead, I'll support you all I can.... wholeheartedly. /klacke |
From: Mikael K. <mik...@cr...> - 2005-03-14 21:55:52
|
m=E5ndag 14 mars 2005 21:02 skrev Claes Wikstrom: > On Sun, 27 Feb 2005 18:08:42 +0100, Mikael Karlsson > > <mik...@cr...> wrote: > > Has anybody looked at the possibility to add new apps to a running serv= er > > in a structured "java servlet" fashion. > > What I had in mind is something like: > > > > Application handler ...... > > I think this is indeed possible to implement. _But_ I think it should be > implemented outside yaws, using embedded mode and work as > a package that is using yaws. Use it's own set of config files etc. > > It may very well (highly likely) that yaws needs to be hacked in order > to implement it well, but so be it. > > So, if you want to build this, please go ahead, I'll support you all > I can.... wholeheartedly. Great! A meta-application so to speak. Thanks. Mikael |