濡傛灉鍦ㄧ被涓彇涓嶅埌ServletContext鏃訛紝 鏈変袱縐嶆柟寮忓彲浠ュ仛鍒?/span>
1) 鍒╃敤Java鐨勭被鍔犺澆鏈哄埗 璋冪敤 XXX.class.getClassLoader().getResource(""); 鏂規硶鏉ヨ幏鍙栧埌ClassPath , 鐒跺悗澶勭悊鑾峰緱WebRoot鐩綍錛岃繖縐嶆柟寮忓彧鑳芥槸璇lass鍦╓ebRoot/WEB-INF/classes涓嬫墠鑳界敓鏁堬紝 濡傛灉璇lass琚墦鍖呭埌涓涓?a target="_blank" style="text-decoration: none; color: #555555; border-bottom-width: 1px; border-bottom-style: dotted; border-bottom-color: #d30010;">jar鏂囦歡涓紝 鍒欒鏂規硶澶辨晥銆傝繖鏃跺氨搴旇鐢ㄤ笅闈竴縐嶆柟寮?br />
2) spring妗嗘灦鐨勬濊礬, 鍦╓EB-INF/web.xml涓?錛?鍒涘緩涓涓獁ebAppRootKey鐨刾aram, 鎸囧畾涓涓?榛樿涓簑ebapp.root)浣滀負閿鹼紝 鐒跺悗閫氳繃Listener , 鎴栬匜ilter , 鎴栬匰ervlet 鎵цString webAppRootKey = getServletContext().getRealPath("/"); 騫跺皢webAppRootKey瀵瑰簲鐨剋ebapp.root 鍒嗗埆浣滀負Key , Value鍐欏埌System Properties緋葷粺灞炴т腑銆備箣鍚庡湪紼嬪簭涓氳繃System.getProperty("webapp.root")鏉ヨ幏寰梂ebRoot鐨勭墿鐞嗚礬寰?br />
涓嬮潰鏄竴浜涘緱鍒癱lasspath鍜屽綋鍓嶇被鐨勭粷瀵硅礬寰勭殑涓浜涙柟娉曘備綘鍙嬌鐢ㄥ叾涓殑涓浜涙柟娉曟潵寰楀埌浣犻渶瑕佺殑璧勬簮鐨勭粷瀵硅礬寰?
銆銆1.DebitNoteAction.class.getResource("")
銆銆寰楀埌鐨勬槸褰撳墠綾籉ileTest.class鏂囦歡鐨刄RI鐩綍銆備笉鍖呮嫭鑷繁!
銆銆濡傦細file:/D:/eclipse/springTest/WebRoot/WEB-INF/classes/atacarnet/src/com/evi/modules/atacarnet/action/
銆銆2.DebitNoteAction.class.getResource("/")
銆銆寰楀埌鐨勬槸褰撳墠鐨刢lasspath鐨勭粷瀵筓RI璺緞銆?/p>
銆銆濡傦細file:/D:/eclipse/springTest/WebRoot/WEB-INF/classes/
銆銆3.Thread.currentThread().getContextClassLoader().getResource("")
銆銆寰楀埌鐨勪篃鏄綋鍓岰lassPath鐨勭粷瀵筓RI璺緞
銆銆濡傦細file:/D:/eclipse/springTest/WebRoot/WEB-INF/classes/
銆銆4.DebitNoteAction.class.getClassLoader().getResource("") 鎴朇lassLoader.getSystemResource("")
銆銆寰楀埌鐨勪篃鏄綋鍓岰lassPath鐨勭粷瀵筓RI璺緞銆?/p>
銆銆濡傦細file:/D:/eclipse/springTest/WebRoot/WEB-INF/classes/
銆銆5.鍙栧緱鏈嶅姟鍣ㄧ浉瀵硅礬寰?/p>
銆銆System.getProperty("user.dir")
銆銆渚嬪:E:\apache-tomcat-5.5.16\apache-tomcat-5.5.16\bin
銆銆鎴戞帹鑽愪嬌鐢═hread.currentThread().getContextClassLoader().getResource("")鏉ュ緱鍒板綋鍓嶇殑classpath鐨勭粷瀵硅礬寰勭殑URI琛ㄧず娉?/p>
銆銆6.鍙栧緱欏圭洰涓殑緇濆璺緞
銆銆涓鑸敤request.getRealPath("/")鎴杛equest.getRealPath("/config/")
銆銆浣嗙幇鍦ㄤ笉鎻愬′嬌鐢╮equest.getRealPath("/")浜嗭紝澶у鍙瘯鐢⊿ervletContext.getRealPath("/")鏂規硶寰楀埌Web搴旂敤紼嬪簭鐨勬牴鐩綍鐨勭粷瀵硅礬寰?/p>
銆銆瑕佸彇寰梥rc鐨勬枃浠墮潪甯稿鏄擄紝鍥犱負src鏄粯璁ょ殑鐩稿鐩綍錛屾瘮濡備綘璇磋鍙栧緱src涓媍om鐩綍鐨則est.java鏂囦歡錛屼綘鍙渶瑕佽繖鏍峰氨澶熶簡
銆銆File f = new File(com/test.java);
銆銆浣嗗鏋滄垜瑕佸彇寰椾笉鍦╯rc鐩綍鎴栬匴ebRoot鐩綍涓嬬殑鏂囦歡鍛紝鑰屾槸瑕佷粠src鎴栬匴ebRoot鍚岀駭鐨勭洰褰曚腑鍙栧憿錛屾瘮濡傝doc鍚?/p>
銆銆鎴戠殑紜柟娉曟槸榪欐牱瀹炵幇鐨勶細
銆銆String path = this.getServletContext().getRealPath("/");
銆銆Properties p = new Properties();
銆銆p.load(new FileInputStream(new File(path.substring(0,(path.lastIndexOf("\\WebRoot") + 1)) + "doc/db.properties")));
銆銆System.out.println(p.getProperty("driverName"));
]]>
The Commons Lang Package
Description
榪欎釜鍖呭寮轟簡鏍囧噯jdk鐨刯ava.lang鍖咃紝閲嶇敤鎬у緢楂樸?p>欏跺眰鐨勫寘閲岄潰鍖呭惈浜嗕竴浜涘伐鍏風被錛屽悓鏃朵竴浜涘瓙鍖呴噷闈紝鍖呭惈浜唌ath,concurrent鍜宐uilder銆備嬌鐢ㄨ繖浜涘伐鍏風被寰堟柟渚褲傚瓙鍖呬腑鍙兘鍖呭惈涓浜涢渶瑕佸疄鐜扮殑鍊熷彛鍜岀被銆備粬浠洿鍍忎簡鍏ㄥ眬鐨勫姛鑳藉疄鐜般?br />Lang 3.0 is JDK 1.5+; before that Lang was JDK 1.2+. In both cases you can find features of later JDKs being maintained by us and likely to be removed or modified in favour of the JDK in the next major version. Note that Lang 3.0 uses a different package than its predecessors, allowing it to be used at the same time as an earlier version.
Lang 3.0闇瑕乯dk 1.5+錛屼箣鍓嶇殑鐗堟湰鍙渶瑕?.2+銆?br />
You will find deprecated methods as you stroll through the Lang documentation. These are removed in the next major version.
Before we begin, it's a good time to mention the Utils classes. They all contain empty public constructors with warnings not to use. This may seem an odd thing to do, but it allows tools like Velocity to access the class as if it were a bean. In other words, yes we know about private constructors and have chosen not to use them.
lang3.*
String manipulation - StringUtils, StringEscapeUtils, RandomStringUtils, Tokenizer, WordUtils
Lang has a series of String utilities. The first is StringUtils, oodles and oodles of functions which tweak, transform, squeeze and cuddle java.lang.Strings. In addition to StringUtils, there are a series of other String manipulating classes; RandomStringUtils, StringEscapeUtils and Tokenizer. RandomStringUtils speaks for itself. It's provides ways in which to generate pieces of text, such as might be used for default passwords. StringEscapeUtils contains methods to escape and unescape Java, JavaScript, HTML, XML and SQL. Tokenizer is an improved alternative to java.util.StringTokenizer.
These are ideal classes to start using if you're looking to get into Lang. StringUtils' capitalize, substringBetween/Before/After, split and join are good methods to begin with. If you use java.sql.Statements a lot, StringEscapeUtils.escapeSql might be of interest.
In addition to these classes, WordUtils is another String manipulator. It works on Strings at the word level, for example WordUtils.capitalize will capitalize every word in a piece of text. WordUtils also contains methods to wrap text.
Character handling - CharSetUtils, CharSet, CharRange, CharUtils
In addition to dealing with Strings, it's also important to deal with chars and Characters. CharUtils exists for this purpose, while CharSetUtils exists for set-manipulation of Strings. Be careful, although CharSetUtils takes an argument of type String, it is only as a set of characters. For example, CharSetUtils.delete("testtest", "tr") will remove all t's and all r's from the String, not just the String "tr".
CharRange and CharSet are both used internally by CharSetUtils, and will probaby rarely be used.
JVM interaction - SystemUtils, CharEncoding
SystemUtils is a simple little class which makes it easy to find out information about which platform you are on. For some, this is a necessary evil. It was never something I expected to use myself until I was trying to ensure that Commons Lang itself compiled under JDK 1.2. Having pushed out a few JDK 1.3 bits that had slipped in (Collections.EMPTY_MAP is a classic offender), I then found that one of the Unit Tests was dying mysteriously under JDK 1.2, but ran fine under JDK 1.3. There was no obvious solution and I needed to move onwards, so the simple solution was to wrap that particular test in a if(SystemUtils.isJavaVersionAtLeast(1.3f)) {, make a note and move on.
The CharEncoding class is also used to interact with the Java environment and may be used to see which character encodings are supported in a particular environment.
Serialization - SerializationUtils, SerializationException
Serialization doesn't have to be that hard! A simple util class can take away the pain, plus it provides a method to clone an object by unserializing and reserializing, an old Java trick.
Assorted functions - ObjectUtils, ClassUtils, ArrayUtils, BooleanUtils
Would you believe it, ObjectUtils contains handy functions for Objects, mainly null-safe implementations of the methods on java.lang.Object.
ClassUtils is largely a set of helper methods for reflection. Of special note are the comparators hidden away in ClassUtils, useful for sorting Class and Package objects by name; however they merely sort alphabetically and don't understand the common habit of sorting java and javax first.
Next up, ArrayUtils. This is a big one with many methods and many overloads of these methods so it is probably worth an in depth look here. Before we begin, assume that every method mentioned is overloaded for all the primitives and for Object. Also, the short-hand 'xxx' implies a generic primitive type, but usually also includes Object.
- ArrayUtils provides singleton empty arrays for all the basic types. These will largely be of use in the Collections API with its toArray methods, but also will be of use with methods which want to return an empty array on error.
- add(xxx[], xxx) will add a primitive type to an array, resizing the array as you'd expect. Object is also supported.
- clone(xxx[]) clones a primitive or Object array.
- contains(xxx[], xxx) searches for a primitive or Object in a primitive or Object array.
- getLength(Object) returns the length of any array or an IllegalArgumentException if the parameter is not an array. hashCode(Object), equals(Object, Object), toString(Object)
- indexOf(xxx[], xxx) and indexOf(xxx[], xxx, int) are copies of the classic String methods, but this time for primitive/Object arrays. In addition, a lastIndexOf set of methods exists.
- isEmpty(xxx[]) lets you know if an array is zero-sized or null.
- isSameLength(xxx[], xxx[]) returns true if the arrays are the same length.
- Along side the add methods, there are also remove methods of two types. The first type remove the value at an index, remove(xxx[], int), while the second type remove the first value from the array, remove(xxx[], xxx).
- Nearing the end now. The reverse(xxx[]) method turns an array around.
- The subarray(xxx[], int, int) method splices an array out of a larger array.
- Primitive to primitive wrapper conversion is handled by the toObject(xxx[]) and toPrimitive(Xxx[]) methods.
Lastly, ArrayUtils.toMap(Object[]) is worthy of special note. It is not a heavily overloaded method for working with arrays, but a simple way to create Maps from literals.
Using toMap
Map colorMap = MapUtils.toMap(new String[][] {{
{"RED", "#FF0000"},
{"GREEN", "#00FF00"},
{"BLUE", "#0000FF"}
});
Our final util class is BooleanUtils. It contains various Boolean acting methods, probably of most interest is the BooleanUtils.toBoolean(String) method which turns various positive/negative Strings into a Boolean object, and not just true/false as with Boolean.valueOf.
Flotsam - BitField, Validate
On reaching the end of our package, we are left with a couple of classes that haven't fit any of the topics so far.
The BitField class provides a wrapper class around the classic bitmask integer, whilst the Validate class may be used for assertions (remember, we support Java 1.2).
lang3.builder.*
When you write a hashcode, do you check Bloch's Effective Java? No? You just hack in a quick number? Well HashCodeBuilder will save your day. It, and its buddies (EqualsBuilder, CompareToBuilder, ToStringBuilder), take care of the nasty bits while you focus on the important bits, like which fields will go into making up the hashcode.
lang3.math.*
Although Commons-Math also exists, some basic mathematical functions are contained within Lang. These include classes to a Fraction class, various utilities for random numbers, and the flagship class, NumberUtils which contains a handful of classic number functions.
There are two aspects of this package I would like to highlight. The first is NumberUtils.createNumber(String), a method which does its best to convert a String into a Number object. You have no idea what type of Number it will return, so you should call the relevant xxxValue method when you reach the point of needing a number. NumberUtils also has a related isNumber method.
lang3.mutable.*
New in 2.1, the mutable package provides mutable wrappers for primitive values (such as int, long, etc.) and Object. These wrappers are simiar to the wrappers provided by the Java API, but allow the wrapped value to be changed without needing to create a separate wrapper object.
lang3.text.*
The text package was added in Lang 2.2. It provides, amongst other classes, a replacement for StringBuffer named StrBuilder, a class for substituting variables within a String named StrSubstitutor and a replacement for StringTokenizer named StrTokenizer. While somewhat ungainly, the Str prefix has been used to ensure we don't clash with any current or future standard Java classes.
lang3.time.*
Lang 2.0 saw the arrival of a time package. It contains some basic utilities for manipulating time (a delorean, police box and grandfather clock?). These include a StopWatch for simple performance measurements and an optimised FastDateFormat class.
New in Lang 2.1 is the DurationFormatUtils class, which provides various methods for formatting durations.
lang3.concurrent.*
In Lang 3.0 a new concurrent package was introduced containing interfaces and classes to support programming with multiple threads. Its aim is to serve as an extension of the java.util.concurrent package of the JDK.
Concurrent initializers
A group of classes deals with the correct creation and initialization of objects that are accessed by multiple threads. All these classes implement the ConcurrentInitializer interface which provides just a single method:
public interface ConcurrentInitializer<T> {
T get() throws ConcurrentException;
}
A ConcurrentInitializer produces an object. By calling the get() method the object managed by the initializer can be obtained. There are different implementations of the interface available addressing various use cases:
ConstantInitializer is a very straightforward implementation of the ConcurrentInitializer interface: An instance is passed an object when it is constructed. In its get() method it simply returns this object. This is useful, for instance in unit tests or in cases when you want to pass a specific object to a component which expects a ConcurrentInitializer.
The LazyInitializer class can be used to defer the creation of an object until it is actually used. This makes sense, for instance, if the creation of the object is expensive and would slow down application startup or if the object is needed only for special executions. LazyInitializer implements the double-check idiom for an instance field as discussed in Joshua Bloch's "Effective Java", 2nd edition, item 71. It uses volatile fields to reduce the amount of synchronization. Note that this idiom is appropriate for instance fields only. For static fields there are superior alternatives.
We provide an example use case to demonstrate the usage of this class: A server application uses multiple worker threads to process client requests. If such a request causes a fatal error, an administrator is to be notified using a special messaging service. We assume that the creation of the messaging service is an expensive operation. So it should only be performed if an error actually occurs. Here is where LazyInitializer comes into play. We create a specialized subclass for creating and initializing an instance of our messaging service. LazyInitializer declares an abstract initialize() method which we have to implement to create the messaging service object:
public class MessagingServiceInitializer
extends LazyInitializer<MessagingService> {
protected MessagingService initialize() throws ConcurrentException {
// Do all necessary steps to create and initialize the service object
MessagingService service = ...
return service;
}
}
Now each server thread is passed a reference to a shared instance of our new MessagingServiceInitializer class. The threads run in a loop processing client requests. If an error is detected, the messaging service is obtained from the initializer, and the administrator is notified:
public class ServerThread implements Runnable {
/** The initializer for obtaining the messaging service. */
private final ConcurrentInitializer<MessagingService> initializer;
public ServerThread(ConcurrentInitializer<MessagingService> init) {
initializer = init;
}
public void run() {
while (true) {
try {
// wait for request
// process request
} catch (FatalServerException ex) {
// get messaging service
try {
MessagingService svc = initializer.get();
svc.notifyAdministrator(ex);
} catch (ConcurrentException cex) {
cex.printStackTrace();
}
}
}
}
}
The AtomicInitializer class is very similar to LazyInitializer. It serves the same purpose: to defer the creation of an object until it is needed. The internal structure is also very similar. Again there is an abstract initialize() method which has to be implemented by concrete subclasses in order to create and initialize the managed object. Actually, in our example above we can turn the MessagingServiceInitializer into an atomic initializer by simply changing the extends declaration to refer to AtomicInitializer<MessagingService> as super class.
The difference between AtomicInitializer and LazyInitializer is that the former uses classes from the java.util.concurrent.atomic package for its implementation (hence the name). This has the advantage that no synchronization is needed, thus the implementation is usually more efficient than the one of the LazyInitializer class. However, there is one drawback: Under high load, if multiple threads access the initializer concurrently, it is possible that the initialize() method is invoked multiple times. The class guarantees that get() always returns the same object though; so objects created accidently are immideately discarded.
With AtomicSafeInitializer there is yet another variant implementing the lazy initializing pattern. Its implementation is close to AtomicInitializer; it also uses atomic variables internally and therefore does not need synchronization. The name "Safe" is derived from the fact that it implements an additional check which guarantees that the initialize() method is called only once. So it behaves exactly in the same way as LazyInitializer.
Now, which one of the lazy initializer implementations should you use? First of all we have to state that is is problematic to give general recommendations regarding the performance of these classes. The initializers make use of low-level functionality whose efficiency depends on multiple factors including the target platform and the number of concurrent threads. So developers should make their own benchmarks in scenarios close to their specific use cases. The following statements are rules of thumb which have to be verified in practice.
AtomicInitializer is probably the most efficient implementation due to its lack of synchronization and further checks. Its main drawback is that the initialize() method can be called multiple times. In cases where this is not an issue AtomicInitializer is a good choice. AtomicSafeInitializer and LazyInitializer both guarantee that the initialization method is called only once. Because AtomicSafeInitializer does not use synchronization it is probably slightly more efficient than LazyInitializer, but the concrete numbers might depend on the level of concurrency.
Another implementation of the ConcurrentInitializer interface is BackgroundInitializer. It is again an abstract base class with an initialize() method that has to be defined by concrete subclasses. The idea of BackgroundInitializer is that it calls the initialize() method in a separate worker thread. An application creates a background initializer and starts it. Then it can continue with its work while the initializer runs in parallel. When the application needs the results of the initializer it calls its get() method. get() blocks until the initialization is complete. This is useful for instance at application startup. Here initialization steps (e.g. reading configuration files, opening a database connection, etc.) can be run in background threads while the application shows a splash screen and constructs its UI.
As a concrete example consider an application that has to read the content of a URL - maybe a page with news - which is to be displayed to the user after login. Because loading the data over the network can take some time a specialized implementation of BackgroundInitializer can be created for this purpose:
public class URLLoader extends BackgroundInitializer<String> {
/** The URL to be loaded. */
private final URL url;
public URLLoader(URL u) {
url = u;
}
protected String initialize() throws ConcurrentException {
try {
InputStream in = url.openStream();
// read content into string
...
return content;
} catch (IOException ioex) {
throw new ConcurrentException(ioex);
}
}
}
An application creates an instance of URLLoader and starts it. Then it can do other things. When it needs the content of the URL it calls the initializer's get() method:
URL url = new URL("http://www.application-home-page.com/");
URLLoader loader = new URLLoader(url);
loader.start(); // this starts the background initialization
// do other stuff
...
// now obtain the content of the URL
String content;
try {
content = loader.get(); // this may block
} catch (ConcurrentException cex) {
content = "Error when loading URL " + url;
}
// display content
Related to BackgroundInitializer is the MultiBackgroundInitializer class. As the name implies, this class can handle multiplie initializations in parallel. The basic usage scenario is that a MultiBackgroundInitializer instance is created. Then an arbitrary number of BackgroundInitializer objects is added using the addInitializer() method. When adding an initializer a string has to be provided which is later used to obtain the result for this initializer. When all initializers have been added the start() method is called. This starts processing of all initializers. Later the get() method can be called. It waits until all initializers have finished their initialization. get() returns an object of type MultiBackgroundInitializer.MultiBackgroundInitializerResults. This object provides information about all initializations that have been performed. It can be checked whether a specific initializer was successful or threw an exception. Of course, all initialization results can be queried.
With MultiBackgroundInitializer we can extend our example to perform multiple initialization steps. Suppose that in addition to loading a web site we also want to create a JPA entity manager factory and read a configuration file. We assume that corresponding BackgroundInitializer implementations exist. The following example fragment shows the usage of MultiBackgroundInitializer for this purpose:
MultiBackgroundInitializer initializer = new MultiBackgroundInitializer();
initializer.addInitializer("url", new URLLoader(url));
initializer.addInitializer("jpa", new JPAEMFInitializer());
initializer.addInitializer("config", new ConfigurationInitializer());
initializer.start(); // start background processing
// do other interesting things in parallel
...
// evaluate the results of background initialization
MultiBackgroundInitializer.MultiBackgroundInitializerResults results =
initializer.get();
String urlContent = (String) results.getResultObject("url");
EntityManagerFactory emf =
(EntityManagerFactory) results.getResultObject("jpa");
...
The child initializers are added to the multi initializer and are assigned a unique name. The object returned by the get() method is then queried for the single results using these unique names.
If background initializers - including MultiBackgroundInitializer - are created using the standard constructor, they create their own ExecutorService which is used behind the scenes to execute the worker tasks. It is also possible to pass in an ExecutorService when the initializer is constructed. That way client code can configure the ExecutorService according to its specific needs; for instance, the number of threads available could be limited.
Utility classes
Another group of classes in the new concurrent package offers some generic functionality related to concurrency. There is the ConcurrentUtils class with a bunch of static utility methods. One focus of this class is dealing with exceptions thrown by JDK classes. Many JDK classes of the executor framework throw exceptions of type ExecutionException if something goes wrong. The root cause of these exceptions can also be a runtime exception or even an error. In typical Java programming you often do not want to deal with runtime exceptions directly; rather you let them fall through the hierarchy of method invocations until they reach a central exception handler. Checked exceptions in contrast are usually handled close to their occurrence. With ExecutionException this principle is violated. Because it is a checked exception, an application is forced to handle it even if the cause is a runtime exception. So you typically have to inspect the cause of the ExecutionException and test whether it is a checked exception which has to be handled. If this is not the case, the causing exception can be rethrown.
The extractCause() method of ConcurrentUtils does this work for you. It is passed an ExecutionException and tests its root cause. If this is an error or a runtime exception, it is directly rethrown. Otherwise, an instance of ConcurrentException is created and initialized with the root cause. (ConcurrentException is a new exception class in the o.a.c.l.concurrent package.) So if you get such a ConcurrentException, you can be sure that the original cause for the ExecutionException was a checked exception. For users who prefer runtime exceptions in general there is also an extractCauseUnchecked() method which behaves like extractCause(), but returns the unchecked exception ConcurrentRuntimeException instead.
In addition to the extractCause() methods there are corresponding handleCause() methods. These methods extract the cause of the passed in ExecutionException and throw the resulting ConcurrentException or ConcurrentRuntimeException. This makes it easy to transform an ExecutionException into a ConcurrentException ignoring unchecked exceptions:
Future<Object> future = ...;
try {
Object result = future.get();
...
} catch (ExecutionException eex) {
ConcurrentUtils.handleCause(eex);
}
There is also some support for the concurrent initializers introduced in the last sub section. The initialize() method is passed a ConcurrentInitializer object and returns the object created by this initializer. It is null-safe. The initializeUnchecked() method works analogously, but a ConcurrentException throws by the initializer is rethrown as a ConcurrentRuntimeException. This is especially useful if the specific ConcurrentInitializer does not throw checked exceptions. Using this method the code for requesting the object of an initializer becomes less verbose. The direct invocation looks as follows:
ConcurrentInitializer<MyClass> initializer = ...;
try {
MyClass obj = initializer.get();
// do something with obj
} catch (ConcurrentException cex) {
// exception handling
}
Using the initializeUnchecked() method, this becomes:
ConcurrentInitializer<MyClass> initializer = ...;
MyClass obj = ConcurrentUtils.initializeUnchecked(initializer);
// do something with obj
Another utility class deals with the creation of threads. When using the Executor framework new in JDK 1.5 the developer usually does not have to care about creating threads; the executors create the threads they need on demand. However, sometimes it is desired to set some properties of the newly created worker threads. This is possible through the ThreadFactory interface; an implementation of this interface has to be created and pased to an executor on creation time. Currently, the JDK does not provide an implementation of ThreadFactory, so one has to start from scratch.
With BasicThreadFactory Commons Lang has an implementation of ThreadFactory that works out of the box for many common use cases. For instance, it is possible to set a naming pattern for the new threads, set the daemon flag and a priority, or install a handler for uncaught exceptions. Instances of BasicThreadFactory are created and configured using the nested Builder class. The following example shows a typical usage scenario:
BasicThreadFactory factory = new BasicThreadFactory.Builder()
.namingPattern("worker-thread-%d")
.daemon(true)
.uncaughtExceptionHandler(myHandler)
.build();
ExecutorService exec = Executors.newSingleThreadExecutor(factory);
The nested Builder class defines some methods for configuring the new BasicThreadFactory instance. Objects of this class are immutable, so these attributes cannot be changed later. The naming pattern is a string which can be passed to String.format(). The placeholder %d is replaced by an increasing counter value. An instance can wrap another ThreadFactory implementation; this is achieved by calling the builder's wrappedFactory() method. This factory is then used for creating new threads; after that the specific attributes are applied to the new thread. If no wrapped factory is set, the default factory provided by the JDK is used.
Synchronization objects
The concurrent package also provides some support for specific synchronization problems with threads.
TimedSemaphore allows restricted access to a resource in a given time frame. Similar to a semaphore, a number of permits can be acquired. What is new is the fact that the permits available are related to a given time unit. For instance, the timed semaphore can be configured to allow 10 permits in a second. Now multiple threads access the semaphore and call its acquire() method. The semaphore keeps track about the number of granted permits in the current time frame. Only 10 calls are allowd; if there are further callers, they are blocked until the time frame (one second in this example) is over. Then all blocking threads are released, and the counter of available permits is reset to 0. So the game can start anew.
What are use cases for TimedSemaphore? One example is to artificially limit the load produced by multiple threads. Consider a batch application accessing a database to extract statistical data. The application runs multiple threads which issue database queries in parallel and perform some calculation on the results. If the database to be processed is huge and is also used by a production system, multiple factors have to be balanced: On one hand, the time required for the statistical evaluation should not take too long. Therefore you will probably use a larger number of threads because most of its life time a thread will just wait for the database to return query results. On the other hand, the load on the database generated by all these threads should be limited so that the responsiveness of the production system is not affected. With a TimedSemaphore object this can be achieved. The semaphore can be configured to allow e.g. 100 queries per second. After these queries have been sent to the database the threads have to wait until the second is over - then they can query again. By fine-tuning the limit enforced by the semaphore a good balance between performance and database load can be established. It is even possible to change the number of available permits at runtime. So this number can be reduced during the typical working hours and increased at night.
The following code examples demonstrate parts of the implementation of such a scenario. First the batch application has to create an instance of TimedSemaphore and to initialize its properties with default values:
TimedSemaphore semaphore = new TimedSemaphore(1, TimeUnit.SECONDS, 100);
Here we specify that the semaphore should allow 100 permits in one second. This is effectively the limit of database queries per second in our example use case. Next the server threads issuing database queries and performing statistical operations can be initialized. They are passed a reference to the semaphore at creation time. Before they execute a query they have to acquire a permit.
public class StatisticsTask implements Runnable {
/** The semaphore for limiting database load. */
private final TimedSemaphore semaphore;
public StatisticsTask(TimedSemaphore sem, Connection con) {
semaphore = sem;
...
}
/**
* The main processing method. Executes queries and evaluates their results.
*/
public void run() {
try {
while (!isDone()) {
semaphore.acquire(); // enforce the load limit
executeAndEvaluateQuery();
}
} catch (InterruptedException iex) {
// fall through
}
}
}
The important line here is the call to semaphore.acquire(). If the number of permits in the current time frame has not yet been reached, the call returns immediately. Otherwise, it blocks until the end of the time frame. The last piece missing is a scheduler service which adapts the number of permits allowed by the semaphore according to the time of day. We assume that this service is pretty simple and knows only two different time slots: working shift and night shift. The service is triggered periodically. It then determines the current time slot and configures the timed semaphore accordingly.
public class SchedulerService {
/** The semaphore for limiting database load. */
private final TimedSemaphore semaphore;
...
/**
* Configures the timed semaphore based on the current time of day. This
* method is called periodically.
*/
public void configureTimedSemaphore() {
int limit;
if (isWorkshift()) {
limit = 50; // low database load
} else {
limit = 250; // high database load
}
semaphore.setLimit(limit);
}
}
With the setLimit() method the number of permits allowed for a time frame can be changed. There are some other methods for querying the internal state of a timed semaphore. Also some statistical data is available, e.g. the average number of acquire() calls per time frame. When a timed semaphore is no more needed, its shutdown() method has to be called.
]]>
- 閬靛驚鏈浣沖疄璺碉紝綆鍗曠殑寤虹珛欏圭洰-鍦ㄥ垎縐掍箣闂村緩绔嬩竴涓柊鐨勯」鐩垨鑰呮ā鍧椼?br />
- 鍦ㄥ涓」鐩箣闂寸粺涓浣跨敤銆?br />
- 渚濋檮鐜鐨勭鐞嗭紝鍖呮嫭鑷姩鐨勫崌綰с?br />
- 鏂逛究鍦板湪鍚屼竴鏃墮棿鍙傚姞澶氫釜欏圭洰銆?br />
- 澶т笖涓嶆柇澧為暱鐨勫簱鍜屽厓鏁版嵁鍙緵椋熺敤銆?br />
- 鍙墿灞曪紝鐢╦ava鎴栬剼鏈璦寮鍙戞彃浠?br />
- 鍔犲叆鏂扮殑鍔熻兘鍙渶瑕佸緢灝戞垨涓嶉渶瑕侀澶栫殑閰嶇疆
- Ant浠誨姟鏀寔渚濋檮鐜綆＄悊錛屽湪Maven涔嬪榪涜鍙戝竷銆?/li>
- 鍦ㄥぇ澶氭暟鎯呭喌涓嬶紝maven涓嶉渶瑕佽剼鏈氨鍙互緙栬瘧澶氫釜欏圭洰錛屾墦鍖呮垚jar, war鎴栧熀浜庡厓鏁版嵁榪涜欏圭洰鍙戝竷
- 娓呮櫚鐨勯」鐩俊鎭細Maven鑳藉寤虹珛涓涓珯鐐規垨PDF鏂囨。錛屽叾涓寘鎷」鐩殑涓浜涘熀鏈俊鎭拰鎶ヨ〃銆?br />
- 鐗堟湰綆＄悊鍜岄」鐩彂甯冿細涓嶉渶瑕佸お澶氱殑棰濆閰嶇疆錛宮aven浼氬拰浣犵殑浠ｇ爜綆＄悊鍣ㄦ暣鍚堬紝鐒跺悗鍩轟簬涓瀹氱殑tag,鏉ュ府鍔╃鐞嗕綘鐨勭増鏈傚畠涔熷彲浠ヤ負鍏朵粬鐨勯」鐩彂甯冨埌涓涓湴鏂廣俶aven涔熸敮鎸佸彂甯冩垚jar鎴栧叾浠栧綊妗ｇ殑鏂囦歡鎴栨槸婧愪唬鐮併?br />
- 渚濋檮綆＄悊錛歮aven寤鴻闆嗕腑綆＄悊jar搴撱傞」鐩鎴峰彲浠ュ埌闆嗕腑鐨刯ar搴撲腑涓嬭澆浠諱綍鍖呫傝繖鍏佽maven鐢ㄦ埛鍙互鍦ㄥ涓」鐩腑鍏敤jar錛屽茍榧撳姳欏圭洰涔嬮棿鐨勪氦嫻併?/li>
Maven濡備綍甯姪鏀硅繘鎴戜滑鐨勫紑鍙戣繃紼嬶紵
閫氳繃鏍囧噯鐨勭害瀹氬拰瀹炶返Maven瀵逛綘鐨刡uild嫻佺▼鎻愪緵甯姪錛屽姞閫熶綘鐨勫紑鍙戝懆鏈熷茍鍚屾椂甯姪浣犵殑欏圭洰鎴愬姛銆?p>涓嬮潰鎴戜滑鎻愪緵涓浜涗緥瀛愯浣犳潵榪愯maven錛?br />濡備綍寤虹珛Maven?
鍩烘湰涓婏紝maven榛樿鐨勯厤緗凡緇忚凍澶熼潰瀵瑰ぇ閮ㄥ垎鎯呭喌浜嗭紝浣嗘槸濡傛灉浣犻渶瑕佷慨鏀圭紦瀛樼瓥鐣ユ垨鑰呰緗甴ttp浠ｇ悊錛屼綘灝遍渶瑕佽嚜宸卞緩绔嬩竴涓厤緗傝緇嗚鍙傝?a >Guide to Configuring Maven銆?/p>
濡備綍寤虹珛鎴戠殑絎竴涓猰aven欏圭洰錛?/a>
鎴戜滑浼氫嬌鐢╩aven鐨刟rchetype 鏈哄埗鏉ュ緩绔嬫垜浠殑絎竴涓猰aven欏圭洰銆俶aven涓紝archetype鏄」鐩ā鐗堬紝鍦ㄥ姞涓婁竴浜涚敤鎴風殑杈撳叆鏉ュ緩绔嬩竴涓猰aven鐨勯」鐩傛垜浠細鍚戜綘灞曠ずarchetype鏈哄埗濡備綍宸ヤ綔銆傛洿澶氳鍙傝?p>鍒涘緩鏈綆鍗曠殑maven欏圭洰錛屽彧闇瑕佹墽琛屼笅闈㈢殑鍛戒護灝卞彲浠ヤ簡
mvn archetype:generate \ -DarchetypeGroupId=org.apache.maven.archetypes \ -DgroupId=com.mycompany.app \ -DartifactId=my-app
鎵ц鍛戒護鍚庯紝棣栧厛錛屼綘浼氬彂鐜頒竴涓彨my-app鐨勬枃浠跺す寤虹珛浜嗭紝鍏朵腑鏈塸om.xml鏂囦歡錛屽唴瀹瑰涓嬶細
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
pom.xml閲屾湁欏圭洰鐨刾roject object model銆俻om鏄痬aven鐨勫熀鏈伐浣滃崟鍏冦俆his is important to remember because Maven is inherently project-centric in that everything revolves around the notion of a project. 綆鍗曠殑璇達紝pom鍖呭惈浜嗘墍鏈夐」鐩殑閲嶈淇℃伅銆傛洿澶氳鍙傝?a >Introduction to the POM.
This is a very simple POM but still displays the key elements every POM contains, so let's walk through each of them
to familiarize you with the POM essentials:
- project This is the top-level element in all Maven pom.xml files.
- modelVersion This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model.
- groupId This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plug-ins.
- artifactId This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form <artifactId>-<version>.<extension> (for example, myapp-1.0.jar).
- packaging This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). This not only means if the artifact produced is JAR, WAR, or EAR but can also indicate a specific lifecycle to use as part of the build process. (The lifecycle is a topic we will deal with further on in the guide. For now, just keep in mind that the indicated packaging of a project can play a part in customizing the build lifecycle.) The default value for the packaging element is JAR so you do not have to specify this for most projects.
- version This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide.
- name This element indicates the display name used for the project. This is often used in Maven's generated documentation.
- url This element indicates where the project's site can be found. This is often used in Maven's generated documentation.
- description This element provides a basic description of your project. This is often used in Maven's generated documentation.
For a complete reference of what elements are available for use in the POM please refer to our POM Reference. Now let's get back to the project at hand.
After the archetype generation of your first project you will also notice that the following directory structure has been created:
my-app |-- pom.xml `-- src |-- main | `-- java | `-- com | `-- mycompany | `-- app | `-- App.java `-- test `-- java `-- com `-- mycompany `-- app `-- AppTest.java
As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in ${basedir}/src/main/java and test sources reside in ${basedir}/src/test/java, where ${basedir} represents the directory containing pom.xml).
If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a Maven convention and to learn more about it you can read our Introduction to the Standard Directory Layout.
Now that we have a POM, some application sources, and some test sources you are probably asking ...
]]>
]]>
1.http://code.google.com/p/visualswing4eclipse/
2涓敤浜嶫2SE swing涔嬬被鐨勬闈㈢紪紼嬨?br />
2. doxygen http://www.stack.nl/~dimitri/doxygen/
鑳芥牴鎹」鐩殑婧愭枃浠訛紝鑷姩鐢熸垚姣旇緝瀹屾暣鐨勬枃妗ｏ紝鍖呮嫭綾誨眰嬈″浘
3. open explorer http://blog.samsonis.me/2009/02/open-explorer-plugin-for-eclipse/
鍙互鍦╡clipse涓瘮杈冩柟渚跨殑鎵撳紑鏈湴鏂囦歡澶?/div>
]]>
Internet Explorer error "connection timed out" when server does not respond
闂寰楀埌瑙ｅ喅銆?br />鍏跺疄鍙互璇撮棶棰樻棤娉曞緱鍒拌В鍐熾傛垜鎬庝箞鍙兘璁╂瘡涓敤鎴峰幓淇敼浠栦滑鐨勬敞鍐岃〃涔堛?br />
鐪嬫潵鍙兘閲囧彇寮傛鐨勮姹傛柟寮忎簡銆?/span>
]]>
Actuate 綆鍗曟姤琛ㄧ殑寤虹珛榪囩▼
1錛?1. 鎵撳紑 e.report 閫夋嫨new report
2錛?2.閫夋嫨絀虹櫧鎶ヨ〃
3錛?3. 寤虹珛鏁版嵁搴撹繛鎺ャ?/span>Toolsà Database Connection
4錛?4. 濉啓鍙傛暟
5錛?5. 鍙屽嚮datasource , 濉啓鏌ヨ鍙傛暟
6錛?6. 閫変腑Content, Tool--銆?span style="font-family: Wingdings;"> Grouping, 璁劇疆鏁翠釜鎶ヨ〃鐨?/span>group錛?/span>1灞?/span>or n灞傘?/span>
7錛?7. 鍗曞嚮grouping option,璁劇疆group鐨勬樉紺猴紝鏄惁闇瑕?/span>befer,after絳夛紝姣忎釜group闇瑕佸崟鐙緗?/span>
8錛?nbsp; 8. 璁劇疆鍚勭欏甸潰鐨勬帶浠?/span>
9錛?9. 璁劇疆鍙傛暟錛岃繖浜涘弬鏁板彲浠ョ敤鍦ㄦ姤琛ㄦ帶鍒朵笂鎴栨槸鏌ヨ鐨勫弬鏁?/span>Tools -- Parameters
淇敼鍚庣殑鏌ヨ瀛楁
鍙傛暟10. 鐢ㄦ潵鎺у埗欏甸潰鏄劇ず
宸?/span>label涓轟緥瀛愶紝閲嶅啓OnRow鏂規硶
Super::OnRow( row )
if fundmode="M" then
me.Text = "Manual Fund Name"
else
me.Text = "Auto Fund Name"
end if
End Sub
11. 鐢?/span>datasource涓殑鏁版嵁鎺у埗欏甸潰
Super::OnRow( row )
If row.GetValue("DR_SHORT_FLAG") =0 Then
me.Text = "BUY BACK"
ElseIf row.GetValue("DR_SHORT_FLAG") =1 Then
me.Text = "Sell to Open"
End if
End Sub
]]>