That's what I'm doing now, but the problem is that it forces me to
re-release the BaseApp every time I want to ship a new feature. The BaseApp
is on a slower release schedule, about once every six months, whereas it
would be nice to support new features sooner than that.
The BaseApp is performing some network management functions, and the
"features" I've been talking about are the management of additional server
types in the network. My goal is to be able to dynamically add support for
new server types without re-releasing the BaseApp. Otherwise the new server
types will go unmanaged until the next 6-month release.
-- Joe
----Original Message Follows----
From: "Murray Collingwood" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: Re: Adding a plug-in to a webapp
Date: Mon, 19 Sep 2005 12:05:29 +1000
Can you deploy the entire application with all options and use the security
system to
establish which menu items appear?
This avoids the problem of different versions of baseApp and module.
It also avoids the problem of trying to look for different modules
installed.
The only issue is that there may be a larger download for your customers
when they
upgrade as the entire application is shipped each time.
Kind regards
mc
On 18 Sep 2005 at 21:27, Joe Bermann wrote:
> Hi,
>
> Im looking for some advice on how to design a Struts-based webapp that
can
> accept dynamic plug-in components after deployment. Ive searched the
> archives and found some interesting posts about Struts Modules and Single
> Sign On, but I didnt find anything that addressed my situation exactly.
>
> I have a core webapp, lets call it BaseApp, that contains a menu of
launch
> points to various features. After BaseApp is deployed and running at a
> customer site, the time will come when I want to add a launch point to a
new
> feature there. In my current design Ill need to re-deploy an updated
> BaseApp that contains a new menu item and the new feature. A much more
> flexible design would allow me drop in a new set of files that the
BaseApp
> would recognize and link to (after restarting Tomcat). This way the
BaseApp
> wouldnt have to be updated, re-qualified, or re-deployed (a huge savings
at
> my company).
>
> One of the problems is dealing with authorization issues the users
should
> have to log in only once and should be automatically logged out after a
> period of inactivity, regardless of where in the GUI they click.
> Unfortunately the BaseApp has already been developed with custom security
> code; container managed security was not used. After the users password
is
> authorized, a special object is stored in session scope; the presence of
> that object indicates an authorized user.
>
> Another problem is upgrading the software in the field. Eventually a new
> version of the BaseApp will be released and the deployment in the field
> needs to be upgraded. This means that any plug-ins need to be upgraded
too,
> or at least maintained (not wiped out).
>
> Ive thought of using separate webapps (i.e. the plug-in could be
packaged
> as a new webapp) with a dynamic menu in the BaseApp, but then Im faced
with
> the authorization problems mentioned above.
>
> Is there a standard pattern in Struts to satisfy these requirements (will
> Struts Modules do what I need)? Is there some way to drop in
additional
> files into a pre-deployed webapp? Does anyone have experience with these
> types of issues?
>
> Thanks!
>
> -- Joe
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date:
14/09/2005
>
FOCUS Computing
Mob: 0415 24 26 24
[EMAIL PROTECTED]
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
