MyEc Javascript 璋冭瘯鍣ㄨ瘯棣栦釜涓篔avascript銆傚畬鏁撮泦鎴愬鎴風(fēng)Eclipse璋冭瘯鍣ㄣ傜壒寰佷富瑕佸寘鍚細(xì)
- Debug any web page containing JavaScript source or included JavaScript files, or standalone JavaScript files
- 璋冭瘯浠諱綍web欏甸潰鍖呭惈Javascript 婧愪唬鐮佹垨鍖呭惈Javascript 鏂囦歡錛屾垨鑰呭崟鐙殑Javascript鏂囦歡
- Operations: Pause, Resume, Step Into, Step Over, Step to Return, Terminate
- 鎿嶄綔錛氭殏鍋溿侀噸鏂板紑濮嬨佽繘鍏ャ佽煩鍑恒佽煩鍏ヨ繑鍥炪佺粓姝?
- Views: 瑙嗗浘
- Web Browser View (web 嫻忚鍣ㄨ鍥?
- Call Stack View聽 錛堝懠鍙爢鏍堣鍥撅級(jí)
- Variables View (鍙橀噺瑙嗗浘)
- Console View聽 錛堟帶鍒跺彴瑙嗗浘錛?/li>
- Set JavaScript breakpoints in: 璁劇疆javascript鏂偣
- JavaScript聽files (Javascript鏂囦歡)
- HTML with embedded JavaScript and linked JavaScript files 錛堝寘鍚唴緗殑javascript鍜屽叧鑱旂殑javascript鏂囦歡鐨凥TML錛?
- JSP聽files (jsp 鏂囦歡)
- Conditional breakpoints planned for MyEclipse 4.1.1 錛堜負(fù)MyEC鐨勬湁鏉′歡鐨勬柇鐐硅鍒掞級(jí)
- Integrates with Eclipse Launch Manager 錛堥泦鎴怑clipse鍙戣綆＄悊鍣級(jí)
- Quick launch from context-menu using "Debug As" (浣跨敤Debug As 榪呴熻皟鐢ㄤ笂涓嬫枃鎸夐挳)
- Launch from Eclipse Debug toolbar action 錛堜粠Eclipse 璋冭瘯宸ュ叿鏉¤涓轟腑璋冪敤錛?
- Use Launch Profile to modify launch configuration 錛堬級(jí)
- Launch JavaScript resource from project location or deployed MyEclipse web-application
An unbounded priority queue based on a priority heap. This queue orders elements according to an order specified at construction time, which is specified either according to their natural order (see Comparable), or according to a Comparator, depending on which constructor is used. A priority queue does not permit null elements. A priority queue relying on natural ordering also does not permit insertion of non-comparable objects (doing so may result in ClassCastException).
銆銆涓涓瀬澶х殑浼樺厛闃熷垪鍩轟簬涓涓紭鍏堝爢鏍堛傝繖涓槦鍒楁寜鐓т竴涓檺瀹氬湪鏋勯犳椂闂撮『搴忔帓鍒楀厓绱狅紝榪欐槸涔熸槸鎸夌収瀹冧滑鐨勮嚜鐒剁殑欏哄簭錛堟煡鐪婥omparable錛夐檺瀹氱殑錛屾垨鑰呮寜鐓т竴涓狢omparator,渚濋潬浣跨敤鐨勬瀯閫犲瓙銆備竴涓紭鍏堥槦鍒椾笉鍏佽涓虹┖鍏冪礌銆備竴涓紭鍏堥槦鍒椾緷闈犺嚜鐒墮『搴忎篃涓嶅厑璁告彃鍏ヤ竴涓潪comparable瀵硅薄錛堣繖鏍峰仛浼?xì)漶旂敓ClassCastException鐨勭粨鏋滐級(jí)銆?/P>
The head of this queue is the least element with respect to the specified ordering. If multiple elements are tied for least value, the head is one of those elements -- ties are broken arbitrarily. The queue retrieval operations poll, remove, peek, and element access the element at the head of the queue.
銆銆榪欎釜闃熷垪澶存槸鏈灝忕殑鍏冪礌浼撮殢鏈熸湜闄愬畾鐨勬帓搴忋傚鏋滃涓厓绱犱負(fù)鏈灝忕殑鍊肩害鏉燂紝澶存槸榪欎簺鍏冪礌涓殑涓涓?--綰︽潫鏄換鎰忔墦鏂殑銆傞槦鍒楄幏寰楁搷浣減oll(鎺?,remove(縐婚櫎)錛宲eek銆鍜屽湪闃熷垪澶撮儴鐨勫厓绱?/P>
A priority queue is unbounded, but has an internal capacity governing the size of an array used to store the elements on the queue. It is always at least as large as the queue size. As elements are added to a priority queue, its capacity grows automatically. The details of the growth policy are not specified.
銆銆涓涓紭鍏堥槦鍒楁槸鏋佸ぇ鐨勶紝浣嗘槸鎷ユ湁涓涓唴閮ㄧ殑瀹歸噺璋冭妭鏁扮粍鐨勫ぇ灝忕敤鏉ュ瓨鍌ㄥ湪闃熷垪涓殑鍏冪礌銆傚畠鎬繪槸鑷沖皯鍜岄槦鍒楀ぇ灝忔槸鏄竴鏍峰ぇ灝忕殑銆備綔涓哄厓绱犺鍔犲叆涓涓紭鍏堥槦鍒楋紝瀹冪殑瀹歸噺鏄嚜鍔ㄥ鍔犵殑銆傚鍔犵瓥鐣ョ殑緇嗚妭鏄病鏈夋寚瀹氱殑銆?/P>
This class and its iterator implement all of the optional methods of the Collection and Iterator interfaces. The Iterator provided in method iterator() is not guaranteed to traverse the elements of the PriorityQueue in any particular order. If you need ordered traversal, consider using Arrays.sort(pq.toArray()).
銆銆榪欎釜綾誨拰瀹冪殑鏋氫婦瀹炵幇鎵鏈夊彲閫夌殑闆嗗悎鍜屾灇涓炬帴鍙ｇ殑鏂規(guī)硶銆傝繖涓灇涓炬敮鎸乮terator()鏂規(guī)硶鏄笉淇濊瘉鍦ㄤ換浣曠壒瀹氱殑欏哄簭閬嶅巻PriorityQueue鐨勫厓绱犮傚鏋滀綘闇瑕侀『搴忕殑閬嶅巻錛岃冭檻浣跨敤Array.sort(pq.toArray()).
Note that this implementation is not synchronized. Multiple threads should not access a PriorityQueue instance concurrently if any of the threads modifies the list structurally. Instead, use the thread-safe PriorityBlockingQueue class.
銆銆娉ㄦ剰榪欎釜瀹炵幇涓嶆槸涓嶅悓姝ョ殑銆傚涓嚎紼嬩笉搴斿綋騫跺彂璁塊棶涓涓狿riorityQueue瀹炰緥錛屽鏋滅嚎紼嬪湪緇撴瀯涓婄嚎紼嬩換涓涓淇敼銆備綔涓烘浛鎹紝浣跨敤綰跨▼瀹夊叏鐨凱riorityBlockingQueue綾匯?/P>
Implementation note: this implementation provides O(log(n)) time for the insertion methods (offer, poll, remove() and add) methods; linear time for the remove(Object) and contains(Object) methods; and constant time for the retrieval methods (peek, element, and size).
This class is a member of the Java Collections Framework.
Since:
1.5
See Also:
Serialized Form
Utility classes commonly useful in concurrent programming. This package includes a few small standardized extensible frameworks, as well as some classes that provide useful functionality and are otherwise tedious(娌夐椃鐨? or difficult to implement. Here are brief(鎽樿鐨? descriptions of the main components. See also the locks(閿? and atomic(鍘熷瓙鐨? packages.
Executors(鎵ц鑰?
Interfaces. Executor is a simple standardized interface for defining custom thread-like subsystems(瀛愮郴緇?, including thread pools(綰跨▼姹?, asynchronous IO(寮傛IO), and lightweight task frameworks(杞婚噺綰т換鍔℃鏋?. Depending on which concrete Executor class is being used, tasks may execute in a newly(浠ユ柊鐨勬柟寮? created thread, an existing task-execution thread, or the thread calling execute(), and may execute sequentially(緇х畫鍦? or concurrently(騫跺彂鍦?. ExecutorService provides a more complete asynchronous(寮傛鐨? task execution framework. An ExecutorService manages queuing(闃熷垪) and scheduling(琛岀▼瀹夋帓) of tasks, and allows controlled shutdown. The ScheduledExecutorService subinterface adds support for delayed(寤舵椂鐨? and periodic(瀹氭湡鐨? task execution. ExecutorServices provide methods arranging(瀹夋帓鐨? asynchronous execution of any function expressed as Callable, the result-bearing analog(綾諱技鐗? of Runnable. A Future returns the results of a function, allows determination of whether execution has completed, and provides a means to cancel execution.
Implementations. Classes ThreadPoolExecutor and ScheduledThreadPoolExecutor provide tunable(鍙皟鐨?, flexible(鐏墊椿鐨? thread pools. The Executors class provides factory methods for the most common kinds and configurations of Executors, as well as a few utility methods for using them. Other utilities based on Executors include the concrete class FutureTask providing a common extensible implementation of Futures, and ExecutorCompletionService, that assists in coordinating(璁＄畻璋冮厤涓績(jī)) the processing of groups of asynchronous(寮傛鐨? tasks.
[Executor ExecutorService ScheduledExecutorService ScheduledThreadPoolExecutor ExecutionCompletionService]
Queues(闃熷垪)
The java.util.concurrent ConcurrentLinkedQueue class supplies an efficient scalable(鍙崌綰х殑) thread-safe(綰跨▼瀹夊叏) non-blocking(闈炴ā鍧楀寲) FIFO queue. Five implementations in java.util.concurrent support the extended BlockingQueue interface, that defines blocking versions of put and take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, PriorityBlockingQueue, and DelayQueue. The different classes cover the most common usage contexts for producer-consumer, messaging, parallel tasking, and related concurrent designs.
[LinkedBlockingQueue ArrayBlockingQueue SynchronousQueue PriorityBlockingQueue DelayQueue]
Timing(瀹氭椂)
The TimeUnit class provides multiple granularities<闂撮殧灝哄> (including nanoseconds鍗佷嚎鍒嗕箣涓縐? for specifying and controlling time-out(鏆傚仠) based operations. Most classes in the package contain operations based on time-outs in addition to(闄?..浠ュ) indefinite(涓嶇‘瀹氱殑) waits. In all cases that time-outs are used, the time-out specifies the minimum time that the method should wait before indicating(鎸囧嚭) that it timed-out. Implementations make a "best effort" to detect錛堝療瑙夛級(jí) time-outs as soon as possible after they occur. However, an indefinite(妯＄硦鐨? amount of time may elapse(嫻侀? between a time-out being detected and a thread actually executing again after that time-out.
Synchronizers(鍚屾)
Four classes aid(甯姪) common special-purpose synchronization idioms(璇硶). Semaphore(鏃楄) is a classic concurrency tool. CountDownLatch(Countdown 鍊掓暟璁＄ latch闂ㄦ彃閿) is a very simple yet very common utility for blocking until a given number of signals, events, or conditions hold. A CyclicBarrier(cyclic 寰幆鐨?barrier 灞忛殰) is a resettable(鍙噸緗殑) multiway(澶氳礬鐨? synchronization point useful in some styles of parallel programming. An Exchanger allows two threads to exchange(浜ゆ崲) objects at a rendezvous point(闆嗗悎鐐?, and is useful in several pipeline(綆￠亾) designs.
Concurrent Collections(騫跺彂闆嗗悎)
Besides Queues, this package supplies a few Collection implementations designed for use in multithreaded contexts: ConcurrentHashMap, CopyOnWriteArrayList, and CopyOnWriteArraySet.
The "Concurrent" prefix used with some classes in this package is a shorthand(閫熻) indicating several differences from similar "synchronized" classes. For example java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are synchronized. But ConcurrentHashMap is "concurrent". A concurrent collection is thread-safe, but not governed by a single exclusion lock. In the particular case of ConcurrentHashMap, it safely permits any number of concurrent reads as well as a tunable number of concurrent writes. "Synchronized" classes can be useful when you need to prevent all access to a collection via a single lock, at the expense of poorer scalability. In other cases in which multiple threads are expected to access a common collection, "concurrent" versions are normally preferable. And unsynchronized collections are preferable when either collections are unshared, or are accessible only when holding other locks.
Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators provide weakly consistent rather than fast-fail traversal. A weakly consistent iterator is thread-safe, but does not necessarily freeze the collection while iterating, so it may (or may not) reflect any updates since the iterator was created.
Since:
1.5
split
public String[] split(String regex)
- Splits this string around matches of the given regular expression.
This method works as if by invoking the two-argument
splitmethod with the given expression and a limit argument of zero. Trailing empty strings are therefore not included in the resulting array.The string "boo:and:foo", for example, yields the following results with these expressions:
Regex Result : { "boo", "and", "foo" } o { "b", "", ":and:f" } - Parameters:
regex- the delimiting regular expression- Returns:
- the array of strings computed by splitting this string around matches of the given regular expression
- Throws:
PatternSyntaxException- if the regular expression's syntax is invalid- Since:
- 1.4
- See Also:
Pattern
public interface LoginModule
LoginModule describes the interface implemented by authentication technology providers. LoginModules are plugged in under applications to provide a particular type of authentication.
While applications write to the LoginContext API, authentication technology providers implement the LoginModule interface. A Configuration specifies the LoginModule(s) to be used with a particular login application. Therefore different LoginModules can be plugged in under the application without requiring any modifications to the application itself.
The LoginContext is responsible<璐熻矗> for reading the Configuration and instantiating the appropriate<閫傚綋鐨?gt; LoginModules. Each LoginModule is initialized with a Subject, a CallbackHandler, shared LoginModule state, and LoginModule-specific options. The Subject represents the Subject currently being authenticated and is updated with relevant<鐩稿叧> Credentials<鍑瘉> if authentication succeeds. LoginModules use the CallbackHandler to communicate with users. The CallbackHandler may be used to prompt for usernames and passwords, for example. Note that the CallbackHandler may be null. LoginModules which absolutely require a CallbackHandler to authenticate<璁よ瘉> the Subject may throw a LoginException. LoginModules optionally use the shared state to share information or data among themselves.
NameCallback:
PasswordCallback:
The LoginModule-specific options represent the options configured for this LoginModule by an administrator or user in the login Configuration. The options are defined by the LoginModule itself and control the behavior within it. For example, a LoginModule may define options to support debugging/testing capabilities<鑳藉姏>. Options are defined using a key-value syntax, such as debug=true. The LoginModule stores the options as a Map so that the values may be retrieved using the key. Note that there is no limit to the number of options a LoginModule chooses to define.
The calling application sees the authentication process as a single operation. However, the authentication process within the LoginModule proceeds in two distinct phases. In the first phase, the LoginModule's login method gets invoked by the LoginContext's login method. The login method for the LoginModule then performs the actual authentication (prompt for and verify a password for example) and saves its authentication status as private state information. Once finished, the LoginModule's login method either returns true (if it succeeded) or false (if it should be ignored), or throws a LoginException to specify a failure. In the failure case, the LoginModule must not retry the authentication or introduce delays. The responsibility of such tasks belongs to the application. If the application attempts to retry the authentication, the LoginModule's login method will be called again.
In the second phase, if the LoginContext's overall<鍏ㄩ潰> authentication succeeded (the relevant REQUIRED, REQUISITE<闇姹?gt;, SUFFICIENT<瓚沖> and OPTIONAL LoginModules succeeded), then the commit method for the LoginModule gets invoked. The commit method for a LoginModule checks its privately saved state to see if its own authentication succeeded. If the overall LoginContext authentication succeeded and the LoginModule's own authentication succeeded, then the commit method associates the relevant<鐩稿叧> Principals (authenticated identities) and Credentials<鍑瘉> (authentication data such as cryptographic keys) with the Subject located within the LoginModule.
If the LoginContext's overall authentication failed (the relevant REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL LoginModules did not succeed), then the abort錛堝紓甯革級(jí) method for each LoginModule gets invoked. In this case, the LoginModule removes/destroys any authentication state originally saved.
Logging out a Subject involves only one phase. The LoginContext invokes the LoginModule's logout method. The logout method for the LoginModule then performs the logout procedures, such as removing Principals or Credentials from the Subject or logging session information.
A LoginModule implementation must have a constructor with no arguments<鏃犲弬鏁版瀯閫犲瓙>. This allows classes which load the LoginModule to instantiate it.
- package gongfei.cmc.articles.onlinecounter;
- public class OnlineCounter {
- private static long online = 0;
- public static long getOnline() {
- return online;
- }
- public static void raise(){
- online++;
- }
- public static void reduce(){
- online--;
- }
- }
銆銆鐒跺悗錛岀紪鍐橦ttpSessionListener瀹炵幇綾伙紝鍦ㄨ繖涓疄鐜扮被鐨剆essionCreated鏂規(guī)硶涓皟鐢∣nlineCounter鐨剅aise鏂規(guī)硶錛屽湪sessionDestroyed鏂規(guī)硶涓皟鐢∣nlineCounter鐨剅educe鏂規(guī)硶錛屼唬鐮佸涓嬶細(xì)
- package gongfei.cmc.articles.onlinecounter;
- import javax.servlet.http.HttpSessionEvent;
- import javax.servlet.http.HttpSessionListener;
- public class OnlineCounterListener implements HttpSessionListener {
- public void sessionCreated(HttpSessionEvent hse) {
- OnlineCounter.raise();
- }
- public void sessionDestroyed(HttpSessionEvent hse) {
- OnlineCounter.reduce();
- }
- }
銆銆鍐嶇劧鍚庯紝鎶婅繖涓狧ttpSessionListener瀹炵幇綾繪敞鍐屽埌緗戠珯搴旂敤涓紝涔熷氨鏄湪緗戠珯搴旂敤鐨剋eb.xml涓姞鍏ュ涓嬪唴瀹癸細(xì)
- <web-app>
- 鈥︹?
- <listener>
- <listener-class>
- gongfei.cmc.articles.example.OnlineCounterListener
- </listener-class>
- </listener>
- 鈥︹?
- </web-app>
鍘熸枃鍦板潃錛?A >http://www.javaresearch.org/article/showarticle.jsp?column=106&thread=18541