Installing Jupyter Notebook and Numpy in Windows

I had hard time to install Jupyter Notebook.  My machine already had Python 2.7 and after installing anaconda and trying to run 'juypter notebook' command threw python errors.

Then I tried to uninstall Python 2.7 and again let the anaconda install its own python version.  No luck.

Then finally I removed all the Python installation but forgot to remove the path variables (more on this below).  Then installed python 3.5 version (take the latest 3.5 release).

Then using pip3 install jupyter, the notebook got installed successfully.

Then running 'jupyter notebook', got an error message "Fatal Python error: Py_Initialize: unable to load the file system codec".  Upon checking the forums, one of the solution was to check the PATH and the PYTHONPATH environment variables.  Bingo..they were still referring to the older and now removed installations of Python.

Removed them and the 'jupyter notebook' brought the index page in the browser but with the 404 error.

Again, forums helped me.  It looks like there may be a bug in the jupyter version I downloaded, so if you run the 'jupyter notebook' from your root folder (c:\), then this error will happen.  This could be due to the fact that the root folder has hidden system files.   Switch to any folder, say, c:\tmp, and run the command, brings the page with the file contents of that folder.

Numpy is bit different.  Since there is no installation manager provided by numpy.org, you need to first download the binary wheel for the python version you're using.  Important: Make sure you are downloading the right version of the whl file.  if you're using Python 3.5, look for the one with the name that contains cp35.

Then go to that downloaded folder and run pip install <whl file name>.  For example, pip3 install "numpy-1.11.2+mkl-cp35-cp35m-win32.whl".  This will install the numpy package.

That's all folks!.

Using Jboss JConsole

If you're using JBoss as your app server, then you don't need to setup JDK settings for the JMX.  Instead you need to check the following: http://stackoverflow.com/questions/17105933/enabling-jmx-remote-in-jboss-6-1

Then run JBOSS_HOME/bin/jconsole.sh (or .bat for Windows).

In the "Remote" section enter the following:service:jmx:remoting-jmx://<server-name>:9999 (the default OOTB port number is 9999.  Check 'management-native' value in standalone.xml.

Then enter the username and password we created using add-user.sh (or .bat) in jboss/bin.

Using Jstatd

JVisuslVM is useful in profiling your server applications local or remote.  To profile your application, you need to run the jstatd daemon in the server your application is running.  Running jstatd is not as straightforward.  Follow these steps:

1) Create a policy file.  The policy tool is in JAVA_HOME/jre/bin.  Start policytool.exe

2) You need to provide the security policy for the tools.jar.  The tools.jar is usually in JAVA_HOME/lib.  DO NOT GIVE RELATIVE PATH such as $JAVA_HOME/lib/tools.jar.  The jstatd doesn't recognize it.  Instead provide the absolute path.

3) Click "Add Policy Entry" and enter the following in "CodeBase" text box: file:/usr/java/default/lib/tools.jar (for non-windows and also, check your java path in your machine) or "c:/Program Files (x86)/Java/jdk1.7.0_79/lib/tools.jar" (for Windows, for ex.  Use "/" for windows path also).

4) Click "Add Permission" and enter the following in "AllPermission" text box: java.security.AllPermission. Click Ok.

5) Click "Done"

6) Click File->Save and save it.

7) Copy this policy file to the remote server (if needed).

8) Go to $JAVA_HOME/lib folder.

9) Run the following: jstatd -J-Djava.security.policy=/<absolute path to the folder where the policy file is>/<policyfile name> -p1234

Note: The -p option may not  required in some cases and this value is a random value chosen.

Now run the Java VisualVM and Click on Remote and add the remote server name.  You should see  the Jstatd process.

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.

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.

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.

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,,,,