1. Rebase vs Merge in Git
2. Avoid Merge commit in Git, this one shows very detail about the difference on these two options, and it is the exact problem I was facing.

I’d also like to quote the work pattern that is described in the above 1st link. (The result is basically put all your branch work/commits ahead of your base branch, for example master, and of course without adding those meaningless merge commits that you would have if you use the git merge.)

1. Create new branch B from existing branch A
2. Add/commit changes on branch B
3. Rebase updates from branch A
4. Merge changes from branch B onto branch A

I typically use the ‘master’ branch as the base branch, which means that I only sync this branch from the remote repository, and only merge commits into this branch when I think the bug/feature is completed. Once I’ve done the merge in master, I’ll do the commit and push, so the code in master branch’s staging repository is very short. However, I’ve done a lot of pull request from remote repository into the master branch, as I need to sync other people’s work, and then I’ll do the rebase on the topic/bugfix branch that I am working on to sync the work without adding the merge commit, and put my commit in front of others commits that are already in the repo.

One caution with regard to the rebase operation is: (Again quote from the 2nd link that I pointed)

If you’ve shared the branch with anyone else, or are pushing it to a clone of the repository, do not rebase, but use merge instead. From the man page:

When you rebase a branch, you are changing its history in a way that will cause problems for anyone who already has a copy of the branch in their repository and tries to pull updates from you. You should understand the implications of using git rebase on a repository that you share.

Git is a DVCS, so it means that we have all histories, logs in my local machine, the remote one should be served as a backup/collaborate purpose. So it means for checking the commits/difference, it should be accomplished without connecting to internet.  Here I’ll try to enumerate some options/commands that I ran for checking those updates/commits. If you have any other good usages/commands that I left out. please feel free to make a comment.

1. Show all of previous commits (result only shows commit summary):

git  log

2. Show the latest n commits:

git  log  -n

3. Show the statistics (like updated file list) in previous commits:

git log –stat

4. Show previous commits with patches:

git log -p

5. Show a specific commit with commit hash id, you just need to have enough first couple letters to make it unique:
Add –stats (if you want to show the statistics) and -p (if you want to show the detailed diff) options.

git show 36b314c (first couple letters of id)

6. Show commits/histories to a specific file (-p, -n apply here as well, but should be in front of filepath):

git log — filepath

7. Show a diff on a specific file with a specific commit:

git show commitId (like 36b314c for example) — filepath

9. Show difference between two commits:

git diff firstCommitId secondCommitId

10. Show difference between two commits for a specific file.

git diff firstCommitId secondCommitId — filepath

In RiftSaw 3 development, we are taking this opportunity to upgrading its JPA layer from JPA 1.0 to JPA 2.0, as JPA 2.0 is back compatible, it shouldn’t be an big issue. However, we’ve implemented the ConnectionProvider and TransactionManagerLookup interfaces, since we’ve created the Datasource and TransactionManager on our own, we need to implement these two interfaces to ask Hibernate to use our own one.

In Hibernate 4.x, the whole package has been split into three categories, API/Impl/SPI.  So the ConnectionProvider class has been re-packaged at: org.hibernate.service.jdbc.connections.spi.ConnectionProvider, if you see the internal implementation of this, you would also notice that it also implements the Configurable and Stoppable. The Configurable interface allows you to access to the Hibernate’s properties, which is kept as Map. It is much like Spring’s BeanNameAware interface, where you get to access to the BeanName. So below is the code snippet that I used for my ConnectionProvider.

public class DataSourceConnectionProvider implements ConnectionProvider, Configurable, Stoppable  {

  private Properties _props;

  private boolean available = true;

  public DataSourceConnectionProvider() {
  }

  @SuppressWarnings( {"unchecked"})
  public void configure(Map properties) {
	 _props = new Properties();
	 _props.putAll(properties);
  }

  public Connection getConnection() throws SQLException {
	if (!available) {
		throw new HibernateException( "Provider is closed!" );
	}
    Connection c = HibernateUtil.getConnection(_props);
    DbIsolation.setIsolationLevel(c);
    return c;
  }

