handledEvents wildcards clarification

[Kevin Frender <kfrender@bea.com>]

Wildcard-matching of event names is described in section 4.1.16 of the 
specification with the sentence:

Each [event] name specified is allowed to end with a "." character to 
indicate the Portlet is willing to process any event whose name starts 
with the characters before the "." character.

My strict, literal interpretation of this sentence is that the "." 
character on the end of the handledEvent string is NOT included as part 
of the pattern to be matched-- the pattern to be matched includes only 
"characters before the '.' character" and NOT the '.' itself.

I don't think this is what was intended by the technical committee- 
section 4.1.11 talks about using "." to delimit hierarchy levels in 
event names and implies the reason why "." is used is for wildcard 
matching.

I'm pointing this out to try and ensure consistent interpretation of the 
specification.  I think the specification either needs a clarification 
that the "." is included in matching the wildcard name with an event 
name (such as "... Portlet is willing to process any event whose name 
starts with the characters before and including the '.' character"), or 
we need to agree that the '.' is NOT included and leave the 
specification worded as it is now.

One potential reason to leave the specification worded as it is now is 
that it allows for more powerful wildcard matching.  For example, WSRP 
defines standard names for mode and state change events:

{urn:oasis:names:tc:wsrp:v2:types}newMode
{urn:oasis:names:tc:wsrp:v2:types}newWindowState

These event names do not use '.' to separate hierarchy levels as section 
4.1.11 suggests, so if a portlet wanted to subscribe to both of these 
events there is no way to do it with a wildcard if the '.' is included 
in the wildcard-matching pattern.  However, if the '.' is not included, 
a handledEvents specification of 
"{urn:oasis:names:tc:wsrp:v2:types}new." would match both events.

If we do leave the specification worded as it is now, it is still 
possible to ensure a '.' is matched for a wildcard- simply specify two 
periods on the end of the wildcarded event name, such as 
"somens:localPart.."

JSR286 has this same issue and obviously we would want the 
specifications to match in their interpretation.

 Kevin

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.