You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Norbert Pabiś <No...@e-point.pl> on 2001/04/23 13:34:17 UTC
[PROPOSAL] application management
Hi.
My name is Norbert Pabiś and I work with Rafał Krzewski in e-point, a
company from Poland.
Below I write our proposal of how could sub-application management look
in Turbine.
A proposal for sub-application management on Turbine framework.
Now is very hard in Turbine to manage single application. Application
files are splitted to many directories (models, modules, ...).
There is a need of a simple deployment method.
Below I describe a prosposal for this. It consists of special directory
structure (it also deals with localized templates and strings)
and a deployment tool that knows how to install, uninstall and upgrade
an application.
-------------------------------------------------------
WAR - webapplication archive
/index.html
/templates/X/en_EN/strings.properties (localization strings)
/screens
/layouts
/navigations
/pl_PL/strings.properties (localization strings)
/screens
/layouts
/navigations
/.../strings.properties (localization strings)
/screens
/layouts
/navigations
/code/X/lib
/classes
/script/screen
/action
/...
/WEB_INF/web.xml
/lib
/classes
/conf/X/config.xml
/...
/res/X/images
/... (any user dir e.g. for js, css, swf files)
-------------------------------------------------------
TAR - turbine application archive
/images
/... (any user dir e.g. for js, css, swf files)
/templates/en_EN/strings.properties (localization strings)
/screens
/layouts
/navigations
/pl_PL/strings.properties (localization strings)
/screens
/layouts
/navigations
/.../strings.properties (localization strings)
/screens
/layouts
/navigations
/code/lib
/classes
/script/screen
/action
/...
/conf/config.xml
/...
Description:
/index.html - probably redirect to servlet
.../X/... - a name of exemplatory application.
/templates - directiories for templates, each application has its own
subdirectory with subdirectories for localized templates
and strong.properties with strings to be used in applications
/code - directory for application binary files: classes, used libs (jars)
/code/script - directory for script code files (e.g. for Python)
/WEB-INF - classes, libs and configuration for turbine
/WEB-INF/conf - configuration for applications
/res - directory for application's static data (image, css, js files)
Now we need a deployment tool that will enable to install, uninstall and
upgrade (update) application. There is a question if should this deploy
tool be written in Perl, pure Java or any other language.
IMHO the best idea is to create a Java interface with methods:
install, uninstall, upgrade, configure. Then you can write any tool
implementing this interface. If you wish you can even call Perl
script from Java.
"Configure" would be a method that allows an application to do its
own specific tasks other than splitting archive eg. running SQL script
and create tables in database. It would be hard for a deploy tool
to install application in database, that is why it is better to delegate
this task to an application.
The interface could be:
interface DeployTool {
void install(String name) {
}
void uninstall(String name) {
}
void configure(String name) {
}
}
If "name" is the same install would first uninstall the application
to avoid merging problems.
In this case we don't even need special "update" method.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] application management
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/23/01 4:34 AM, "Norbert Pabis´" <No...@e-point.pl> wrote:
> TAR - turbine application archive
I haven't read through it all yet, but do NOT use TAR as the acronym. This
will cause mass confusion for people for obvious reasons. Please think of
something better. :-)
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] application management
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Ilkka Priha" <ip...@surfeu.fi> writes:
> Have you considered a structure where subapp specific files would be kept
> under the same directory:
We face similar issues in Tigris. We've found that sub-applications
must either have namespace protection when installed into the "site"
location (which is what we currently do), or must live apart.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re[2]: [PROPOSAL] application management
Posted by Norbert Pabiś <No...@e-point.pl>.
On Mon, 23 Apr 2001 21:27:18 +0200
Rafal Krzewski <Ra...@e-point.pl> wrote:
> Another issue is preventing the browsers from downloading the templates.
> You would
> have to add magic phrases to web.xml file. No way to do that at
> application's runtime-
> this would effectively make hot-plugging of apps impossible.
Yes, that is a very important issue. Browsers must not access any configuration
file, code, source...or even templates. It just should be able to access
only user static files. When we split sub-application in many
directories we can configure Apache or other www server easily to
protect sub-app special files.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] application management
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Ilkka Priha wrote:
>
> Have you considered a structure where subapp specific files would be kept
> under the same directory:
<snip>
>
> It might be easier to maintain a large set of subapps, avoid naming
> conflicts and perform subapp specific operations if all files were under one
> subapp root. On the other hand, the template search path will be more
> complicated.
Yes, template lookap would get more complicated. Allowing multiple
factors
in selecting the template lookup will make the system more complicated
and slower.
Right now we have people that would like to keep different templates for
1) sub-application
2) locale
3) media type (HTML/WML)
4) template type (JSP/Velocity etc.)
sorting this all won't be easy...
Another issue is preventing the browsers from downloading the templates.
You would
have to add magic phrases to web.xml file. No way to do that at
application's runtime-
this would effectively make hot-plugging of apps impossible.
>
> Can the deployment tool be implemented as a service?
*If* we want hot plugging of sub applications it should be implemented
as a
service. Our opinion is that instaling/uninstaling the applications is
such
a disruptive operation that it justifies taking the system down. This
removes
a lot of complication from the proces (at least that's the feeling I
have
right now...).
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PROPOSAL] application management
Posted by Jason van Zyl <jv...@apache.org>.
Ilkka Priha wrote:
> Have you considered a structure where subapp specific files would be kept
> under the same directory:
I think that is a definite must, an entity to itself. I think mixing up
elements
of applications is a really bad idea. At least be self contained in its own
directory structure or better yet completely run from a JAR that doesn't
need to be unpacked at all.
>
>
> /app/X/templates/en_EN/strings-properties
> /screens
> /layouts
> /navigations
> /pl_PL/strings-properties
> /screens
> /layouts
> /navigations
>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [PROPOSAL] application management
Posted by Ilkka Priha <ip...@surfeu.fi>.
Have you considered a structure where subapp specific files would be kept
under the same directory:
/app/X/templates/en_EN/strings-properties
/screens
/layouts
/navigations
/pl_PL/strings-properties
/screens
/layouts
/navigations
/...
/res/images
/...
/classes
/lib
/etc/conf
/script
/...
/Y/templates/...
It might be easier to maintain a large set of subapps, avoid naming
conflicts and perform subapp specific operations if all files were under one
subapp root. On the other hand, the template search path will be more
complicated.
Can the deployment tool be implemented as a service?
-- Ilkka
> -----Original Message-----
> From: Norbert Pabiś [mailto:Norbert.Pabis@e-point.pl]
> Sent: Monday, April 23, 2001 14:34
> To: turbine-dev
> Subject: [PROPOSAL] application management
>
>
> Hi.
>
> My name is Norbert Pabiś and I work with Rafał Krzewski in e-point, a
> company from Poland.
>
> Below I write our proposal of how could sub-application management look
> in Turbine.
>
> A proposal for sub-application management on Turbine framework.
>
> Now is very hard in Turbine to manage single application. Application
> files are splitted to many directories (models, modules, ...).
> There is a need of a simple deployment method.
> Below I describe a prosposal for this. It consists of special directory
> structure (it also deals with localized templates and strings)
> and a deployment tool that knows how to install, uninstall and upgrade
> an application.
>
> -------------------------------------------------------
> WAR - webapplication archive
> /index.html
> /templates/X/en_EN/strings.properties (localization strings)
> /screens
> /layouts
> /navigations
> /pl_PL/strings.properties (localization strings)
> /screens
> /layouts
> /navigations
> /.../strings.properties (localization strings)
> /screens
> /layouts
> /navigations
> /code/X/lib
> /classes
> /script/screen
> /action
> /...
> /WEB_INF/web.xml
> /lib
> /classes
> /conf/X/config.xml
> /...
> /res/X/images
> /... (any user dir e.g. for js, css, swf files)
>
> -------------------------------------------------------
> TAR - turbine application archive
> /images
> /... (any user dir e.g. for js, css, swf files)
> /templates/en_EN/strings.properties (localization strings)
> /screens
> /layouts
> /navigations
> /pl_PL/strings.properties (localization strings)
> /screens
> /layouts
> /navigations
> /.../strings.properties (localization strings)
> /screens
> /layouts
> /navigations
> /code/lib
> /classes
> /script/screen
> /action
> /...
> /conf/config.xml
> /...
>
> Description:
> /index.html - probably redirect to servlet
>
> .../X/... - a name of exemplatory application.
>
> /templates - directiories for templates, each application has its own
> subdirectory with subdirectories for localized templates
> and strong.properties with strings to be used in applications
>
> /code - directory for application binary files: classes, used libs (jars)
>
> /code/script - directory for script code files (e.g. for Python)
>
> /WEB-INF - classes, libs and configuration for turbine
>
> /WEB-INF/conf - configuration for applications
>
> /res - directory for application's static data (image, css, js files)
>
> Now we need a deployment tool that will enable to install, uninstall and
> upgrade (update) application. There is a question if should this deploy
> tool be written in Perl, pure Java or any other language.
> IMHO the best idea is to create a Java interface with methods:
> install, uninstall, upgrade, configure. Then you can write any tool
> implementing this interface. If you wish you can even call Perl
> script from Java.
> "Configure" would be a method that allows an application to do its
> own specific tasks other than splitting archive eg. running SQL script
> and create tables in database. It would be hard for a deploy tool
> to install application in database, that is why it is better to delegate
> this task to an application.
>
> The interface could be:
>
> interface DeployTool {
> void install(String name) {
> }
>
> void uninstall(String name) {
> }
>
> void configure(String name) {
> }
> }
>
> If "name" is the same install would first uninstall the application
> to avoid merging problems.
> In this case we don't even need special "update" method.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org