1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<?xml-stylesheet type="text/xml" href="../../nbbuild/javadoctools/apichanges.xsl"?>
<!DOCTYPE apichanges PUBLIC "-//NetBeans//DTD API changes list 1.0//EN" "../../nbbuild/javadoctools/apichanges.dtd">
<apichanges>
<apidefs>
<apidef name="keyring">Keyring API</apidef>
</apidefs>
<changes>
<change id="edt">
<api name="keyring"/>
<summary>Keyring API usable from any thread</summary>
<version major="1" minor="10"/>
<date day="6" month="1" year="2012"/>
<author login="phejl"/>
<compatibility>
<p>
Existing callers should use the Keyring directly from
any thread and should not try to avoid EDT anymore.
</p>
<p>
SPI implementors should not be changed and they may
continue to assume that they will not be called directly
from EDT.
</p>
</compatibility>
<description>
<p>
It hasn't been allowed to call the Keyring from EDT.
This change removes the limitation as the need to read
password from the UI is not so rare. To resolve this people
had to code custom threading solution to prevent possible
deadlock on fallback implementation of the keyring API.
</p>
</description>
<class package="org.netbeans.api.keyring" name="Keyring"/>
<issue number="206475"/>
</change>
<change id="initial">
<api name="keyring"/>
<summary>Keyring API created</summary>
<version major="1" minor="0"/>
<date day="11" month="12" year="2009"/>
<author login="jglick"/>
<compatibility>
<p>
Modules formerly storing passwords in some other way should
not only begin using <code>Keyring</code>, but also delete any
passwords from the old storage as they are transferred.
</p>
</compatibility>
<description>
<p>
A new API was created for securely storing user passwords.
Where possible it uses a native keyring.
</p>
</description>
<issue number="173413"/>
</change>
</changes>
<htmlcontents>
<!-- Generated from apichanges.xml -->
<head>
<title>Change History for the Keyring API</title>
<link rel="stylesheet" href="prose.css" type="text/css"/>
</head>
<body>
<p class="overviewlink"><a href="@TOP@/overview-summary.html">Overview</a></p>
<h1>Introduction</h1>
<p>This document lists changes made to the <a href="@TOP@/overview-summary.html">CHANGEME API</a>.</p>
<hr/>
<standard-changelists module-code-name="org.netbeans.modules.keyring"/>
<hr/><p>@FOOTER@</p>
</body>
</htmlcontents>
</apichanges>
|
