Multi-owner application

[Michel Goldstein <mi...@gmail.com>]

Hi,

I'm not sure this is the correct place for this question, but...

Right now I have a Tomcat/JSF application that is in production and working
well. I guess it's working so well that some other groups in the same
company came to me asking if they could use my application to manage (and
store) their data. This seems like a simple use case, but as I've been too
indoctrinated into an SOA-like system, I've decided to take this new
requirement to a much more "challenging" level: how to make this web
application in such a way that each "page owner" have complete freedom to
change any of their pages and underlying beans without affecting any other
owner (i.e., in a more realistic sense, not requiring extensive QA work from
all teams when any of the teams decide to make a change).

When I write "complete freedom to change" I mean the ability to change their
faces-config and web.xml (the use of some components require adding new
filters and mappings, for example). However, as far as I know, an
application in Tomcat can only have one web.xml (which makes sense in many
ways).

Then allowing multiple web applications in a same tomcat environment seems
to restrict the navigability and passing of managed beans from one
application to another. As, as far as I know, navigation rules are
restricted to a single application.

My next idea was to use an external shared state manager (EJBs, Jboss, etc.)
and an off-JSF navigation mechanism when crossing the application border.
Then create managed bean implementations that are proxies to these "external
shared state managers". Although this seems to work, it suddenly seemed
quite complex and much harder to maintain. I'd have to create my own
navigation mechanism and a method to synchronize the external scope to the
managed bean scopes.

Does anybody have experience with these requirements? Is there any simpler
solution I'm missing here? Or should I just give up on creating this
isolation because it will potentially create more trouble than benefit?

Thank you,
Michel