Monday, August 24, 2015

Switching SOLR JDK version

In some cases, your JAVA_HOME environment variable may not point to the  version SOLR demands.  For example, my development environment demands JDK 6, where as SOLR 5,x requires JDK 1.7 and above.

SOLR provides its own JAVA_HOME environment variable SOLR_JAVA_HOME.  Set this variable to the JDK version you need to and you are all set.

In Windows, use the Control Panel->Environment Variables section to set the SOLR_JAVA_HOME.

Then run solr start -p <port-number>, usually, <port-number> = 8983.

That is all.

Wednesday, May 27, 2015

Using serialver JDK command

If you are implementing java.io.Serializable, it is a good practice to create the serialVersionUID for that class.  Otherwise, when the class structure is changed (adding or removing the attributes), you will have the nightmare of handling the different serialVersionUID issues.

You can provide any random value to the serialVersionUID but it is better to let the tools generate the unique IDs for each class.

Eclipse comes with the built-in serialVersionUID option to generate the unique UID.  However, if the project is not compiled successfully (typically the dependencies issues), or if you don't want Eclipse to build your project, generating the version UID is not possible.

That is where serialver command line comes to the rescue.  The format is:

serialver [-classpath classpath] [-show] [className]

[-classpath classpath] - is where your class files' root folder.  For ex. if you have <myfolder>/target/classes/com/mytest/MyOnlyTest.class, then your class files root folder is <myfolder>/target/classes/.  

Most of the times the classpath value is required.  If you run the serialver command from "<myfolder>/target/classes", the classpath value will be "./".  It is always better to start from the folder where the root package is the subdirectory of that.

[-show] - This will provide UI option.  This will work just like the command line.

[className] - The fully qualified class name (that is including the package name).  For ex. com.mytest.MyOnlyTest

Example  (Using the command line):

c:\<myfolder>\target\classes>serialver -classpath "./" com.mytest.MyOnlyTest

If the class is a valid one, you will see the serialVersionUID entry like this:

com.mytest.MyOnlyTest:  static final long serialVersionUID = -7039383885342506716L

Copy that value and paste it in your java file.

Example (Using the UI):

c:\<myfolder>\target\classes>serialver -classpath "./" -show

This will display a small box with entering the full class name.  Enter com.mytest.MyOnlyTest, then click "Show".  If the class is a valid one, you will see the serialVersionUID entry in the "Serial Version" box.  

Copy that value and paste it in your java file.

Note: If you get the <className> is not found, check whether you entered the right class path value.

Thursday, April 2, 2015

Reverting accidental SVN Checkins

The one thing I want from TortoiseSVN is a confirmation message whenever I am commiting my changes.  Sometimes, I use "SVN Commit..." option to see which files were changed and accidentally, I hit "Ok" instead of "Cancel".   If you're in the same boat, read on.

If you accidentally checked in the files that are not supposed to be, you need to revert that revision and bring your local code back to the same set of files that must be in the "Changed" state.  Follow these steps for the result:


  1. Create a new local folder.
  2. Get the latest code from the branch where the files are accidentally checked in.
  3. Right click on the local folder and select "Tottoise SVN...Show Log". This will show the revisions including the one you had accidentally checked in.
  4. Right click the revision below the one you last checked in.
  5. Choose "Revert to this revision" option.
  6. This will cancel all the changes that were checked in the "accidental" version in your local copy.
  7. Right click on the new local folder and select "SVN Commit..." to commit the reverted changes.
  8. To bring back your changes to the local folder, see the next section "Bringing back the changes to the local version".



Bringing back the changes to the local version

  1. Go back to the root of the folder where the "accidental" check in happened.
  2. Right click and "Tortoise SVN...Show Log".
  3. Click the revision  you checked in accidentally and the revision below that.
  4. Right Click and select "Show differences as unified Diff".  This will show all the changes you did.
  5. Click "File" and save it as a patch.
  6. In the root of the folder, right click and "Svn Update"
  7. It will bring the latest version (which had been checked in after cancelling out your changes).
  8. Right click on the root folder and select "Tortoise SVN...Apply Patch..." option.
  9. Select the patch file you created in 5).
  10. Select "Patch All Items" option.
  11. Your changes should now be available in the local branch.

Tuesday, February 24, 2015

Factory Pattern using Spring injection

In this article, let us see how to use Spring injection to use the factory design pattern.

What is factory design pattern?

From wikipedia, the factory design pattern is:"In class-based programming, the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created. This is done by creating objects via calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor."

The advantage of the factory pattern is the caller just sends the information about which class the caller would like to execute based on the runtime scenario.  A typical example is when you want to encrypt a string based on different RSA algorithms, you can write the encrytion methods in individual classes and at run time, the caller can choose to call the factory method to specify which algorithm he needs to encrypt the data.

To implement the above example, I have created an interface called ICrypto which has two methods: encrypt and decrypt:



           public interface ICrypto{
             public byte[] encrypt(byte[] plaintext);
             public byte[] decrypt(byte[] encryptedText);
           }


