Openldap overlays

Resource --


http://www.zytrax.com/books/ldap/ch6/ppolicy.html

Weblogic Scripting Tool WLST

Resource

file:///F:/bea/weblogic92/samples/server/docs/core/index.html

Weblogic Node Manager importance

Resource

http://blogs.oracle.com/jamesbayer/2010/01/weblogic_nodemanager_quick_sta.html

GC Viewer tool to analyze gc logs

Resource --

http://www.javaperformancetuning.com/tools/gcviewer/index.shtml

Free TTS - Text To Speech library

http://www.linuxfromscratch.org/blfs/view/6.2.0/multimedia/freetts.html

CXF webservice

Resource--

http://www.jroller.com/gmazza/entry/web_service_tutorial

Unit Testing Servlets with Weblogic and Cactus

Resource

http://www.abcseo.com/papers/cactus-wl51.htm

Lunt Demo

link for lunt build demo --

http://demo.pmease.com/

Choosing the right Collection

Here is a guide for selecting the proper implementation of a Set, List, or Map. It was compiled for Java 1.4. Many additions have been made to the Collections Framework since then (notably the Queue and Deque interfaces, and various items in java.util.concurrent). These later additions have been omitted here, since this briefer summary should suffice for most cases.
The best general purpose or 'primary' implementations are likely ArrayList, LinkedHashMap, and LinkedHashSet. They are marked below as " * ". Their overall performance is better, and you should use them unless you need a special feature provided by another implementation. That special feature is usually ordering or sorting.
Here, "ordering" refers to the order of items returned by an Iterator, and "sorting" refers to sorting items according to Comparable or Comparator.
 

Interface	HasDuplicates?	Implementations					Historical
Set	no	HashSet	...	LinkedHashSet*	...	TreeSet	...
List	yes	...	ArrayList*	...	LinkedList	...	Vector, Stack
Map	no duplicate keys	HashMap	...	LinkedHashMap*	...	TreeMap	Hashtable, Properties

Principal features of non-primary implementations :

• HashMap has slightly better performance than LinkedHashMap, but its iteration order is undefined
• HashSet has slightly better performance than LinkedHashSet, but its iteration order is undefined
• TreeSet is ordered and sorted, but slow
• TreeMap is ordered and sorted, but slow
• LinkedList has fast adding to the start of the list, and fast deletion from the interior via iteration

Iteration order for above implementations :

• HashSet - undefined
• HashMap - undefined
• LinkedHashSet - insertion order
• LinkedHashMap - insertion order of keys (by default), or 'access order'
• ArrayList - insertion order
• LinkedList - insertion order
• TreeSet - ascending order, according to Comparable / Comparator
• TreeMap - ascending order of keys, according to Comparable / Comparator

For LinkedHashSet and LinkedHashMap, the re-insertion of an item does not affect insertion order. For LinkedHashMap, 'access order' is from the least recent access to the most recent access. In this context, only calls to get, put, and putAll constitute an access, and only calls to these methods affect access order.
While being used in a Map or Set, these items must not change state (hence, it is recommended that these items be immutable objects):

• keys of a Map
• items in a Set

Sorting requires either that :

• the stored items implement Comparable
• a Comparator for the stored objects be defined

To retain the order of a ResultSet as specified in an ORDER BY clause, insert the records into a List or a LinkedHashMap.


Resource

http://www.javapractices.com/topic/TopicAction.do?Id=65

Continuous Integration

Any Agile Project Manager worth his salt should be aware of the term ‘Continuous Integration’ (often shortened to ‘CI’). But what is it, and how is it done?
This series of short blog articles aims to answer these two questions, so you can start your next project, or re-configure an existing project, armed with the necessary understanding about this key practice within agile software delivery.
Background
The basic premise of CI is pretty straightforward. An agile team needs a repeatable and reliable method to create a build of the software under development. Why so? Well, if its not already obvious, you may want to revisit the principles behind the Agile Manifesto. Within them you will notice a number of references to ‘working software’, and the foundation of any working software is a stable, tested build.
Recipe for CI
So how does CI help to create this build? Lets list the essential ingredients that we need :

1. Source Code Control – in a typical agile project, developers turn User Stories into source code, in whatever programming language(s) the project is using. Once their work is at an appropriate level of completeness, they check-in or commit their work to the source code (a.k.a version) control system; for example, Subversion
2. Build Tool – if the source code needs to be compiled (e.g. Java or C++) then we will need tooling to support that. Modern Integrated Developer Environments (IDE), such as Eclipse or Visual Studio are able to perform this task as developers save source code files. But if we want to build the software independently of an IDE in an automated fashion, say on a server environment, we need an additional tool to do this. Examples of this type of tool are Ant, Maven and Rake and Make. These tools can also package a binary output from the build. For example, with Java projects this might be a JAR or WAR file – the deployable unit that represents the application being developed.
3. Test Tools – as part of the build process, in addition to compilation and the creation of binary outputs, we should also verify that (at minimum) the unit tests pass. For example, in Java these are often written using the JUnit automated unit testing framework. The tools in (2) often natively support the running of such tests, so they should always be executed during a build. In addition to unit testing, there are numerous other quality checks we can perform and status reports CI can produce. I’ll cover these in detail in a subsequent part to this series.
4. Schedule or Trigger – we might want to create our build according to a schedule (e.g ‘every afternoon’) or when there is a change in the state of the project source code. In the latter case we can set up a simple rule that triggers a build whenever a developer changes the state of the source code by committing his/her changes, as outlined in (1). This has the effect of ensuring that your teams work is continuously integrated to produce a stable build, and, as you may have guessed, is where this practice gets its name from.
5. Notifications – the team needs to know when a build fails, so it can respond and fix the issue. There are lots of ways to notify a team these days – instant messaging, Twitter etc, but the most common by far is still email.
Continuous Integration Recipe The tool that wires these five elements together is a Continuous Integration Server. It interacts with the source control system to obtain the latest revision of the code, launches the build tool (which also runs the unit tests) and notifies us of any failures. And it does this according to a schedule or state change based trigger. A CI server often also provides a web-based interface that allows a team to review the status, metrics and data associated with each build. CI Server options There is a pretty overwhelming choice of available tools in this space. Some are open source, some proprietary. I don’t have time to go into all the available options here unfortunately. However, there is a handy feature comparison matrix available here. Of course, it would be remiss of me not to mention our own hosted service, which allows you to get started with CI in no time at all, without having to be an ‘expert’ user. Resource -- http://www.theserverside.com/discussions/thread.tss?thread_id=60718