Thursday, October 22, 2009
Thursday, October 15, 2009
Saturday, October 3, 2009
Wednesday, July 1, 2009
Monday, June 15, 2009
Wednesday, May 6, 2009
LDAP Intro
LDAP is standardized. The body of LDAP standards, including the network protocols, the directory structure, and the services provided by an LDAP server, are all available in the form of RFCs (Requests For Comments).
LDAP was designed to be a general-purpose directory server. It has not been designed with the purpose of capturing a specific type of data (like telephone numbers or email addresses). Instead, it was designed to give implementers the ability to define—clearly and carefully—what data the directory should store.
Such a generic directory server ought to be able to store many different kinds of information.
Let's continue with our comparison of a directory server and a phone book. A phone book contains a very specific type of information, organized in a very specific way, and designed to fulfil a very specific purpose. Here's an example phone book entry:
Acme Services
123 W. First St.
Chicago, IL 60616-1234
(773) 555-8943 or (800) 555 9834
As mentioned earlier, this sort of directory has specific information, organized in a specific way, designed to fulfill a specific purpose: it is information about how to contact a specific organization (Acme Services) organized in a familiar pattern (address and phone number). And it is designed so that a person, having a particular name in mind, can quickly scan through the directory (which is ordered alphabetically by organization name), and find the desired contact information.
But there are a few things to note about the phone book entry:
* The data is arranged for searching by only one value: the name of the organization. If you should happen to have the phone number of the organization, but not the name, searching the phone book for the matching telephone number in order to ascertain the name would be a taxing, and probably futile task.
* The format of the entry is sparse, and requires that the reader will be able to recognize the format and supply auxiliary information required for making sense of the data. One accustomed to reading phone book entries will be able to extrapolate from the previous entry, and identify the information this way:
Organization Name: Acme Services
Street Address: 123 West First Street
City: Chicago
State: Illinois
Postal Code: 60616-1234
Country: USA
Phone Number: +1 773 555 8943
Phone Number: +1 800 555 9834
In this example, the meaning of the information is made more explicit. Each value is preceded by a name that identifies the type of information given. Acme Services is now identified as the name of an organization. Information is also broken up into smaller chunks (city and state on separate lines), and some information which was implicit in the previous entry (such as the country) has been made explicit. And where two pieces of information (the two phone numbers) were initially compressed onto one line, they have now been separated, making the information more explicit.
This form of entry is closer to the way a record would look in an LDAP directory. But there is still another issue to address. How can we distinguish between two very similar records?
For example, say we have a telephone directory for the entire state of Illinois. And in Illinois, we have a company called Acme Services located in the city of Chicago, and another company named Acme Services located in the city of Springfield.
Simply knowing the company name alone is not sufficient information to isolate just one entry in the phone book. To do that, we would need some sort of unique name—a name that exists only once in the entire directory, and which can be used to refer to one specific entry.
A Unique Name: The DN
One way of distinguishing between two very similar records is to create a unique name for each record in the directory. This is the strategy adopted by LDAP; each record in the directory has a distinguished name. The distinguished name is an important LDAP term; usually it is abbreviated as DN.
In an LDAP directory, the directory designer is the one who decides what components will make up a DN, but typically the DN reflects where the record is in the directory (a concept we will examine in the next part), as well as some information that distinguishes this record from other near records.
A DN then, is composed of a combination of directory information, and looks something like this:
dn: o=Acme Services, l=Chicago, st=Illinois, c=US
This single identifier is sufficient to pick it out from the Springfield company by the same name. The DN of the Springfield company named Acme Services would, according to the previous scheme, look something like this:
dn: o=Acme Services, l=Springfield, st=Illinois, c=US
Some parts of LDAP records are case sensitive, and others are not. DNs, for example, are not case sensitive.
Let's take a specific look at what an LDAP entry looks like.
A LDAP entry is composed of a DN and one or more attributes. The DN serves as a unique identifier within an LDAP directory information tree. Attributes provide information about that entry. Let's convert our previous telephone directory entry into an LDAP record:
dn: o=Acme Services, l=Chicago, st=Illinois, c=US
o: Acme Services
postalAddress: 123 West First Street
l: Chicago
st: Illinois
postalCode: 60616-1234
c: US
telephoneNumber: +1 773 555 8943
telephoneNumber: +1 800 555 9834
objectclass: organization
The first line is the DN. All other lines in this record represent attributes.
These attribute names, like o and postalAddress, refer to well-defined attribute definitions contained in an LDAP schema. They cannot be "invented" on the fly, or made up as you go. Creating new attributes requires writing a schema.
An attribute describes a specific type of information. There are eight attributes here in our example, representing the following:
1. Organization Name (o)
2. Mailing address (postalAddress)
3. Locality (l), which may be the name of a city, town, village, and so forth
4. State or Province (st)
5. Postal Code or ZIP Code (postalCode)
6. Country (c)
7. Telephone Number (telephoneNumber)
8. Object Class (objectclass), which specifies what type (or types) of record this entry is
An attribute may have one or more attribute names, where these names are synonyms. For example c and countryName are both names for the attribute type that identify a country. Both identify the same information, and LDAP will treat the two names as describing the same type of information.
In any given record, an attribute may have one or more values (assuming the attribute's definition allows more than one value). The record above has only one attribute that contains more than one value. The telephoneNumber attribute has two values, each representing a different phone number.
Attribute names are not case sensitive. The attribute name o is treated as synonymous with the name O. Likewise, GivenName, givenname, and givenName are all evaluated as the same attribute name.
As for the values of attributes, case sensitivity depends on the attribute definition. For example, the values of DNs and objectclass attributes are not case sensitive, but a URI (labeledURI) attribute value is case sensitive.
The Object Class Attribute
The last attribute in the given record is the objectclass attribute. This is a special attribute that provides information about what type of record (or entry) this is.
An object class determines what attributes may be given to a record.
LDAP was designed to be a general-purpose directory server. It has not been designed with the purpose of capturing a specific type of data (like telephone numbers or email addresses). Instead, it was designed to give implementers the ability to define—clearly and carefully—what data the directory should store.
Such a generic directory server ought to be able to store many different kinds of information.
Let's continue with our comparison of a directory server and a phone book. A phone book contains a very specific type of information, organized in a very specific way, and designed to fulfil a very specific purpose. Here's an example phone book entry:
Acme Services
123 W. First St.
Chicago, IL 60616-1234
(773) 555-8943 or (800) 555 9834
As mentioned earlier, this sort of directory has specific information, organized in a specific way, designed to fulfill a specific purpose: it is information about how to contact a specific organization (Acme Services) organized in a familiar pattern (address and phone number). And it is designed so that a person, having a particular name in mind, can quickly scan through the directory (which is ordered alphabetically by organization name), and find the desired contact information.
But there are a few things to note about the phone book entry:
* The data is arranged for searching by only one value: the name of the organization. If you should happen to have the phone number of the organization, but not the name, searching the phone book for the matching telephone number in order to ascertain the name would be a taxing, and probably futile task.
* The format of the entry is sparse, and requires that the reader will be able to recognize the format and supply auxiliary information required for making sense of the data. One accustomed to reading phone book entries will be able to extrapolate from the previous entry, and identify the information this way:
Organization Name: Acme Services
Street Address: 123 West First Street
City: Chicago
State: Illinois
Postal Code: 60616-1234
Country: USA
Phone Number: +1 773 555 8943
Phone Number: +1 800 555 9834
In this example, the meaning of the information is made more explicit. Each value is preceded by a name that identifies the type of information given. Acme Services is now identified as the name of an organization. Information is also broken up into smaller chunks (city and state on separate lines), and some information which was implicit in the previous entry (such as the country) has been made explicit. And where two pieces of information (the two phone numbers) were initially compressed onto one line, they have now been separated, making the information more explicit.
This form of entry is closer to the way a record would look in an LDAP directory. But there is still another issue to address. How can we distinguish between two very similar records?
For example, say we have a telephone directory for the entire state of Illinois. And in Illinois, we have a company called Acme Services located in the city of Chicago, and another company named Acme Services located in the city of Springfield.
Simply knowing the company name alone is not sufficient information to isolate just one entry in the phone book. To do that, we would need some sort of unique name—a name that exists only once in the entire directory, and which can be used to refer to one specific entry.
A Unique Name: The DN
One way of distinguishing between two very similar records is to create a unique name for each record in the directory. This is the strategy adopted by LDAP; each record in the directory has a distinguished name. The distinguished name is an important LDAP term; usually it is abbreviated as DN.
In an LDAP directory, the directory designer is the one who decides what components will make up a DN, but typically the DN reflects where the record is in the directory (a concept we will examine in the next part), as well as some information that distinguishes this record from other near records.
A DN then, is composed of a combination of directory information, and looks something like this:
dn: o=Acme Services, l=Chicago, st=Illinois, c=US
This single identifier is sufficient to pick it out from the Springfield company by the same name. The DN of the Springfield company named Acme Services would, according to the previous scheme, look something like this:
dn: o=Acme Services, l=Springfield, st=Illinois, c=US
Some parts of LDAP records are case sensitive, and others are not. DNs, for example, are not case sensitive.
Let's take a specific look at what an LDAP entry looks like.
A LDAP entry is composed of a DN and one or more attributes. The DN serves as a unique identifier within an LDAP directory information tree. Attributes provide information about that entry. Let's convert our previous telephone directory entry into an LDAP record:
dn: o=Acme Services, l=Chicago, st=Illinois, c=US
o: Acme Services
postalAddress: 123 West First Street
l: Chicago
st: Illinois
postalCode: 60616-1234
c: US
telephoneNumber: +1 773 555 8943
telephoneNumber: +1 800 555 9834
objectclass: organization
The first line is the DN. All other lines in this record represent attributes.
These attribute names, like o and postalAddress, refer to well-defined attribute definitions contained in an LDAP schema. They cannot be "invented" on the fly, or made up as you go. Creating new attributes requires writing a schema.
An attribute describes a specific type of information. There are eight attributes here in our example, representing the following:
1. Organization Name (o)
2. Mailing address (postalAddress)
3. Locality (l), which may be the name of a city, town, village, and so forth
4. State or Province (st)
5. Postal Code or ZIP Code (postalCode)
6. Country (c)
7. Telephone Number (telephoneNumber)
8. Object Class (objectclass), which specifies what type (or types) of record this entry is
An attribute may have one or more attribute names, where these names are synonyms. For example c and countryName are both names for the attribute type that identify a country. Both identify the same information, and LDAP will treat the two names as describing the same type of information.
In any given record, an attribute may have one or more values (assuming the attribute's definition allows more than one value). The record above has only one attribute that contains more than one value. The telephoneNumber attribute has two values, each representing a different phone number.
Attribute names are not case sensitive. The attribute name o is treated as synonymous with the name O. Likewise, GivenName, givenname, and givenName are all evaluated as the same attribute name.
As for the values of attributes, case sensitivity depends on the attribute definition. For example, the values of DNs and objectclass attributes are not case sensitive, but a URI (labeledURI) attribute value is case sensitive.
The Object Class Attribute
The last attribute in the given record is the objectclass attribute. This is a special attribute that provides information about what type of record (or entry) this is.
An object class determines what attributes may be given to a record.
Tuesday, May 5, 2009
ADF security
Whenever one enables the security in an ADF web application one must always cross verify if jdev has generated "adf-config.xml" in the folder "web-project/.adf/META-INF"
from the docs "To enable Oracle ADF Security authorization, you create a configuration file named
more details of ADF xml can be found here.
from the docs "To enable Oracle ADF Security authorization, you create a configuration file named
adf-config.xml that sets the application's container to use Oracle ADF Security. The file initializes the ADFContext and SecurityContext."more details of ADF xml can be found here.
Tuesday, March 31, 2009
Tuesday, March 3, 2009
JSF and Error pages
Have been looking around for a general strategy that for adding an error page to an ADF Application. found there options
Option 1 : make html error pages for each type of exception
Option 2 : make one error page and generalized bean
Option 3 : Make one error page, One task flow for it , In all the managaed beans inside try catch do add return "error_page_task_flow"
Different approaches may be useful in different scenarious
Option 1 : make html error pages for each type of exception
Option 2 : make one error page and generalized bean
Option 3 : Make one error page, One task flow for it , In all the managaed beans inside try catch do add return "error_page_task_flow"
Different approaches may be useful in different scenarious
Sunday, March 1, 2009
why we cant mock static methods
This wasn't obvious to me at first, it took me a while to get why we can't mock static methods. So here it goes the reason in one line,
"Static methods aren't polymorphic, they are resolved at compile time, therefor it's not possible to use mock objects to test."
Hope this help you guys who are scratching your head like I was.... (if you are not sure about polymorphism, think of it as late binding)
In my previous posts i showed one of the ways you can mock static methods, but the limitation is that you need to know the implementation of the class. What if i am using another classes static method whose cource code i dont know.
for example : FacesContext fc = facesContext.getInstance();
"Static methods aren't polymorphic, they are resolved at compile time, therefor it's not possible to use mock objects to test."
Hope this help you guys who are scratching your head like I was.... (if you are not sure about polymorphism, think of it as late binding)
In my previous posts i showed one of the ways you can mock static methods, but the limitation is that you need to know the implementation of the class. What if i am using another classes static method whose cource code i dont know.
for example : FacesContext fc = facesContext.getInstance();
Mocking singletons and Factories
Mocking singletons ., factories may not be that obvious.
public class Singleton {
private Singleton instance = new Singleton ();
public static Singleton getInstance() {
return instance;
}
}
@Test
public void testSingleton() {
Field instanceField = Singleton .class.getField("instance");
instanceField.setAccessible(true);
Singleton realSingleton = instanceField.get(null);
Singleton mockSingleton = EasyMock.createMock(Singleton .class);
try {
instanceField.set(null, mockSingleton);
// now do your testing, Singleton.getInstance() should now return the mock
} finally {
instanceField.set(null, reallSingleton);
instanceField.setAccessible(false);
}
}
This is fairly hacky, not robust to changes in the singleton class, won't work with a security manager, and it may not work well in the case where the field is instantiated in a static initializer and other fields use that instance when they are initialized. But it probably will work in many cases.
public class Singleton {
private Singleton instance = new Singleton ();
public static Singleton getInstance() {
return instance;
}
}
@Test
public void testSingleton() {
Field instanceField = Singleton .class.getField("instance");
instanceField.setAccessible(true);
Singleton realSingleton = instanceField.get(null);
Singleton mockSingleton = EasyMock.createMock(Singleton .class);
try {
instanceField.set(null, mockSingleton);
// now do your testing, Singleton.getInstance() should now return the mock
} finally {
instanceField.set(null, reallSingleton);
instanceField.setAccessible(false);
}
}
This is fairly hacky, not robust to changes in the singleton class, won't work with a security manager, and it may not work well in the case where the field is instantiated in a static initializer and other fields use that instance when they are initialized. But it probably will work in many cases.
Monday, February 2, 2009
Difference between rebuild and make in jdeveloper
The difference is ...
Please note that in both cases the selection makes a difference:
- Rebuild is compiling all selected .java files, regardless if an up-to-date .class file is available or not
- Make is compiling those selected .java files for which no up-to-date .class file is available PLUS all .java files which are on the source path AND dependent on the selected .java files
Please note that in both cases the selection makes a difference:
- if your selection includes only .java files or packages, only files in the same project will be compiled
- if you select one or more projects, compilation will also include any projects which depend on the selected project(s). To prevent building a long list of dependend projects the latest builds of JDev offer the feature Build | Make
Only and Build | Rebuild Only, respectively.
Monday, January 26, 2009
Java Util package doesnt have a generic tree ?
Hi
Many a times developers say that java util package doesn't support a geveric java tree
the api does have
A generic tree can be written as here and here
Google created its own collections framework that is being used in many of its applications as explained in videos 1 and 2. the project can be downloaded from here.
Many a times developers say that java util package doesn't support a geveric java tree
the api does have
A generic tree can be written as here and here
Google created its own collections framework that is being used in many of its applications as explained in videos 1 and 2. the project can be downloaded from here.
Friday, January 23, 2009
Oracle doesnt support dirty read
more details at
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import oracle.jdbc.OracleStatement;
public class ConnectionClass {
public ConnectionClass() {
}
public Connection getConnection() throws ClassNotFoundException,
SQLException {
Class.forName("oracle.jdbc.driver.OracleDriver");
Connection con = DriverManager.getConnection(
"jdbc:oracle:thin:@hyc65003fwks.idc.oracle.com:1521:nn11g",
"scott","tiger");
con.setAutoCommit(false);
System.out.println("isolation lvl "+con.getTransactionIsolation());
con.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
return con;
}
public static void main(String[] args) throws ClassNotFoundException,
SQLException {
ConnectionClass obj = new ConnectionClass();
Connection con1 = obj.getConnection();
Connection con2 = obj.getConnection();
obj.doUpdate(con1);
obj.read(con2);
con1.rollback();
con1.close();
System.out.println("again reading.......");
obj.read(con2);
con2.close();
}
int i=0;
public void doUpdate(Connection con) throws SQLException {
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
i++;
String sql = "insert into delme values('aa"+i+"')";
System.out.println("sql >>>"+sql);
System.out.println(stmt.executeUpdate(sql));
stmt.close();
}
public void read(Connection con) throws SQLException {
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
String sql = "select * from delme";
System.out.println("sql >>>"+sql);
ResultSet rs = stmt.executeQuery(sql);
while(rs.next()) {
System.out.println(rs.getString(1));
}
rs.close();
stmt.close();
}
}
/* Exception in thread "main" java.sql.SQLException: READ_COMMITTED and SERIALIZABLE are the only valid transaction levels
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:110)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:171)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:227)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:439)
at oracle.jdbc.driver.PhysicalConnection.setTransactionIsolation(PhysicalConnection.java:3988)
at jdbcproj.ConnectionClass.getConnection(ConnectionClass.java:22)
at jdbcproj.ConnectionClass.main(ConnectionClass.java:29)
Process exited with exit code 1. */
Thursday, January 22, 2009
HashMap and null keys
most of us know a hashMap allows null keys and also null values , but what if we add two values corresponding to same null key
What will be the output of
System.out.println(map)
will for the null key it will print the last key value pair , i.e. as per my understanding the null key is unique and on adding more value elements to the same null key will override the old values
map.put(null,null);
map.put(null,"D");
map.put(null,"E");
What will be the output of
System.out.println(map)
will for the null key it will print the last key value pair , i.e.
Convert HashMap to HashTable
How will you convert a HashMap having null values and/or keys to a hash table ?
import java.util.HashMap;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
public class HashTableHashMap
{
public static void main(String[] args) {
Map map = new HashMap();
map.put("a",null);
map.put("b","B");
map.put(null,"D");
System.out.println(map);
Hashtable ht = new Hashtable();
Set set = map.entrySet();
Iterator itr = set.iterator();
while(itr.hasNext()){
Map.Entry entry = (Map.Entry)itr.next();
Object key = entry.getKey();
Object val = entry.getValue();
if(key==null){
key = ""+null; // Or whatever you want
}
if(val==null){
val = ""+null; // Or whatever you want
}
ht.put(key,val);
}
System.out.println(ht);
}
}
Monday, January 19, 2009
Monday, January 12, 2009
Tuesday, January 6, 2009
JSF page refresh
To refresh a JSF page the following piece of code is useful
FacesContext context = FacesContext.getCurrentInstance();
String viewId = context.getViewRoot().getViewId();
ViewHandler handler = context.getApplication().getViewHandler();
UIViewRoot root = handler.createView(context, viewId);
root.setViewId(viewId);
context.setViewRoot(root);
If your page is not getting refreshed due to browser caching
FacesContext context = FacesContext.getCurrentInstance();
String viewId = context.getViewRoot().getViewId();
ViewHandler handler = context.getApplication().getViewHandler();
UIViewRoot root = handler.createView(context, viewId);
root.setViewId(viewId);
context.setViewRoot(root);
If your page is not getting refreshed due to browser caching
FacesContext facesContext = event.getFacesContext();
HttpServletResponse response = (HttpServletResponse) facesContext.getExternalContext().getResponse();
response.addHeader("Pragma", "no-cache");
response.addHeader("Cache-Control", "no-cache");
response.setHeader("Cache-Control", "no-store");
response.addHeader("Cache-Control", "must-revalidate");
Monday, January 5, 2009
Data Structures
Few good links for Data Structures
- C API : http://code.google.com/p/c-generic-library/
- google collections : http://code.google.com/p/google-collections/
- java listenable collections : http://code.google.com/p/jalico/
- JRDF : http://code.google.com/p/jrdf/
- J5Collections : http://code.google.com/p/j5collections/
- Stanford video tutorial : http://in.youtube.com/view_play_list?p=84A56BC7F4A1F852
- Book : http://www.brpreiss.com/books/opus5/html/page257.html
- all slide handout from the textbook http://ww0.java4.datastructures.net/handouts/
- comparison of link implementation in java (ArrayList, Vector, LikedList) http://www.onjava.com/pub/a/onjava/2001/05/30/optimization.html?page=1
- time your execution program example http://www.rgagnon.com/javadetails/java-0132.html *in Java 5, you can also use nano Timing method.
- Queue in Java 5 http://www.devx.com/Java/Article/21983
- Josephus Problem http://en.wikipedia.org/wiki/Josephus_problem
- Pigeonhole principle http://en.wikipedia.org/wiki/Pigeonhole_principle
- Iterator Example http://www.particle.kth.se/~lindsey/JavaCourse/Book/Part1/Java/Chapter10/iterator.html or http://www.java-examples.com/iterate-through-elements-java-arraylist-using-iterator-example
- Tree in Java 5 http://it-essence.xs4all.nl/roller/technology/entry/three_tree_traversals_in_java
- Prime in Hash http://www.interactivecode.com/programming-coding-1/hashing-why-mod-prime-2101/
- Last 2 slides of ch9.2 page17-18ch09.2.pdf
Subscribe to:
Posts (Atom)