My Bread Basket

All you need to know about java annotations - brief

2010-05-22T04:24:00.000-07:00

1) What are annotations?

Annotations are tags (@) that you insert into your source code which acts as information to an external tool that process them.
Example:


   @Log(logLevel="Debug")
   public void someAPI(){...}

@Log is an annotation here which informs the external tool which processes @Log to start logging in debug mode when someAPI method is executed.

2) Why do we need Annotations?

Some of the uses of annotations could be
#) Provide information to the tools so that the tools can generate auxiliary files such as deployment descriptors.
#) Provide information to the tools so that the tools can automatically generate code for testing, logging, transaction, security etc.

3) How of Annotations?

#) Defining Annotations -
Considering the above log example, this is how @Log can be defined


import java.lang.annotations.*;

@Target (ElementType.METHOD)
@Retention (RetentionPolicy.RUNTIME)
public @interface Log
{
   String logLevel() default "info";
}

The @Target and @Retention are annotations provided to another annotations and hence called meta annotations.

@Target annotation helps in specifying the target element on which @Log annotation can be used. In this example the METHOD is used as the target which indicates that @Log is applicable to only methods in a class.

You can add annotations to the following items
# Packages
# Classes (including enums)
# Interfaces (including annotation interfaces)
# Methods
# Constructors
# Instance Fields
# Local Variables
# Parameter Variables

Example: -


public @interface BugReport
{
   enum Status {FIXED, NOTABUG};
   boolean showStopper() default false;
   String assignedTo() default "[None]";
   Status status() default Status.UNCONFIRMED;
   Reference ref() default @reference;
   String[] reportedBy();
   Class testCase() default Void.class
}

and annotation looks like this


@BugReport(showStoppre=true, assignedTo="xyz", testCase=TestClass.class,
          status=BugReport.Status.CONFIRMED, ...)

@Retention meta annotation specifies how long an annotation is retained. You can specify atmost one of the following values.

SOURCE - Annotatoins are not included in class file.
CLASS - Annotations are included in class file, but the virtual machine need not load them.
RUNTIME - Annotations are included in class file and loaded by the virtual machine. They are available throu the refelection API.

4) Annotation Processing

Annotation can be processed at three levels
#) In the source code [SOURCE]
You process annotation at the source level if you want to produce other source files, such as XML descriptor files, stubs/skeletons, remote interfaces etc. For source level annotations u need to parse java source file. Java provides an annotation process tool (apt) which processes annotations in source files and feeds them to annotation processor that you supply.

#) In bytecode files [CLASS]
If you want to process annotations at the bytecode level then you need to analyze class files. BCEL is the library which helps in processing class files and modifying class files. This type of processing can be used to modify class files to add byte codes for logging etc.
You can run a bytecode engineering tool in two modes.You can simply write a tool that
reads a class file, processes the annotations, injects the bytecodes, and writes the modified class file. Alternatively, you can defer the bytecode engineering until load time, when the class loader loads the class.

#) At Runtime, in the virtual machine [RUNTIME]
This is the easiest way of processing an annotation which can be done by reflection api's at runtime.

Two Entities to One Table mapping

2010-03-13T01:42:00.000-08:00

The picture below shows how two entities can be mapped to one single table -

Two Tables to One Entity mapping

2010-03-13T01:11:00.000-08:00

The picture below shows how two table can be mapped to one single entity -

Entity Relationship Cascade

2010-03-13T00:31:00.000-08:00

The table below shows the Entity Manager API used for cascading when you want to save entity relationship

Entity Manager Merge() Vs Persist()

2010-03-12T23:43:00.000-08:00

Like every one knows Persist is used to create a new entry and merge is normally used to update an already existing entry but the confusion begins when we realize that merge can also be used to create a new entry as well.

So the question is why do we have persist when merge can do both update and create entries?

Here it goes -

1) Performance and Memory
Persist will just dump the entity into the database but merge will have to first figure out if this entry exists in the database for it to make out if it is a create or a update scenario. Secondly merge will copy the passed object and will save the copied object into the database, so if the entity relationship is complex this copy procedure is more time consuming and a lil memory intensive.

2) RBAC
Some roles can only update few entries and may not be allowed to create new entries or viceversa, so to have a seggregation we have seperate apis for persist and merge.

Flush, Persist and Merge

2010-02-28T09:11:00.000-08:00

Flush

There are two flush modes -
1) Auto
2) Commit

Auto flush is the default which flushes [persists] the entities in the persistence context at the transaction commit time and also on every query executed with in a transaction. Exception to this is find() because if we want to find an entity which is modified then the find will return back the entity that is present in the persistence context. But if we execute a query then query doesnt return the whole entity but returns some fields as a list and this is the reason that thepersistence context is flushed during query execution.

Commit mode will flush the persistence context when the transaction commits.

We can force flush by calling the flush method on the entity manager to flush the persistence context.

Persist and Merge

Merge can persist but persist cannot merge.
When an entity is persisted and before even the transaction is not commited, we can get the primary key if the primary key is autogenerated using table strategy.

Persistence Context and Entity Manager

2010-02-28T06:53:00.000-08:00

Persistence Context is nothing but a bag that holds entities. Entity Manager contains persistence context and manages [creates, updates, deletes] the entities that are part of that persistence context. This is shown in the following figure

The life cycle of persistence context depends on whether it is transaction-scoped or extended persistence context.

Transaction-Scoped Persistence Context -

Transaction begins when the bean method is invoked and it ends when the method returns or completes. Similarly transaction-scoped persistence context follows the transaction and is created when the transaction begins and ends after the transaction commits or rolls back.

Extended Persistence Context -

This type of Persistence Context is independent of transaction i.e., the creation or destruction of persistence context is not dependent on transaction begin or transaction end as in the case of transaction-scoped persistence context. Persistence Context will be created when the statefull session bean is created and it is destroyed when the stateful session bean is destroyed.

Note:

There can be many instances of Entity Manager referring to the same single instance of persistence context if all these entity managers are part of the same transaction i.e., entity manager instances part of different ejb's invoked by an ejb which starts and ends the transaction. Please refer the picture below -

Reusable component template as given in the extjs.com documentation

2009-11-25T09:33:00.000-08:00

A Re-usable Template

The following is a template (based on the template posted by Jozef Sakalos in mjlecomte's forum post) that you can use as a starting-point when extending Ext.Component classes

MyComponent = Ext.extend(Ext.some.component, {
// Prototype Defaults, can be overridden by user's config object
propA: 1,

initComponent: function(){
   // Called during component initialization

   // Config object has already been applied to 'this' so properties can 
   // be overriden here or new properties (e.g. items, tools, buttons) 
   // can be added, eg:
   Ext.apply(this, {
       propA: 3
   });

   // Before parent code

   // Call parent (required)
   MyComponent.superclass.initComponent.apply(this, arguments);

   // After parent code
   // e.g. install event handlers on rendered component
},

// Override other inherited methods 
onRender: function(){

   // Before parent code

   // Call parent (required)
   MyComponent.superclass.onRender.apply(this, arguments);

   // After parent code

}
});

// register xtype to allow for lazy initialization
Ext.reg('mycomponentxtype', MyComponent);

As an enlightening example, if you used the above class via either of the following:

var myComponent = new MyComponent({
propA: 2
});
// Or lazily:
{..
items: {xtype: 'mycomponentxtype', propA: 2}
..}

then the property propA would have been set three times, to the values 1, 2, and 3 consecutively. If you follow the code (and the comments) through you will see that value starts as 1 (Prototype default) and then is set to 2 by the user's config object, and finally is overridden in initComponent and set to 3. Hopefully this example gives you a bit of insight into the order in which the code is executed (not in the order that you read it from start to finish!).

Because components nest other components, here's a quick way to grab the top-most component.

var topCmp = (function(o){while(o.ownerCt){o=o.ownerCt} return o;})(this);

More clearer and specific example


Application.PersonnelGrid = Ext.extend(Ext.grid.GridPanel, {
     border:false
    ,initComponent:function() {
        Ext.apply(this, {
             store:new Ext.data.Store({...})
            ,columns:[{...}, {...}]
            ,plugins:[...]
            ,viewConfig:{forceFit:true}
            ,tbar:[...]
            ,bbar:[...]
        });

        Application.PersonnelGrid.superclass.initComponent.apply(this, arguments);
    } // eo function initComponent

    ,onRender:function() {
        this.store.load();

        Application.PersonnelGrid.superclass.onRender.apply(this, arguments);
    } // eo function onRender
});

Ext.reg('personnelgrid', Application.PersonnelGrid);

Optimistic Concurrency Control by enabling versioning in Hibernate

2009-11-24T10:32:00.000-08:00

Note:
The following article is an excerpt from the great book - "Java Persistence with Hibernate"

Choosing an isolation level

Developers (ourselves included) are often unsure what transaction isolation level
to use in a production application. Too great a degree of isolation harms scalability
of a highly concurrent application. Insufficient isolation may cause subtle,
unreproduceable bugs in an application that you’ll never discover until the system
is working under heavy load.

Note that we refer to optimistic locking (with versioning) in the following explanation,
a concept explained later in this chapter. You may want to skip this section
and come back when it’s time to make the decision for an isolation level in your
application. Picking the correct isolation level is, after all, highly dependent on
your particular scenario. Read the following discussion as recommendations, not
carved in stone.

Hibernate tries hard to be as transparent as possible regarding transactional
semantics of the database. Nevertheless, caching and optimistic locking affect
these semantics. What is a sensible database isolation level to choose in a Hibernate
application?

First, eliminate the read uncommitted isolation level. It’s extremely dangerous to
use one transaction’s uncommitted changes in a different transaction. The rollback
or failure of one transaction will affect other concurrent transactions. Rollback
of the first transaction could bring other transactions down with it, or
perhaps even cause them to leave the database in an incorrect state. It’s even possible
that changes made by a transaction that ends up being rolled back could be
committed anyway, because they could be read and then propagated by another
transaction that is successful!

Secondly, most applications don’t need serializable isolation (phantom reads
aren’t usually problematic), and this isolation level tends to scale poorly. Few
existing applications use serializable isolation in production, but rather rely on
pessimistic locks (see next sections) that effectively force a serialized execution of
operations in certain situations.

This leaves you a choice between read committed and repeatable read. Let’s first
consider repeatable read. This isolation level eliminates the possibility that one
transaction can overwrite changes made by another concurrent transaction (the
second lost updates problem) if all data access is performed in a single atomic
database transaction. A read lock held by a transaction prevents any write lock a
concurrent transaction may wish to obtain. This is an important issue, but
enabling repeatable read isn’t the only way to resolve it.

Let’s assume you’re using versioned data, something that Hibernate can do for
you automatically. The combination of the (mandatory) persistence context
cache and versioning already gives you most of the nice features of repeatable
read isolation. In particular, versioning prevents the second lost updates problem,
and the persistence context cache also ensures that the state of the persistent
instances loaded by one transaction is isolated from changes made by other transactions.
So, read-committed isolation for all database transactions is acceptable if
you use versioned data.

Repeatable read provides more reproducibility for query result sets (only for
the duration of the database transaction); but because phantom reads are still
possible, that doesn’t appear to have much value. You can obtain a repeatable-
read guarantee explicitly in Hibernate for a particular transaction and piece
of data (with a pessimistic lock).
Setting the transaction isolation level allows you to choose a good default locking
strategy for all your database transactions. How do you set the isolation level?

Setting an isolation level

Every JDBC connection to a database is in the default isolation level of the DBMS—
usually read committed or repeatable read. You can change this default in the
DBMS configuration. You may also set the transaction isolation for JDBC connections
on the application side, with a Hibernate configuration option:
hibernate.connection.isolation = 4
Hibernate sets this isolation level on every JDBC connection obtained from a
connection pool before starting a transaction. The sensible values for this option
are as follows (you may also find them as constants in java.sql.Connection):
■ 1—Read uncommitted isolation
■ 2—Read committed isolation
■ 4—Repeatable read isolation
■ 8—Serializable isolation

Note that Hibernate never changes the isolation level of connections obtained
from an application server-provided database connection in a managed environment!
You can change the default isolation using the configuration of your application
server. (The same is true if you use a stand-alone JTA implementation.)
As you can see, setting the isolation level is a global option that affects all connections
and transactions. From time to time, it’s useful to specify a more restrictive
lock for a particular transaction. Hibernate and Java Persistence rely on
optimistic concurrency control, and both allow you to obtain additional locking
guarantees with version checking and pessimistic locking.

An optimistic approach always assumes that everything will be OK and that conflicting
data modifications are rare. Optimistic concurrency control raises an
error only at the end of a unit of work, when data is written. Multiuser applications
usually default to optimistic concurrency control and database connections
with a read-committed isolation level. Additional isolation guarantees are
obtained only when appropriate; for example, when a repeatable read is required.
This approach guarantees the best performance and scalability.
Understanding the optimistic strategy
To understand optimistic concurrency control, imagine that two transactions read
a particular object from the database, and both modify it. Thanks to the read-committed
isolation level of the database connection, neither transaction will run into any dirty reads. However, reads are still nonrepeatable, and updates may also be
lost. This is a problem you’ll face when you think about conversations, which are
atomic transactions from the point of view of your users. Look at figure 10.6.
Let’s assume that two users select the same piece of data at the same time. The
user in conversation A submits changes first, and the conversation ends with a successful
commit of the second transaction. Some time later (maybe only a second),
the user in conversation B submits changes. This second transaction also commits
successfully. The changes made in conversation A have been lost, and (potentially
worse) modifications of data committed in conversation B may have been based
on stale information.

You have three choices for how to deal with lost updates in these second transactions
in the conversations:
■ Last commit wins—Both transactions commit successfully, and the second
commit overwrites the changes of the first. No error message is shown.
■ First commit wins—The transaction of conversation A is committed, and the
user committing the transaction in conversation B gets an error message.
The user must restart the conversation by retrieving fresh data and go
through all steps of the conversation again with nonstale data.
■ Merge conflicting updates—The first modification is committed, and the transaction
in conversation B aborts with an error message when it’s committed.
The user of the failed conversation B may however apply changes selectively,
instead of going through all the work in the conversation again.

If you don’t enable optimistic concurrency control, and by default it isn’t enabled,
your application runs with a last commit wins strategy. In practice, this issue of lost
updates is frustrating for application users, because they may see all their work
lost without an error message.

Figure 10.6
Conversation B overwrites
changes made by conversation A.

Obviously, first commit wins is much more attractive. If the application user of
conversation B commits, he gets an error message that reads, Somebody already committed
modifications to the data you’re about to commit. You’ve been working with stale
data. Please restart the conversation with fresh data. It’s your responsibility to design
and write the application to produce this error message and to direct the user to
the beginning of the conversation. Hibernate and Java Persistence help you with
automatic optimistic locking, so that you get an exception whenever a transaction
tries to commit an object that has a conflicting updated state in the database.
Merge conflicting changes, is a variation of first commit wins. Instead of displaying
an error message that forces the user to go back all the way, you offer a dialog that
allows the user to merge conflicting changes manually. This is the best strategy
because no work is lost and application users are less frustrated by optimistic concurrency
failures. However, providing a dialog to merge changes is much more
time-consuming for you as a developer than showing an error message and forcing
the user to repeat all the work. We’ll leave it up to you whether you want to use
this strategy.

Optimistic concurrency control can be implemented many ways. Hibernate
works with automatic versioning.

Enabling versioning in Hibernate
Hibernate provides automatic versioning. Each entity instance has a version,
which can be a number or a timestamp. Hibernate increments an object’s version
when it’s modified, compares versions automatically, and throws an exception if a
conflict is detected. Consequently, you add this version property to all your persistent
entity classes to enable optimistic locking:
public class Item {
...
private int version;
...
}
You can also add a getter method; however, version numbers must not be modified
by the application. The <version> property mapping in XML must be placed
immediately after the identifier property mapping:
<class name="Item" table="ITEM">
<id .../>
<version name="version" access="field" column="OBJ_VERSION"/>
...
</class>

The version number is just a counter value—it doesn’t have any useful semantic
value. The additional column on the entity table is used by your Hibernate application.
Keep in mind that all other applications that access the same database can
(and probably should) also implement optimistic versioning and utilize the same
version column. Sometimes a timestamp is preferred (or exists):
public class Item {
...
private Date lastUpdated;
...
}
<class name="Item" table="ITEM">
<id .../>
<timestamp name="lastUpdated"
access="field"
column="LAST_UPDATED"/>
...
</class>
In theory, a timestamp is slightly less safe, because two concurrent transactions
may both load and update the same item in the same millisecond; in practice,
this won’t occur because a JVM usually doesn’t have millisecond accuracy (you
should check your JVM and operating system documentation for the guaranteed
precision).

Furthermore, retrieving the current time from the JVM isn’t necessarily safe in
a clustered environment, where nodes may not be time synchronized. You can
switch to retrieval of the current time from the database machine with the
source="db" attribute on the mapping. Not all Hibernate SQL dialects
support this (check the source of your configured dialect), and there is
always the overhead of hitting the database for every increment.
We recommend that new projects rely on versioning with version numbers, not
timestamps.

Optimistic locking with versioning is enabled as soon as you add a
or a <timestamp> property to a persistent class mapping. There is no other switch.
How does Hibernate use the version to detect a conflict?

Automatic management of versions
Every DML operation that involves the now versioned Item objects includes a version
check. For example, assume that in a unit of work you load an Item from the
database with version 1. You then modify one of its value-typed properties, such as
the price of the Item. When the persistence context is flushed, Hibernate detects
that modification and increments the version of the Item to 2. It then executes
the SQL UPDATE to make this modification permanent in the database:
update ITEM set INITIAL_PRICE='12.99', OBJ_VERSION=2
where ITEM_ID=123 and OBJ_VERSION=1
If another concurrent unit of work updated and committed the same row, the
OBJ_VERSION column no longer contains the value 1, and the row isn’t updated.
Hibernate checks the row count for this statement as returned by the JDBC
driver—which in this case is the number of rows updated, zero—and throws a
StaleObjectStateException. The state that was present when you loaded the
Item is no longer present in the database at flush-time; hence, you’re working
with stale data and have to notify the application user. You can catch this exception
and display an error message or a dialog that helps the user restart a conversation
with the application.
What modifications trigger the increment of an entity’s version? Hibernate
increments the version number (or the timestamp) whenever an entity instance is
dirty. This includes all dirty value-typed properties of the entity, no matter if
they’re single-valued, components, or collections. Think about the relationship
between User and BillingDetails, a one-to-many entity association: If a Credit-
Card is modified, the version of the related User isn’t incremented. If you add or
remove a CreditCard (or BankAccount) from the collection of billing details, the
version of the User is incremented.
If you want to disable automatic increment for a particular value-typed property
or collection, map it with the optimistic-lock="false" attribute. The
inverse attribute makes no difference here. Even the version of an owner of an
inverse collection is updated if an element is added or removed from the
inverse collection.
As you can see, Hibernate makes it incredibly easy to manage versions for optimistic
concurrency control. If you’re working with a legacy database schema or
existing Java classes, it may be impossible to introduce a version or timestamp
property and column. Hibernate has an alternative strategy for you.

Transaction Isolation Levels

2009-11-24T07:31:00.000-08:00

Dirty Read
A dirty read occurs if a one transaction reads changes made by another transaction
that has not yet been committed. This is dangerous, because the changes made by
the other transaction may later be rolled back, and invalid data may be written by
the first transaction, as shown in the figure

Non-repeatable Read
An unrepeatable read occurs if a transaction reads a row twice and reads different
state each time. For example, another transaction may have written to the row
and committed between the two reads as shown in the figure

Phantom Read
A phantom read is said to occur when a transaction executes a query twice, and
the second result set includes rows that weren’t visible in the first result set or rows
that have been deleted. (It need not necessarily be exactly the same query.) This
situation is caused by another transaction inserting or deleting rows between the
execution of the two queries as shown in the figure

Lost update
A lost update occurs if two transactions both update a row and then the second
transaction aborts, causing both changes to be lost. This occurs in systems that
don’t implement locking.

Transaction Isolation Levels

Read Uncommitted
A system that permits dirty reads but not lost updates is said to operate in
read uncommitted isolation. One transaction may not write to a row if another
uncommitted transaction has already written to it. Any transaction may read
any row, however.

Read Committed
A system that permits unrepeatable reads but not dirty reads is said to implement
read committed transaction isolation. This may be achieved by using
shared read locks and exclusive write locks. Reading transactions don’t
block other transactions from accessing a row. However, an uncommitted
writing transaction blocks all other transactions from accessing the row.

Repeatable Read
A system operating in repeatable read isolation mode permits neither unrepeatable
reads nor dirty reads. Phantom reads may occur. Reading transactions
block writing transactions (but not other reading transactions), and
writing transactions block all other transactions.

Serializable
Serializable provides the strictest transaction isolation. This isolation level
emulates serial transaction execution, as if transactions were executed one
after another, serially, rather than concurrently. Serializability may not be
implemented using only row-level locks. There must instead be some other
mechanism that prevents a newly inserted row from becoming visible to a
transaction that has already executed a query that would return the row.

Managing User Preferences - Personalize the User Space

2009-11-22T09:21:00.000-08:00

Managing User Preferences

User does many things once he logins into the application to personalize his space.
Some of the many things will be setting the window sizes, positioning the windows, hiding or showing widgets etc etc.

Here I will briefly go through how to manage user preferences in ext js.

Initialize the state provider

Ext.state.Manager.setProvider(new HttpProvider());
In this case we are initializing the manager with the Http state provider persisting the state to the database.

Initialize the scheduler

Scheduler in this case will schedule the task for persisting the state to the database.
delayedTask = new Ext.util.DelayedTask(this.persistState, this);
Here DelayedTask is used as the scheduler.

Initialize the state manager

Initialize the state manager by loading any state persisted before by reading it from the database via HttpProvider.

Start the scheduler

delayedTask.delay(1000);
Here we are asking the scheduler to poll the state manager once in 1000 milli seconds to know if there are any changes in the state to be persisted.
The callback api, in this case, the persistState api will be called if there are any changes to the state.

persistState api may look like this,

function persistState() {

if(!stateDirty) {
delayedTask.delay(1000); // If state not dirty delay the scheduler for 1000 milliseconds more
}

delayedTask.cancel(); // stop the scheduler and submit the state to the server asking it to persist to the database.
submitState();
}

Override the set method of the provider
Set method of the provider is used to set the state [user preference like window size, x & y position etc] to the state manager.

Override the set method of the Provider to set the stateDirty flag to true and start the scheduler which was cancelled when the state was submitted to the server.
stateDirty = true;
delayedTask.delay(1000);
superclass.set();

Shopping Cart: Project set up & Login Screen

2009-11-15T06:08:00.000-08:00

1) Create new project
Project is the collection of modules.

