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] <mailto:[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]
<mailto:[email protected]>> wrote:
Hi
That's cool!. Any plans for jsf 2.0 + portlets?
regards,
Leonardo
2010/6/22 Scott O'Bryan <[email protected]
<mailto:[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
