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>

Reply via email to