The implementation of the above interface for AES will be:


           public class AESCrypto implements ICrypto {
             public AESCrypto() {}
             public byte[] encrypt(byte[] plaintext){
               ...
               //your code here
               ...
               return encryptedBytes;
             }

             public byte[] decrypt(byte[] encryptedtext){
               ...
               //your code here
               ...
               return plainTextInBytes;
             }
           }

Similarly, for RC2, the implementation is:

           public class RC2Crypto implements ICrypto {
             public RC2Crypto() {}
             public byte[] encrypt(byte[] plaintext){
               ...
               //your code here
               ...
               return encryptedBytes;
             }

             public byte[] decrypt(byte[] encryptedtext){
               ...
               //your code here
               ...
               return plainTextInBytes;
             }
           }

Define the crypto types enum:

           public enum CryptoTypes{
             AES_CRYPTO_TYPE,
             RC2_CRYPTO_TYPE;
           }


Now we need a factory class which is going to create the instance of one of the implementations above:

           public final class CryptoFactory {
             //make sure the constructor is not accessible.
             private CryptoFactory(){}
             //factory method
             public final static ICrypto getCryptoInstance(CryptoTypes type) {
               switch(type){
                case AES_CRYPTO_TYPE:
                 return new AESCrypto();
                case RC2_CRYPTO_TYPE:
                 return RC2Crypto();
               }
             }
           }

Now the caller can call the CryptoFactory.getCryptoInstance() with the enum value as a parameter and get the instance,

The above is a typical example of the factory pattern in non-spring world.

In Spring, all of the above are the same except the factory class.  Using the injection mechanism, the factory class need not go through the switch() statement.  Lets see how this can be achieved:

  1.  First define all the implemented beans in the spring bean definition XML.For example:
    <bean id="crypto.rc2crypto" class="com.example.RC2Crypto"></bean>
  2. Then define the enum constants also as a bean instance.  For example:                               <bean id="ctyptotype.enum.rc2" class="com.example.CryptoTypes" factory-method="valueOf"            <constructor-arg value="RC2_CRYPTO_TYPE"/>                                                                 </bean>
  3. Now wire up the crypto type bean definitions with the implementation bean definitions as a map.  For example:                                                                                                                                    <util:map id="cryptoMap" map-class="java.util.LinkedHashMap">
    <entry key-ref="ctyptotype.enum.rc2" value-ref="crypto.rc2crypto" />
    <entry key-ref="ctyptotype.enum.aes" value-ref="crypto.aescrypto" />
       </util:map>
  4. Wire the factory bean instance with the map we created in 3.  For example:                    <bean id="crypto.factory" class="com.example.CryptoFactory">                                                            <property name="cryptoTypes" ref="cryptoMap" />                                                   </bean>

With the above implementation, the same CryptoFactory will look like this:


           public final class CryptoFactory {
             private Map cryptoTypes;

             public Map getCryptoTypes() {
               return cryptoTypes;
             }

             public void setcryptoTypes(Map cryptoTypes) {
               this.cryptoTypes = cryptoTypes;
             }

             public ICrypto createCryptoFactory(CryptoTypes cryptoType){
               return cryptoTypes.get(cryptoType);
             }
           }

Now the caller can inject the instance of the crypto factory bean in their bean class and call createCryptoFactory(CryptoType.AES_CRYPTO_TYPE).

Even better way is the caller bean can define allowed crypto types for that bean (for example, the bean can use only AES_CRYPTO_TYPE) and use that variable instance to call createCryptoFactory().   It is now boiled down to the bean implementor's design.

Advantages of using Spring injection

As I mentioned above, once we defined all the possible types as enum, the caller bean can control which subset of enum types it can use to get the crypto implmentation's instance.  This adds more security as module X in the application can use only AES crypto type whereas module Y can use only RC2 crypto type.

Also, turning on or off of any crypto type is going to be only in the spring context XML files rather than in the code.  The factory class is encapsulated from which crypto types it is using.

And that is all folks,,,,


Wednesday, January 7, 2015

Useful Regular Expressions

Often times we need to search and if needed, replace the text in the large document or extract logs based on some fixed string values.  This post lists some of the regular expressions I have used very often.  This post will be updated regularly as I come across new regular expressions for new use cases:

Use Case 1:

Find a position if the first occurrence of the string.  for example, find the first occurrence of the string "SF_".  This will highlight the line up to that string.

^.*?(?=SF_)

Use Case 2:

Select whole line.

(.+)

Use Case 3:

Surround the entire line with the double quotes and add "," after the endquote.

"\1",

Use Case 4:

Find end of the line and add "," at the end.

Search: ([^\n])$
Replace : \1,

Use Case 5:

Find a string and highlight up to the end of the line.

Search: <string>.*

Example:
query.*


That is all for now.  As I mentioned in the beginning, I will update this post as I come across interesting scenarios.