2) Create Modules
Module is the collection of facets.

3) There are lots of facets but 4 facets are quiet important to make a note of
Web, EJB, JPA and JEE facets.

4) Write a web.xml for your application in the web facet.

5) Configure an authenticator valve in context.xml

6) Write a redirect servlet


package com.shoppingcart.security.login;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import javax.servlet.RequestDispatcher;
import java.io.IOException;
import java.util.Enumeration;


public class RedirectServlet extends HttpServlet
{
  protected void service(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws ServletException, IOException
  {
      final String svlpath = httpServletRequest.getServletPath();
      Enumeration en = httpServletRequest.getAttributeNames();
      String actualReqPathKey = "javax.servlet.forward.servlet_path";
      String actualReqPath = (String)httpServletRequest.getAttribute(actualReqPathKey);

      String pageName = actualReqPath;

      if ("/unsecured/login".equals(svlpath)) {
          if("/index.jsp".equals(actualReqPath)) {
              pageName = "/Login.jsp";
          }
      }
      else {
          throw new ServletException("RedirectServlet: operation '" + svlpath + "' not supported!");
      }
      redirectToLogin(httpServletRequest, httpServletResponse, pageName);
  }

  private void redirectToLogin(HttpServletRequest request, HttpServletResponse response, String pageName) throws IOException, ServletException
  {
      RequestDispatcher dispatcher = this.getServletContext().getContext("/shoppingcart").getRequestDispatcher(pageName);
      if (dispatcher != null) {
          response.setContentType("text/html");
          dispatcher.include(request, response);
      }
  }

}

7) Mention about the module in application.xml

8) Configure JBoss from the ide.

9) Compile the application, deploy and run jboss.

How does it all work

When the user points the browser to localhost:8080/shoppingcart for the first time, the jboss server figures out from the web.xml configuration that this resource cannot be accessed publicly by everyone and that it needs to be secured and only allowed roles can access it. To authenticate the jboss server will use the FormAuthenticator which is configured as the valve in context.xml. The FormAuthenticator will interpret the request and changes the url to the one mentioned in web.xml, in this case it is /unsecured/login and redirects to RedirectServlet. The RedirectServlet will dispatch the request to Login.jsp and hence the Login.jsp is sent back to the browser.

Probability 6

2009-10-31T11:04:00.000-07:00

Mixing multiple probabilities

Given a box of 10 coins out of which 9 coins are fair and one coin has both sides heads, what is the probability of getting all heads on picking a coin from the bag and flipping it 5 times.

There are two outcomes possible if we pick a coin from the bag.
The first outcome would be that we pick a normal coin and its probability would be 9/10 --- (1).
The second outcome would be that we pick a coin having both sided heads, whose probability is 1/10 --- (2).

Now after this,
Given a normal coin what is the probability of getting all 5 heads is, as we know it to be (1/2)*(1/2)*(1/2)*(1/2)*(1/2) = 1/32 --- (3).

Given a both sided heads coin, the probability of getting all 5 heads is 1 --- (4).

From (1), (2), (3) & (4) we get the
P(getting all 5 heads) = (P(picking the normal coin)*P(getting all heads provided its normal coin))+(P(Picking an unfair coin)*P(getting all heads provided its unfair coin))

= (1/32)*(9/10) + 1*(1/10) = 9/320 + 1/10 = 41/320

Probability 5

2009-10-31T10:18:00.000-07:00

What is the probability of getting a 7 when two dice is thrown.

The total number of outcomes throwing 2 dice would be 36 as shown in the figure below.
As you can see in the figure, the number of times we get 7 is 6.

Therefore, the P(7) = 6/36 = 1/6.

Probability 4

2009-10-28T10:45:00.000-07:00

Example:
---------

The probability of me making a shot in basketball is 80%, I have 3 shots and we need 1 pt to win the match. What is the probability of we winning the match?

P(we winning) = P(me making atleast one shot) = 1 - P(me making no shots at all)

P(me making no shots at all) = 0.2 * 0.2 * 0.2 = 0.008 = 0.8%

P(we winning) = 1-0.008 = 99.2%

Probability 3

2009-10-27T10:37:00.000-07:00

Arrangements [Permutations] meeting Probability.

1) Find the probability of getting only one heads in 5 flips

Outcomes are

TTTTH
TTTHT
TTHTT
THTTT
HTTTT

The probability of occurrence of each of these outcomes is 1/32.
Since there are 5 such arrangements the total probability becomes 5/32.

2) Find the probability of not getting exactly one heads in 5 flips

This is exactly equal to all the outcomes except the above which results to 1-5/32 = 27/32

Probability 2

2009-10-26T11:21:00.000-07:00

Probability Tree

Probability Tree is a very good tool in finding the probability of an occurrence of an event provided -
1) The outcomes or circumstances of an event are very small in number
2) The experiment should not be repeated large number of times

Note:
The depth of the tree is the number of times the experiment is repeated.
Example: Flipping coins 5 times.

The width of the tree is the count of all possible outcomes of an event.
Example: H & T are the 2 outcome of flipping the coin.

Lets take an example and solve the probability using Probability Tree

Find the probability of two heads occuring on two consecutive flips of coins, i.e., P(HH)

From the above probability tree the total out comes or circumstances of flipping coin twice is 4. Out of the 4 outcomes, the total number of times we get HH is 1, so the P(HH) = 1/4.

Another way to look at it is the probability of first flip leading to heads is 1/2, and this remains the same even during the second flip because both heads and tails are equally probable and they are not mutually exclusive so it leads to 1/2 * 1/2 = 1/4.

Note we multiply the probabilities because the events are not mutually exclusive.

Similary P(1H, 1T) = 2/4 = 1/2

P(HHHHH) = 1/2*1/2*1/2*1/2*1/2 = 1/32

P(Out of 7 flips, heads should not come even once) = p(TTTTTTT) = 1/128

Probability 1

2009-10-25T11:15:00.000-07:00

Probability
-------------

Two ways of looking at probability are:

1) Repeated experiments possible [Frequency Test]
Perform an experiment repeatedly and identify wht percent of times the experiment has
behaved the way u want it to behave.
Example: Flipping a coin hundred times to know the probability of occurrence of heads.

2) Repeated experiments not possible
Based on the data that you have, how strongly you believe that the experiment will behave
the way you want it to behave.
Example: What are the chances that its going to rain today.

Definition of Probability
-----------------------------

P(x) = number of events in which x is true
------------------------------------
total number of events or all possible outcomes of an event or all possible circumstances of an event.

In case of flipping a coin, the total number of circumstances or outcome of flipping a coin is 2, it can be either heads or tails.

assuming that the occurence of all the events are equally probable, i.e no single event should occur more number of times than other events.

Examples:
---------

P(Occurence of Head on flipping a coin) = 1 / 2 = 50%

Determining the master node in a JBoss Cluster

2009-10-18T04:27:00.000-07:00

Thanks to the original author and the source

How to determine which node in the cluster is the master node?

Have you ever dealt with clustered singleton service? How to determine which cluster node is the master? Well, if I am the current node, I can simply ask whether I am the master or not. But what if I already know that the current node is not the master, and I want to determine which node among other nodes in the cluster is the master?

First I would like to give brief summary about HASingleton service (HA stands for High Availability).

Summary:
HASingleton service, is a service that is deployed on every node in a cluster, but runs only on one node, while the other nodes remain passive. The node that the service runs on, is the master node.

How does JBoss selects the master node?
Well the first node in a cluster will become master node. If existing master node will leave the cluster as a result of a shutdown for example, another node is selected as master from the remaining nodes.

Master node can control which tasks will get executed, and how many times. HASingletons also have the ability to share a memory state across clustered partition. Something like caching ...

Solution:
Lets assume that I have a service bean that extends from HASingletonSupport class. HASingletonSupport in its turn extends from HAServiceMBeanSupport
and implements two interfaces: HASingletonMBean and HASingleton. All of them give me those wonderful APIs that can tell me whether the current node is the master or not, what the status of my cluster, how many nodes etc. etc.

public class MyHAService extends HASingletonSupport implements
MyHAServiceMBean {
private static Logger logger =
Logger.getLogger(MyHAService.class);
public void startService() throws Exception {
logger.info(" *** STARTED MY SINGLETON SERVICE *** ");
super.startService();
}
public void stopService() throws Exception {
logger.info(" *** STOPPED MY SINGLETON SERVICE *** ");
super.stopService();
}
public boolean isMasterNode() {
return super.isMasterNode();
}
public void startSingleton() {
logger.info(" *** CURRENT NODE IP:"
+ this.getPartition().getClusterNode()
.getIpAddress().getHostAddress() +
" ELECTED AS A MASTER NODE *** ");
}
public void stopSingleton() {
logger.info(" *** CURRENT NODE IP:"
+ this.getPartition().getClusterNode()
.getIpAddress().getHostAddress()
+ " STOPPED ACTING AS A MASTER NODE *** ");
}
public void partitionTopologyChanged(List newReplicants, int newViewID) {
logger.info(" *** TOPOLOGY CHANGE STARTING *** ");
super.partitionTopologyChanged(newReplicants, newViewID);
}
}

public class MyHAService extends HASingletonSupport implements
      MyHAServiceMBean {

private static Logger logger =
  Logger.getLogger(MyHAService.class);

public void startService() throws Exception {
      logger.info(" *** STARTED MY SINGLETON SERVICE *** ");
      super.startService();
}

public void stopService() throws Exception {
      logger.info(" *** STOPPED MY SINGLETON SERVICE *** ");
      super.stopService();
}

public boolean isMasterNode() {
      return super.isMasterNode();
}


public void startSingleton() {
      logger.info(" *** CURRENT NODE IP:"
              + this.getPartition().getClusterNode()
   .getIpAddress().getHostAddress() +
   " ELECTED AS A MASTER NODE *** ");
}


public void stopSingleton() {
      logger.info(" *** CURRENT NODE IP:"
              + this.getPartition().getClusterNode()
   .getIpAddress().getHostAddress()
              + " STOPPED ACTING AS A MASTER NODE *** ");
}


public void partitionTopologyChanged(List newReplicants, int newViewID) {
      logger.info(" *** TOPOLOGY CHANGE STARTING *** ");
      super.partitionTopologyChanged(newReplicants, newViewID);

 }
}

startSingleton() - invoked when the current node elected as a master.
stopSingleton() - invoked when the current node stops acting as a master.
partitionTopologyChanged() - invoked when new node joins or leaves the cluster.

As i mentioned before, I have the ability to know whether the current node is the master node, by calling isMasterNode(). The method will return true if the node is master and false if its not.

In case I already know that the current node is not the master, I can ask the clustered partition (the cluster) which node is the master. For example I can request the current view of my cluster.

The implementation can be similar to the method below which you can have inside your service bean:

private String getMasterSocket() {
HAPartition partition = this.getPartition();
if (partition != null) {
if (partition.getCurrentView() != null) {
return partition.getCurrentView().get(0).toString();
} else {
return null;
}
} else {
return null;
}
}

private String getMasterSocket() {

      HAPartition partition = this.getPartition();

      if (partition != null) {

          if (partition.getCurrentView() != null) {
              return partition.getCurrentView().get(0).toString();

          } else {
              return null;
          }
      } else {
          return null;
      }
  }

The method above will return me a string contains port and ip of the master node, for example:

192.168.62.12:1099

The HAPartition service maintains across cluster a registry of nodes in a view order. Now, keep in mind that an order of the nodes in the view, does not necessary reflect the order nodes have joined the cluster.

So the first node in the view as you can see beloew, will be the master node.
Simple as that.

return partition.getCurrentView().get(0).toString();

Please note:
Method getPartition() may return null, if super.startService() hasnt been called. Have a look at implementation of HAServiceMBeanSupport and my other post JBoss Clustering - How many nodes in the cluster?.

Finding the number of cluster nodes in JBoss

2009-10-18T04:24:00.000-07:00

Thanks to the Original Author and source

How to find out how many nodes in the cluster

If you want to know how many nodes there are in the current cluster partition, all you have to do is to ask HAPartition for the node list. HAPartition represents your cluster partition, and it contains all the information you need to know about your cluster and the nodes: their host names, IPs, position in the cluster view.

Lets assume you have a service bean that extends from HASingletonSupport. HASingletonSupport in its turn extends from HAServiceMBeanSupport.

HAServiceMBeanSupport is the one who gives you access to HAPartition object.

The code to request for HAPartition object and node list that you see below , you can put somewhere in your service bean:

HAPartition partition = getPartition();
ClusterNode[] nodes = partition.getClusterNodes();
System.out.println(nodes.length);

ClusterNode object represents your node in the cluster. It contains information about node's host name, its internet address and a few more things. getClusterNodes(), returns to you an array contains as many ClusterNode objects as you have currently in your cluster. So by getting the value of array length, you will know how many nodes your cluster has.

Another way, is to do practically the same, but to request from a HAPartition a current view of your cluster:

HAPartition partition = getPartition();
Vector v = partition.getCurrentView();

System.out.println(partition.getCurrentView().size());

for (Object o : v) {
  System.out.println(o.toString());
}

The view, which is a Vector contains information about node sockets. When printed, it will return to you a String representation of node ip + port: xxx.xxx.xxx.xxx:port. Also by printing size of the Vector, you will get number of nodes in the cluster.

Important note:
I noticed there is some delay happening from the time when node leaves the cluster to the time when HAPartition returns an updated view. In another words - after node has left the cluster and topology change has occurred, the HAPartition may return to you an old view still containing the dead node. So be careful.

Also, getPartition() may return null, if super.startService() hasnt been called. Have a look at implementation of HAServiceMBeanSupport and my other post JBoss Clustering - HASingleton service.

JBoss Clustering

2009-10-18T03:38:00.000-07:00

Thanks to the original author and Source

Singleton Service

A clustered singleton service is deployed on multiple nodes in a cluster but runs on only one of the nodes. The node running the singleton service is typically called the master node. When the master fails, another master is selected from the remaining nodes and the service is restarted on the new master.

Figure 1. Clustered singleton service

Many times, an application needs to ensure that a certain task is run exactly once. Thus, only one of the nodes in a cluster should execute the task. The other nodes should knowingly remain passive. Examples of singleton tasks include:

Sending email to the system administrator when the system is brought up or taken down. This notification does not take into account how many nodes are in the cluster. As long as at least one node is active, the system is up. When all nodes are down, the system is down.
Database schema validation upon startup. When a database-driven application is brought up, it is a good practice for the middle tier servers to verify whether the version of the business logic they implement matches the database schema.
Sending recurring notifications to system users. For example, a calendar application might send out email prior to each instance of a scheduled recurring meeting.
Load balancing of queued tasks. It's popular to use a single coordinator that distributes tasks among nodes in a cluster.
Fault tolerance. If an application uses a distributed cache, it is common to designate a single master node responsible for maintaining a current copy of distributed states. The other nodes make requests of the current master node. When the master fails, another node takes over its responsibilities.

While it is fairly easy to implement such singleton tasks in a single VM, the solution will usually not work immediately in a clustered environment. Even in the simple case of a task activated upon startup on one of the nodes in a two-node cluster, several problems must be addressed:

When the application is started simultaneously on both nodes, which VM should run the singleton task?
When the application is started on one node and then started later on another, how does the second node know not to run the singleton task again?
When the node that started the task fails, how does another node know to resume the task?
When the node that started the task fails, but later recovers, how do we ensure that the task remains running on only one of the nodes?

The logic to solve these problems is unlikely to be included in the design of a single-VM solution. However, a solution can be found to address the case at hand and it can be patched on the startup task. This is an acceptable approach for a few startup tasks and two-node clusters.

As the application grows and becomes more successful, more startup tasks may be necessary. The application may also need to scale to more than two nodes. The clustered singleton problem can quickly become mind-boggling for larger clusters, where the different node startup scenarios are far more difficult to enumerate than in the two-node case. Another complicating factor is communication efficiency. While two nodes can directly connect to each other and negotiate, 10 nodes will have to establish 45 total connections to use the same technique.

This is where JBoss comes in handy. It eliminates most of the complexity and allows application developers to focus on building singleton services regardless of the cluster topology.

We will illustrate how the JBoss clustered singleton facility works with an example. First, we will need a service archive descriptor. Let's use the one that ships with JBoss under server/all/farm/cluster-examples-service.xml. The following is an excerpt:

<!--    | This MBean is an example of a cluster Singleton    -->
<mbean code="org.jboss.ha.singleton.examples.HASingletonMBeanExample"
         name="jboss.examples:service=HASingletonMBeanExample">
</mbean>
<!- - -->
  <!--    | This is a singleton controller which works similarly to the
          | SchedulerProvider (when a MBean target is used)    -->
  <mbean code="org.jboss.ha.singleton.HASingletonController"
         name="jboss.examples:service=HASingletonMBeanExample-HASingletonController">
     <depends>jboss:service=DefaultPartition</depends>
     <depends>jboss.examples:service=HASingletonMBeanExample</depends>
     <attribute name="TargetName">jboss:service=HASingletonMBeanExample</attribute>
     <attribute name="TargetStartMethod">startSingleton</attribute>
     <attribute name="TargetStopMethod">stopSingleton</attribute>
  </mbean>
<!- - -->

This file declares two MBeans, HASingletonMBeanExample and HASingletonController. The first one is a singleton service that contains the custom code. It is a simple JavaBean with the following source code:

public class HASingletonMBeanExample
 implements HASingletonMBeanExampleMBean {

   private boolean isMasterNode = false;

   public void startSingleton() {
       isMasterNode = true;
   }

   public boolean isMasterNode() {
       return isMasterNode; 
   }

   public void stopSingleton() {
       isMasterNode = false; 
   }
}

All of the custom logic for this particular singleton service is contained within this class. Our example is not too useful; it simply indicates, via the isMasterNode member variable, whether the master node is running the singleton. This value will be true only on the one node in the cluster where it is deployed.

HASingletonMBeanExampleMBean exposes this variable as an MBean attribute. It also exposes startSingleton() and stopSingleton() as managed MBean operations. These methods control the lifecycle of the singleton service. JBoss invokes them automatically when a new master node is elected.

How does JBoss control the singleton lifecycle throughout the cluster? The answer to this question is in the MBean declarations. Notice that the HASingletonMBeanExample-HASingletonController MBean also takes the name of the sample singleton MBean and its start and stop methods.

On each node in the cluster where these MBeans are deployed, the controller will work with all of the other controllers with the same MBean name deployed in the same cluster partition to oversee the lifecycle of the singleton. The controllers are responsible for tracking the cluster topology. Their job is to elect the master node of the singleton upon startup, as well as to elect a new master should the current one fail or shut down. In the latter case, when the master node shuts down gracefully, the controllers will wait for the singleton to stop before starting another instance on the new master node.

A singleton service is scoped in a certain cluster partition via its controller. Notice that, in the declaration above, the controller MBean depends on the MBean service DefaultPartition. If the partition where the singleton should run is different than the default, its name can be provided to the controller via the MBean attribute PartitionName.

Clustered singletons are usually deployed via the JBoss farming service. To test this example, just drop the service file above in the server/all/farm directory. You should be able to see the following in the JBoss JMX web console:

Figure 2. Controller MBean view. The MasterNode attribute will have value True on only one of the nodes.

Figure 3. Sample singleton MBean view. The MasterNode attribute will have the same value as the MasterNode attribute on the controller MBean.

Brief on JBoss EAR Deployment

2009-10-17T23:57:00.000-07:00

EAR Deployment Process:

1) The EAR starts getting deployed and EARDeployer is the main class that does that.

2) All the dependent jars are scanned and deployed if not deployed. MainDeployer is the main class that does this.

3) The Queue Sevice and Topic Service will be started if there are any topics or queues defined in the Application. TopicService and QueueService are the main class that does this.

4) EJB3Deployment begins, which deploys Enterprise beans and Persistence Units in the application or module. EJB3Deployer iterates through the ear to find all the jars which has persistence units and enterprise beans for deployment.

a) If a persistence unit is detected, first an corresponding MDB will be created and registered into JMXServer. Similarly if an EJB is detected, a corresponding MDB is created and registered into JMX. JmxKernelAbstraction is the main class that does this.

b) Once PersistenceUnitMDB is registered, the service is started to create all the relevant tables n EntityManager relationships etc into db and PersistenceUnitDeployment is the class that does this.

c) Similarly once EJBMDB is registered, the service is started using EJBContainer class.

