This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 159614 - Notifications API review
Summary: Notifications API review
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Stanislav Aubrecht
Depends on: 160945
  Show dependency tree
Reported: 2009-03-04 14:58 UTC by Stanislav Aubrecht
Modified: 2009-03-28 20:49 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Aubrecht 2009-03-04 14:58:40 UTC
there's a need for a generic notifications api that would allow informing the user about various events in an
unobtrusive way. examples of such events are 'updates available', 'hudson build failed', 'instant messaging events'.
Comment 3 Jaroslav Tulach 2009-03-05 17:48:53 UTC
Y01 A "tck" test showing behaviour of SimpleDisplayer and some complex one in is the same would be nice.
Comment 4 Jesse Glick 2009-03-13 02:18:02 UTC
I am using it without problems so far. I have not attempted to use the facility to inject a custom JComponent.

getDefault is missing Javadoc. Should specify that it looks for an impl in lookup and has a fallback.

It is not necessary to specify @throws NullPointerException for null args; _all_ NB APIs are presumed to never accept or
return null unless otherwise specified.
Comment 5 Stanislav Aubrecht 2009-03-13 11:23:48 UTC
i fixed the javadoc. all changes should propagate to the main repo soon since cdev has been converted to regular team repo

Y01: what's 'tck' test?
Comment 6 Jaroslav Tulach 2009-03-14 06:24:54 UTC
Re. TCK. See, section "Testing Foreign Code". In your 
situation you would have a test in openide.awt. You would run it once to verify openide.awt's impl is OK. You would 
run it for second time to test that core.ui's impl is OK.
Comment 7 Jesse Glick 2009-03-25 14:20:23 UTC
[JG01] See issue #160945. Behavior must be documented (in Javadoc for each applicable method) w.r.t. use of HTML in
strings. Possible choices:

1. HTML is not permitted. #160945 must be backed out, and hudson module must not use it.

2. HTML is required. Any modules constructing strings from arbitrary sources should use XMLUtil.escapeForElementContent
to make sure stray '<'s are not interpreted as tags etc.

3. HTML is permitted if a method returns a value beginning with "<html>". #160945 should be backed out, but impl code
should be reviewed for any place where an API-supplied string is concatenated with any other string - in which case
"<html>" may need to be moved to the front of the compound string, or the non-API-supplied portion may need to be escaped.
Comment 8 Stanislav Aubrecht 2009-03-27 14:48:33 UTC
[JG01] - i implemented your suggested option 1. html is used in api impl to create link-like buttons so html tags inside
the text may lead to visual discrepancies
NotificationDisplayer.notify( String, Icon, JComponent, JComponent, Priority) can be used for notifications with
custom-rendered content

core-main a095e36b5f97
Comment 9 Quality Engineering 2009-03-28 20:49:49 UTC
Integrated into 'main-golden', will be available in build *200903281400* on (upload may still be in progress)
User: S. Aubrecht <>
Log: #159614 - don't allow html tags in notification texts