Saturday, October 31, 2009

Probability 6

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
Posted by at No comments:
Labels: ,

Probability 5

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.
Posted by at No comments:
Labels: ,

Wednesday, October 28, 2009

Probability 4

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%
Posted by at No comments:
Labels: ,

Tuesday, October 27, 2009

Probability 3

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
Posted by at No comments:
Labels: ,

Monday, October 26, 2009

Probability 2

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
Posted by at No comments:
Labels: ,

Sunday, October 25, 2009

Probability 1

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%
Posted by at No comments:
Labels: ,

Sunday, October 18, 2009

Determining the master node in a JBoss Cluster


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.
  1. public class MyHAService extends HASingletonSupport implements
  2. MyHAServiceMBean {

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

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

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

  17. public boolean isMasterNode() {
  18. return super.isMasterNode();
  19. }


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


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


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

  42. }
  43. }
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:
  1. private String getMasterSocket() {

  3. HAPartition partition = this.getPartition();

  5. if (partition != null) {

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

  10. } else {
  11. return null;
  12. }
  13. } else {
  14. return null;
  15. }
  16. }
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?.
Posted by at No comments:
Labels:

Finding the number of cluster nodes in JBoss


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.
Posted by at No comments:
Labels:

JBoss Clustering

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.

clustered singleton diagram
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:

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

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

Posted by at No comments:
Labels:

Saturday, October 17, 2009

Brief on JBoss EAR Deployment

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.
Posted by at No comments:
Labels:

JBoss Lookup

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:

  1. Context ctx = new InitialContext();
  2. 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:

  1. javax.naming.NameNotFoundException: somepath not bound
  2. at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
  3. at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
  4. at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
  5. at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
  6. at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  7. at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  8. at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  9. at java.lang.reflect.Method.invoke(Method.java:585)
  10. at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
  11. at sun.rmi.transport.Transport$1.run(Transport.java:153)
  12. at java.security.AccessController.doPrivileged(Native Method)
  13. at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
  14. at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
  15. at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
  16. at java.lang.Thread.run(Thread.java:595)
  17. at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
  18. at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
  19. at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
  20. at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
  21. at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
  22. at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
  23. 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):

  1. java: Namespace

  3. +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  4. +- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
  5. +- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)
  6. +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
  7. +- comp (class: javax.naming.Context)
  8. +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
  9. +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  10. +- jaas (class: javax.naming.Context)
  11. | +- dukesbank (class: org.jboss.security.plugins.SecurityDomainContext)
  12. | +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)
  13. | +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)
  14. | +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)


  17. Global JNDI Namespace

  19. +- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)
  20. +- ebankAccountController (proxy: $Proxy75 implements interface com.sun.ebank.ejb.account.AccountControllerHome,interface javax.ejb.Handle)
  21. +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
  22. +- jmx (class: org.jnp.interfaces.NamingContext)
  23. | +- invoker (class: org.jnp.interfaces.NamingContext)
  24. | | +- RMIAdaptor (proxy: $Proxy48 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
  25. | +- rmi (class: org.jnp.interfaces.NamingContext)
  26. | | +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)
  27. +- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  28. +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  29. +- ebankCustomer (proxy: $Proxy67 implements interface com.sun.ebank.ejb.customer.LocalCustomerHome)
  30. +- UserTransactionSessionFactory (proxy: $Proxy14 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
  31. +- ebankCustomerController (proxy: $Proxy77 implements interface com.sun.ebank.ejb.customer.CustomerControllerHome,interface javax.ejb.Handle)
  32. +- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  33. +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  34. +- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple)
  35. +- ebankAccount (proxy: $Proxy68 implements interface com.sun.ebank.ejb.account.LocalAccountHome)
  36. +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
  37. +- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
  38. +- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
  39. +- queue (class: org.jnp.interfaces.NamingContext)
  40. | +- A (class: org.jboss.mq.SpyQueue)
  41. | +- testQueue (class: org.jboss.mq.SpyQueue)
  42. | +- ex (class: org.jboss.mq.SpyQueue)
  43. | +- DLQ (class: org.jboss.mq.SpyQueue)
  44. | +- D (class: org.jboss.mq.SpyQueue)
  45. | +- C (class: org.jboss.mq.SpyQueue)
  46. | +- 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:
  1. +- 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 plaincopy to clipboardprint?
  1. Context ctx = new InitialContext();
  2. ctx.lookup("ebankTxController");


Similarly in the same Global JDNI Namespace, we see :

  1. +- queue (class: org.jnp.interfaces.NamingContext)
  2. | +- 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:

  1. Context ctx = new InitialContext();
  2. 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

  1. +- 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:

  1. Context ctx = new InitialContext();
  2. 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.
Posted by at No comments:
Labels:

Thursday, October 1, 2009

All you need to know about Javascript Inheritance

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;
}
Posted by at No comments:
Labels: ,
Subscribe to: Posts (Atom)