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

Reply via email to