Gang -
ComponentSystemEvent has this new override:
Index: javax/faces/event/ComponentSystemEvent.java
===================================================================
--- javax/faces/event/ComponentSystemEvent.java (revision 8845)
+++ javax/faces/event/ComponentSystemEvent.java (revision 11719)
+ /**
+ * <p class="changed_added_2_2">Before calling the corresponding method
+ * on the superclass, verify that there is a current component so
+ * that EL expressions that start with #{component} or #{cc} operate
+ * as expected.</p>
+ *
+ * @param listener {_at_link FacesListener} to evaluate
+ * @since 2.2
+ */
+ @Override
+ public void processListener(FacesListener listener) {
+ UIComponent c = getComponent();
+ UIComponent cFromStack;
+ boolean didPush = false;
+ FacesContext context = FacesContext.getCurrentInstance();
+ cFromStack = UIComponent.getCurrentComponent(context);
+ if (null == cFromStack) {
+ didPush = true;
+ c.pushComponentToEL(context, null);
+ }
+ try {
+ if (listener instanceof SystemEventListener) {
+ super.processListener(listener);
+ } else if (listener instanceof ComponentSystemEventListener) {
+
((ComponentSystemEventListener)listener).processEvent(this);
+ }
+ } finally {
+ if (didPush) {
+ c.popComponentFromEL(context);
+ }
+ }
+ }
Which was added to address this spec issue:
JAVASERVERFACES_SPEC_PUBLIC-1043 When publishing a ComponentSystemEvent,
ensure the EL current component is pushed correctly
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1043
In my mind, it should be the responsibility of whatever code calls
publishEvent() to ensure that proper context is set up before publishing
the event. This should already be happening implicitly for most events,
eg. the current component should already be set up for any events that
are published during JSF lifecycle processing. Failure to do this would
indicate a bug in the calling code that we don't want to mask with some
bonus ComponentSystemEvent magic.
If there are some cases where the JSF implementations are failing to
take care of this (eg. when delivering PreRenderViewEvents?), I would
prefer that we clean up the implementations to handle this correctly
rather than complicate ComponentSystemEvent.processListener().
If we're worried about missing some cases, I suppose we could add a
Debug project stage test to check/warn about this.
Andy