For various reasons, we don't use the Tapestry "@Shell" component, and do not have a BASE tag generated in our replacement. So far, everything works great, as long as you make sure references to images/css/other assets are properly rooted. As far as I can tell, the BASE tag is nice, but can be lived without.
jeff -----Original Message----- From: Petri Wessman [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 12, 2005 8:46 AM To: Tapestry users Subject: Re: Problem with Tapestry 4 base tag and Apache frontend On Wed, 2005-10-12 at 11:31 -0400, Kevin Menard wrote: > On Wed, 12 Oct 2005 11:20:55 -0400, Petri Wessman <[EMAIL PROTECTED]> wrote: > > > Hello all, I'm writing an app with the new Tapestry (version 4 beta 10 > > at the moment), and so far love the changes -- so much nicer and cleaner > > that Tapestry 3. > > > > However, I just ran into a problem. I tried deploying the app on the > > to-be production server with an Apache frontend, I've been using direct > > JBoss access to port 8080 so far. No luck, reverse proxying refused to > > work, Tapestry kept directing me to port 8080 even though I had > > specified ProxyPassReverse to Apache. > > I ran into this too. I decided to just go with mod_jk, which took care of > the problem. I do wonder if this will still work in Apache httpd 2.1, > which makes mod_jk an enhancement to mod_proxy. Actually, I just figured out an interim solution. In my hivemind.xml I added a section: <implementation service-id="tapestry.url.BaseTagWriter"> <create-instance class="com.ourcompany.BaseTagWriter"/> </implementation> Where my BaseTagWriter is just a no-op IRender implementation. This drops out the base tag, and now Apache normal/reverse proxy works fine. Problem solved. ...except that this doesn't solve it in the general sense, since the base tag was apparently added there for a reason. Without it, some new things may break(?). The ideal solution would be an ability to tell Tapestry what to generate in that base tag -- or maybe only generate it when it's really needed. Or something, don't know enough about Tapestry internals to offer a final solution here. But the above workaround does work, it seems. Hooray. :) //Petri --------------------------------------------------------------------- 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]