5) Once EJB Deployment is done, TomcatDeployer will deploy the web application if any in the particular module being scanned.

6) Cluster Session Management is started for this particular application, JBossCacheManager is the one responsible for this.

7) Once all the above steps are done, the application can have application specific database initializers, inventory trackers, etc started.

Before the EAR Deployment begins, all the services starting from Transaction Service, Timer Service, UDDI, WebService, etc would have started.
All the JBoss related Webapps like jmx-console, web-console will start. Once all these JBoss goes ahead with the EAR Deployment.

JBoss Lookup

2009-10-17T04:44:00.000-07:00

Thanks to the original author.
You can find the original source here

Many a times when you are doing a lookup in the JNDI tree, you see javax.naming.NameNotFoundException. A simple code that does the lookup will look something like:

Context ctx = new InitialContext();
Object obj = ctx.lookup("somepath/somename");

Context ctx = new InitialContext(); Object obj = ctx.lookup("somepath/somename");

This code just looks up the JNDI tree to get an object bound by the name "somepath/somename". Looks simple. However, chances are that you might even see this exception:

javax.naming.NameNotFoundException: somepath not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:595)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
at javax.naming.InitialContext.lookup(InitialContext.java:351)

javax.naming.NameNotFoundException: somepath not bound  at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)  at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)  at org.jnp.server.NamingServer.getObject(NamingServer.java:543)  at org.jnp.server.NamingServer.lookup(NamingServer.java:267)  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  at java.lang.reflect.Method.invoke(Method.java:585)  at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)  at sun.rmi.transport.Transport$1.run(Transport.java:153)  at java.security.AccessController.doPrivileged(Native Method)  at sun.rmi.transport.Transport.serviceCall(Transport.java:149)  at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)  at java.lang.Thread.run(Thread.java:595)  at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)  at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)  at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)  at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)  at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)  at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)  at javax.naming.InitialContext.lookup(InitialContext.java:351)

Look closely at the stacktrace. It shows that while looking up the JNDI tree it could not find the jndi name "somepath" (this name may vary). The reason is simple, the JNDI tree does not have any object bound by this name.

To quote the javadocs of this exception "This exception is thrown when a component of the name cannot be resolved because it is not bound."

So how do i know, what's the name to which my object is bound? Each application server, usually provides a JNDI view which can be used to see the contents of the JNDI tree. If you know what object you are looking for (ex: the name of the bean), then you can traverse this JNDI tree to see what name it is bound to. The JNDI view is specific to every application server.

To give an example, JBoss provides its JDNI tree view, through the JMX console. Here are the steps, one has to follow to check the JNDI tree contents on JBoss:

- Go to http://<>:<>/jmx-console (Ex: http://localhost:8080/jmx-console)
- Search for service=JNDIView on the jmx-console page
- Click on that link
- On the page that comes up click on the Invoke button beside the list() method
- The page that comes up will show the contents of the JNDI tree.

Here's an sample of how the output looks like(just a small part of the entire output):

java: Namespace
+- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
+- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
+- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)
+- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
+- comp (class: javax.naming.Context)
+- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
+- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
+- jaas (class: javax.naming.Context)
| +- dukesbank (class: org.jboss.security.plugins.SecurityDomainContext)
| +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)
| +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)
| +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)
Global JNDI Namespace
+- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)
+- ebankAccountController (proxy: $Proxy75 implements interface com.sun.ebank.ejb.account.AccountControllerHome,interface javax.ejb.Handle)
+- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
+- jmx (class: org.jnp.interfaces.NamingContext)
| +- invoker (class: org.jnp.interfaces.NamingContext)
| | +- RMIAdaptor (proxy: $Proxy48 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
| +- rmi (class: org.jnp.interfaces.NamingContext)
| | +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)
+- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
+- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
+- ebankCustomer (proxy: $Proxy67 implements interface com.sun.ebank.ejb.customer.LocalCustomerHome)
+- UserTransactionSessionFactory (proxy: $Proxy14 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
+- ebankCustomerController (proxy: $Proxy77 implements interface com.sun.ebank.ejb.customer.CustomerControllerHome,interface javax.ejb.Handle)
+- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
+- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
+- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple)
+- ebankAccount (proxy: $Proxy68 implements interface com.sun.ebank.ejb.account.LocalAccountHome)
+- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
+- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
+- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
+- queue (class: org.jnp.interfaces.NamingContext)
| +- A (class: org.jboss.mq.SpyQueue)
| +- testQueue (class: org.jboss.mq.SpyQueue)
| +- ex (class: org.jboss.mq.SpyQueue)
| +- DLQ (class: org.jboss.mq.SpyQueue)
| +- D (class: org.jboss.mq.SpyQueue)
| +- C (class: org.jboss.mq.SpyQueue)
| +- B (class: org.jboss.mq.SpyQueue)

java: Namespace    +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)   +- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)   +- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)   +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)   +- comp (class: javax.naming.Context)   +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)   +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)   +- jaas (class: javax.naming.Context)   |   +- dukesbank (class: org.jboss.security.plugins.SecurityDomainContext)   |   +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)   |   +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)   |   +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)    Global JNDI Namespace    +- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)   +- ebankAccountController (proxy: $Proxy75 implements interface com.sun.ebank.ejb.account.AccountControllerHome,interface javax.ejb.Handle)   +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)   +- jmx (class: org.jnp.interfaces.NamingContext)   |   +- invoker (class: org.jnp.interfaces.NamingContext)   |   |   +- RMIAdaptor (proxy: $Proxy48 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)   |   +- rmi (class: org.jnp.interfaces.NamingContext)   |   |   +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)   +- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)   +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)   +- ebankCustomer (proxy: $Proxy67 implements interface com.sun.ebank.ejb.customer.LocalCustomerHome)   +- UserTransactionSessionFactory (proxy: $Proxy14 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)   +- ebankCustomerController (proxy: $Proxy77 implements interface com.sun.ebank.ejb.customer.CustomerControllerHome,interface javax.ejb.Handle)   +- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)   +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)   +- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple)   +- ebankAccount (proxy: $Proxy68 implements interface com.sun.ebank.ejb.account.LocalAccountHome)   +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)   +- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)   +- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)   +- queue (class: org.jnp.interfaces.NamingContext)   |   +- A (class: org.jboss.mq.SpyQueue)   |   +- testQueue (class: org.jboss.mq.SpyQueue)   |   +- ex (class: org.jboss.mq.SpyQueue)   |   +- DLQ (class: org.jboss.mq.SpyQueue)   |   +- D (class: org.jboss.mq.SpyQueue)   |   +- C (class: org.jboss.mq.SpyQueue)   |   +- B (class: org.jboss.mq.SpyQueue)

Let's see what this tells us. Let's consider the Global JNDI Namespace first. It contains (among other things) the following:

+- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)

+- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)

This tells me that an object which implements com.sun.ebank.ejb.tx.TxControllerHome and javax.ejb.Handle interfaces is bound to the JNDI tree by the jndi-name "ebankTxController". So if at all i have to lookup this object, my lookup code would be something like:

view plain copy to clipboard print ?

Context ctx = new InitialContext();
ctx.lookup("ebankTxController");

Context ctx = new InitialContext(); ctx.lookup("ebankTxController");

Similarly in the same Global JDNI Namespace, we see :

+- queue (class: org.jnp.interfaces.NamingContext)
| +- A (class: org.jboss.mq.SpyQueue)

+- queue (class: org.jnp.interfaces.NamingContext)   |   +- A (class: org.jboss.mq.SpyQueue)

Make note of the nesting of the names here. This tells me that an object of type org.jboss.mq.SpyQueue is bound by the name "A under the path queue". So your lookup for this object should look like:

Context ctx = new InitialContext();
ctx.lookup("queue/A");

Context ctx = new InitialContext(); ctx.lookup("queue/A");

Now let's move on to the java: namespace in the JNDI tree view above. The difference between a Global JNDI namespace and the java: namespace is that, the object bound in the java: namespace can be looked-up ONLY by clients within the SAME JVM. Whereas, in case of Global JNDI namespace, the objects bound in this namespace can be looked-up by clients, even if they are not in the same JVM as the server. One would ask, how does this matter? Consider a standalone java program(client) which tries to lookup some object on the server (running in its own JVM). Whenever a standalone client is started (using the java command), a new JVM is instantiated. As a result, the server (which is started in its own JVM) and the client are running on different JVMs. Effectively, the client will NOT be able to lookup objects bound in the java: namespace of the server. However, the client can lookup the objects present in the Global JNDI namespace of the server.

So, why are we discussing these details, in a topic which was meant to explain the NameNotFoundException? Let's consider the java: namespace output above. There's a

+- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)

+- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)

This tells me that there's an object bound to the name DefaultDS in the java: namespace. So my lookup code would be:

Context ctx = new InitialContext();
ctx.lookup("java:/DefaultDS");

Context ctx = new InitialContext(); ctx.lookup("java:/DefaultDS");

As explained above, this code is going to return you the object, if this piece of code runs in the same JVM as the server. However, if this piece of code is run from a client in different JVM (maybe a standalone client), then it's going to run into NameNotFoundException. The reason i explained the java: and the Global JNDI namespace is that, sometimes people are surprised that even though the JNDI view shows that the object is bound in the java: namespace(with the same name as the one they pass to the lookup method), they still run into NameNotFoundException. The probable reason might be, the client is in a different JVM.

All you need to know about Javascript Inheritance

2009-10-01T22:38:00.000-07:00

Classical Inheritance


<html>
<script>
function Person(name)
{
   this.name = name;
}

Person.prototype.getName = function() {
   return this.name;
}


function Author(name, book)
{
   Person.call(this, name);
   this.book = book;
}


Author.prototype = new Person();

Author.prototype.getBook = function() {
   return this.book;
}




var simpson = new Author("Simpson", "The Big Fat Book");
alert(simpson.getName());
alert(simpson.getBook());

function Me()
{
   Author.call(this, "Vinuth", "GentleMenz Arena");
}

Me.prototype = new Author();

Me.prototype.getBook = function() {
   return "MyBreadBasket";
}

var me = new Me();
alert(me.getName() + " - " + me.getBook());
</script>
</html>

How of Classical Inheritance

1) Define a function as a constructor,
for e.g., Person, Author and Me shown above.

2) Constructors initializes the member variables and methods using the "this" keyword as shown in Person and Author constructors.

3) Define the complete structure by adding methods.
In the above example Person is defined as having a method called getName.
In javascript prototype keyword is used extensively for this as shown below.


Person.prototype.getName = function() {
 return this.name;
}

4) Extend Author from Person and this is done using two steps.
a) In the constructor of Author call the Person's constructor like Person.call(this,...);
"this" as the parameter to the call method says that you are invoking Person in the Author's context,
i.e., "this" here refers to Author's Object.
b) Prototype chaining:
It is a way to define the hierarchy of objects.
Here Author's prototype is linked to Person meaning Author is an extension of Person or Author is of type Person.
This is done using Author.prototype = new Person();

5) Creating the objects is as simple as "var author = new Author();" and calling a method of its super class will be like "author.getName();"

Prototypal Inheritance


<html>
<script>

var Person = {
 name: "Vinuth",
 getName: function() {
     return this.name;
 }
};


alert(Person.getName());

function clone(obj)
{
 function F(){}
 F.prototype = obj;
 return new F();
}

var Author = clone(Person);

Author.setName = function(name) {
this.name = name;
}

alert(Author.getName());
Author.setName("Chet");
alert(Author.getName());


</script>
</html>

All about Prototypal Inheritance

1) Most importantly there is no use of keyword "function" for defining the classes.
There is no concept of classes.
The beauty of Prototypal language is that everything is an object and there is no class concept at all.
As you can see in the above example Person is not a class but its an object and it is defined using the configuration object.
Configuration objects are defined as {...} within the flower brackets "{}".

2) Since there is no concept of classes and everything in Prototypal language is object, we do not use the keyword "new" at all.

3) extends is achieved by using prototype keyword as shown in the clone() method above.

4) Any objects can be extended as easily as just defining a method or property on the object directly as follows


Author.setName = function(name) {
 this.name = name;
}

Private Members in Javascript

2009-09-27T23:03:00.000-07:00

I just had a glance at this wonderful article on Private Members in Javascript, its really worth a read.

Objects

JavaScript is fundamentally about objects. Arrays are objects. Functions are objects. Objects are objects. So what are objects? Objects are collections of name-value pairs. The names are strings, and the values are strings, numbers, booleans, and objects (including arrays and functions). Objects are usually implemented as hashtables so values can be retrieved quickly.

If a value is a function, we can consider it a method. When a method of an object is invoked, the this variable is set to the object. The method can then access the instance variables through the this variable.

Objects can be produced by constructors, which are functions which initialize objects. Constructors provide the features that classes provide in other languages, including static variables and methods.

Public

The members of an object are all public members. Any function can access, modify, or delete those members, or add new members. There are two main ways of putting members in a new object:

In the constructor

This technique is usually used to initialize public instance variables. The constructor's this variable is used to add members to the object.

function Container(param) {
  this.member = param;
}

So, if we construct a new object

var myContainer = new Container('abc');

then myContainer.member contains 'abc'.

In the prototype

This technique is usually used to add public methods. When a member is sought and it isn't found in the object itself, then it is taken from the object's constructor's prototype member. The prototype mechanism is used for inheritance. It also conserves memory. To add a method to all objects made by a constructor, add a function to the constructor's prototype:

Container.prototype.stamp = function (string) {
  return this.member + string;
}

So, we can invoke the method

myContainer.stamp('def')

which produces 'abcdef'.

Private

Private members are made by the constructor. Ordinary vars and parameters of the constructor becomes the private members.

function Container(param) {
  this.member = param;
  var secret = 3;
  var that = this;
}

This constructor makes three private instance variables: param, secret, and that. They are attached to the object, but they are not accessible to the outside, nor are they accessible to the object's own public methods. They are accessible to private methods. Private methods are inner functions of the constructor.

function Container(param) {

  function dec() {
      if (secret > 0) {
          secret -= 1;
          return true;
      } else {
          return false;
      }
  }

  this.member = param;
  var secret = 3;
  var that = this;
}

The private method dec examines the secret instance variable. If it is greater than zero, it decrements secret and returns true. Otherwise it returns false. It can be used to make this object limited to three uses.

By convention, we make a private that parameter. This is used to make the object available to the private methods. This is a workaround for an error in the ECMAScript Language Specification which causes this to be set incorrectly for inner functions.

Private methods cannot be called by public methods. To make private methods useful, we need to introduce a privileged method.

Privileged

A privileged method is able to access the private variables and methods, and is itself accessible to the public methods and the outside. It is possible to delete or replace a privileged method, but it is not possible to alter it, or to force it to give up its secrets.

Privileged methods are assigned with this within the constructor.

function Container(param) {

  function dec() {
      if (secret > 0) {
          secret -= 1;
          return true;
      } else {
          return false;
      }
  }

  this.member = param;
  var secret = 3;
  var that = this;

  this.service = function () {
      if (dec()) {
          return that.member;
      } else {
          return null;
      }
  };
}

service is a privileged method. Calling myContainer.service() will return 'abc' the first three times it is called. After that, it will return null. service calls the private dec method which accesses the private secret variable. service is available to other objects and methods, but it does not allow direct access to the private members.

Closures

This pattern of public, private, and privileged members is possible because JavaScript has closures. What this means is that an inner function always has access to the vars and parameters of its outer function, even after the outer function has returned. This is an extremely powerful property of the language. There is no book currently available on JavaScript programming that shows how to exploit it. Most don't even mention it.

Private and privileged members can only be made when an object is constructed. Public members can be added at any time.

Patterns

Public

function Constructor(...) {
this.membername = value;

}
Constructor.prototype.membername = value;

Private

function Constructor(...) {
var that = this; varmembername = value;
function membername(...) {...}

}

Note: The function statement

function membername(...) {...}

is shorthand for

var membername = function membername(...) {...};

Privileged

function Constructor(...) {
this.membername = function (...) {...};

}

Original Source

Prototype Based Programming

2009-09-27T10:01:00.000-07:00

Prototype-based programming is a style of object-oriented programming in which classes are not present, and behavior reuse (known as inheritance in class-based languages) is performed via a process of cloning existing objects that serve as prototypes. This model can also be known as class-less, prototype-oriented or instance-based programming.

The original (and most canonical) example of a prototype-based language is the programming language Self developed by David Ungar and Randall Smith. However, the classless programming style has recently grown increasingly popular, and has been adopted for the programming languages JavaScript, Cecil, NewtonScript, Io, MOO, REBOL, Lisaac and several others.

Comparison with class-based models

With class-based languages, the structure of objects is specified in programmer-defined types called classes. While classes define the type of data and functionality that objects will have, instances are "usable" objects based on the patterns of a particular class. In this model, classes act as collections of behavior (methods) and structure that are the same for all instances, whereas instances carry the objects' data. The role distinction is thus primarily based on a distinction between structure and behavior on the one hand, and state on the other.

Advocates of prototype-based programming often argue that class-based languages encourage a model of development that focuses first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behavior of some set of examples and only later worry about classifying these objects into archetypal objects that are later used in a fashion similar to classes. As such, many prototype-based systems encourage the alteration of prototypes during runtime, whereas only very few class-based object-oriented systems (such as the first dynamic object-oriented system, Smalltalk) allow classes to be altered during the execution of a program.

While the vast majority of prototype-based systems are based around interpreted and dynamically typed programming languages, it is important to point out that statically typed systems based around prototypes are technically feasible. The Omega programming language discussed in Prototype-Based Programming ^[1] is an example of such a system, though according to Omega's website even Omega is not exclusively static but rather its "compiler may choose to use static binding where this is possible and may improve the efficiency of a program."

Object construction

In class-based languages a new instance is constructed through the class's constructor and an optional set of constructor arguments. The resulting instance is modeled on the layout and behavior dictated by the chosen class.

In prototype-based systems there are two methods of constructing new objects, through cloning of an existing object, and through ex nihilo ("from nothing") object creation. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.^[2]

Systems that support ex nihilo object creation allow new objects to be created from scratch without cloning from an existing prototype. Such systems provide a special syntax for specifying the properties and behaviors of new objects without referencing existing objects. In many prototype languages, there is often a basic Object prototype that carries commonly needed methods and is used as a master prototype for all other objects. One useful aspect of ex nihilo object creation is to ensure that a new object's slot names do not have namespace collisions with the top-level Object object. (In the Mozilla JavaScript implementation, one can accomplish this by setting a newly constructed object's __proto__ property to null.)

Cloning refers to a process whereby a new object is constructed by copying the behavior of an existing object (its prototype). The new object then carries all the qualities of the original. From this point on, the new object can be modified. In some systems the resulting child object maintains an explicit link (via delegation or resemblance) to its prototype, and changes in the prototype cause corresponding changes to be apparent in its clone. Other systems, such as the Forth-like programming language Kevo, do not propagate change from the prototype in this fashion, and instead follow a more concatenative model where changes in cloned objects do not automatically propagate across descendants.^[3]

//Example of true prototypal inheritance style in JavaScript.

//"ex nihilo" object creation employing the literal object notation {}.
var foo = {one: 1, two: 2};
//another "ex nihilo" object.
var bar = {three: 3};

//Gecko and Webkit JavaScript engines can directly manipulate the internal prototype link.
//For the sake of simplicity, let's just pretend that the following line works regardless of the engine used:
bar.__proto__ = foo; // bar is now the child of foo.

//If we try to access foo's properties from bar from now on, we'll succeed. 
bar.one //resolves to 1.

//The child objects properties are also accessible.
bar.three //resolves 3.

Delegation

In prototype-based languages that use delegation, the language runtime is capable of dispatching the correct method or finding the right piece of data simply by following a series of delegation pointers (from object to its prototype) until a match is found. All that is required to establish this behavior-sharing between objects is the delegation pointer. Unlike the relationship between class and instance in class-based object-oriented languages, the relationship between the prototype and its offshoots does not require that the child object have a memory or structural similarity to the prototype beyond this link. As such, the child object can continue to be modified and amended over time without rearranging the structure of its associated prototype as in class-based systems. It is also important to note that not only data but also methods can be added or changed. For this reason, most prototype-based languages refer to both data and methods as "slots".

Criticism

Advocates of class-based object models who criticize prototype-based systems often have concerns that could be seen as similar to those concerns that proponents of static type systems for programming languages have of dynamic type systems (see Datatype). Usually, such concerns involve: correctness, safety, predictability, and efficiency.

On the first three points, classes are often seen as analogous to types (in most statically typed object-oriented languages they serve that role) and are proposed to provide contractual guarantees to their instances, and to users of their instances, that they will behave in some given fashion.

On the last point, efficiency, the declaration of classes simplifies many compiler optimizations that allow developing efficient method and instance variable lookup. For the Self language, much development time was spent on developing, compiling, and interpreting techniques to improve the performance of prototype-based systems versus class-based systems. For example, the Lisaac compiler produces code almost as fast as C. Tests have been run with an MPEG-2 codec written in Lisaac, copied from a C version. These tests show the Lisaac version is 1.9% slower than the C version with 37% fewer lines of code^[5].

The most common criticism made against prototype-based languages is that the community of software developers is not familiar with them, despite the popularity and market permeation of JavaScript. This knowledge level of prototype based systems seems to be changing with the proliferation of JavaScript frameworks and increases in the complex use of JavaScript as "Web 2.0" matures.

Scope in Javascript

2009-09-27T07:54:00.000-07:00

