Then in each application war, reference the tile definitions in the common war. I assume I could specify in each application war's struts config file the absolute path to the common war tile definitions files.
In the end, what I'd like is a StrutsTemplate WAR that all applications start from. In this template I could set up the struts config and define the "standard" file structure. This template would have tile/image/etc references back to the Common war described above.
I'm going down this road because I like the idea of having each application being its own WAR. You get an http session object only available to your app and adding/removing an app from production is as simple as adding/removing it from the EAR. Problem is I have a slew of content that I want all applications to be able to use, but only have the content exist in one place. Solutions are obvious when it comes to images and truly static HTML....like run apache for those things. Solution gets a bit stickier when you consider tiles. I don't want every application to have a copy of the standard tile definitions or layouts or the tiles themselves. I'd like to have all that content defined in a Common.war and let each individual app use it. Is it even possible to do something like this? Can appA's struts config reference the tile definition in appB?
Jason Berk [ June 16, 2006: Message edited by: Jason Berk ]
Joined: Feb 15, 2005
Can appA's struts config reference the tile definition in appB?
I'm afraid the answer is no.
The reason is that Tiles uses the ServletContext's RequestDispatcher object to render tile definitions, and this object can only forward to JSPs or servlets in the same Web Application (WAR file). Also, your idea about putting absolute paths to tiles definitions in the struts-config.xml file won't work. All paths in this file are relative to the context path, and cannot be absolute. Granted, you could change this by extending Struts, but that's what it does now.
You can put truly static content in one central place, but putting Tile definitions in a central place won't work with the "out of the box" version of Struts. There's always the possibility of writing your own extensions to struts to make this work, but these extensions would not be trivial.
If you do decide to try extending Struts, you might be interested to know that the Java Standard Tag Library (JSTL) has a <c:import> tag that does have the ability to include a JSP from another Web application in the same JVM. You might be able to create your own version of tiles that takes advantage of this.
thanks...I was afraid of that. If I understand you correctly (regarding struts out of the box), if I want to have each application be its own WAR, then every WAR will have to contain a copy of the standard definition files, the standard tiles, and the standard layouts.
That means if we change our footer content, we'd have to update the footer in every WAR that used it.
I don't like putting everyting into one WAR cause (if I understand WSAD's session context) each application in the WAR would be sharing the same session and that could lead to naming collisions which would be a real PITA to debug.
On the other hand, having all the layouts, definitions, tiles copied into each new webapp doesn't sound very scalable either.
How is the rest of the world (you?) handling this. Are other just using one WAR with multiple "apps"? Is this something that people have just come to except and hope their header/footer don't change often...and when they do change the IDE makes updating them easier?
I wish I could "extend" JSPs. I want a master jsp with includes to the header/footer content and children JSPs that fill in the page content.
I want to have my cake and eat it too...:-)
Joined: Feb 15, 2005
In the applications that I develop, they're each pretty much self-contained. About the only things that they share are a cascading style sheet and some "legalese" that the lawyers make us put on the welcome page. In the case of the CSS, We just have multiple copies, and yes, there is a bit of a problem with them getting out of sync. In the case of the legal stuff, it's completely static content, so we can centralize the location of it.
For large projects that have pages that share headers and footers, I think most developers end up just using one big war file with multiple modules.
Regarding your objection that they all share the same session, a little co-ordination between the teams could solve that. For example, you could require that anything put in the session use a key from a global constants class. Then when any developer wants to put something in the session, he/she has to check what's already in the constants class and add a new unique value.