  public void closeConnection(Connection con) throws SQLException {
    con.close();
  }

  public boolean supportsAggressiveRelease() {
    return true;
  }

  public boolean isUnwrappableAs(Class unwrapType) {
		return ConnectionProvider.class.equals(unwrapType) ||
				DataSourceConnectionProvider.class.isAssignableFrom(unwrapType);
  }

  @SuppressWarnings( {"unchecked"})
  public  T unwrap(Class unwrapType) {
		if (ConnectionProvider.class.equals(unwrapType) ||
				DataSourceConnectionProvider.class.isAssignableFrom(unwrapType)) {
			return (T) this;
		} else {
			throw new UnknownUnwrapTypeException( unwrapType );
		}
  }

  public void stop() {
	available = false;
  }
}

For the TransactionManagerLookup interface, you would get WARN  saying this API has been deprecated ( I believe it has been deprecated before 4.x, but I didn’t get a chance to upgrade it until now), we should implement the org.hibernate.service.jta.platform.spi.JtaPlatform SPI instead, and set it to the ‘hibernate.transaction.jta.platform’ property. Instead of having a class that implement the JtaPlatform SPI directly, I’ve subclassed it from the  AbstractJtaPlatform class, so that I’ve only needed to override two interfaces. Below is the code snippet for my custom JtaPlatform impl.

/**
 *
 * uses {@link HibernateUtil} to obtain the JTA {@link TransactionManager} object.
 *
 * @author Jeff Yu
 *
 */
public class OdeJtaPlatform extends AbstractJtaPlatform {

	private Properties properties = new Properties();

	public void configure(Map configValues) {
		super.configure(configValues);
		properties.putAll(configValues);
	}

	@Override
	protected TransactionManager locateTransactionManager() {
		return HibernateUtil.getTransactionManager(properties);
	}

	@Override
	protected UserTransaction locateUserTransaction() {
		throw new UnsupportedOperationException("locateUserTransaction is not supported. Use the locateTransactionManager instead.");
	}

} 

And then when you create your entityManagerFactory, remember to pass the following properties in.

props.put(Environment.CONNECTION_PROVIDER, DataSourceConnectionProvider.class.getName());
props.put(Environment.JTA_PLATFORM, OdeJtaPlatform.class.getName());

Done, the custom ConnectionProvider and JtaPlatform implementation should be all set now.

Hope this will help you do the Hibernate upgrade at some point. Here, I’d like to thanks Strong Liu to send the helpful links to me on this upgrading.

1. Using JBoss MC’s xml syntax
This is the most common and recommended way to do. Below is the JBoss RiftSaw Clustering service that uses the ‘HAPartitonService’ from JBoss AS Cluster.

   <bean name="RiftSawClusteringService" class="org.jboss.soa.bpel.clustering.JBossClusteringService">
   	 <property name="haPartition"><inject bean="HAPartition" /></property>
   	 <property name="bpelEngineName">bpel/Engine</property>
   	 <depends>BPELEngine</depends>
   </bean>

See Ales’ Advanced Dependency Injections article for more about MC’s xml syntax.

2. Using JBoss MC’s service programmatically
This way actually is the main topic for this blog entry. If you are a Spring framework user, you would know you can use BeanFactory or ApplicationContext to get the service bean. Then in JBoss, you would wonder, whats the equivalent way to do this?

1) org.jboss.kernel.Kernel, this is the service that has the KernelController and ControllerContext that we need for getting the service. so firstly, you can define a service in -jboss-bean.xml that injects the Kernel service, like the following:

<!--    Locate the single instance of the kernel    -->
<bean name="org.jboss.soa.bpel.runtime.util:service=KernelLocator"
     class="org.jboss.soa.bpel.runtime.integration.KernelLocator">
    <property name="kernel">
      <inject bean="jboss.kernel:service=Kernel" />
    </property>
</bean>

We’ve defined above class as following:

