> > "Craig R. McClanahan" wrote:
> > > Because this question comes up occasionally, I would be interested in
> > > understanding more about what might motivate a desire to have more than one
> > > instance of the controller servlet. Do you have some particular use cases in
> > > mind where this would be helpful?
> > >
> >
> > I'll take a stab at this...I've been meaning to for a while but
> > have been too busy to sit down and write up my issues.
> >
>
> Elod, thanks (as always) for your thoughtful and detailed analysis. I'm going to be
> on an airplane a lot this week, so I'm going to spend a bunch of that time thinking
>on
> these issues. My original vision was that you would deal with these kinds of
> complexity and (functional) scale issues by using multiple cooperating webapps. Now,
> I want to think about that a little more.
>
> If I can define a non-backwards-incompatible way to implement multiple controllers
> later (that we can all agree to), I'm game to go ahead with a 1.0 release now --
> otherwise, this is definitely something that should be determined (one way or the
> other) before a 1.0 final release.
>
fair enough. enjoy the trip. i guess you'll be in my neck of the
concrete jungle for the remainder of the week...
> In the mean time, I'm sure you've thought of a few of the following workarounds
>within
> the current architecture, based on the idea of using separate webapps but
>establishing
> a means of sharing stuff:
>
> * Are you using container-managed security for login authentication?
> If so, the container might have "single sign on" features that manage
> the cross-app authentication questions.
we do not use container authentication. we are currently tied
heavily to a legacy backend system for authentication and customer
profile processing.
(as background, we're prototyping in jrun3.0. the future threatens
weblogic hitting us like a 10-ton gorilla but that future is possibly
1-2 years away)
>
> * Most servlet containers (although not required by the spec) offer a means
> to declare a set of classes to be "global" to all web apps. Normally, this
> is done by establishing a classloader that is the (shared) parent of the
> classloaders used for each web app. One nice feature of such global
> classes is that global statics are shared -- so you can easily build an
> infrastructure for in-memory sharing between webapps.
this would be interesting albeit not very portable. i'm not sure if
jrun has any such support (but something tells me 'no' since i haven't
accidentally come across anything like this so far)
>
> * Alternatively, it is also feasible to use external mechanisms (databases,
> EJBs, etc.) to share information between webapps -- although there are
> likely to be performance impacts if the amount of shared data is high,
> and/or the rate of change to this data is high.
this would be the most expensive and painful solution. EJBs are
not on the horizon for a while (the weblogic project). getting
database support is quite painful here (the bureaucracy is so
extreme and entrenched that it's almost easier to walk up to a rabid
lioness protecting her cubs than it is get any sort of timely and
reasonable support for database table space, disk space, schemas, etc.).
and it doesn't help that this project is in experimental prototyping
stages at the moment. performance may not be so exciting either; the
database is already fairly well loaded with normal activities. not
to mention the considerable development effort needed get some sort
of database backed sharing mechanism working.
unfortunately [for you i suppose :) ], the simplest solution always
comes back to struts supporting multiple controllers. do i have
a one track mind or what? :)
>
> Craig
e
--
_______________________________________________________________________
Elod Horvath ('e')
