An application Manager to start,stop an application with autoreload option to
automatically reload an updated jar could be nice.
Miessbrandt Gunter wrote:
What version of turbine do you use?
Gunter M.
-----Ursprüngliche Nachricht-----
Von: Brekke, Jeff [mailto:Jeff.Brekke@;qg.com]
Gesendet: Donnerstag, 17. Oktober 2002 16:15
An: 'Turbine Users List'
Betreff: RE: Modular Application Design?
Only templates and classes. Flux was the first project to be
packaged this way. Velocity can read the templates from the
jar. My tr.props is a regular tr.props, but the
module.packages= line is pretty long, and at the bottom I
have a bunch of 'include fooapp.properties' lines to pull in
the properties files from my sub applications. It is a pain
since these need to be copied into the same directory as
tr.props ( at least thats how we are doing it ) and aren't
read from the jar. We just copy all the additional stuff
into the main turbine apps tree ( props, images, javascript,
etc ). It isn't ideal, but was the best we could do with
turbine and breaking up our applications.
Real support for Sub-applications would include full
life-cycle management of the sub-app and stuff. Maybe the
avalon containers will help.
=================================================================
Jeffrey D. Brekke Quad/Graphics
[EMAIL PROTECTED] http://www.qg.com
-----Original Message-----
From: Miessbrandt Gunter [mailto:miessbrandt@;ixtern.de]
Sent: Thursday, October 17, 2002 9:08 AM
To: 'Turbine Users List'
Subject: AW: Modular Application Design?
Hi Jeff,
i'm very interested about packaging sub-applications in a jar-file.
Can you send me your TR.props file? What kind of files contains the
jar-file? Images too, or only templates and java files?
Thanks in advance
Gunter M.
-----Ursprüngliche Nachricht-----
Von: Brekke, Jeff [mailto:Jeff.Brekke@;qg.com]
Gesendet: Donnerstag, 17. Oktober 2002 15:59
An: 'Turbine Users List'
Betreff: RE: Modular Application Design?
This is what we are currently doing for our sub-applications.
Each project packages up the code and templates into a jar.
The jars are pulled into a main turbine application along
with the sub applications configuration file. We just add an
'include' to the bottom of tr.props for the subapps config.
The module.packages line is also updated.
It works, but what would really be nice is to extend the
functionality to, as you mention below, allow the jar to be
dropped in real time, and the turbine app auto pick it up.
This would need to have the config packaged into the jar, the
module.packages auto-updated, and dynamic updating of
TurbineResources.
=================================================================
Jeffrey D. Brekke Quad/Graphics
[EMAIL PROTECTED] http://www.qg.com
-----Original Message-----
From: Scott Eade [mailto:seade@;backstagetech.com.au]
Sent: Wednesday, October 16, 2002 6:01 PM
To: turbine-user
Subject: Re: Modular Application Design?
I believe what you are suggesting is possible. Classes can be
loaded from jar files by default and turbine provides
ClasspathResourceLoader for
retrieving templates from a jar file. If the classes and
templates for a
module are provided in a jar file and a configuration file
is added to
inform the main application about the module (so it knows how
to integrate
it) then all that should be required is a restart of the
webapp to kick the
new module off. Note that a new module might also need the
resource loader
paths and module.packages to be updated in TR.props to work
properly.
HTH,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au
From: Ian Beatty <[EMAIL PROTECTED]>
Reply-To: "Turbine Users List"
<[EMAIL PROTECTED]>
Date: Wed, 16 Oct 2002 14:09:00 -0400
To: [EMAIL PROTECTED]
Subject: Modular Application Design?
Greetings.
I'm checking out Turbine as a possible base for a major web
application I'm
starting to design. I see a lot that I like, but I am
concerned about one
aspect. Perhaps readers of this list could help to resolve
the question for
me.
It's important that the finished application be easily
extensible, in the
sense that someone else could develop a "module" that would
add to the
application. A module would get inserted into the website's
page hierarchy
at a particular location, supplying an entire new branch.
For example, it
might define a directory "http://localhost/myapp/module3/"
and all contents
of that directory. Or perhaps it would get inserted into
an existing
directory (supplied by the base app or an already-installed
module) such as
"http://localhost/myapp/somepart/module5/".
As I understand the Turbine framework, this would require
files to be
separately inserted into some or all of the application's
templates/app/screens, templates/app/navigations, and
templates/app/layouts
hierarchies. In addition, appropriate class files would
have to be inserted
at the right places in the application's WEB-INF/classes
hierarchy, and
various configuration and properties files might need
altering as well.
What I'd really like is a way to just drop a folder or JAR
containing all
the module's classes, templates configuration information
and properties
into a directory somewhere, and have the Turbine app
recognize it. Perhaps
I'd have to specify in an app-global configuration file
where that module's
root should be located in the application's existing
hierarchy (as it
appears in URLs). Then installing a module is as simple as
drag-and-drop,
and edit one file.
(I realize I'd also need to have any back-end support for
the module
installed separately, such as EJBs or DB tables, but I'm
not worried about
that part here.)
Is this possible in the Turbine framework? Anybody got any
neat ideas?
Thanks,
..Ian
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
--- -- --- --
Dr. Ian Beatty [EMAIL PROTECTED]
Physics Education Research Group voice: 413.545.9483
Department of Physics fax: 413.545.4884
Univ. of Massachusetts
http://umperg.physics.umass.edu/idb/
Amherst, MA 01003-4525 USA
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
--- -- ---
--
--
To unsubscribe, e-mail:
<mailto:turbine-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:turbine-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:turbine-user-> [EMAIL PROTECTED]>
For
additional commands,
e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:turbine-user-> [EMAIL PROTECTED]>
For
additional commands,
e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:turbine-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:turbine-user-help@;jakarta.apache.org>
--
To
unsubscribe, e-mail:
<mailto:turbine-user-> [EMAIL PROTECTED]>
For
additional commands,
e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org>