package org.jboss.soa.bpel.runtime.integration;
public class KernelLocator{
  private static Kernel kernel;
  public static Kernel getKernel()  {    return KernelLocator.kernel;  }
  public void setKernel(Kernel kernel)  {    KernelLocator.kernel = kernel;  }
}

2) Use the KernelController and ControllerContext to get the service that we defined in *-jboss-bean.xml.
Below is the code to actually obtain the started service out of JBoss AS.

public class KernelAwareSPIFactory{
   @SuppressWarnings("unchecked")
   public <T> T getKernelProvidedSPI(String beanName, Class<T> spiArtifact)   {
      KernelController controller = KernelLocator.getKernel().getController();
      ControllerContext ctx = controller.getInstalledContext(beanName);
      return (T)ctx.getTarget();   }
}

In the end, let’s take an example from RiftSaw code base to show how it was used.

In RiftSaw, we’ve defined a ServerConfig interface.

public interface ServerConfig{
  /** The default bean name */
  String BEAN_NAME = "org.jboss.soa.bpel.runtime.util:service=ServerConfig";

  String getImplementationTitle();

  String getImplementationVersion();

  File getServerTempDir();

  File getServerDataDir();

  String getWebServiceHost();

  int getWebServicePort();

  .....
}

And then we’ve had the ServerConfigImpl class.

public class ServerConfigImpl implements ServerConfig{  ....}

With this implementation, we’ve defined the ServerConfig service in the *-jboss-bean.xml as following.

<!--       ServerConfig    -->
 <bean name="org.jboss.soa.bpel.runtime.util:service=ServerConfig"
        class="org.jboss.soa.bpel.runtime.integration.ServerConfigImpl">
    <property name="mbeanServer">
     <inject bean="JMXKernel" property="mbeanServer"/>
    </property>
    <property name="webServiceHost">${jboss.bind.address}</property>
  </bean>

Now, finally let’s see how we get this ServerConfig Service in our code.