Scope is one of the foundational aspects of the JavaScript language, and probably the one I’ve struggled with the most when building complex programs. I can’t count the number of times I’ve lost track of what the this keyword refers to after passing control around from function to function, and I’ve often found myself contorting my code in all sorts of confusing ways, trying to retain some semblance of sanity in my understanding of which variables were accessible where.

In typical object-oriented programming, we need a way of identifying and referring to the object that we’re currently working with. this serves the purpose admirably, providing our objects the ability to examine themselves, and point at their own properties.

This article will tackle the problem head-on, outlining definitions of context and scope, examining two JavaScript methods that allow us to manipulate context, and concluding with a deep dive into an effective solution to ninety percent of the problems I’ve run into.
Where Am I? And Who Are You?

Every bit of your JavaScript program is executed in one execution context or another. You can think of these contexts as your code’s neighborhood, giving each line an understanding of where it comes from, and who its friends and neighbors are. As it turns out, this is important information, as JavaScript societies have fairly strict rules about who can associate with whom; execution contexts are better thought of as gated communities than as open subdivisions.

We can refer to these social boundaries generally as scope, and they’re important enough to be codified in each neighborhood’s charter, which we’ll refer to as the context’s scope chain. Code within a particular neighborhood can only access variables listed on its scope chain, and prefers interaction with locals to associations outside its neighborhood.

Practically speaking, evaluating a function establishes a distinct execution context that appends its local scope to the scope chain it was defined within. JavaScript resolves identifiers within a particular context by climbing up the scope chain, moving locally to globally. This means that local variables with the same name as variables higher up on the scope chain take precedence, which makes sense: If my good friends are talking together about “Mike West,” it’s pretty clear that they’re talking about me, not about the bluegrass singer or the Duke professor, even though the latter two are (arguably) better known.

Let’s walk through some example code to explore the implications:


<script type="text/javascript">
var ima_celebrity = "Everyone can see me! I'm famous!",
the_president = "I'm the decider!";

function pleasantville() {
var the_mayor = "I rule Pleasantville with an iron fist!",
 ima_celebrity = "All my neighbors know who I am!";

function lonely_house() {
 var agoraphobic = "I fear the day star!",
  a_cat = "Meow.";
}
}
</script>

Our global star, ima_celebrity, is recognized by everyone. She’s politically active, talking with the_president on a fairly frequent basis, and incredibly friendly; she’ll sign autographs and answer questions for anyone she runs into. That said, she doesn’t have a whole lot of personal contact with her fans. She’s pretty sure they exist and that they probably have lives of their own somewhere, but she certainly doesn’t know what they’re doing, or even their names.

Inside pleasantville, the_mayor is a well-known face. She’s always walking the streets of her town, chatting up her constituents, shaking hands, and kissing babies. As pleasantville is a big, important neighborhood, she’s got a big red phone in her office, giving her a direct line to the president (or at least a top aide) 24 hours a day, 7 days a week. She’s seen lonely_house up on a hill at the outskirts of town, but never really worried about who lives inside.

That lonely_house is a world unto itself. The agoraphobic stays inside most of the time, playing solitaire and feeding a_cat. He’s called the_mayor a few times to ask about local noise regulations, and even wrote ima_celebrity (Pleasantville’s ima_celebrity, that is) some fan mail after seeing her on the local news.
this? What’s that?

In addition to establishing a scope chain, each execution context offers a keyword named this. In its most common usage, this serves as an identity function, providing our neighborhoods a way of referring to themselves. We can’t always rely on that behavior, however: Depending on how we get into a particular neighborhood, this might mean something else entirely. In fact, how we get into the neighborhood is itself exactly what this generally refers to. Four scenarios deserve special attention:

* Calling an Object’s Method

In typical object-oriented programming, we need a way of identifying and referring to the object that we’re currently working with. this serves the purpose admirably, providing our objects the ability to examine themselves, and point at their own properties.


     <script type="text/javascript">
      var deep_thought = {
       the_answer: 42,
       ask_question: function () {
        return this.the_answer;
       }
      };
   
      var the_meaning = deep_thought.ask_question();
     </script>

This example builds an object named deep_thought, sets its the_answer property to 42, and creates an ask_question method. When deep_thought.ask_question() is executed, JavaScript establishes an execution context for the function call, setting this to the object referenced by whatever came before the last ”.”, in this case: deep_thought. The method can then look in the mirror via this to examine its own properties, returning the value stored in this.the_answer: 42.

* Constructor

Likewise, when defining a function to be used as a constructor with the new keyword, this can be used to refer to the object being created. Let’s rewrite the example above to reflect that scenario:


     <script type="text/javascript">
      function BigComputer(answer) {
       this.the_answer = answer;
       this.ask_question = function () {
        return this.the_answer;
       }
      }
   
      var deep_thought = new BigComputer(42);
      var the_meaning = deep_thought.ask_question();
     </script>

Instead of explicitly creating the deep_thought object, we’ll write a function to create BigComputer objects, and instantiate deep_thought as an instance variable via the new keyword. When new BigComputer() is executed, a completely new object is created transparently in the background. BigComputer is called, and its this keyword is set to reference that new object. The function can set properties and methods on this, which is transparently returned at the end of BigComputer’s execution.

Notice, though, that deep_thought.the_question() still works just as it did before. What’s going on there? Why does this mean something different inside the_question than it does inside BigComputer? Put simply, we entered BigComputer via new, so this meant “the new object.” On the other hand, we entered the_question via deep_thought, so while we’re executing that method, this means “whatever deep_thought refers to”. this is not read from the scope chain as other variables are, but instead is reset on a context by context basis.

* Function Call

What if we just call a normal, everyday function without any of this fancy object stuff? What does this mean in that scenario?


     <script type="text/javascript">
      function test_this() {
       return this;
      }
      var i_wonder_what_this_is = test_this();
     </script>

In this case, we weren’t provided a context by new, nor were we given a context in the form of an object to piggyback off of. Here, this defaults to reference the most global thing it can: for web pages, this is the window object.

* Event Handler

For a more complicated twist on the normal function call, let’s say that we’re using a function to handle an onclick event. What does this mean when the event triggers our function’s execution? Unfortunately, there’s not a simple answer to this question.

If we write the event handler inline, this refers to the global window object:


     <script type="text/javascript">
      function click_handler() {
       alert(this); // alerts the window object
      }
     </script>
     ...
     <button id='thebutton' onclick='click_handler()'>Click me!</button>

However, when we add an event handler via JavaScript, this refers to the DOM element that generated the event. (Note: The event handling shown here is short and readable, but otherwise poor. Please use a real addEvent function instead.):


     <script type="text/javascript">
      function click_handler() {
       alert(this); // alerts the button DOM node
      }
   
      function addhandler() {
       document.getElementById('thebutton').onclick = click_handler;
      }
   
      window.onload = addhandler;
     </script>
     ...
     <button id='thebutton'>Click me!</button>

Complications

Let’s run with that last example for a moment longer. What if instead of running click_handler, we wanted to ask deep_thought a question every time we clicked the button? The code for that seems pretty straightforward; we might try this:


<script type="text/javascript">
function BigComputer(answer) {
this.the_answer = answer;
this.ask_question = function () {
 alert(this.the_answer);
}
}

function addhandler() {
var deep_thought = new BigComputer(42),
 the_button = document.getElementById('thebutton');

the_button.onclick = deep_thought.ask_question;
}

window.onload = addhandler;
</script>

Perfect, right? We click on the button, deep_thought.ask_question is executed, and we get back “42.” So why is the browser giving us undefined instead? What did we do wrong?

The problem is simply this: We’ve passed off a reference to the ask_question method, which, when executed as an event handler, runs in a different context than when it’s executed as an object method. In short, the this keyword in ask_question is pointing at the DOM element that generated the event, not at a BigComputer object. The DOM element doesn’t have a the_answer property, so we’re getting back undefined instead of “42.” setTimeout exhibits similar behavior, delaying the execution of a function while at the same time moving it out into a global context.

This issue crops up all over the place in our programs, and it’s a terribly difficult problem to debug without keeping careful track of what’s going on in all the corners of your program, especially if your object has properties that do exist on DOM elements or the window object.
Manipulating Context With .apply() and .call()

We really do want to be able to ask deep_thought a question when we click the button, and more generally, we do want to be able to call object methods in their native context when responding to things like events and setTimeout calls. Two little-known JavaScript methods, apply and call, indirectly enable this functionality by allowing us to manually override the default value of this when we execute a function call. Let’s look at call first:


<script type="text/javascript">
var first_object = {
num: 42
};
var second_object = {
num: 24
};

function multiply(mult) {
return this.num * mult;
}

multiply.call(first_object, 5); // returns 42 * 5
multiply.call(second_object, 5); // returns 24 * 5
</script>

In this example, we first define two objects, first_object and second_object, each with a num property. Then we define a multiply function that accepts a single argument, and returns the product of that argument, and the num property of its this object. If we called that function by itself, the answer returned would almost certainly be undefined, since the global window object doesn’t have a num property unless we explicitly set one. We need some way of telling multiply what its this keyword ought refer to; the call method of the multiply function is exactly what we’re looking for.

The first argument to call defines what this means inside the executed function. The remaining arguments to call are passed into the executed function, just as if you’d called it yourself. So, when multiply.call(first_object, 5) is executed, the multiply function is called, 5 is passed in as the first argument, and the this keyword is set to refer to object first_object. Likewise, when multiply.call(second_object, 5) is executed, the multiply function is called, 5 is passed in as the first argument, and the this keyword is set to refer to object second_object.

apply works in exactly the same way as call, but allows you to wrap up the arguments to the called function in an array, which can be quite useful when programatically generating function calls. Replicating the functionality we just talked about using apply is trivial:


<script type="text/javascript">
...

multiply.apply(first_object, [5]); // returns 42 * 5
multiply.apply(second_object, [5]); // returns 24 * 5
</script>

apply and call are very useful on their own, and well worth keeping around in your toolkit, but they only get us halfway to solving the problem of context shifts for event handlers. It’s easy to think that we could solve the problem by simply using call to shift the meaning of this when we set up the handler:


function addhandler() {
var deep_thought = new BigComputer(42),
the_button = document.getElementById('thebutton');

the_button.onclick = deep_thought.ask_question.call(deep_thought);
}

The problem with this line of reasoning is simple: call executes the function immediately. Instead of providing a function reference to the onclick handler, we’re giving it the result of an executed function. We need to exploit another feature of JavaScript to really solve this problem.

The Beauty of .bind()

I’m not a huge fan of the Prototype JavaScript framework, but I am very much impressed with the quality of its code as a whole. In particular, one simple addition it makes to the Function object has had a hugely positive impact on my ability to manage the context in which function calls execute: bind performs the same general task as call, altering the context in which a function executes. The difference is that bind returns a function reference that can be used later, rather than the result of an immediate execution that we get with call.

If we simplify the bind function a bit to get at the key concepts, we can insert it into the multiplication example we discussed earlier to really dig into how it works; it’s quite an elegant solution:


<script type="text/javascript">
var first_object = {
num: 42
};
var second_object = {
num: 24
};

function multiply(mult) {
return this.num * mult;
}

Function.prototype.bind = function(obj) {
var method = this,
 temp = function() {
  return method.apply(obj, arguments);
 };

return temp;
}

var first_multiply = multiply.bind(first_object);
first_multiply(5); // returns 42 * 5

var second_multiply = multiply.bind(second_object);
second_multiply(5); // returns 24 * 5
</script>

First, we define first_object, second_object, and the multiply function, just as before. With those taken care of, we move on to creating a bind method on the Function object’s prototype, which has the effect of making bind available for all functions in our program. When multiply.bind(first_object) is called, JavaScript creates an execution context for the bind method, setting this to the multiply function, and setting the first argument, obj, to reference first_object. So far, so good.

The real genius of this solution is the creation of method, set equal to this (the multiply function itself). When the anonymous function is created on the next line, method is accessible via its scope chain, as is obj (this couldn’t be used here, because when the newly created function is executed, this will be overwritten by a new, local context). This alias to this makes it possible to use apply to execute the multiply function, passing in obj to ensure that the context is set correctly. In computer-science-speak, temp is a closure that, when returned at the end of the bind call, can be used in any context whatsoever to execute multiply in the context of first_object.

This is exactly what we need for the event handler and setTimeout scenarios discussed above. The following code solves that problem completely, binding the deep_thought.ask_question method to the deep_thought context, so that it executes correctly whenever the event is triggered:


function addhandler() {
var deep_thought = new BigComputer(42),
the_button = document.getElementById('thebutton');

the_button.onclick = deep_thought.ask_question.bind(deep_thought);
}

Beautiful.

References

* JavaScript Closures is the best resource on the net for a thorough discussion of closures: what they do, how they do it, and how to use them without going insane.
* The Protype JavaScript Framework is full of little nuggets like bind. The version available here not only allows the binding of a particular this value, but also of some or all of a function’s arguments, which comes in handy all too often.
* Douglas Crockford’s JavaScript essays are excellent resources for both basic and advanced JavaScript programmers. The man knows what he’s talking about, and explains difficult concepts in an easy-to-grasp manner.
* Variable Scope for New Programmers is a good article if you'd like more discussion of scope from a beginner's perspective. Written by Jonathan Snook, and published in this very magazine at the end of last year, it's still an informative and useful read.

Original Source

First ExtJs program

2009-09-26T04:44:00.001-07:00


<html>
<head>

   <!--
       The following css and scripts are needed for any ext js programming.
       ext-all.css is the css file, ext-base.js is the core ext js file
       which helps in AJAX Communication, DOM Manipulation, Event Management.
       ext-all-debug.js contains the ui components, data services, remoting, Drag & Drop and Utilities

   -->
   <link rel="stylesheet" type="text/css" href="../resources/css/ext-all.css" />
   <script type="text/javascript" src="../adapter/ext/ext-base.js"></script>
   <script type="text/javascript" src="../ext-all-debug.js"></script>
   <script type="text/javascript">
       Ext.BLANK_IMAGE_URL = '../resources/images/default/s.gif';
   </script>

   <script type="text/javascript">
       function buildWindow() {
           var win = new Ext.Window(

           //Configuration Node for the Window
           {
               id : 'myWindow',
               title : 'My first Ext JS Window',
               width : 300,
               height : 150,
               layout : 'fit',
           });
           win.show(); // 3
       }

       //Entry point for any ext js code
       Ext.onReady(buildWindow);


   </script>
</head>
<body>

   <script type='text/javascript'>
       function highlightWindow() {
           var win = Ext.getCmp('myWindow');
           var winBody = win.body;
           winBody.highlight();
       }
       highlightWindow.defer(1000);
   </script>
</body>
</html>

Saving (detached) entities

2009-09-12T05:57:00.000-07:00

Saving an entity in JPA is simple, right? We just pass the object we want to persist to EntityManager.persist. It all seems to work quite well until we run into the dreaded "detached entity passed to persist" message. Or a similar message when we use a different JPA provider than the Hibernate EntityManager.

So what is that detached entity the message talks about? A detached entity (a.k.a. a detached object) is an object that has the same ID as an entity in the persistence store but that is no longer part of a persistence context (the scope of an EntityManager session). The two most common causes for this are:

The EntityManager from which the object was retrieved has been closed.
The object was received from outside of our application, e.g. as part of a form submission, a remoting protocol such as Hessian, or through a BlazeDS AMF Channel from a Flex client.

The contract for persist (see section 3.2.1 of the JPA 1.0 spec) explicitly states that an EntityExistsException is thrown by the persist method when the object passed in is a detached entity. Or any other PersistenceException when the persistence context is flushed or the transaction is committed. Note that it is not a problem to persist the same object twice within one transaction. The second invocation will just be ignored, although the persist operation might be cascaded to any associations of the entity that were added since the first invocation. Apart from that latter consideration there is no need to invoke EntityManager.persist on an already persisted entity because any changes will automatically be saved at flush or commit time.

saveOrUpdate vs. merge

Those of you that have worked with plain Hibernate will probably have grown quite accustomed to using the Session.saveOrUpdate method to save entities. The saveOrUpdate method figures out whether the object is new or has already been saved before. In the first case the entity is saved, in the latter case it is updated.

When switching from Hibernate to JPA a lot of people are dismayed to find that method missing. The closest alternative seems to be the EntityManager.merge method, but there is a big difference that has important implications. The Session.saveOrUpdate method, and its cousin Session.update, attach the passed entity to the persistence context while EntityManager.merge method copies the state of the passed object to the persistent entity with the same identifier and then return a reference to that persistent entity. The object passed is not attached to the persistence context.

That means that after invoking EntityManager.merge, we have to use the entity reference returned from that method in place of the original object passed in. This is unlike the the way one can simply invoke EntityManager.persist on an object (even multiple times as mentioned above!) to save it and continue to use the original object. Hibernate's Session.saveOrUpdate does share that nice behaviour with EntityManager.persist (or rather Session.save) even when updating, but it has one big drawback; if an entity with the same ID as the one we are trying to update, i.e. reattach, is already part of the persistence context, a NonUniqueObjectException is thrown. And figuring out what piece of code persisted (or merged or retrieved) that other entity is harder than figuring out why we get a "detached entity passed to persist" message.

Putting it all together

So let's examine the three possible cases and what the different methods do:

Scenario	`EntityManager.persist`	`EntityManager.merge`	`SessionManager.saveOrUpdate`
Object passed was never persisted	1. Object added to persistence context as new entity 2. New entity inserted into database at flush/commit	1. State copied to new entity. 2. New entity added to persistence context 3. New entity inserted into database at flush/commit 4. New entity returned	1. Object added to persistence context as new entity 2. New entity inserted into database at flush/commit
Object was previously persisted, but not loaded in this persistence context	1. `EntityExistsException` thrown (or a `PersistenceException` at flush/commit)	2. Existing entity loaded. 2. State copied from object to loaded entity 3. Loaded entity updated in database at flush/commit 4. Loaded entity returned	1. Object added to persistence context 2. Loaded entity updated in database at flush/commit
Object was previously persisted and already loaded in this persistence context	1. `EntityExistsException` thrown (or a `PersistenceException` at flush or commit time)	1. State from object copied to loaded entity 2. Loaded entity updated in database at flush/commit 3. Loaded entity returned	1. `NonUniqueObjectException` thrown

Looking at that table one may begin to understand why the saveOrUpdate method never became a part of the JPA specification and why the JSR members instead choose to go with the merge method. BTW, you can find a different angle on the saveOrUpdate vs. merge problem in Stevi Deter's blog about the subject.

The problem with merge

Before we continue, we need to discuss one disadvantage of the way EntityManager.merge works; it can easily break bidirectional associations. Consider the example with the Order and OrderLine classes from the previous blog in this series. If an updated OrderLine object is received from a web front end (or from a Hessian client, or a Flex application, etc.) the order field might be set to null. If that object is then merged with an already loaded entity, the order field of that entity is set to null. But it won't be removed from the orderLines set of the Order it used to refer to, thereby breaking the invariant that every element in an Order's orderLines set has its order field set to point back at that Order.

In this case, or other cases where the simplistic way EntityManager.merge copies the object state into the loaded entity causes problems, we can fall back to the DIY merge pattern. Instead of invoking EntityManager.merge we invoke EntityManager.find to find the existing entity and copy over the state ourselves. If EntityManager.find returns null we can decide whether to persist the received object or throw an exception. Applied to the Order class this pattern could be implemented like this:


 Order existingOrder = dao.findById(receivedOrder.getId());
 if(existingOrder == null) {
  dao.persist(receivedOrder);
 } else {
  existingOrder.setCustomerName(receivedOrder.getCustomerName());
  existingOrder.setDate(receivedOrder.getDate());
 }

The pattern

So where does all this leave us? The rule of thumb I stick to is this:

When and only when (and preferably where) we create a new entity, invoke EntityManager.persist to save it. This makes perfect sense when we view our domain access objects as collections. I call this the persist-on-new pattern.
When updating an existing entity, we do not invoke any EntityManager method; the JPA provider will automatically update the database at flush or commit time.
When we receive an updated version of an existing simple entity (an entity with no references to other entities) from outside of our application and want to save the new state, we invoke EntityManager.merge to copy that state into the persistence context. Because of the way merging works, we can also do this if we are unsure whether the object has been already persisted.
When we need more control over the merging process, we use the DIY merge pattern.

I hope this blog gives you some pointers on how to save entities and how to work with detached entities. We'll get back to detached entities when we discuss Data Transfer Objects in a later blog. But next week we'll handle a number of common entity retrieval pattern first. In the meantime your feedback is welcome. What are your JPA patterns?

Original Source

Bidirectional assocations

2009-09-12T03:48:00.000-07:00

JPA offers the @OneToMany, @ManyToOne, @OneToOne, and @ManyToMany annotations to map associations between objects. While EJB 2.x offered container managed relationships to manage these associations, and especially to keep bidirectional associations in sync, JPA leaves more up to the developer.

The setup

Let's start by expanding the Order example from the previous blog with an OrderLine object. It has an id, a description, a price, and a reference to the order that contains it:

@Entity
public class OrderLine {
@Id
@GeneratedValue
private int id;

private String description;

private int price;

@ManyToOne
private Order order;

public int getId() { return id; }
public void setId(int id) { this.id = id; }

public String getDescription() { return description; }
public void setDescription(String description) { this.description = description; }

public int getPrice() { return price; }
public void setPrice(int price) { this.price = price; }

public Order getOrder() { return order; }
public void setOrder(Order order) { this.order = order; }
}

Using the generic DAO pattern, we quickly get ourselves a very basic OrderLineDao interface and an implementation:

public interface OrderLineDao extends Dao<Integer, OrderLine> {
public List<OrderLine> findOrderLinesByOrder(Order o);
}

