Future implementations could supply Mock Objects test this, maybe even using he myfaces testing framework. While he TCK is flexible enough to test JSF/Bridge combinations, providing mock objects for these tests might allow us to make sure the delegation on the Bridge that is being tested is working correctly.
That said, it looks like the exposure here is pretty minimal for now. I will say this though, in Portlet Bridge 3.0, this delegation functionality is a BEAR. We may wan to fix this in the JSF 2.0 bridge spec. Scott Sent from my iPhone On Jun 24, 2010, at 11:14 AM, Michael Freedman <[email protected]> wrote: Short answer is I don't think its necessary, though if MyFaces wanted to make adjustments it would expand the reach of these tests. In the end, I couldn't figure out a JSF spec compliant way to write these tests and hence they are excluded however because I did figure out a way that worked with the Mojarra implementation I kept the tests around for those who want to use them as unit tests to validate this function. Here are the gory details: Render Policy is a configuration parameter that controls how the bridge's ViewHandler processes a render. By default, the bridge will delegate the render call and only process the render itself if the delegate throws an exception. To avoid this behavior you can either tell the bridge to either ALWAYS_DELEGATE or NEVER_DELEGATE -- each which do the obvious thing. So the TCK tests for these configurations require we insert a ViewHandler as the delegate of the bridge's viewHandler. As you likely know, there is no formal way of doing this in JSF 1.2 as all such viewhandlers are chained in an arbitrary chain. In the end I found a "trick" that worked in Mojarra whereby the TCK test supplied a faces Application object that overrode setViewHandler and inserts the test ViewHandler before any other (that goes through this call). This works in Mojarra because of the particular implementation style they have for bootstrapping the objects at init time. MyFaces has a different implementation style/strategy and though I don't remember the details my test's scheme doesn't work -- I think all the registered ViewHandlers are processed during the init stage without calling setViewHandler. -Mike- On 6/23/2010 10:31 PM, Leonardo Uribe wrote: Hi Ok, good to know that. Looking into the tck I saw this comment: ".....Render Policy tests are excluded because its mechanism relies on a Mojarra impl dependency (doesn't work on MyFaces) If you are testing with Mojarra uncomment these out to get the additional test apps built...." My question is: Do we need to implement something on MyFaces to make this work? or it is a Mojarra specific feature? regards, Leonardo Uribe 2010/6/23 Scott O'Bryan <[email protected]> > Yes there is.. Although the JSR has not been kicked off yet, we do have > a 'very' preliminary stab as JSF 2.0 bridge that runs Trinidad 2.0. Bright > now it exists as a private branch over in the Portlet Bridge svn repository. > Starting with this version, I'm taking advantage of the MyFaces 'share' > project to get the implementation of some base classes. It should cut down > on the amount of 'duplicated' work. Don't know what the final project will > look like exactly but O don't expect it to take nearly as long as the other > two bridges. > > Scott > > Sent from my iPhone > > On Jun 22, 2010, at 4:48 PM, Leonardo Uribe <[email protected]> wrote: > > Hi > > That's cool!. Any plans for jsf 2.0 + portlets? > > regards, > > Leonardo > > 2010/6/22 Scott O'Bryan <[email protected]> > >> Hello everyone, >> >> For those of you unfamiliar with the portlet-bridge project, it is >> essentially the R.I. implementation of JSR-301 and JSR-328. For over a year >> some core people have been working on getting the R.I. up to par. The one >> piece that was missing from this was the TCK. >> >> Well, Michael Freedman will be announcing the release of Portlet Bridge >> 1.0, which will become the R.I. for JSR-301 pending approvals. We also got >> the legalities of the TCK release figured out as well and I wanted to run >> things by the developers before putting a release of the project to a vote. >> >> Essentially, the TCK exists, en total, here at Apache and is run using a >> plugable maven build script instead of Sun's Portal TCK Harness like we were >> planning on using initially. What this means is that the TCK will be >> downloadable by anyone though the TCK project's svn repository right here at >> MyFaces. To my knowledge I think this is a first for Apache and will >> hopefully pave the way for continued support of the JCP from the Apache >> Community. >> >> I'd like to start a vote to release the official TCK for JSR-301 tomorrow >> but I wanted to do one final sanity check from the community to make sure >> this is still in line with what people want. When we talked about the TCK >> earlier, there were many questions as to why this TCK could not exist >> completely in the open source community and, in the end, that's exactly what >> we did. >> >> Thanks, >> Scott O'Bryan >> > >