ServerConfig = new KernelAwareSPIFactory()
               .getKernelProvidedSPI("org.jboss.soa.bpel.runtime.util:service=ServerConfig", ServerConfig.class

And then, here you go, you’ve got the ServerConfig service that is in the JBoss AS.

Hope this can help people who are doing integration with JBoss AS a little bit.

PS: Thanks Glen for pointing out some grammar errors that I did earlier. As what we used to say “your patch has been applied, thanks a lot. ”

1.Installing PostgreSQL on Leopard using MacPorts
2.Installing MySQL on Mac OS X Leopard using MacPorts

And this is what the scheduler-simple module for, it takes care of putting a task into database and pull tasks out of database and how to run them. Lets make a simple example here, say your bpel process has a invoke Activity to invoke an external web service. In Ode, just right before entering invoke Activity, we’ve created a job that captures this invoke activity information, and store it into the database. Because once we’ve started Ode Bpel Server, we already started a background thread that checks this ode_job table periodically, once we’ve found that there is a job needs to be executed, it will load it from database, put it into memory, and then submit it to the ExecutorService for execution.

In this blogpost, we will examine this module’s architecture and important APIs.

First is the Task API, this is the parent class for Job and SchedulerTask.

class Task {
    /** Scheduled date/time. */
    public long schedDate;

    Task(long schedDate) {
        this.schedDate = schedDate;
    }
}

It is very simple, just had a scheduled date for its execution.
Next, we will see the Job’s API, Job is for invoking an external service and like. we’ve put all of important information into the JobDetail object.

class Job extends Task {
    private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss z");
    String jobId;
    boolean transacted;
    JobDetails detail;
    boolean persisted = true;

    public Job(long when, String jobId, boolean transacted, JobDetails jobDetail) {
        super(when);
        this.jobId = jobId;
        this.detail = jobDetail;
        this.transacted = transacted;
    }
....
}

Now, lets look at another type of Task, which is called SchedulerTask.

private abstract class SchedulerTask extends Task implements Runnable {
    SchedulerTask(long schedDate) {
        super(schedDate);
    }
}

This is an abstract class, its subclasses are: LoadImmediateTask, UpgradeJobsTask, CheckStaleNodes.

To understand these tasks, it is better that we look at what SimpleScheduler class defined. In Ode, the job design was based around three time horizons: “immediate”, “near future”, and “everything else”.
Immediate jobs (i.e. jobs that are about to be up) are written to the database and kept in an in-memory priority queue. When they execute, they are removed from the database. Near future jobs are placed in the database and assigned to the current node, however they are not stored in
memory. Periodically jobs are “upgraded” from near-future to immediate status, at which point they get loaded into memory. Jobs that are further out in time, are placed in the database without a node identifer; when they are ready to be “upgraded” to near-future jobs they are assigned to one
of the known live nodes. recovery is straight forward, with stale node identifiers being reassigned to known good nodes.

In terms of time, we defined two variables, one is: _immediateInterval and _nearFutureInterval.
if a job’s scheduled date is between [now, now + _immediateInterval], it belongs to the “immediate” job.
while if it is in [now + _immediateInterval, now + _nearFutureInterval], it belongs to the “near future” job then.

You can check the SimpleScheduler.doLoadImmediate() and SimpleScheduler.doUpgrade() respectively for its logic.

Also, you may be aware that we’ve also had the CheckStaleNodes task, this is basically for clustering work, to
check if there are any stale nodes, if it has, we will move the assigned jobs over to other node by updating nodeId.

So now, we’ve seen different Tasks, like Jobs and SchedulerTask. Now, we will need an interface to run these Tasks, hence TaskRunner was introduced.

interface TaskRunner {
    public void runTask(Task task);
}

Here is the implementation from SimpleScheduler.TaskRunner() method.

public void runTask(final Task task) {
    if (task instanceof Job) {
        Job job = (Job)task;
        if( job.detail.getDetailsExt().get("runnable") != null ) {
            runPolledRunnable(job);
        } else {
            runJob(job);
        }
    } else if (task instanceof SchedulerTask) {
        _exec.submit(new Callable() {
            public Void call() throws Exception {
                try {
                    ((SchedulerTask) task).run();
                } catch (Exception ex) {
                    __log.error("Error during SchedulerTask execution", ex);
                }
                return null;
            }
        });
    }
}

As I said before, once we’ve start BpelServer, we will start a thread running, it only gets stopped only when the BpelServer is been stopped.
Thats called SchedulerThread.

In this class, basically we had following members: PriorityBlockingQueue, this is queue for the immediate execution. TaskRunner, this is the
container for running Task. The logic for the running is quite straight forward.

/**
 * Pop items off the todo queue, and send them to the task runner for processing.
 */
public void run() {
    while (!_done) {
        _lock.lock();
        try {
            long nextjob;
            while ((nextjob = nextJobTime()) > 0 && !_done)
                _activity.await(nextjob, TimeUnit.MILLISECONDS);

            if (!_done && nextjob == 0) {
                Task task = _todo.take();
                _taskrunner.runTask(task);

            }
        } catch (InterruptedException ex) {
            ; // ignore
        } finally {
            _lock.unlock();
        }
    }
}

Now that we’ve seen all of important APIs here, we will look at how we start SimpleScheduler when ODEServer is started.
excerpt from SimpleScheduler.start() method.

public synchronized void start() {
    if (_running)
        return;

    if (_exec == null)
        _exec = Executors.newCachedThreadPool();

    _todo.clearTasks(UpgradeJobsTask.class);
    _todo.clearTasks(LoadImmediateTask.class);
    _todo.clearTasks(CheckStaleNodes.class);
    _processedSinceLastLoadTask.clear();
    _outstandingJobs.clear();

    _knownNodes.clear();

    try {
        execTransaction(new Callable() {

            public Void call() throws Exception {
                _knownNodes.addAll(_db.getNodeIds());
                return null;
            }

        });
    } catch (Exception ex) {
        __log.error("Error retrieving node list.", ex);
        throw new ContextException("Error retrieving node list.", ex);
    }

    long now = System.currentTimeMillis();

    // Pretend we got a heartbeat...
    for (String s : _knownNodes) _lastHeartBeat.put(s, now);

    // schedule immediate job loading for now!
    _todo.enqueue(new LoadImmediateTask(now));

    // schedule check for stale nodes, make it random so that the nodes don't overlap.
    _todo.enqueue(new CheckStaleNodes(now + randomMean(_staleInterval)));

    // do the upgrade sometime (random) in the immediate interval.
    _todo.enqueue(new UpgradeJobsTask(now + randomMean(_immediateInterval)));

    _todo.start();
    _running = true;
}

Also, please noted that we had two different types of JobProcessor, one is ordinary JobProcessor, the other one is PolledRunnableJobProcessor, which is meant for running some jobs that gets run periodically.

1. Instant message: Adium, http://adium.im/
2. video chat: skype, http://www.skype.com
3. irc client, colloquy, http://colloquy.info/
4. chinese input, just use the built-in one directly, here is an post about the chinese input, and also can use the chinese language for the whole mac osx. http://appleclinic.wordpress.com/2008/04/16/chinese-text-input/
5. firefox, In case you still like to use the firefox in your mac box, yes, it works great. http://www.firefox.com
6. twitter client, twitterrific: http://iconfactory.com/software/twitterrific
7. QQ, this one should be very china specific, , good news is that we do have a Mac OS X QQ as beta right now.
8. QuickSilver, this is a new tool compared to what I had in both windows and linux, it makes people really easy to start application, you can download and install it from here. http://www.blacktree.com/
9. Textmate, this one is a lot of rubyists choice on doing ruby on rails.. http://macromates.com/, not free though.
10. Skitch, http://skitch.com/, make it easy to share screenshot etc.
11. Eclipse, this is still my preference for java programming.
12. Macports, this is a utility more like Fedora’s Yum, Ubuntu’s apt-get.
13. Growl, this is a great software for the notifications.
14. dropbox, this is a pretty good software if you want to sync stuff between mac and iphone.

If you want to install JDK5 in the snow leopard, here is a good solution to this problem, http://www.scribd.com/doc/22853741/Installing-Java-5-Back-on-Snow-Leopard, Here I’d like to thank Kurt, strong, liweinan for making some suggestions on these softwares.

At last, this is what I had, http://skitch.com/jeffyu/dp3pm/fullscreen.

please let me know what else you believe that I should try out.

 __log.debug("Initializing transaction manager");
 initTxMgr();
__log.debug("Creating data source.");
initDataSource();
__log.debug("Starting DAO.");
initDAO();
EndpointReferenceContextImpl eprContext = new EndpointReferenceContextImpl(this);                __log.debug("Initializing BPEL process store.");
initProcessStore(eprContext);
__log.debug("Initializing BPEL server.");
initBpelServer(eprContext);
 __log.debug("Initializing HTTP connection manager");
 initHttpConnectionManager();

// Register BPEL event listeners configured in axis2.properties file.
registerEventListeners();
registerMexInterceptors();
registerContextInterceptors();        .....

As above code shown:

• Initialized the TransactionManager, which will be used in the datasource and scheduler service.
• Created the data source.
• Created the DAOConnectionFactory, the extension API is BpelDAOConnectionFactory.
• Created the EndpointReferenceContext, which takes care of resolving EndpointReference.
• Created the Process Store, it takes care of process deploying, undeploying, list etc.
• Initializing the BpelServer, includes following actions: setMessageExchangeContext, setDaoConnectionFactory, setBindingContext, the BindingContext and the MessageExchangeContext are the extension points for communicating with partner services.
• Register the EventListners, MexInterceptors etc, these are all the APIs in BpelServer.

You also could see how we initialize the BpelServer in the MockBpelServer class. In the Riftsaw project,it is in the BpelEngineImpl class. In the Riftsaw project, we are adding another implementation for the ProcessStore that leverages the JBoss Application Server’s Deployer mechanism, also we adding another implementation for the BindingContext that use the JAXWS based approach, which used the JBossWS to accomplish.