public class JpaOrderLineDao extends JpaDao<Integer, OrderLine> implements
 OrderLineDao {

public List<OrderLine> findOrderLinesByOrder(Order o) {
 Query q = entityManager.createQuery("SELECT e FROM "
   + entityClass.getName() + " e WHERE order = :o ");
 q.setParameter("o", o);
 return (List<OrderLine>) q.getResultList();
}
}

We can use this DAO to add a orderline to an order, or to find all the order lines for an order:

 OrderLine line = new OrderLine();
line.setDescription("Java Persistence with Hibernate");
line.setPrice(5999);
line.setOrder(o);
orderLineDao.persist(line);

Collection<OrderLine> lines = orderLineDao.findOrderLinesByOrder(o);

Mo associations, mo problems

All this is pretty straight forward, but it gets interesting when we make this association bidirectional. Let's add an orderLines field to our Order object and include a naïve implementation of the getter/setter pair:

 @OneToMany(mappedBy = "order")
private Set<OrderLine> orderLines = new HashSet<OrderLine>();

public Set<OrderLine> getOrderLines() { return orderLines; }
public void setOrderLines(Set<
OrderLine> orderLines) { this.orderLines = orderLines; }

The mappedBy field on the @OneToMany annotation tells JPA that this is the reverse side of an association and, instead of mapping this field directly to a database column, it can look at order field of a OrderLine object to know with which Order object it goes.

So without changing the underlying database we can now retrieve the orderlines for an order like this:

 Collection<
OrderLine> lines = o.getOrderLines();

No more need to access the OrderLineDao.

But there is a catch! While container managed relationships (CMR) as defined by EJB 2.x made sure that adding an OrderLine object to the orderLines property of an Order also sets the order property on that OrderLine (and vice versa), JPA (being a POJO framework) performs no such magic. This is actually a good thing because it makes our domain objects usable outside of a JPA container, which means you can test them more easily and use them when they have not been persisted (yet). But it can also be confusing for people that were used to EJB 2.x CMR behaviour.

If you run the examples above in separate transactions, you will find that they run correctly. But if you run them within one transaction like the code below does, you will find that the item list while be empty:

 Order o = new Order();
o.setCustomerName("Mary Jackson");
o.setDate(new Date());

OrderLine line = new OrderLine();
line.setDescription("Java Persistence with Hibernate");
line.setPrice(5999);
line.setOrder(o);

System.out.println("Items ordered by " + o.getCustomerName() + ": ");
Collection<OrderLine> lines = o.getOrderLines();
for (OrderLine each : lines) {
 System.out.println(each.getId() + ": " + each.getDescription()
   + " at $" + each.getPrice());
}

This can be fixed by adding the following line before the first System.out.println statement:

 o.getOrderLines().add(line);

Fixing and fixing...

It works, but it's not very pretty. It breaks the abstraction and it's brittle as it depends on the user of our domain objects to correctly invoke these setters and adders. We can fix this by moving that invocation into the definition of OrderLine.setOrder(Order):

 public void setOrder(Order order) {
 this.order = order;
 order.getOrderLines().add(this);
}

When can do even better by encapsulating the orderLines property of the Order object in a better manner:

 public Set<OrderLine> getOrderLines() { return orderLines; }
public void addOrderLine(OrderLine line) { orderLines.add(line); }

And then we can redefine OrderLine.setOrder(Order) as follows:

 public void setOrder(Order order) {
 this.order = order;
 order.addOrderLine(this);
}

Still with me? I hope so, but if you're not, please try it out and see for yourself.

Now another problem pops up. What if someone directly invokes the Order.addOrderLine(OrderLine) method? The OrderLine will be added to the orderLines collection, but its order property will not point to the order it belongs. Modifying Order.addOrderLine(OrderLine) like below will not work because it will cause an infinite loop with addOrderLine invoking setOrder invoking addOrderLine invoking setOrder etc.:

 public void addOrderLine(OrderLine line) {
 orderLines.add(line);
 line.setOrder(this);
}

This problem can be solved by introducing an Order.internalAddOrderLine(OrderLine) method that only adds the line to the collection, but does not invoke line.setOrder(this). This method will then be invoked from OrderLine.setOrder(Order) and not cause an infinite loop. Users of the Order class should invoke Order.addOrderLine(OrderLine).

The pattern

Taking this idea to its logical conclusion we end up with these methods for the OrderLine class:

 public Order getOrder() { return order; }

public void setOrder(Order order) {
 if (this.order != null) { this.order.internalRemoveOrderLine(this); }
 this.order = order;
 if (order != null) { order.internalAddOrderLine(this); }
}

And these methods for the Order class:

 public Set<OrderLine> getOrderLines() { return Collections.unmodifiableSet(orderLines); }

public void addOrderLine(OrderLine line) { line.setOrder(this); }
public void removeOrderLine(OrderLine line) { line.setOrder(null); }

public void internalAddOrderLine(OrderLine line) { orderLines.add(line); }
public void internalRemoveOrderLine(OrderLine line) { orderLines.remove(line); }

These methods provide a POJO-based implementation of the CMR logic that was built into EJB 2.x. With the typical POJOish advantages of being easier to understand, test, and maintain.

Of course there are a number of variations on this theme:

If Order and OrderLine are in the same package, you can give the internal... methods package scope to prevent them from being invoked by accident. (This is where C++'s friend class concept would come in handy. Then again, let's not go there. ).
You can do away with the removeOrderLine and internalRemoveOrderLine methods if order lines will never be removed from an order.
You can move the responsibility for managing the bidirectional association from the OrderLine.setOrder(Order) method to the Order class, basically flipping the idea around. But that would mean spreading the logic over the addOrderLine and removeOrderLine methods.
Instead of, or in addition to, using Collections.singletonSet to make the orderLine set read-only at run-time, you can also use generic types to make it read-only at compile-time:
```
public Set<
? extends OrderLine> getOrderLines() { return Collections.unmodifiableSet(orderLines); }
```
But this makes it harder to mock these objects with a mocking framework such as EasyMock.

There are also some things to consider when using this pattern:

Adding an OrderLine to an Order does not automatically persist it. You'll need to also invoke the persist method on its DAO (or the EntityManager) to do that. Or you can set the cascade property of the @OneToMany annotation on the Order.orderLines property to CascadeType.PERSIST (at least) to achieve that. More on this when we discuss the EntityManager.persist method.
Bidirectional associations do not play well with the EntityManager.merge method. We will discuss this when we get to the subject of detached objects.
When an entity that is part of a bidirectional associated is (about to be) removed, it should also be removed from the other end of the association. This will also come up when we talk about the EntityManager.remove method.
The pattern above only works when using field access (instead of property/method access) to let your JPA provider populate your entities. Field access is used when the @Id annotation of your entity is placed on the corresponding field as opposed of the corresponding getter. Whether to prefer field access or property/method access is a contentious issue to which I will return in a later blog.
And last but not least; while this pattern may be a technically sound POJO-based implementation of managed associations, you can argue why you need all those getters and setters. Why would you need to be able to use both Order.addOrderLine(OrderLine) and OrderLine.setOrder(Order) to achieve the same result? Doing away with one of these could make our code simpler. See for example James Holub's article on getters and setters. Then again, we've found that this pattern gives developers that use these domain objects the flexibility to associate them as they wish.

Original Source

Advanced JBoss Class Loading

2009-09-08T11:01:00.000-07:00

Advanced JBoss Class Loading

Introduction

One of the main concerns of a developer writing hot re-deployable JBoss applications is to understand how JBoss class loading works. Within the internals of the class loading mechanism lies the answer to questions like

What happens if I pack a newer version of an utility library with my application, while an older version of the same library lingers somewhere in the server's lib directory?
How can I use two different versions of the same utility library, simultaneously, within the same instance of the application server?
What version of an utility class I am currently using?

or even the most fundamental of them all

Why do I need to mess with all this class loading stuff anyway?

This article tries to provide the reader with the knowledge required to answer these questions. It will start by trying to answer the last one, and then it will present several often encountered use cases and explain the behavior of the JBoss class loading mechanism when faced with those situations.

The Need for Class Loaders and Class Loading Management

Class Namespace Isolation

An application server should ideally give its deployed applications the freedom to use whatever utility library and whatever version of the library they see fit, regardless of the presence of concurrent applications that want to use the same library. This is mandated by the J2EE specifications, which calls it class namespace isolation (Java EE 5 Specifications, Section EE.8.4). The fact that different applications load their classes in different class name spaces or class loading domains allow them to do just that: run whatever class version they like, oblivious to the fact that their neighbors use the same class.

Java doesn't provide the formal notion of class version. So how is it possible to implement a class loading domain? The runtime identity of a class in Java 2 is defined by the fully qualified class name and its defining class loader. This means that the same class, loaded by two different class loaders, is seen by the Virtual Machine as two completely different types.

If you like history, you probably know that this wasn't always the case. In Java 1.1 the runtime identity of a class was defined only by its fully qualified class name. That made Vijay Saraswat declare in 1997 that "[Java is not type-safe|http://matrix.research.att.com/vj/bug.html]" and Sheng Liang and Gilad Bracha fixed it by strengthening the type system to include a class's defining class loader in addition to the name of the class to fully define the type. This is good and ... not so good. It is good because now its not possible anymore that a rogue class loader would re-define your "java.lang.String" class. The VM will detect that and throw a ClassCastException. It is also good because now it is possible to have class loading domains within the same VM. Not so good however, is the fact that passing an object instance by reference between two class loading domains is not possible. Doing so results in the dreaded ClassCastException. If you would like to know more details about how this happens, please follow this link. Not being able to pass an Object by reference means you have to fall back on serialization and serialization means performance degradation.

Hot Redeployment

Returning to application servers, the need for class loaders becomes probably obvious: this is how an application server implements class namespace isolation: each application gets its own class loader at deployment, and hence, its own "version" of classes.

To extend this even more, it would be nice if we could re-deploy an application (i.e. instantiate a newer version of a class), at run-time, without necessarily bringing down the VM and re-starting it to reload the class. That would mean 24x7 uptime. Java 4 doesn't intrinsically support the concept of hot re-deployment. Once a dependent class reference was added to the runtime constant pool of a class, it is not possible to drop that reference anymore.

However, it is possible to trick the server (or the VM) into doing this. If application A interacts with application B, but doesn't have any direct references to the B classes, and B changes, let's say a newer and better version becomes available, it is possible to create a new class loader, load the new B classes and have the invocation bus (the application server) route all invocations from A to the new B classes. This way, A deals with a new version of B without even knowing it. If the application server is careful to drop all explicit references to the old B classes, they will eventually be garbage collected and the old B will eventually disappear from the system.

Sharing Classes

Isolating class loading domains is nice. Our applications will run happily and safe. But very slowly, when it comes to interacting with each other. This is because each interaction involves passing arguments by value, which means serialization, which means overhead.

We're sometimes (actually quite often) faced with the situation where in we would like to allow applications to share classes. We know precisely, for example, that in our environment, application A and B, otherwise independent, will always use the same version of the utility library and doing so, they could pass references among themselves without any problem. The added benefit in this case is that the invocations will be faster, given the fact serialization is cut out.

One word of caution though. In this situation, if we hot redeploy the utility library, we also must re-deploy the application A and B: the current A and B classes used direct references to the utility classes, so they're tainted forever, they won't ever be able to use the new utility classes.

JBoss makes possible for applications to share classes. JBoss 3.x does that by default. JBoss 4.0 does this for the "standard" configuration, but maintains class namespace isolation between applications for its "default" configuration. JBoss 4.0.1 reverts to the 3.x convention.

Class Repositories or How JBoss Class Loading Works

JBoss makes sharing classes possible by introducing the concept of class loader repository. The central piece of the class loading mechanism is the org.jboss.mx.loading.UnifiedClassLoader3 (UCL). UnifiedClassLoader3 extends URLClassLoader. Each UCL is associated with a shared repository of classes and resources, usually an instance of org.jboss.mx.loading.UnifiedLoaderRepository3. Every UCL is associated with a single instance of UnifiedLoaderRepository3, but a repository can have multiple UCLs. A UCL may have multiple URLs associated with it for class and resource loading. By default, there is a single UnifiedLoaderRepository3 shared across all UCL instances. UCLs form a single flat class namespace.

The class loader parent for each UCL is a NoAnnotationClassLoader instance. The NoAnnotationClassLoader extends URLClassLoader. A singleton NoAnnotationClassLoader instance is created during the server's boot process and its job is to define classes available in the $JBOSS_HOME/lib libraries (ex: commons-logging.jar, concurrent.jar, dom4j.jar, jboss-common.jar, jboss-jmx.jar, jboss-system.jar, log4j-boot.jar, xercesImpl.jar, etc.). The NoAnnotationClassLoader's parent is the system class loader (sun.misc.Launcher$AppClassLoader).

When a new UCL is created and associated with the repository, it contributes to the repository a map of packages it can potentially serve classes from. It doesn't add any class to the repository's class cache yet, because nobody has requested any class at this stage. The repository just walks through the class loader's URL to see what packages that UCL is capable of handling. So, the UCL just declares that it can potentially serve classes from the packages that are present in its classpath.

When requested to load a class, a UCL overrides the standard Java2 class loading model by first trying to load a class from its associated repository's cache. If it doesn't find it there, it delegates the task of loading the class to the first UCL associated with the repository that declared it can load that class. The order in which the UCLs have been added to the repository becomes important, because this is what defines "first" in this context. If no "available" UCL is found, the initiating UCL falls back to the standard Java2 parent delegation. This explains why you are still able to use "java.lang.String", for example.

At the end of this process, if no class definition is found in the bootstrap libraries, in the $JBOSS_HOME/lib libraries nor among the libraries associated with the repository's UCL, the UCL throws a ClassNotFoundException. However, if one of the pair UCL is able to load the class, the class will be added to the repository's class cache and from this moment on, it will be returned to any UCL requesting it.

Even if the Java bootstrap packages or $JAVA_HOME/lib packages are not added to the repository's package map, the classes belonging to those packages can be loaded through the process described above and they are added to the repository too. This explains why you'll find "java.lang.String" in the repository.

Note: Package Map is nothing but ...

/** A HashMap<String, Set<UCL>> of package names to the set of
    * ClassLoaders which have classes in the package.
    * Access synchronized via this.packagesMap monitor.
    */

Class sharing can be turned off. J2EE-style class namespace isolation is available. You get an "isolated" application by scoping the application's deployment. At the JBoss class loading management system level, scoping translates into creating a child repository. A scoped application still can load the classes present in the classpaths of the UCLs or the root repository. Depending on whether repository's "Java2ParentDelegation" flag is turned on or off, a scoped application even has access to the class instances available in the root repository's cache. However, sibling child repositories can never share classes.

Note: Even if an HierarchicalLoaderRepository3$NoParentClassLoader instance has its parent set to be an instance of NoAnnotationURLClassLoader, as represented above, the NoParentClassLoader implementation of loadClass() always throws a ClassNotFoundException to force the UCL to only load from its URLs. We will look closer at how NoParentClassLoader works and how a scoped application loads a class available in the system's bootstrap libraries when we present the Cases 3 and 4, below.

Real World Scenarios

We will explore the complex interactions presented above based on concrete use cases.

We start by assuming that we want to deploy our own application (be it a JBoss service, a complex enterprise archive or a simple stateless session bean), and this application relies on an external library. For simplicity, we could assume that the utility library contains only a single class, org.useful.Utility. The Utility class can be packed together with the application classes inside the application archive, or it could be packed in its own archive, utility.jar. We could also assume that we always use the JBoss' default configuration.

Our hypothetical application consists of a single class, org.pkg1.A. We will consider several common situations:

Case 1. The Utility.class is present in the application's archive, but nowhere else on the server.

The short story: The current UCL will become the defining class loader of the class, and the class will be added to the repository's class cache. The details of the process are presented below.

First time the application needs to use a strong-typed Utility reference, the VM asks the current UCL to load the class. The UCL tries to get the class from the repository's cache (1). If it is found, the class is returned and the process stops right here. If the class is not found, the UCL queries the repository for UCLs capable to load classes from the package the unknown class is part of (3). Being the single UCL able to define the class, the control returns to it and load manager calls loadClassLocally() on it (4). loadClassLocally() first tries to call super.loadClass() (5), which ends by involving the NoAnnotationClassLoader in the loading process. If the class is present in the bootstrap libraries or $JBOSS_HOME/lib (the URLs associated with the NoAnnotationClassLoader instance), it is loaded. Otherwise, the class is loaded from the URLs associated with the current UCL. Finally, the class is added to the repository's class cache (6).

This is the configuration of the UnifiedLoaderRepository after the class loading takes place.

Case 2. The Utility.class is present both in the application's archive AND server/default/lib. The deployment is non-scoped.

The short story: The version of the class available in server/default/lib/utility.jar will be used by the new deployment. The version of the class packed with the deployment will be ignored.

The key element here is that when getPackageClassLoaders() is invoked on the repository, the method calls returns two potential classloaders that can load org.useful.Utility: UCL0 and UCL1. The UCL0 is chosen, because it was added to the repository before UCL1 and it will be used to load org.useful.Utility.

This is the configuration of the UnifiedLoaderRepository after the class loading takes place.

Case 3. The Utility.class is present both in the application's archive AND server/default/lib. The deployment is scoped and Java2ParentDelegation is turned off (default).

The short story: The utility class is loaded from the application's archive.

Because Java2ParentDelegation is turned off by default, the Step (1.1) is never executed, parentRepository.getCachedClass() never gets called, so the UCL doesn't have access to the repository's cached classes.

Within the scope of the call to getPackageClassLoaders() at Step 3, the child repository also calls getPackageClassLoaders() on its parent, and also includes into the returned class loader set a UCL (constructed on the spot and associated to the child repository) that has among its ancestors an instance of NoAnnotationURLClassLoader, which ultimately can reach the system class loader. Why is that? Remember that the UCL's parent, HierarchicalLoaderRepository3$NoParentClassLoader, overrides loadClass() to always throw a ClassNotFoundException, thus forcing the UCL to only load from its URLs. If the UCL relies only on its class loader parent to load bootstrap classes, it will throw ClassNotFoundException and fail when your application wants to load "java.lang.String", for example. The NoAnnotationURLClassLoader-delegating UCL instance included in the return set provides a way load bootstrap library classes.

Always the HierarchialLoaderRepository's class loaders take precedence over the parent's (their "order" is lower). For the case depicted above, UCL1 is the preferred class loader.

This is the configuration of the UnifiedLoaderRepository after the class loading takes place.

Case 4. The Utility.class is present both in the application's archive AND server/default/lib. The deployment is scoped, but java2ParentDelegation is turned on.

When Java2ParentDelegation is turned on, the Step (1.1) is executed, and if a cached class is found in the parent repository, it is returned and the process stops here.

Within the scope of the call to getPackageClassLoaders() at Step (3), the child repository also calls getPackageClassLoaders() on its parent, but does not include into the returned class loader set a UCL with a parent to the system class loader. If there are no class loaders in the repository capable of handling the request ask the class loader itself in the event that its parent(s) can load the class (repository.loadClassFromClassLoader())

The HierarchialLoaderRepository's class loaders take precedence over the parent's (their "order" is lower). For the case depicted above, UCL1 is the preferred class loader.

This is the configuration of the UnifiedLoaderRepository after the class loading takes place.

Question: What happens if the parent delegation is true and a classloader already loaded the class in the parent repository's class cache?

Answer: My scoped application will use the already loaded class from the parent repository's class cache.

TO_DO

Create similar use cases for WARs. Deploying a WAR involves an extra class loader (WebappClassLoader) created by the servlet container, that can be independently configured using the WAR's jboss-web.xml.

Explain how UCL3 are created, by whom and why. Explain the relationship between UCL created during an EAR deployment. Multiple UCLs are created (the one corresponding to the EAR and then for the embedded JARs, WARs, etc).

More details on Java2ParentDelegation flag. Make it clear that it only affects the relationship between repositories not classloaders. If a class is not found in any repository, then the standard delegation model is invoked (i.e. the parent classloader is asked to find the class).

JPA Performance: Dont Ignore the Database

2009-08-30T10:34:00.000-07:00

Database Schema

Good Database schema design is important for performance. One of the most basic optimizations is to design your tables to take as little space on the disk as possible , this makes disk reads faster and uses less memory for query processing.

Data Types

You should use the smallest data types possible, especially for indexed fields. The smaller your data types, the more indexes (and data) can fit into a block of memory, the faster your queries will be.

Normalization

Database Normalization eliminates redundant data, which usually makes updates faster since there is less data to change. However a Normalized schema causes joins for queries, which makes queries slower, denormalization speeds retrieval. More normalized schemas are better for applications involving many transactions, less normalized are better for reporting types of applications. You should normalize your schema first, then de-normalize later. Applications often need to mix the approaches, for example use a partially normalized schema, and duplicate, or cache, selected columns from one table in another table. With JPA O/R mapping you can use the @Embedded annotation for denormalized columns to specify a persistent field whose @Embeddable type can be stored as an intrinsic part of the owning entity and share the identity of the entity.

Database Normalization and Mapping Inheritance Hiearchies

The Class Inheritance hierarchy shown below will be used as an example of JPA O/R mapping.

In the Single table per class mapping shown below, all classes in the hierarchy are mapped to a single table in the database. This table has a discriminator column (mapped by @DiscriminatorColumn), which identifies the subclass. Advantages: This is fast for querying, no joins are required. Disadvantages: wastage of space since all inherited fields are in every row, a deep inheritance hierarchy will result in wide tables with many, some empty columns.

