Changed target to EE-4.1.0.GA for now.

After discussion this is deemed to be an edge case. We should keep an eye on this one though as eventually we might want/need it for both ICEfaces-EE and BridgeIt. Therefore I'll keep this one on my list.

I fixed an NPE that was occurring due the changes noted in the previous comment. Those changes should be re-evaluated during the course of developing the required API.

I also adjusted the logging to include the exception because it appears that any RuntimeException that occurs here will potentially cause a Push storm.

The current mechanism I've been using in the chat-sms sample application looks something like:

public static boolean registerForNotification(ServletContext sc, String protocol, String message, List<String> pushIDList) {
    MainServlet ms = MainServlet.getInstance(sc);
    PushGroupManager pusher = ms.getPushGroupManager();
    NotifyBackURI notifyBackURI = new NotifyBackURI(protocol + ":" + message);
    boolean notificationSet = pusher.setNotifyBackURI(pushIDList, notifyBackURI, true);
    log.info("\n  notification set: " + notificationSet +
            "\n  notify back URI : " + notifyBackURI +
            "\n  push ID list    : " + pushIDList
    );
    return notificationSet;
}

However this also relies some changes that I needed to make to icepush-ee:

r34339 PUSH-221: some tweaks to allow server side registration of notification providers to work
r34550 PUSH-221: some tweaks to allow server side registration of notification providers to work

The main changes involved retrieving the existing notifyBackURI for a PushID (if one exists) and then setting that on the BlockingConnectionServer as it currently only examines requests from the client that contain the specific header.

I also added a LoggingNotificationProvider that allows desktop browsers to simulate Cloud push behaviour by logging those notifications to the app server's console.

r34340 PUSH-221: add a LoggingNotificationProvider to help with debugging

Given a sample use case:

• user composes an SMS containing ice.push.browser and sends it
  to an ICEsoft phone number. This is convenient because we can
  create a link for them that pre-fills the message with
  the browser ID
  sms:5551212?body=Register%20for%20cloud%20push%20ve6oa
• we receive an HTTP POST at our server from twilio containing
  the SMS

Ted's initial suggestion about how it might work using just the browser id:

At that point we want to call something like this, because we
have the notifyBackURI, which is sms:phonenumber

public void park(final String pushId, final NotifyBackURI notifyBackURI)

So, we should look at how difficult it would be to add more support
for browserID. Maybe the ability to registerCloudPushId would be
a good place to start (even if we just kept a table of browserID/pushID
we could iterate through them and park them all).