Vaadin 7 Notification.show() Problem - Message Never Renders

Vaadin 6 / 7 / 8
1

Greetings,

I am upgrading my Vaadin 6 application to Vaadin 7 and things are going pretty well in general.

However, I am converting all of my notifications from :

getWindow().showNotification(...) to

Notification.show(...) and the none of the messages render in the browser.
They do not show up in the browser. At all.
The Vaadin 6 to 7 migration guide addresses this in one sentence (“The API for Notifications has also changed, static methods Notification.show() are now used instead of Window.showNotification().”) so I assumed that is all I needed to do.

But the messages do not render in the browser. I literally changed each line of code from the Vaadin 6 API form (getWindow().showNotification()) to the Vaadin 7 API form (Notification.show()). When I run my application using Vaadin 6, the message appears in the browser. With Vaadin 7 it does not.

With Vaadin 6.x I saw the message in the browser. With Vaadin 7.3.6 I see nothing. The message simply fails to render. My application works fine (I also use log4j to log each message that is supposed to be displayed to the user). The user messages simply do not show up.

Thinking maybe there is some sort of error under the covers, I installed an ErrorHandler in my UI class and see no output.

I tried adding ?debug to the end of my URL to see if additional information showed up that way. Still nothing.

From the lack of posts on this topic, it would appear that I am the only one having this issue. I hope that is not the case, thus I appeal to the forum for help.

Any help is appreciated. If you would like to see source code, it is above. :slight_smile:

Thanks,
Steve

2

Could you post some code snippet please.

3

Yes, I can post some code snippet. The following code does not work:

Notification.show("This does not work");

I suppose that was unclear from my post. :wink:

The code above does not render in the browser. Any browser. And I’ve tried it Firefox, Chrome and IE.

4

Did you try a fresh Vaadin 7 project to test this Notification code. I am sure it will work. Since, your project is a migrated one (Vaadin 6 to Vaadin 7), there might be some issues related to missing Vaadin 7 jars.

5

Unfortunately, I don’t have the luxury of starting over with a brand new Vaadin 7 project. I either have to find a way to make the migration work (which will include getting Notification messages to work), or stay with Vaadin 6.x until we can migrate to another UI framework (probably Apache Wicket).

For anyone interested in replying with something helpful, I am running under JBoss EAP 7.3.2. Vaadin 6 works without this particular issue. Vaadin 7 seems to work fine (Layouts seem a little glitchy compared to 6). So far this notifiction issue is the only one I’m having.

If you have migrated from 6 to 7 and have seen issues like this one, please reply. If not, please don’t bother.

I may have better luck at Stackoverflow.com.

6

You should create a new Vaadin 7 project in Eclipse (it’s a small task to do), and then copy all of your code into it. This will at least ensure you have the Vaadin 7 stuff in place for your builds.

Certainly that code should work, and the fact that it doesn’t indicates your project is not set up correctly.

Were there any errors in the widgetset builds? Are you sure your test runtime environment has all of the Vaadin 7 stuff and none of the old stuff?

Odd that you have so much working except notifications, though. That certainly wasn’t one of the many sore points we had in converting from 6 to 7!

7