In the Joined Subclass mapping shown below, the root of the class hierarchy is represented by a single table, and each subclass has a separate table that only contains those fields specific to that subclass. This is normalized (eliminates redundant data) which is better for storage and updates. However queries cause joins which makes queries slower especially for deep hierachies, polymorphic queries and relationships.

In the Table per Class mapping (in JPA 2.0, optional in JPA 1.0), every concrete class is mapped to a table in the database and all the inherited state is repeated in that table. This is not normlalized, inherited data is repeated which wastes space. Queries for Entities of the same type are fast, however polymorphic queries cause unions which are slower.

Know what SQL is executed

You need to understand the SQL queries your application makes and evaluate their performance. Its a good idea to enable SQL logging, then go through a use case scenario to check the executed SQL. Logging is not part of the JPA specification, With EclipseLink you can enable logging of SQL by setting the following property in the persistence.xml file:

<properties>
<property name="eclipselink.logging.level" value="FINE"/>
</properties>

With Hibernate you set the following property in the persistence.xml file:

<properties>
<property name="hibernate.show_sql" value="true" />
</properties>

Basically you want to make your queries access less data, is your application retrieving more data than it needs, are queries accessing too many rows or columns? Is the database query analyzing more rows than it needs? Watch out for the following:

queries which execute too often to retrieve needed data
retrieving more data than needed
queries which are too slow
- you can use EXPLAIN to see where you should add indexes

With MySQL you can use the slow query log to see which queries are executing slowly, or you can use the MySQL query analyzer to see slow queries, query execution counts, and results of EXPLAIN statements.

Understanding EXPLAIN

For slow queries, you can precede a SELECT statement with the keyword EXPLAIN to get information about the query execution plan, which explains how it would process the SELECT, including information about how tables are joined and in which order. This helps find missing indexes early in the development process.

You should index columns that are frequently used in Query WHERE, GROUP BY clauses, and columns frequently used in joins, but be aware that indexes can slow down inserts and updates.

Lazy Loading and JPA

With JPA many-to-one and many-to-many relationships lazy load by default, meaning they will be loaded when the entity in the relationship is accessed. Lazy loading is usually good, but if you need to access all of the "many" objects in a relationship, it will cause n+1 selects where n is the number of "many" objects.

You can change the relationship to be loaded eagerly as follows :

However you should be careful with eager loading which could cause SELECT statements that fetch too much data. It can cause a Cartesian product if you eagerly load entities with several related collections.

If you want to override the LAZY fetch type for specific use cases, you can use Fetch Join. For example this query would eagerly load the employee addresses:

In General you should lazily load relationships, test your use case scenarios, check the SQL log, and use @NameQueries with JOIN FETCH to eagerly load when needed.

Partitioning

the main goal of partitioning is to reduce the amount of data read for particular SQL operations so that the overall response time is reduced

Vertical Partitioning splits tables with many columns into multiple tables with fewer columns, so that only certain columns are included in a particular dataset, with each partition including all rows.

Horizontal Partitioning segments table rows so that distinct groups of physical row-based datasets are formed. All columns defined to a table are found in each set of partitions. An example of horizontal partitioning might be a table that contains historical data being partitioned by date.

Vertical Partitioning

In the example of vertical partitioning below a table that contains a number of very wide text or BLOB columns that aren't referenced often is split into two tables with the most referenced columns in one table and the seldom-referenced text or BLOB columns in another.

By removing the large data columns from the table, you get a faster query response time for the more frequently accessed Customer data. Wide tables can slow down queries, so you should always ensure that all columns defined to a table are actually needed.

The example below shows the JPA mapping for the tables above. The Customer data table with the more frequently accessed and smaller data types is mapped to the Customer Entity, the CustomerInfo table with the less frequently accessed and larger data types is mapped to the CustomerInfo Entity with a lazily loaded one to one relationship to the Customer.

Horizontal Partitioning

The major forms of horizontal partitioning are by Range, Hash, Hash Key, List, and Composite.

Horizontal partitioning can make queries faster because the query optimizer knows what partitions contain the data that will satisfy a particular query and will access only those necessary partitions during query execution. Horizontal Partitioning works best for large database Applications that contain a lot of query activity that targets specific ranges of database tables.

Hibernate Shards

Partitioning data horizontally into "Shards" is used by google, linkedin, and others to give extreme scalability for very large amounts of data. eBay "shards" data horizontally along its primary access path.

Hibernate Shards is a framework that is designed to encapsulate support for horizontal partitioning into the Hibernate Core.

Caching

JPA Level 2 caching avoids database access for already loaded entities, this make reading reading frequently accessed unmodified entities faster, however it can give bad scalability for frequent or concurrently updated entities.

You should configure L2 caching for entities that are:

read often
modified infrequently
Not critical if stale

You should also configure L2 (vendor specific) caching for maxElements, time to expire, refresh...

References and More Information:

JPA Best Practices presentation
MySQL for Developers Article
MySQL for developers presentation
MySQL for developers screencast
Keeping a Relational Perspective for Optimizing Java Persistence
Java Persistence with Hibernate
Pro EJB 3: Java Persistence API
Java Persistence API 2.0: What's New ?
High Performance MySQL book
Pro MySQL, Chapter 6: Benchmarking and Profiling
EJB 3 in Action
sharding the hibernate way
JPA Caching
Best Practices for Large-Scale Web Sites: Lessons from eBay

Original Source

Summary of Business Tier Patterns

2009-08-29T08:44:00.000-07:00

The Presentation Tier will access the Business Tier via Business Delegate .
Business Delegate inturn access EJB by looking up using Service Locator.
The EJB [Session Facade] or the WebService End Point representing the Deployment Layer communicates to Application Service Layer [Algorithms, Main Logic].
Application Service Layer access Entities [Business Objects].

The communication between Tiers happen using Transfer Objects [not shown in the figure].
The Deployment Layer can also communicate to Business Objects directly and not via Application Service Layer depending on the Transaction Design.

How do inventors actually think of inventions

2009-08-27T10:22:00.000-07:00

How do inventors actually think of inventions? Most of them say they first define a problem, then come up with a way to solve it. “I look for something not being done efficiently,” says Micron’s Leonard Forbes. “I tour around a lot of conferences and keep up on the literature to try to identify problems. I’ll go through different approaches. It’s not usually an ‘aha’ moment, but more a process of elimination.”

What happens next is the strange, incomprehensible part: finding the answer. Yamazaki says he gets his best ideas after dozing. “Oftentimes, I’ll fall asleep while taking the train home at the end of the day,” he says. “I wake up, and I have an inspiration.”

Mark Gardner, who stopped working for the chipmaker Advanced Micro Devices in 2005, also cogitates while snoozing. “I wake up every day thinking of inventions,” he says. “I don’t know if it’s a curse or a blessing.”

Other innovators don’t close their eyelids to find inspiration but know that their brains function best when they’re not trying to work on a problem. “A lot of times, you don’t come up with solutions right away,” says Akram. “I keep a problem in the back of my mind, thinking about it in different settings, adding a little here and there. Some of this thinking occurs when I’m on a plane or driving my car.” Hearing this, Akram’s colleague Warren Farnworth pipes in, “I hate to say it, but there’s something about standing in the shower, rubbing my head with shampoo, and I’ll go, Wow, why didn’t I think of that before?”

Also important is an environment that encourages experimentation. All the men say they have to feel free to propose any idea, no matter how outrageous. “When chasing an invention, you have to not be very critical of suggestions,” Weder says. “You have to try not to snicker.” Even when the wildest solutions don’t work, they can spark discussion that might lead to other ideas. “There are two kinds of supervisors,” says Akram. “One says, ‘Why are you wasting our time?’ The other says, ‘This is so cool!’ ” Micron’s researchers have thrived under the latter.

Then there is another, less romantic reason why these men have so many patents. All work for firms that value patents, systematically and aggressively apply for them, and reward those who win them. At Micron, the patent lawyers’ offices are next to the R&D lab, so engineers can stop by and quickly find out if an idea is patentable. Yamazaki and Silverbrook now run companies that essentially produce nothing but patentable technology—and they make money licensing it to manufacturers. In his 24 years at A.M.D., which relies on patentable inventions to compete with archrival Intel, Gardner figures he made more than $1 million in bonuses from his patents.

Which brings up the subject of wealth. It’s tempting to think that owning hundreds of patents must be the key to riches, but it’s not necessarily true. Inventions created while working for a company usually belong to that company. The leading inventors are all well paid—their firms understand their value—but none is cruising the Aegean on his yacht or lining up to buy the Yankees. Silverbrook has the best shot at great wealth, if his printer technology takes flight.

Silverbrook, Yamazaki, and Weder will continue to chase one another at the top of the list. They each have nearly twice as many patents as the fifth-ranked inventor, Micron’s Gurtej Sandhu. They are the reticent megastars of invention, each eclipsing Edison just as Barry Bonds roared past Babe Ruth. These three, especially, deserve a place not just in the popular imagination, but also in history.

Traditional SaaS vs Cloud enabled SaaS

2009-08-27T09:56:00.000-07:00

Inspired by Gilad's great summary on the Cloud Programming model, I try to summarize the difference that I observe between the traditional SaaS model and the "cloud-enabled SaaS model". Although cloud providers advocates zero effort is need to migrate existing applications into the cloud, it is my belief that this "strict-port" approach doesn't fully exploit the full power of cloud computing. There are a number of characteristic that cloud is different from traditional data center environment, application which design along these characteristic will take more advantages from the cloud.

I believe a Cloud-enabled-Application should have the following characteristic in its fundamental design.

Latency Awareness

Traditional SaaS App typically run within a single data center and assume low latency among server components. Now in the cloud environment that span many distant geographic locations, but the assumption of low latency cannot hold any more. We need to be “smarter” when choosing where to deploy to avoid the situation of putting frequently communicating components between far-distant locations. “Cloud-enabled SaaS app” need to be aware of latency difference and built in self-configuring and self-tuning mechanism to cope with that.

Cost Awareness

Traditional SaaS app typically run on already purposed hardware where utilization efficiency is not a concern. Now with the “pay as you go” model, application need to pay more attention to its usage pattern and efficiency of underlying resources because it will affect the operation cost. Cloud-enabled SaaS application need to understand the cost model of different resources utilization (such as CPU cost may be very different from Bandwidth cost) and adjust their usage strategy to minimize the operation cost.

Security Awareness

Traditional SaaS app typically run on a fully trusted data center based on perimeter security. But in the Hybrid cloud model, the perimeter being drawn is very different now. Application need to carefully select where to store its data such that sensitivity will not be leaking. This involve careful determination of storage provider or use encryption for protection.

Capitalize on Elasticity

Traditional SaaS App is not used to large-scale growth / shrink of compute resources and typically haven’t designed well to handle how data get distributed to newly joined machines (in a growth scenario) or redistributed among remaining machines (in a shrink scenario). This ends up having a very inefficient use of network bandwidth and results in high cost and low performance. More sophisticated data distribution protocol that align with the growth and shrink dimension is needed for “Cloud-enabled SaaS app”

Original Source

Summary of Presentation Tier Patterns

2009-08-23T03:15:00.000-07:00

1) Intercepting Filters

You want to intercept and manipulate a request and a response before and after the request is processed.

When:

a) Does the client have a valid session?

b) Does the request path violate any constraints?

c) Do you support the browser type of the client?

d) What encoding does the client use to send the data?

e) Is the request stream encrypted or compressed?

Actors:

a) Filter Manager

Filter Manager manages Filter Processing. It creates the FilterChain with the appropriate filters, in the correct order, and initiates processing.

b) Filter Chain

The FilterChain is an ordered collection of independent filters.

c) Filter

Filter represents individual filters.

d) Target

The Target is the resource requested by the client. Target here can be a Front Controller.

2) Front Controller

You want a centralized access point for presentation-tier request handling

When:

a) You want to avoid duplicate control logic

b) You want to apply common logic to multiple requests.

c) You want to separate system processing logic from the view.

d) You want to centralize controlled access points into your system.

Does:

a) Converts the protocol specific requests into a more general form with the help of Context Object. An example of this is retrieving parameters from an HttpServletRequest instance and populating a MyRequest object that can be used independent of any servlet-related artifacts.

b) Validates the ContextObject for FormBased and Business Validation using the Validator provided by the ContextObject.

c) Delegates request to Application Controller.

3) Context Object

You want to avoid using protocol-specific system information outside of its relevant context. An example of this is retrieving parameters from an HttpServletRequest instance and populating a MyRequest object that can be used independent of any servlet-related artifacts. Context Object also provides a framework to validate the user data.

Actors:

a) ProtocolInterface [HttpServletRequest, HttpServletResponse]

An object that exposes protocol or tier-specific details.

b) ContextFactory [RequestContextFactory, ResponseContextFactory]

A ContextFactory creates a protocol and tier independent ContextObject.

c) ContextObject [RequestContextObject, ResponseContextObject]

ContextObject is a generic object used to share domain-neutral state throughout an application. Per Form a separate ContextObject can be created like for example StudentAdmission form can have its own ContextObject called StudentAdmissionContextObject which has its own logic for validating form.

4) Application Controller

You want to centralize and modularize action and view management.

Does:

a) First, the incoming request must be resolved to an action that services the request. This is called action management.

b) Second, the appropriate view is located and dispatched. This is called view management.

Actors:

a) Client

Client invokes the application controller. In the presentation tier, a FrontController or an InterceptingFilter typically fulfill this role.

b) ApplicationController

Uses Mapper to resolve an incoming request to the appropriate action and view, to which it delegates or dispatches.

c) Mapper

Uses a Map to translate an incoming request into the appropriate action [Command] and view [ViewFactory].

d) Map

Holds references to handles that represent target resources [Command or ViewFactory]

e) Target

A resource that helps fulfill a particular request, including commands, views and style sheets.

5) CommandProcessing

You want to perform core request handling and invoke business logic before control is passed to the view.

Actors:

a) ApplicationController

Manages choosing the appropriate action [Command] to fulfill the request.

b) CommandProcessor

Helps in processing the Command.

c) Command

Command performs an action for a request. It invokes the business method on the BusinessDelegate.

d) BusinessDelegate

BusinessDelegate acts as the façade which hides the details of invoking the BusinessService.

e) BusinessService

BusinessService is the Enterprise Beans normally Session Beans which does our task and returns the data in the form of the PresentationModel used by the view to render.

f) PresentationModel

PresentationModel is the data returned by the BusinessService for the use by the view.

6) ViewFactory

Helps in creating View

Does:

a) View Preparation

The view preparation phase involves request handling, action management, and view management. A request is resolved to a specific action, that action is invoked and the appropriate view is identified, with the request then being dispatched to that view.

b) View Creation

Subsequently, during view creation, the view retrieves content from its model, using helpers to retrieve and adapt the model state. Often extracted and adapted from TransferObject, this content is inserted, formatted, and converted into the static template text of the view to generate a dynamic response.

Actors:

a) ViewHelper

It helps in separating a view from its processing logic. This can be in the form of JSPTags, Helper Pojos etc.

b) ViewTemplate

Template used in creating view.

c) CompositeView

You want to build a view from modular, atomic component parts that are combined to create a composite whole, while managing the content and the layout independently.

d) PresentationModel

Presentation Model is the data used by the view.

ACID Properties

2009-08-14T23:49:00.000-07:00

Atomicity

First, a transaction needs to be atomic (or all-or-nothing], meaning that it executes
completely or not at all. There must not be any possibility that only part
of a transaction program is executed.
For example, suppose we have a transaction program that moves $100 from
account A to account B. It takes $100 out of account A and adds it to account
B. When this runs as a transaction, it has to be atomic—either both or neither
of the updates execute. It must not be possible for it to execute one of the
updates and not the other.
The TP system guarantees atomicity through database mechanisms that
track the execution of the transaction. If the transaction program should fail
for some reason before it completes its work, the TP system will undo the
effects of any updates that the transaction program has already done. Only if it
gets to the very end and performs all of its updates will the TP system allow
the updates to become a permanent part of the database.
By using the atomicity property, we can write a transaction program that
emulates an atomic business transaction, such as a bank account withdrawal,
a flight reservation, or a sale of stock shares. Each of these business actions
requires updating multiple data items. By implementing the business action
by a transaction, we ensure that either all of the updates are performed or
none are. Furthermore, atomicity ensures the database is returned to a known
state following a failure, reducing the requirement for manual intervention
during restart. The successful completion of a transaction is called commit. The failure of
a transaction is called abort.

Consistency
A second property of transactions is consistency—a transaction program
should maintain the consistency of the database. That is, if you execute the
transaction all by itself on a database that's initially consistent, then when the
transaction finishes executing the database is again consistent.

