So Dennis, why did you "blow the whistle" on the RC? Was it from reading about a problem someone else had or was it b/c the TCK failed? I'm assuming you were just reporting a problem that someone else had and thought that it was present in the RC.
I do agree we need to slow down and make sure everything works properly. Lets all take a deep breath and figure out what's next. I'm going to start by rereading the release wiki and adding anything I think is missing there. Sean On 8/1/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Ok. That's kind of what my understanding of the behavior was, but it wasn't matching reality :) Thanks for clarifying it -- so it's definitely a bug. On 8/1/06, Dennis Byrne <[EMAIL PROTECTED]> wrote: > >I haven't said much because I don't really understand the problem. > >One thing that is confusing me is that the issue open appeared to be > >regarding a case-sensitivity issue. > > A little more on this. The CACHE param is there only for individuals who wish to disable it, meaning the key is not stored in app scope at startup. It will then be created on each request ( major performance hit ). I did this only because there is no guarantee that an encryption provider *must* provide a thread safe version of the key object ( making it unsafe to store in the session or the application). > > >My experience was that a new > >'org.apache.myfaces.secret.CACHE' parameter is now required in my > >web.xml file that was previously not required, and it's unclear to me > >from the documentation what this does or why it's required. > > This parameter should never be required by the application developer. > > Dennis Byrne > > >