Have you checked that client, server and theme use the same Vaadin version? You can check those versions by adding ?debug to the url of your application (e.g. http://localhost:8080/myapp/?debug) which should open a debug window. The second tab of that window should contain lines:

Client engine version 7.3.6 Server engine version 7.3.6 Theme version 7.3.6 And those 3 version numbers should match. Another possibility is that your theme just hides those notifications. Do you have your own custom theme in use?

8

Thanks for the reply, David. The problem with my project is that it is several projects. We have code spread over numerous JARs. That said, I will try to merge my existing POMs into the one generated by the maven-archetype-application, and see where that gets me. I tried doing this by eye, but as you said, my project probably is not set up correctly.

One question for you: you asked if my widgetsets compiled correctly. I have no custom widgets, so I thought including the vaadin-client-compiled JAR was sufficient to use pre-packaged Vaadin widgets. Am I missing something?

Thanks again.
Steve

9

Henri, thanks for the reply, and if the theme I’m using is what is hiding the notifications, this may be the culprit.
BTW, I do see the notification - after the Notification.show() call - when I refresh the browser window
manually

. If my UI class has @PreserveOnRefresh, and I hit F5 (in Firefox, Chrome and IE) I see the notification (without @PreserveOnRefresh, of course, the application is restarted and I see nothing).

Here is what I’m getting:

Client engine version7.3.6 Server engine version7.3.6 Theme version none Widget setcom.vaadin.DefaultWidgetSet Themereindeer Communication methodXHR Heartbeat300s Interesting that my theme version is “none”. What am I missing?

10

To expand on my reply to Henri:

I can get the Notification to show up, but only if I manually refresh the browser window (after I make sure @PreserveOnRefresh is set in my UI subclass). This is because the Notification is added to a List of Notifications inside the Page object, and rendered to the browser when paintContent() is called.

Unfortunately, the only way I have gotten paintContent() to be called thus far is to manually refresh the browser window.

11

So the problem is that the notification is added on an external thread to the application outside the normal request-response cycle. To fix this you need to use polling or push to show the notification. Also you need to remember to synronize accessing the application from an external thread. See
https://vaadin.com/book/-/page/advanced.push.html
 for more information about push and UI.access.

12

Well, that may be sufficient per the documentation, but as we’ve always had at least one add-on, so we’ve always compiled the widgetsets. It was acting odd, so it seems a likely culprit.

As for needing refreshers and such for Notification.show() calls, I would only think that’s try if you are calling that from some background thread and as part of the handling of a vaadin request. If a user clicks a button or the like and that results in the Notification.show() (this must be the most normal usage of it), I’ve never seen it get stuck. Also, if that’s the case, you shouldn’t need to refresh to see it, you should see if you click on any other button or UI element that causes an interaction to the server.

13

That’s what Henri Kerola said as well, that my processing was occurring in a background thread. But upon further reflection, I’m not sure that’s the case. Here is my code:

[code]
@SuppressWarnings(“serial”)
private void createSaveButton(Layout layout) {
// → Save Button
saveButton = new Button(“Save”);
layout.addComponent(saveButton);
saveButton.addClickListener(new ClickListener() {
@Override
public void buttonClick(ClickEvent event) {
// Do any validation that standard validators
/// don’t cover
if (saveRegistrationInfo() == true) {
Notification.show(“Registration Info Saved.”);
}
}

});

}
[/code]I assumed the buttonClick() code above would run on the “UI thread” (and not a background thread that would require me to send a Push notification). Is that not the case?

The saveRegistrationInfo() call does call a backend (via synchronous call) Web Service, but (a) how would Vaadin know that at compile time (or run time for that matter), and (b) wouldn’t all code within buttonClick() run on the same thread?

S

14

That looks like normal processing to me and I never had to do anything special to make the notification appear in such a scenario as other updates you do within the button’s click listener should all make it back to the client browser with the response.

15

Thanks, David. That’s what I thought. So, I am going to pursue the “project not setup correctly” angle and see where that gets me. As it turns out, I am using several Addons, that I am not explicitly recompiling, so I’m taking your advice and recompiling all Widgetsets. I appreciate your responses. I will figure this out and post the “fix” to this thread, though it may take me a while… I’m having to learn more about Vaadin internals than I think one should have to, but such is the nature of migration and enhanced APIs.

16

Okay, so I figured out what my problem was: me (careless overriding of important methods).

At the start of the upgrade from 6 to 7, in researching the Vaadin 7 framework, and while making the necessary changes to my code I put the following block of code in my UI subclass:

@Override public void markAsDirty() { } I can sense a collective gasp of horror from those of you who know what a terrible thing I’ve just done. Furthermore, you know that the “dirty” flag indicates that there are unrendered state changes (such as, oh, I dunno, a Notification, maybe?), that must be rendered on return to the browser as part of the normal request/response cycle.

Had I done this:

@Override public void markAsDirty() { super.markAsDirty(); } I would have been fine. I have since removed my override of this method altogether.

So, I debated whether to let this thread slide into ignomy, or humbly confess my sins. Since I don’t know if what I did was such a mind-numbingly dumb thing to do that nobody has ever seen it manifest in quite this way, or whether others should be warned not to override markAsDirty() without calling super.markAsDirty(), out of caution (and perhaps a sense of duty) I wanted to post a reply in case others should make the same mistake.

Thanks to all who attempted to help me. I appreciate your time and energy.

Steve

17

Hey, at least you found it! Yeah, we don’t override that method anywhere in our code base. Gotta be careful when you override a method…