By consistent, we mean "internally consistent." In database terms, this
means that the database satisfies all of its integrity constraints. There are
many possible kinds of integrity constraints, such as the following:
• All primary key values are unique (e.g., no two employee records have
the same employee number).
• The database has referential integrity, meaning that records only reference
objects that exist (e.g., the Part record and Customer record that are
referenced by an Order record really exist).
• Certain predicates hold (e.g., the sum of expenses in each department is
less than or equal to the department's budget).
Ensuring that transactions maintain the consistency of the database is good
programming practice. However, unlike atomicity, isolation, and durability,
consistency is a responsibility shared between transaction programs and the
TP system that executes those programs. That is, a TP system ensures that a
set of transactions is atomic, isolated, and durable, whether or not they are
programmed to preserve consistency. Thus, strictly speaking, the ACID test
for transaction systems is a bit too strong, because the TP system does its part
for C only by guaranteeing AID. It's the application programmer's responsibility
to ensure the transaction program preserves consistency.

Isolation
The third property of a transaction is isolation. We say that a set of transactions
is isolated if the effect of the system running them is the same as if it ran
them one at a time. The technical definition of isolation is serializability. An
execution is serializable (meaning isolated) if its effect is the same as running
the transactions serially, one after the next, in sequence, with no overlap in
executing any two of them. This has the same effect as running the transactions
one at a time.
A classic example of a nonisolated execution is a banking system, where
two transactions each try to withdraw the last $100 in an account. If both
transactions read the account balance before either of them updates it, then
both transactions will determine there's enough money to satisfy their
requests, and both will withdraw the last $100. Clearly, this is the wrong
result. Moreover, it isn't a serializable result. In a serial execution, only the
first transaction to execute would be able to withdraw the last $100. The second
one would find an empty account.
Notice that isolation is different from atomicity. In the example, both
transactions executed completely, so they were atomic. However, they were
not isolated and therefore produced undesirable behavior.
If the execution is serializable, then from the point of view of an end user
who submits a request to run a transaction, the system looks like a standalone
system that's running that transaction all by itself. Between the time he
or she runs two transactions, other transactions from other users may run. But

during the period that the system is processing that one user's transaction, it
appears to the user that the system is doing no other work. But this is only an
illusion. It's too inefficient for the system to actually run transactions serially
because there is lots of internal parallelism in the system that must be
exploited by running transactions concurrently.
If each transaction preserves consistency, then any serial execution (i.e.,
sequence) of such transactions preserves consistency. Since each serializable
execution is equivalent to a serial execution, a serializable execution of the
transactions will preserve database consistency, too. It is the combination of
transaction consistency and isolation that ensures that executions of sets of
transactions preserve database consistency.
The database typically places locks on data accessed by each transaction.
The effect of placing the locks is to make the execution appear to be serial. In
fact, internally, the system is running transactions in parallel, but through
this locking mechanism the system gives the illusion that the transactions are
running serially, one after the next. In Chapter 6 on locking, we will describe
those mechanisms in more detail and present the rather subtle argument why
locking actually produces serializable executions.

Durability
The fourth property of a transaction is durability. Durability means that when
a transaction completes executing, all of its updates are stored on a type of
storage, typically disk storage, that will survive the failure of the TP system.
So even if the transaction program or operating system fails, once the transaction
has committed, its results are durably stored on a disk and can be found
there after the system recovers from the failure.
Durability is important because each transaction is usually providing a service
that amounts to a contract between its users and the enterprise that is
providing the service. For example, if you're moving money from one account
to another, once you get a reply from the transaction saying that it executed,
you really expect that the result is permanent. It's a legal agreement between
the user and the system that the money has been moved between these two
accounts. So it's essential that the transaction actually makes sure that the
updates are stored on some nonvolatile device, typically disk storage in
today's technology, to ensure that the updates cannot possibly be lost after the
transaction finishes executing. Moreover, the durability of the result often
must be maintained for a long period. For example, some tax regulations allow
audits that can take place years after the transactions were completed.
The durability property is usually obtained via a mechanism that starts by
having the TP system write a copy of all the transaction's updates to a log file
while the transaction program is running. When the transaction program
issues the commit operation, the system first ensures that all the records written
to the log file are out on disk, and then returns to the transaction program,
indicating that the transaction has indeed committed and that the results are
durable. The updates may be written to the database right away, or they may

be written a little later. However, if the system fails after the transaction commits
and before the updates go to the database, then after the system recovers
from the failure it must repair the database. To do this, it rereads the log and
checks that each update by a committed transaction actually made it to the
database. If not, it reapplies the update to the database. When this recovery
activity is complete, the system resumes normal operation. Thus, any new
transaction will read a database state that includes all committed updates. We
describe log-based recovery algorithms in Chapter 8.

Modularity by Example

2009-08-14T10:00:00.000-07:00

There are lots of benefits to modularity, some of which I discussed when introducing modularity patterns. But here’s a simple example, which serves as a prelude to some upcoming posts explaining a few of the patterns.

In the diagram at right (click to enlarge), the top left quadrant shows a sample system with a relatively complex class structure. When change occurs within a single class, shown in red in the bottom left quadrant, understanding the impact of change is difficult. It appears possible that it can propagate to any class dependent on the class highlighted in red. Assessing the impact of change requires that we analyze the complete class structure. The ripple effect appears significant, and change instills fear.

But if the system is modular with classes allocated to these modules, as shown in the bottom right quadrant, then understanding the impact of change can be isolated to a discrete set of modules. And this makes it much easier to identify which modules contain classes that might also change, as shown in the top right quadrant. Change is isolated to classes within modules that are dependent on the module containing the class that is changing.

This is a simple example, but it serves as evidence of the need for modular architecture, and illustrates one reason why modularity is so important. Modularity makes understanding the system easier. It makes maintaining the system easier. And it makes reusing system modules much more likely. As systems grow in size and complexity, it’s imperative that we design more modular software. That means we need a module system for the Java platform. It means that module system shouldn’t be shielded from enterprise developers. And it means we need to understand the patterns that are going to provide the guidance necessary in helping us design more modular software.

From http://techdistrict.kirkk.com

Presentation Model Pattern

2009-08-14T09:03:00.000-07:00

Presentation Model is a design pattern used to build desktop GUIs with a clean separation of concerns. One of the most important advantages of this pattern is the easy creation of unit tests that can focus on the application logic without touching UI components. In fact, this is a goal that many other patterns have failed to accomplish. Read the advantages of the Presentation Model pattern for more details.

The first characteristic of the Presentation Model pattern that you have to understand is how its classes (often referred to as layers) are organized. Figure 1 shows its structure, which details the following classes: view, presentation model and service layer. Before explaining each of them, pay special attention to the references (arrows) and notice that the class that holds the state and logic of the GUI (presentation model class) does not have a reference to the view. What happens is exactly the opposite: the view that has a reference to this class.

Let's understand the role of each of these classes in the pattern:

View: Simple class that contains the UI components. The displayed data reflects the state kept by the Presentation Model class.
Presentation Model: Class that holds the state of the GUI and its logic. The code operates on data and variables in memory and is unaware of the existence of UI components and presentation formats.
Service Layer: Class that represents a channel between the Presentation Model and the outer world, where different types of service might exist (e.g., EJBs, databases, etc.). What lies beyond this layer is not seen by the Presentation Model class.

Figure 1: Three layers of the pattern.

The Presentation Model class has no idea about views. It simply holds the state of the GUI and fires events when this state changes. Moreover, it is possible to attach more than one view to a presentation model instance, which leads to diferent visualizations of the same data.

The separation into decoupled layers and different responsibilities brings important advantages to the GUI implementation and maintenance. When we work this way, the layers become thinner and Ö consequently Ö more simple, which increases the understandability of the code. Besides that, the operations with models and business rules happen only in the presentation model layer, where the unit tests can reach efficiently.

The Presentation Model pattern applied without a framework requires some synchronization code between the layers (see the articles on the JGoodies Binding API).

Inheritence in Javascript

2009-08-10T04:14:00.000-07:00

Example of Inheritence in Javascript:

function Person(name) {

this.name = name;

this.printName = function() {

alert("Name is "+this.name);

}

function Employee(name, sal) {

Person.call(this, name);

this.sal = sal;

this.printSalary = function() {

alert("Salary is "+this.sal);

}

function NonFunctionalEmployee(name, sal, hours) {

Employee.call(this, name, sal);

this.hours = hours;

this.printHours = function() {

alert("Number of hours of work "+this.hours);

}

var nonFunctionalEmp = new NonFunctionalEmployee("XYZ", 3333, 12);

nonFunctionalEmp.printName();

nonFunctionalEmp.printSalary();

nonFunctionalEmp.printHours();

call(this) is the main api which helps in inheritence.

The "this" parameter specifies the context in which the call() should get executed.

Choosing a Web Development Framework

2009-08-09T10:42:00.000-07:00

Here is a list which helps in choosing the web development framework -

Support for MVC (most frameworks have pretty decent support for that now)
Extensible MVC (need to be able to extend the way controllers and views operate. Some frameworks do it by convention and limit you to a set of popular conventions.)
Allows you to build your domain in isolation. (I want my domain model to be completely decoupled from any web technologies, persistence, etc... Just a plain OO domain model)
Gives you very flexible persistence options. (I might decide to use a fully featured ORM (ActiveRecord is not fully featured), or I might want to use SQL, or heck, I might want to do both for efficiency or to scratch a morning itch, who cares about the reason, please let me choose. Oh, and one more thing, what if I don't want to use a SQL database at all? I want to use a native XML store or better yet a key/value store. Even if it's just to piss someone off, I want to do this and one should be able to accomplish that pretty easily. I'm not asking for a mapper for these stores, simply just don't make your framework bound to some relational store though making the work of turning this dependency off a 5 hour chore.)
Supports AJAX (I should be able to easily render JSON or XML views, without much plumbing or lots of mappings and annotations. The authentications and forms support should also expose some form of ajax compliant interfaces, so that forms and authentication can be done using ajax if I choose so. Be able to easily parse submitted data into some data structure and validate/synchronize it with the domain model.)
Bindings (All frameworks have some sort of bindings. Some of them are limiting. I don't want to create command objects to just simply bind the data and than synch with my domain model. If I have domain object graph(s), I should be able to bind it in the view layer. Bindings should be customizable. In Spring MVC for example, you can only bind one input control to a field or set of fields in the command object, but what if I want to bind 3 input fields that collectively represent one field in the domain object, I'm out of luck, unless I use javascript to first serialize those input fields into one field. That really sucks.)
Support RESTful, stateless, and other web concepts in a straightforward way. (I want to be able to configure every part of HTTP and the web and make the application work, look, interact in my way that's compatible with the web, not your way. Some component based frameworks make that harder that it should be, like the fact that they are inherently stateful by default. Some make it hard to support RESTful or custom URI schemes, because they transfer state through URL rewriting. All of these problems don't exist in some frameworks, like Rails, Spring MVC, Grails, etc..., so I know it's possible.)
Validations (Most have fully fledged validation support, but I can't say that it can't be made a bit easier. I do like Spring's flexible validation support.)
Forms (This is a big one. Can you provide a flexible way of creating forms and layouts. I mean seriously, we're developing forms today the same way we've developed forms 15 years ago. Every other aspect of development has moved on, but we're still doing bullshit html form controls. XForms is a way out, but no browser support and pretty hard to integrate support from vendors like Orbeon and Chiba makes the standard useless. Can we either embrace it or come up with something else. Am I the only one that gets an anxiety attack every time I think about creating yet another interactive form that doesn't do anything much differently than the form I created 4 months ago for a different project, though I either have to copy and paste all the cruft or start from the absolute scratch. Wow, that's sad IMO.)
Scalability. I know this one again is not up to the framework, but as I mentioned before, the framework can make it easier or harder to achieve. For example, inherently stateful frameworks that require either session affinity or replication of session state, make it very hard to horizontally scale. Yes, I know you can scale with replications tools available out there, but any synchronous replications is not linearly scalable. So any such frameworks makes it harder. There are many other criteria that can make a framework more scalable than others, but in general, statelessness, stability, and speed makes it viable for faster scalability tunes.)

Original Source

Load Balancing Web Applications

2009-08-08T07:52:00.000-07:00

This article offers an overview of several approaches to load balancing on Web application server clusters. A cluster is a group of servers running a Web application simultaneously, appearing to the world as if it were a single server. To balance server load, the system distributes requests to different nodes within the server cluster, with the goal of optimizing system performance. This results in higher availability and scalability -- necessities in an enterprise, Web-based application.

High availability can be defined as redundancy. If one server cannot handle a request, can other servers in the cluster handle it? In a highly available system, if a single Web server fails, then another server takes over, as transparently as possible, to process the request.

Scalability is an application's ability to support a growing number of users. If it takes an application 10 milliseconds(ms) to respond to one request, how long does it take to respond to 10,000 concurrent requests? Infinite scalability would allow it to respond to those in 10 ms; in the real world, it's somwhere between 10 ms and a logjam. Scalability is a measure of a range of factors, including the number of simultaneous users a cluster can support and the time it takes to process a request.

Of the many methods available to balance a server load, the main two are:

DNS round robin
Hardware load balancers.

DNS Round Robin

As most readers of ONJava probably know, the Domain Name Server (DNS) database maps host names to their IP addresses.

When you enter a URL in a browser (say, www.loadbalancedsite.com), the browser sends a request to the DNS asking it to return the IP address of the site. This is called the DNS lookup. After the Web browser gets the IP address for that site, it contacts the site using the IP address, and displays the page for you.

The DNS server generally contains a single IP address mapped to a particular site name. In our fictional example, our site www.loadbalancedsite.com maps to the IP address 203.24.23.3

To balance server loads using DNS, the DNS server maintains several different IP addresses for a site name. The multiple IP addresses represent the machines in the cluster, all of which map to the same single logical site name. Using our example, www.loadbalancedsite.com could be hosted on three machines in a cluster with the following IP addresses:

203.34.23.3
203.34.23.4
203.34.23.5

In this case, the DNS server contains the following mappings:

www.loadbalancedsite.com  203.34.23.3
www.loadbalancedsite.com  203.34.23.4
www.loadbalancedsite.com  203.34.23.5

When the first request arrives at the DNS server, it returns the IP address 203.34.23.3, the first machine. On the second request, it returns the second IP address: 203.34.23.4. And so on. On the fourth request, the first IP address is returned again.

Using the above DNS round robin, all of the requests to the particular site have been evenly distributed among all of the machines in the cluster. Therefore, with the DNS round robin method of load balancing, all of the nodes in the cluster are exposed to the net.

Advantages of DNS Round Robin

The main advantages of DNS round robin are that it's cheap and easy:

Inexpensive and easy to set up. The system administrator only needs to make a few changes in the DNS server to support round robin, and many of the newer DNS servers already include support. It doesn't require any code change to the Web application; in fact, Web applications aren't aware of the load-balancing scheme in front of it.
Simplicity. It does not require any networking experts to set up or debug the system in case a problem arises.

Disadvantages of DNS Round Robin

Two main disadvantages of this software-based method of load balancing are that it offers no real support for server affinity and doesn't support high availability.

No support for server affinity. Server affinity is a load-balancing system's ability to manage a user's requests, either to a specific server or any server, depending on whether session information is maintained on the server or at an underlying, database level.

Without server affinity, DNS round robin relies on one of three methods devised to maintain session control or user identity to requests coming in over HTTP, which is a stateless protocol.
- cookies
- hidden fields
- URL rewriting
When a user makes a first request, the Web server returns a text-based token uniquely identifying that user. Subsequent requests include this token using either cookies, URL rewriting, or hidden fields, allowing the server to appear to maintain a session between client and server. When a user establishes a session with one server, all subsequent requests usually go to the same server.

The problem is that the browser caches that server's IP address. Once the cache expires, the browser makes another request to the DNS server for the IP address associated with the domain name. If the DNS server returns a differnt IP address, that of another server in the cluster, the session information is lost.
No support for high availability. Consider a cluster of n nodes. If a node goes down, then every nth request to the DNS server directs you to the dead node. An advanced router solves this problem by checking nodes at regular intervals, detecting failed nodes and removing them from the list, so no requests go to them. However, the problem still exists if the node is up but the Web application running on the node goes down.

Changes to the cluster take time to propagate through the rest of the Internet. One reason is that many large organizations -- ISPs, corporations, agencies -- cache their DNS requests to reduce network traffic and request time. When a user within these organizations makes a DNS request, it's checked against the cache's list of DNS names mapped to IP addresses. If it finds an entry, it returns the IP address to the user. If an entry is not found in its local cache, the ISP sends this DNS request to the DNS server and caches response.

When a cached entry expires, the ISP updates its local database by contacting other DNS servers. When your list of servers changes, it can take a while for the cached entries on other organizations' networks to expire and look for the updated list of servers. During that period, a client can still attempt to hit the downed server node, if that client's ISP still has an entry pointing to it. In such a case, some users of that ISP couldn't access your site on their first attempt, even if your cluster has redundant servers up and running.

This is a bigger problem when removing a node than when adding one. When you drop a node, a user may be trying to hit a non-existing server. When you add one, that server may just be under-utilized until its IP address propogates to all the DNS servers.

Although this method tries to balance the number of users on each server, it doesn't necessarily balance the server load. Some users could demand a higher load of activity during their session than users on another server, and this methodology cannot guard against that inequity.

Hardware Load Balancers

Hardware load balancers solve many of the problems faced by the round robin software solution through virtual IP addresses. The load balancer shows a single (virtual) IP address to the outside world, which maps to the addresses of each machine in the cluster. So, in a way, the load balancer exposes the IP address of the entire cluster to the world.

When a request comes to the load balancer, it rewrites the request's header to point to other machines in the cluster. If a machine is removed from the cluster, the request doesn't run the risk of hitting a dead server, since all of the machines in the cluster appear to have the same IP address. This address remains the same even if a node in the cluster is down. Moreover, cached DNS entries around the Internet aren't a problem. When a response is returned, the client sees it coming from the hardware load balancer machine. In other words, the client is dealing with a single machine, the hardware load balancer.

Advantages of Hardware Load Balancers

Server affinity. The hardware load balancer reads the cookies or URL readings on each request made by the client. Based on this information, it can rewrite the header information and send the request to the appropriate node in the cluster, where its session is maintained.

Hardware load balancers can provide server affinity in HTTP communication, but not through a secure channel, such as HTTPS. In a secure channel, the messages are SSL-encrypted, and this prevents the load balancer from reading the session information.
High Availability Through Failover. Failover happens when one node in a cluster cannot process a request and redirects it to another. There are two types of failover:
- Request Level Failover. When one node in a cluster cannot process a request (often because it's down), it passes it along to another node.
- Transparent Session Failover. When an invocation fails, it's transparently routed to another node in the cluster to complete the execution.
Hardware load balancers provide request-level failover; when the load balancer detects that a particular node has gone down, it redirects all subsequent requests to that dead node to another active node in the cluster. However, any session information on the dead node will be lost when requests are redirected to a new node.

Transparent session failover requires execution knowledge for a single process in a node, since the hardware load balancer can only detect network-level problems, not errors. In the execution process of a single node, hardware load balancers do not provide transparent session failover. To achieve transparent session failover, the nodes in the cluster must collaborate among each other and have something like a shared memory area or a common database where all the session data is stored. Therefore, if a node in the cluster has a problem, a session can continue in another node.
Metrics. Since all requests to a Web application must pass through the load-balancing system, the system can determine the number of active sessions, the number of active sessions connected in any instance, response times, peak load times, the number of sessions during peak load, the number of sessions during minimum load, and more. All this audit information is used to fine tune the entire system for optimal performance.

Disadvantages of Hardware Load Balancers

The drawbacks to the hardware route are the costs, the complexity of setting up, and the vulnerability to a single point of failure. Since all requests pass through a single hardware load balancer, the failure of that piece of hardware sinks the entire site.

Load Balancing HTTPS Requests

As mentioned above, it's difficult to load balance and maintain session information of requests that come in over HTTPS, as they're encrypted. The hardware load balancer cannot redirect requests based on the information in the header, cookies, or URL readings. There are two options to solve this problem:

Web server proxies
Hardware SSL decoders.

Implementing Web Server Proxies

A Web server proxy that sits in front of a cluster of Web servers takes all requests and decrypts them. Then it redirects them to the appropriate node, based on header information in the header, cookies, and URL readings.

The advantages of Web server proxies are that they offer a way to get server affinity for SSL-encrypted messages, without any extra hardware. But extensive SSL processing puts an extra load on the proxy.

Apache and Tomcat. In many serving systems, Apache and Tomcat servers work together to handle all HTTP requests. Apache handles the request for static pages (including HTML, JPEG, and GIF files), while Tomcat handles requests for dynamic pages (JSPs or servlets). Tomcat servers can also handle static pages, but in combined systems, they're usually set up to handle dynamic requests.

You can also configure Apache and Tomcat to handle HTTPS requests and to balance loads. To achieve this, you run multiple instances of Tomcat servers on one or more machines. If all of the Tomcat servers are running on one machine, they should be configured to listen on different ports. To implement load balancing, you create a special type of Tomcat instance, called a Tomcat Worker.

As shown in the illustration, the Apache Web server receives HTTP and HTTPS requests from clients. If the request is HTTPS, the Apache Web server decrypts the request and sends it to a Web server adapter, which in turn sends the request to the Tomcat Worker, which contains a load-balancing algorithm. Similar to the Web server proxy, this algorithm balances the load among Tomcat instances.

Hardware SSL Decoder

Finally, we should mention that there are hardware devices capable of decoding SSL requests. A complete description of them is beyond the scope of this article, but briefly, they sit in front of the hardware load balancer, allowing it to decrypt information in cookies, headers and URLs.

These hardware SSL decoders are faster than Web server proxies and are highly scalable. But as with most hardware solutions, they cost more and are complicated to set up and configure.

Javascript: Static Methods and Variables

2009-08-08T01:10:00.000-07:00

Static Methods and Attributes

Applying the lesson of scope and closures from earlier in the chapter can lead to a way to
create static members, which can be both private and publicly accessible. Most methods
and attributes interact with an instance of a class; static members interact with the class
itself. Another way of putting it is to say that static members operate on the class-level instead
of the instance-level; there is only one copy of each static member. As you will see later in
this section, static members are called directly off of the class object.
Here is the Book class with static attributes and methods:
var Book = (function() {

// Private static attributes.
var numOfBooks = 0;

// Private static method.
function checkIsbn(isbn) {
...
}

// Return the constructor.
return function(newIsbn, newTitle, newAuthor) { // implements Publication

// Private attributes.
var isbn, title, author;

// Privileged methods.
this.getIsbn = function() {
return isbn;
};
this.setIsbn = function(newIsbn) {
if(!checkIsbn(newIsbn)) throw new Error('Book: Invalid ISBN.');
isbn = newIsbn;
};

this.getTitle = function() {
return title;
};
this.setTitle = function(newTitle) {
title = newTitle || 'No title specified';
};
this.getAuthor = function() {
return author;
};
this.setAuthor = function(newAuthor) {
author = newAuthor || 'No author specified';
};

// Constructor code.
numOfBooks++; // Keep track of how many Books have been instantiated
// with the private static attribute.
if(numOfBooks > 50) throw new Error('Book: Only 50 instances of Book can be '
+ 'created.');
this.setIsbn(newIsbn);
this.setTitle(newTitle);
this.setAuthor(newAuthor);
}
})();

// Public static method.
Book.convertToTitleCase = function(inputString) {
...
};
// Public, non-privileged methods.
Book.prototype = {
display: function() {
...
}
};

This is similar to the class created earlier in the chapter in the “Private Members Through
Closures” section, with a couple of key differences. Private and privileged members are still
declared within the constructor, using var and this respectively, but the constructor is changed
from a normal function to a nested function that gets returned to the variable Book. This makes
it possible to create a closure where you can declare private static members. The empty parentheses
after the function declaration are extremely important. They serve to execute that
function immediately, as soon as the code is loaded (not when the Book constructor is called).
The result of that execution is another function, which is returned and set to be the Book constructor.
When Book is instantiated, this inner function is what gets called; the outer function is
used only to create a closure, within which you can put private static members.

In this example, the checkIsbn method is static because there is no point in creating a new
copy of it for each instance of Book. There is also a static attribute called numOfBooks, which allows
you to keep track of how many times the Book constructor has been called. In this example, we
use that attribute to limit the constructor to creating only 50 instances.
These private static members can be accessed from within the constructor, which means
that any private or privileged function has access to them. They have a distinct advantage over
these other methods in that they are only stored in memory once. Since they are declared outside
of the constructor, they do not have access to any of the private attributes, and as such, are
not privileged; private methods can call private static methods, but not the other way around.
A rule of thumb for deciding whether a private method should be static is to see whether it
needs to access any of the instance data. If it does not need access, making the method static
is more efficient (in terms of memory use) because only a copy is ever created.
Public static members are much easier to create. They are simply created directly off of
the constructor, as with the previous method convertToTitleCase. This means you are essentially
using the constructor as a namespace.
■Note In JavaScript, everything except for variables of the three primitive types is an object (and even
those primitives are automatically wrapped by objects when needed). This means that functions are also
objects. Since objects are essentially hash tables, you can add members at any time. The end result of this is
that functions can have attributes and methods just like any other object, and they can be added whenever
you want.
All public static methods could just as easily be declared as separate functions, but it is useful
to bundle related behaviors together in one place. They are useful for tasks that are related to
the class as a whole and not to any particular instance of it. They don’t directly depend on any of
the data contained within the instances.

Another Example:

var StaticTest = (function()
{
var count = 0; //Static Variable

return function() { //Constructor

this.incrementCount = function() { //public privileged function
count++;
};

this.printCount = function() { //public privileged function
alert("The count is: " + count);
};

}
})();

//Static Method
StaticTest.printCount = function() {

alert("The count is not accessible in static method [printCount()]");
};

new StaticTest().incrementCount(); //increments count to 1
new StaticTest().printCount(); //prints count as 1
new StaticTest().incrementCount(); //increments count to 2
new StaticTest().printCount(); //prints count as 1
StaticTest.printCount(); //prints The count is not accessible in static method [printCount()]

Source: Pro Javascript Design Patterns

Javascript: Private Members through Closures

2009-08-07T23:48:00.000-07:00

Back to the problem at hand: you need to create a variable that can only be accessed internally.
A closure seems to be a perfect fit because it allows you to create variables that are accessible
only to certain functions and are preserved in between those function calls. To create private
attributes, you define variables in the scope of your constructor function. These attributes will
be accessible to all functions defined within this scope, including privileged methods:
var Book = function(newIsbn, newTitle, newAuthor) { // implements Publication
// Private attributes.
var isbn, title, author;
// Private method.
function checkIsbn(isbn) {
...
}
// Privileged methods.
this.getIsbn = function() {
return isbn;
};
this.setIsbn = function(newIsbn) {
if(!checkIsbn(newIsbn)) throw new Error('Book: Invalid ISBN.');
isbn = newIsbn;
};
this.getTitle = function() {
return title;
};

this.setTitle = function(newTitle) {
title = newTitle || 'No title specified';
};
this.getAuthor = function() {
return author;
};
this.setAuthor = function(newAuthor) {
author = newAuthor || 'No author specified';
};
// Constructor code.
this.setIsbn(newIsbn);
this.setTitle(newTitle);
this.setAuthor(newAuthor);
};
// Public, non-privileged methods.
Book.prototype = {
display: function() {
...
}
};
So how is this different from the other patterns we’ve covered so far? In the other Book
examples, we always created and referred to the attributes using the this keyword. In this
example, we declared these variables using var. That means they will only exist within the Book
constructor. We also declare the checkIsbn function in the same way, making it a private method.
Any method that needs to access these variables and functions need only be declared
within Book. These are called privileged methods because they are public but have access to
private attributes and methods. The this keyword is used in front of these privileged functions
to make them publicly accessible. Because these methods are defined within the Book constructor’s
scope, they can access the private attributes. They are not referred to using this because
they aren’t public. All of the accessor and mutator methods have been changed to refer to the
attributes directly, without this.
Any public method that does not need direct access to private attributes can be declared
normally in the Book.prototype. An example of one of these methods is display; it doesn’t
need direct access to any of the private attributes because it can just call getIsbn or getTitle.
It’s a good idea to make a method privileged only if it needs direct access to the private members.
Having too many privileged methods can cause memory problems because new copies
of all privileged methods are created for each instance.
With this pattern, you can create objects that have true private attributes. It is impossible
for other programmers to create an instance of Book and directly access any of the data. You
can tightly control what gets set because they are forced to go through the mutator methods.
This pattern solves all of the problems with the other patterns, but it introduces a few drawbacks
of its own. In the fully exposed object pattern, all methods are created off of the prototype,
which means there is only one copy of each in memory, no matter how many instances you create.
In this pattern, you create a new copy of every private and privileged method each time a new

object is instantiated. This has the potential to use more memory than the other patterns, so it
should only be used when you require true private members. This pattern is also hard to subclass.
The new inherited class will not have access to any of the superclass’s private attributes or methods.
It is said that “inheritance breaks encapsulation” because in most languages, the subclass has
access to all of the private attributes and methods of the superclass. In JavaScript, this is not the
case. If you are creating a class that might be subclassed later, it is best to stick to one of the fully
exposed patterns.

Summary
1) To declare private variables dont use this keyword, instead use var with in the constructor.
2) The same applies to the private functions as well like checkIsbn() function above.
3) To declare public privileged functions [functions which are public and which can access private variables] use this keyword and define it with in the constructor like setIsbn(), getIsbn() api's above.
4) To declare public non-privileged functions [functions which are public and which cannot access private variables] use prototype to define.

Source:
Pro Javascript Design Patterns

Interfaces in Javascript

2009-08-07T12:20:00.000-07:00

Here is an example of our Interface class and comment combination:
// Interfaces.
var Composite = new Interface('Composite', ['add', 'remove', 'getChild']);
var FormItem = new Interface('FormItem', ['save']);
// CompositeForm class
var CompositeForm = function(id, method, action) { // implements Composite, FormItem
...
};
...
function addForm(formInstance) {
Interface.ensureImplements(formInstance, Composite, FormItem);
// This function will throw an error if a required method is not implemented,
// halting execution of the function.
// All code beneath this line will be executed only if the checks pass.
...
}
Interface.ensureImplements provides a strict check. If a problem is found, an error will be
thrown, which can either be caught and handled or allowed to halt execution. Either way, the
programmer will know immediately that there is a problem and where to go to fix it.

The Interface Class
The following is the Interface class that we use throughout the book:
// Constructor.
var Interface = function(name, methods) {
if(arguments.length != 2) {
throw new Error("Interface constructor called with " + arguments.length +
"arguments, but expected exactly 2.");
}
this.name = name;
this.methods = [];
for(var i = 0, len = methods.length; i < len; i++) {
if(typeof methods[i] !== 'string') {
throw new Error("Interface constructor expects method names to be "
+ "passed in as a string.");
}
this.methods.push(methods[i]);
}
};
// Static class method.
Interface.ensureImplements = function(object) {
if(arguments.length < 2) {
throw new Error("Function Interface.ensureImplements called with " +
arguments.length + "arguments, but expected at least 2.");
}
for(var i = 1, len = arguments.length; i < len; i++) {
var interface = arguments[i];
if(interface.constructor !== Interface) {
throw new Error("Function Interface.ensureImplements expects arguments"
+ "two and above to be instances of Interface.");
}
for(var j = 0, methodsLen = interface.methods.length; j < methodsLen; j++) {
var method = interface.methods[j];
if(!object[method] || typeof object[method] !== 'function') {
throw new Error("Function Interface.ensureImplements: object "
+ "does not implement the " + interface.name
+ " interface. Method " + method + " was not found.");
}
}
}
};

As you can see, it is very strict about the arguments given to each method and will throw
an error if any check doesn’t pass. This is done intentionally, so that if you receive no errors,
you can be certain the interface is correctly declared and implemented.

The Flexibility of JavaScript

2009-08-07T10:54:00.000-07:00

The Flexibility of JavaScript

One of the most powerful features of the language is its flexibility. As a JavaScript programmer,
you can make your programs as simple or as complex as you wish them to be. The language
also allows several different programming styles. You can write your code in the functional style
or in the slightly more complex object-oriented style. It also lets you write relatively complex
programs without knowing anything at all about functional or object-oriented programming;
you can be productive in this language just by writing simple functions. This may be one of the
reasons that some people see JavaScript as a toy, but we see it as a good thing. It allows programmers
to accomplish useful tasks with a very small, easy-to-learn subset of the language. It also
means that JavaScript scales up as you become amore advanced programmer.
JavaScript allows you to emulate patterns and idioms found in other languages. It even
creates a few of its own. It provides all the same object-oriented features as the more traditional
server-side languages.
Let’s take a quick look at a few different ways you can organize code to accomplish one
task: starting and stopping an animation. It’s OK if you don’t understand these examples; all of
the patterns and techniques we use here are explained throughout the book. For now, you can
view this section as a practical example of the different ways a task can be accomplished in
JavaScript.

If you’re coming from a procedural background, you might just do the following:
/* Start and stop animations using functions. */
function startAnimation() {
...
}
function stopAnimation() {
...
}
This approach is very simple, but it doesn’t allow you to create animation objects, which
can store state and have methods that act only on this internal state. This next piece of code
defines a class that lets you create such objects:
/* Anim class. */
var Anim = function() {
...
};
Anim.prototype.start = function() {
...
};
Anim.prototype.stop = function() {
...
};
/* Usage. */
var myAnim = new Anim();
myAnim.start();
...
myAnim.stop();
This defines a new class called Anim and assigns two methods to the class’s prototype
property. We cover this technique in detail in Chapter 3. If you prefer to create classes encapsulated
in one declaration, you might instead write the following:
/* Anim class, with a slightly different syntax for declaring methods. */
var Anim = function() {
...
};
Anim.prototype = {
start: function() {
...
},

stop: function() {
...
}
};
This may look a little more familiar to classical object-oriented programmers who are used
to seeing a class declaration with the method declarations nested within it. If you’ve used this
style before, you might want to give this next example a try. Again, don’t worry if there are parts
of the code you don’t understand:
/* Add a method to the Function object that can be used to declare methods. */
Function.prototype.method = function(name, fn) {
this.prototype[name] = fn;
};
/* Anim class, with methods created using a convenience method. */
var Anim = function() {
...
};
Anim.method('start', function() {
...
});
Anim.method('stop', function() {
...
});
Function.prototype.method allows you to add new methods to classes. It takes two arguments.
The first is a string to use as the name of the new method, and the second is a function
that will be added under that name.
You can take this a step further by modifying Function.prototype.method to allow it to be
chained. To do this, you simply return this after creating each method. We devote Chapter 6
to chaining:
/* This version allows the calls to be chained. */
Function.prototype.method = function(name, fn) {
this.prototype[name] = fn;
return this;
};
/* Anim class, with methods created using a convenience method and chaining. */
var Anim = function() {
...
};

Anim.
method('start', function() {
...
}).
method('stop', function() {
...
});
You have just seen five different ways to accomplish the same task, each using a slightly
different style. Depending on your background, you may find one more appealing than another.
This is fine; JavaScript allows you to work in the style that is most appropriate for the project at
hand. Each style has different characteristics with respect to code size, efficiency, and performance.

A Loosely Typed Language
In JavaScript, you do not declare a type when defining a variable. However, this does not mean
that variables are not typed. Depending on what data it contains, a variable can have one of
several types. There are three primitive types: booleans, numbers, and strings (JavaScript differs
from most other mainstream languages in that it treats integers and floats as the same type).
There are functions, which contain executable code. There are objects, which are composite
datatypes (an array is a specialized object, which contains an ordered collection of values).
Lastly, there are the null and undefined datatypes. Primitive datatypes are passed by value,
while all other datatypes are passed by reference. This can cause some unexpected side effects
if you aren’t aware of it.
As in other loosely typed languages, a variable can change its type, depending on what
value is assigned to it. The primitive datatypes can also be cast from one type to another. The
toString method converts a number or boolean to a string. The parseFloat and parseInt functions
convert strings to numbers. Double negation casts a string or a number to a boolean:
var bool = !!num;
Loosely typed variables provide a great deal of flexibility. Because JavaScript converts type
as needed, for the most part, you won’t have to worry about type errors.

Functions As First-Class Objects
In JavaScript, functions are first-class objects. They can be stored in variables, passed into other
functions as arguments, passed out of functions as return values, and constructed at run-time.
These features provide a great deal of flexibility and expressiveness when dealing with functions.
As you will see throughout the book, these features are the foundation around which you will
build a classically object-oriented framework.
You can create anonymous functions, which are functions created using the function()
{ ... } syntax. They are not given names, but they can be assigned to variables. Here is an
example of an anonymous function:

/* An anonymous function, executed immediately. */
(function() {
var foo = 10;
var bar = 2;
alert(foo * bar);
})();
This function is defined and executed without ever being assigned to a variable. The pair
of parentheses at the end of the declaration execute the function immediately. They are empty
here, but that doesn’t have to be the case:
/* An anonymous function with arguments. */
(function(foo, bar) {
alert(foo * bar);
})(10, 2);
This anonymous function is equivalent to the first one. Instead of using var to declare the
inner variables, you can pass them in as arguments. You can also return a value from this function.
This value can be assigned to a variable:
/* An anonymous function that returns a value. */
var baz = (function(foo, bar) {
return foo * bar;
})(10, 2);
// baz will equal 20.
The most interesting use of the anonymous function is to create a closure. A closure is
a protected variable space, created by using nested functions. JavaScript has function-level scope.
This means that a variable defined within a function is not accessible outside of it. JavaScript is
also lexically scoped, which means that functions run in the scope they are defined in, not the
scope they are executed in. These two facts can be combined to allow you to protect variables by
wrapping them in an anonymous function. You can use this to create private variables for classes:
/* An anonymous function used as a closure. */
var baz;
(function() {
var foo = 10;
var bar = 2;
baz = function() {
return foo * bar;
};
})();

baz(); // baz can access foo and bar, even though it is executed outside of the
// anonymous function.
The variables foo and bar are defined only within the anonymous function. Because the
function baz was defined within that closure, it will have access to those two variables, even
after the closure has finished executing. This is a complex topic, and one that we touch upon
throughout the book. We explain this technique in much greater detail in Chapter 3, when we
discuss encapsulation.

The Mutability of Objects
In JavaScript, everything is an object (except for the three primitive datatypes, and even they
are automatically wrapped with objects when needed). Furthermore, all objects are mutable.
These two facts mean you can use some techniques that wouldn’t be allowed in most other
languages, such as giving attributes to functions:
function displayError(message) {
displayError.numTimesExecuted++;
alert(message);
};
displayError.numTimesExecuted = 0;
It also means you can modify classes after they have been defined and objects after they
have been instantiated:
/* Class Person. */
function Person(name, age) {
this.name = name;
this.age = age;
}
Person.prototype = {
getName: function() {
return this.name;
},
getAge: function() {
return this.age;
}
}
/* Instantiate the class. */
var alice = new Person('Alice', 93);
var bill = new Person('Bill', 30);
/* Modify the class. */

Person.prototype.getGreeting = function() {
return 'Hi ' + this.getName() + '!';
};
/* Modify a specific instance. */
alice.displayGreeting = function() {
alert(this.getGreeting());
}
In this example, the getGreeting method is added to the class after the two instances are
created, but these two instances still get the method, due to the way the prototype object works.
alice also gets the displayGreeting method, but no other instance does.
Related to object mutability is the concept of introspection. You can examine any object at
run-time to see what attributes and methods it contains. You can also use this information to
instantiate classes and execute methods dynamically, without knowing their names at development
time (this is known as reflection). These are important techniques for dynamic scripting
and are features that static languages (such as C++) lack.
Most of the techniques that we use in this book to emulate traditional object-oriented
features rely on object mutability and reflection. It may be strange to see this if you are used to
languages like C++ or Java, where an object can’t be extended once it is instantiated and classes
can’t be modified after they are declared. In JavaScript, everything can be modified at run-time.
This is an enormously powerful tool and allows you to do things that are not possible in those
other languages. It does have a downside, though. It isn’t possible to define a class with a particular
set of methods and be sure that those methods are still intact later on. This is part of
the reason why type checking is done so rarely in JavaScript. We cover this in Chapter 2 when
we talk about duck typing and interface checking.

Inheritance
Inheritance is not as straightforward in JavaScript as in other object-oriented languages. JavaScript
uses object-based (prototypal) inheritance; this can be used to emulate class-based (classical)
inheritance. You can use either style in your code, and we cover both styles in this book. Often
one of the two will better suit the particular task at hand. Each style also has different performance
characteristics, which can be an important factor in deciding which to use.

CSS Shorthand - 2

2009-08-07T10:14:00.000-07:00

CSS Shorthand - 1

2009-08-07T10:09:00.000-07:00

Ok. Let’s set the record straight. There is no official guide for each and every CSS shorthand property value. So let’s work together and put one together shall we? Ok. Straight to the business. Anytime I’ve ran into a specification (besides the confusing mess at the W3C), it turns into showing off a couple of examples and you’re supposed to be set on your way. Well well. Over the years, I’ve found quite some interesting unknown quirky facts about these shorthands… hence this Guide was born.

Background

Backgrounds can be tricky. Nevertheless, effective when condensed correctly. The syntax for declaring the background shorthand values are as follows:

background properties

element {
 background-color: color || #hex || (rgb / % || 0-255);
 background-image:url(URI);
 background-repeat: repeat || repeat-x || repeat-y || no-repeat;
 background-position: X Y || (top||bottom||center) (left||right||center);
 background-attachment: scroll || fixed;
}

Believe it or not, all these properties can be combined into one single background property as follows:

the background shorthand property

element {
 background:
   #fff
   url(image.png)
   no-repeat
   20px 100px
   fixed;
}

The Unknown

Often times developers find themselves wondering What if I leave out this value or that one? How will that effect the design?. Good questions.

By default, the background property will assume the following when you do not declare each value of the properties.

default background property values


element {
 background-color: transparent;
 background-image: none;
 background-repeat: repeat;
 background-position: top left;
 background-attachment: scroll;
}

Lesson learned: be careful on what you don’t declare. By chosing to not declare a value on a shorthand property, you are explicitly declaring the above default settings. For example, let’s look at the following example.

background shorthand example (unexplicit)

element {
 background:red url(image.png);
}

This would be the same as declaring the following values:

background shorthand example (explicit)

element {
 background:red url(image.png) repeat top left scroll;
}

Font

Font is perhaps the trickiest. However, it follows the same rules as the background shorthand property. All that you do not declare will have unexplicit values. Here is the font shorthand specification:

font properties

element {
 font-style: normal || italic || oblique;
 font-variant:normal || small-caps;
 font-weight: normal || bold || bolder || || lighter || (100-900);
 font-size: (number+unit) || (xx-small - xx-large);
 line-height: normal || (number+unit);
 font-family:name,"more names";
}

The default values for the font shorthand property are as follows:

default font property values

element {
 font-style: normal;
 font-variant:normal;
 font-weight: normal;
 font-size: inherit;
 line-height: normal;
 font-family:inherit;
}

And of course without any further ado. The font shorthand property syntax:

the font shorthand property

element {
 font:
   normal
   normal
   normal
   inhert/
   normal
   inherit;
}

Here is where it gets tricky. The fact that font-style, font-variant, and font-weight all come “normal” out of the box, you may need to pay a little more close attention when you’re styling elements that come with default browser styles like <h1> - <h6> or <strong> and <em>. For example, styling the strong element:

strong element styled with font

strong {
 font:12px verdana;
}

By writing the above into your style sheet, you will be unexplicitly removing the font-weight:bold default browser style that is applied to strong elements.

Last but not least (for -font- that is), a real world example:

font shorthand property example (unexplicit)

p {
 font:bold 1em/1.2em georgia,"times new roman",serif;
}

This would be the same as declaring the following properties:

the font shorthand property (explicit)

p {
 font-style:normal;
 font-variant:normal;
 font-weight:bold;
 font-size:1em;
 line-height:1.2em;
 font-family:georgia,"times new roman",serif;
}

Border

Let’s not waste time discussing the warnings. The same rules apply from here on out. This is all you need to know

border properties

element {
 border-width: number+unit;
 border-style: (numerous);
 border-color: color || #hex || (rgb / % || 0-255);
}

becomes this:

the border shorthand propertie

element {
 border:
   4px
   groove
   linen
}

Don’t ask me how that would look. The fact that “linen” is in there, things could get scary. Nevermind the matter, here is where ‘border’ gets funny.

border examples

p {
 border:solid blue;
}
/* will create a '3px' solid blue border...
  who knows where 3px came from?? */

p {
 border:5px solid;
}
/* will create 5px solid 'black' border...
   default must be black?? */

p {
 border:dashed;
}
/* will create a '3px' dashed 'black' border...
   3px black lines unite! */

p { border:10px red; }
p { border:10px; }
p { border:red; }
/* these just don't even work */

One thing to specially take note about declaring a border without a color, the default will be ‘black’ unless otherwise noted through an explicit or inherited ‘color’ property. See the following examples:

border color examples


p {
 border:dotted;
 color:red;
}
/* will create a 3px dotted red border */
/* ----------------------------- */
body {
 color:blue;
}
body p {
 border:5px solid;
}
/* will create a 5px solid blue border */
/* ----------------------------- */

Get it? Got it. Good! (isn’t that a song?) Anyway. On with this

Margin and Padding

These are by far the easiest. Just think about the hands of a clock starting at noon, and follow the hour. For the sake of brevity, we’ll be working with margin (since it’s a shorter word). So for all cases of margin, the same rules apply to padding.

margin properties.

element {
 margin-top: number+unit;
 margin-right: number+unit;
 margin-bottom: number+unit;
 margin-left: number+unit;
}

… combined into the margin superpowers:

the margin shorthand property

/* top right bottom left */
element {
 margin: auto auto auto auto;
}

Of course, you may declare your margin with one, two, three, or four values. Here is how each scenario will be played out:

margin fun

/* adds a 10px margin to all four sides */
element {
 margin:10px;
}

/* adds a 20px margin to top and bottom
   and a 5px margin to left and right */
element {
 margin:20px 5px;
}

/* adds a 50px margin to top
   and a 10px margin to left and right
   and a 300px margin to bottom */
element {
 margin:50px 10px 300px;
}

Understood? Let’s keep going. This is fun isn’t it! (whatever, you like it).

Outline

Quite frankly, this property has dropped off the existence of the design radar. Mainly because of lack of browsers supporting this CSS 2.1 standard (yep, it’s an actual property), but nonetheless, it too has a shorthand property. This property follows the exact same (or same exact - they mean the same thing) specification as the ‘border’ shorthand property. But, for purposes of this being a Guide, it must be here. So:

outline properties

element {
 outline-width: number+unit;
 outline-style: (numerous);
 outline-color: color || #hex || (rgb / % || 0-255);
}

Outline written as shorthand:

outline shorthand property

element {
 outline:3px dotted gray;
}

For purposes of trying to keep things from repeating, please see the border shorthand section on this document to understand the odds, ends, and quirks of the outline property.

List-style

This is it. The last one. It’s rarely used frequently. Hence rarely. That is why I kept it until the end (sorry, the best was first in my own opinion). Here is the list-style properties:

list-style properties

element {
 list-style-type: (numerous);
 list-style-position:inside || outside;
 list-style-image:url(image.png);
}

Here is the defaults:

list-style property defaults

element {
 list-style-type:disc;
 list-style-position:outside;
 list-style-image:none;
}

And for the sake of final brevity. Here is a simple example:

list-style shorthand property example

ul li {
 list-style:square inside url(image.png);
}
/* in this particular case if image.png is not available
   then a square will be provided as secondary */

That’s it!

I hope this provides years and years of referencing for all your CSS shorthand needs. When CSS3 is finally outside its working draft, expect to see this guide updated as necessary.