At 1:53 PM -0700 5/5/04, Craig McClanahan wrote:
Thanks Niall.
The original reason for grabbing the module prefix was to make the
cache keys unique, so that two modules that both defined a form bean
named "foo" (but perhaps with different properties) would not clash.
The approach you recommend
: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 9:53 PM
Subject: Re: Struts-Faces and Version Dependencies
> Thanks Niall.
>
> The original reason for grabbing the module prefix was to make the cache
> keys unique, so that two modules that
;[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 7:47 PM
Subject: Re: Struts-Faces and Version Dependencies
The only reason for needing the ModuleConfig is to get the module prefix
for
the key to store the DynaActionFormClass in the "static" cache in
DynaActionFor
; <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 7:47 PM
Subject: Re: Struts-Faces and Version Dependencies
> The only reason for needing the ModuleConfig is to get the module prefix
for
> the key to store the DynaActionFormClass in the "static" cache in
> DynaActionFormC
[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 6:41 PM
Subject: Struts-Faces and Version Dependencies
> I'm woefully behind in dealing with Struts issues due to "day job"
> responsibilities, but I finally took the time to discover why the
> Struts-Faces nightly build
I'm woefully behind in dealing with Struts issues due to "day job"
responsibilities, but I finally took the time to discover why the
Struts-Faces nightly builds have been failing. Unfortunately, we've
created a public API discrepancy in the latest CVS code (versus 1.1)
that affects the library
