Saturday, March 24, 2018

Copy specific files from within nested folders

I had a situation where I needed to save all log files that were present in nested sub-folders and copy them over to another folder for analysis.
There are many ways to do this - but here is the simplest that I could figure out using rsync:
rsync -aihv --include='*/' --include='*.log* --exclude='*' /source_folder/to/search/in/  /destination_folder/to/copy/to/

Important thing to note here is the order of include and exclude flags passed to rsync command - it is sensitive to the order in which these flags are provided.
First include flag '*/' makes rsync look into subfolders and the second flag selects all files of the format '*.log*'.
The next exclude flag excludes any file not selected as yet and then copies them over to the destination folder.
You can provide more include flags before the exclude flag to select multiple types of files as per your requirement.

Rename multiple files in one command

If you want to rename multiple files, the trusty old Unix "mv" command can't help as it can rename only one file at a time.
This requires us to bring out something different from our Unix arsenal - the "rename" command!
Use the rename command in conjunction with find to rename multiple files:
find /source_folder/to/search/in/ -name 'myapp*.log.201*' -exec rename -v .log. .oldlog. {} \; >> /temp/rename.log

Here we are searching for files named 'myapp*.log.201*' and renaming them to 'myapp*.oldlog.201*'
In case you need to do this on multiple servers, use the for loops trick!

Searching for string in logs on multiple servers

Developers as usual are very lazy and so instead of going to each server to grep for an error string in the log file and creating a report, here is a simple way to collect all the necessary log lines.
Create a file containing a list of server names on which we want to check the logs - one on each line and then run this command if using bash:

for s1 in (cat servers_list.txt); do
  ssh -q ${s1} "grep 'search_string' /search/folder/*/*.log* | sed 's/^/${s1} => /'" >> /tmp/search.log

If you are using csh, then the syntax is slightly different:

foreach s1 in (cat servers_list.txt)
  ssh -q ${s1} "grep 'search_string' /search/folder/*/*.log* | sed 's/^/${s1} => /'" >> /tmp/search.log

The code is simple - for each server, ssh to that server and run the grep command to find out the log lines having the specific string. The bigger trick here is to use sed to pre-pend server name to the grepped log line to make the report useful. This should return a file with lines in the format:

server_name => [log line grepped from the log file]

Tuesday, February 6, 2018

Obi keeps ringing - Calls from weird numbers - Ghost calls

Some time back my Obi Google Voice phone kept ringing constantly and the caller ids were weird numbers. Strangely, Google Voice had no history of any such calls that I could mark as spam and rebooting the Obi device would help.

Researching this problem showed that it could be SIP scanning by bots that probe standard SIP ports causing the phone to ring and caller id to show strange numbers like 1000, 1001, 0000, 123456, etc.

A simple solution to this problem is to change the value of X_InboundCallRoute.
Use Obi Expert > Voice Services > SPx Service > X_InboundCallRoute to:
where GV12345678901 is your Simonics SIP Login Prefix and SPx is the service on which GV is configured

There are other possible solutions as well, but I found this solution to be the simplest - but still for sake of completeness, you can check out the other possible solutions at ObiTalk forum post and Simonics forum post.

Obi100 and Obi110 Google Voice with Simonics Gateway

Obi100 and Obi 110 devices worked great with Google Voice but Obihai declared these devices to be end of life in August 2016. So a recent Google change made these devices to stop working with GV.
To solve this, you could either buy a newer Obi 200 series device or use a paid GV gateway setup by simonics.

Here are the instructions for using simonics GV gateway from the ObiTalk forum post:

1:  Assumptions:  you have an OBi 100 or 110, running the final build 2886 firmware.  You have a working inbound Google Voice telephone number assigned to your Google account.  You've paid the fee to use the gateway, and you are on the gateway setup page.

2:  Go to your OBiTALK web dashboard:  Click the OBi device.  Find the Service Provider (SP1 or SP2) that was setup to use Google Voice.  Delete the SPx configuration by clicking the trash can icon.

3:  After waiting a few minutes for the OBi's configuration to be remotely deleted, again click on the SP1 or SP2 you want to use.  On the next page, scroll down to the bottom and select "OBiTALK Compatible Service Providers".  On the next page, scroll down and click "Generic Service Provider" and click "Next".

4:  On the next page, fill in your GVGW server name, SIP user ID and SIP password, and click "Save".

5:  Wait for the portal to remotely configure your OBi.  It will reboot once or twice (power LED will blink on then off).  Give it plenty of time to finish.

6:  Refresh the OBiTALK dashboard in your browser, and click the SPx.  You should now see that it is registered to the gatway.  You're done!

Wednesday, January 31, 2018

Use CSipSimple instead of ObiTalk ObiOn App on Android

Android app for ObiTalk - ObiOn stopped working some time back so here is my solution for using CSipSimple instead.
It requires you to sign-up for a free IP Freedom account at Callcentric and a bit of setup.

  1. Create an IP Freedom account 12341234567 at Callcentric here
  2. Create a sub-account 12341234567101 (extension 101)
  3. On your Android phone download and install CSipSimple from the Play Store
  4. Add credentials for extension 101 from step 2 in CSipSimple setting
  5. Login to your account on the ObiTalk Portal (
  6. Setup SP2 (Callcentric) with the credentials from step 1 in the ObiTalk portal
  7. Login to the management screen of your Obi on your  network using the IP Address
  8. Under Voice Services > SP2 Service - set up this rule instead of the default:
    X_InboundCallRoute= {101>12341234567:aa},{ph}

That's it! To call into your Obi's AA, dial 100 (100 is the default extension for your main Callcentric account) from CSipSimple app on your phone.
Note that this is valid for Obi100 and Obi110 for sure but may also work for other Obi models.
And don't forget to replace the 12341234567 with the Callcentric number you receive after signing up!

Thanks to the multiple posters on the ObiTalk forums for all the above info that I have condensed into a set of simple easy to follow steps that work.

Monday, May 18, 2015

Solve Spring NoUniqueBeanDefinitionException

I encountered the NoUniqueBeanDefinitionException where-in Spring was unable to which class to inject for an Autowired variable even though the it was properly qualified!

This happened because the Qualifier did not get post-processed and so multiple implementations of the Interface type of the variable being injected were now available in the classpath. So Spring found more that one instance and was unable to decide which instance to inject for the particular Autowired target.

The turn on the default AutowiredAnnotationBeanPostProcessor which processes the @Qualifier , you need to add the line to the beans section of your spring configuration. Since this was missing from the beans section of the configuration file, the Qualifier annotation was ignored in this code:

    public void setDao(@Qualifier("myDaoImpl") MyDAO dao) {

And here is a snippet of the exception that was logged:

 java.lang.RuntimeException: org.springframework.beans.factory.BeanCreationException: Injection of autowired dependencies failed for class [class]; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire method: public void; nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [] is defined: expected single matching bean but found 4: myDaoImpl,secondDaoImpl,thirdDaoImpl,fourthDaoImpl

This error was resolved after adding the below line to the beans section of spring configuration:


Friday, May 15, 2015

Upgrade Hibernate 3..x to Hibernate 4.3.x

NOTE: This is a partial guide to upgrade your Hibernate 3 project to Hibernate 4.3.x

Hibernate has a come a long way from version 3.x to the latest version Hibernate 4.3.x with lots of major changes, bug fixes and enhancements:
  • Started using gradle for builds
  • Redesign the way SessionFactory is built
  • Improved metamodel
  • Initial osgi-fication by package splitting (public, internal, spi)
  • Migration to i18n logging framework (using jboss logging)
  • JDK 1.6 (JDBC4) as baseline

The following hibernate jars are required to be downloaded from the Maven Repository:

  1. hibernate-core-4.3.9.Final.jar
  2. hibernate-annotations-3.5.6-Final.jar
  3. hibernate-commons-annotations-3.2.0.Final.jar (DO NOT USE version)
  4. hibernate-entitymanager-4.3.9.Final.jar
  5. hibernate-validator-5.1.3.Final.jar
  6. jboss-logging-3.1.3.GA.jar
Do not use as it is a release mistake and will create more problems.

You can download the corresponding javadoc and source files by going to the Maven website and searching for: 
g:"org.hibernate" AND a:"hibernate-core" AND v:"4.3.9.Final"

Now that all the required jars are downloaded, hibernate3.jar will need to be replaced by hibernate-core jar; here is a simple guide to when to include rest of the jars.

To resolve the below error, add hibernate-commons-annotations-3.2.0.Final.jar to classpath and the JBoss library path:
NOTE: DO NOT USE as it is a release mistake
java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/MetadataProvider
at org.jboss.hibernate.jmx.Hibernate.buildConfiguration(
at org.jboss.hibernate.jmx.Hibernate.buildSessionFactory(
at org.jboss.hibernate.jmx.Hibernate.startService(
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(

To resolve the below error, add jboss-logging-3.2.1.Final.jar to classpath and the JBoss library path:
Not resheduling failed loading task,{classname: org.hibernate.internal.CoreMessageLogger, requestingThread: Thread[main,5,jboss], requestingClassLoader:{ url=null ,addedOrder=2}, loadedClass: nullnull, loadOrder: 2147483647, loadException: java.lang.NoClassDefFoundError: org/jboss/logging/BasicLogger, threadTaskCount: 0, state: 1, #CCE: 1}
java.lang.NoClassDefFoundError: org/jboss/logging/BasicLogger
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(
at java.lang.ClassLoader.defineClass(

Follow the Hibernate Code Migration Guide to make the appropriate changes as required:

  1. Initial move to ServiceRegistry.  For now, see design wikis or sources for more information.  Not all "services" have been migrated to this model yet.  The main ones (JDBC and transaction stuff) as well as lowever level one (classloading and such) have been migrated.  The rest will be moved during Alpha2 development.
  2. In an initial push toward osgi we started splitting up packages a little bit differently in this release. 
    1. The reason is to identify classes which are intended as
      1. public API, which are fully expected to be used in application code.
      2. internal implementation details, which are only intended for Hibernate use.
      3. SPI contracts, whch define
        1. extension contracts
        2. contracts with Hibernate internals exposed to these extensions
    2. This will potentially lead to some  packaging changes needed in user code:
      1. org.hibernate.dialect.resolver.DialectResolver -> org.hibernate.service.jdbc.dialect.spi.DialectResolver
  3. Deprecated methods that have been removed:
    1. References to org.hibernate.type.AbstractSingleColumnStandardBasicType and org.hibernate.type.SingleColumnType methods should be changed as indicated:
      1. nullSafeGet(ResultSet rs, String name) should be changed to 
        nullSafeGet(ResultSet rs, String name, SessionImplementor session)
      2. get(ResultSet rs, String name) should be changed to 
        get(ResultSet rs, String name, SessionImplementor session)
      3. nullSafeSet(PreparedStatement st, T value, int index) should be changed to nullSafeSet(PreparedStatement st, Object value, int index, SessionImplementor session)
      4. set(PreparedStatement st, T value, int index) should be changed to set(PreparedStatement st, T value, int index, SessionImplementor session)
    2. References to org.hibernate.usertype.UserType methods should be changed as indicated:
      1. nullSafeGet(ResultSet rs, String[] names, Object owner) should be changed to   
        nullSafeGet(ResultSet rs, String[] names, SessionImplementor session, Object owner)
      2. nullSafeSet(PreparedStatement st, Object value, int index) should be changed to nullSafeSet(PreparedStatement st, Object value, int index, SessionImplementor session)
    3. Session.reconnect() - manual disconection and reconnection is now only supported for user-supplied-connection scenarios (JDBC Connection passed in while opening the Session)
    4. Session.connection() - use Session.doWork(), Session.doReturningWork() or Session.sessionWithOptions()...openSession() as replacement depending on need
    5. Most of the overloaded SessionFactory.openSession methods.  Use SessionFactory.withOptions()...openSession() instead
  4. Deprecated classes/interfaces that have been removed:
    1. org.hibernate.classic.Session
    2. org.hibernate.classic.Validatable
    3. org.hibernate.classic.ValidationException
  5. org.hibernate.jdbc.BatcherFactory, Batcher, and their implementations have been replaced by org.hibernate.engine.jdbc.batch.spi.BatchBuilder and Batch, with default implementations in org.hibernate.engine.jdbc.batch.internal. You can override the default BatchBuilder by defining the  "hibernate.jdbc.batch.builder" property as the name of a BatchBuilder implementation, or by providing a BatchBuilder in a custom ServiceRegistry.
  6. hibernate.cfg.xml no longer supported as means of specifying listeners.  New approach invloves using an org.hibernate.integrator.spi.Integrator which works based on "service discovery". 

Thursday, May 14, 2015

Upgrade from Spring 2.5.x to Spring 4.1.x - JBoss

After completing the steps mentioned in my previous post for Upgrading Spring 2.5.x to Spring 4.1.x, the project compiles without problems, however, JBoss deployment does not work as it does not get all the required new Spring Jars.

The Spring component jars also need to be added to the JBoss classpath. However, here are a few specific exceptions that point to requiring specific jars in the JBoss classpath as below.

To resolve the below error, add spring-context.jar to JBoss library path:
java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at sun.reflect.annotation.AnnotationParser.parseClassArray(
at sun.reflect.annotation.AnnotationParser.parseArray(
at sun.reflect.annotation.AnnotationParser.parseMemberValue(
at sun.reflect.annotation.AnnotationParser.parseAnnotation(
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(
at sun.reflect.annotation.AnnotationParser.parseAnnotations(
at java.lang.Class.initAnnotationsIfNecessary(

To resolve the below error, add spring-beans.jar to JBoss library path
java.lang.NoClassDefFoundError: org/springframework/beans/factory/BeanFactory
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(
at java.lang.Class.getDeclaredMethods(
at org.jboss.ejb3.interceptor.InterceptorInfoRepository$AnnotationInitialiser.getInfo(
at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseFromAnnotations(
at org.jboss.ejb3.interceptor.InterceptorInfoRepository.getOrInitialiseFromAnnotations(
at org.jboss.ejb3.interceptor.InterceptorInfoRepository.getInterceptorsFromAnnotation(
at org.jboss.ejb3.interceptor.InterceptorInfoRepository.getClassInterceptors(
at org.jboss.ejb3.EJBContainer.initialiseInterceptors(
at org.jboss.ejb3.EJBContainer.getClassInterceptors(

Hopefully this should resolve all issues for a successful upgrade of Spring 2.5.x to Spring 4.1.x!

Wednesday, May 6, 2015

EasyMock Exceptions when mocking Classes instead of Interfaces

EasyMock as the name suggests, provides an easy way to mock objects for testing where-in you mock interfaces of the classes you want to test. EasyMock then generates mock objects on the fly using Java's proxy mechanism and then simulates it in a simple way and also verifies whether it is used as expected.
When creating some new mock objects for testing using EasyMock 2.5.x, I noticed the below exceptions:
java.lang.IllegalArgumentException: org.hibernate.dialect.Dialect is not an interface
 at java.lang.reflect.Proxy.getProxyClass0(
 at java.lang.reflect.Proxy.newProxyInstance(
 at org.easymock.internal.JavaProxyFactory.createProxy(
 at org.easymock.internal.MocksControl.createMock(
 at org.easymock.EasyMock.createMock(

To solve this, change your import as:
org.easymock.EasyMock.createMock => org.easymock.classextension.EasyMock.createMock

And another set of exceptions popped up:
java.lang.IllegalArgumentException: not a proxy instance
 at java.lang.reflect.Proxy.getInvocationHandler(
 at org.easymock.EasyMock.getControl(
 at org.easymock.EasyMock.replay(

To solve this, change your imports as:
org.easymock.EasyMock.replay => org.easymock.classextension.EasyMock.replay
org.easymock.EasyMock.verify => org.easymock.classextension.EasyMock.verify

Viola! and now we are good!
When mocking classes that are not an interface, we need to use the createMock, replay, and verify methods FROM the class org.easymock.classextension.EasyMock and NOT the ones we regularly use from org.easymock.EasyMock
However, since EasyMock 3.0, the separate classextension package has been deprecated and left in place for backward compatibility and the above changes are not required. So it is recommended that if possible, one should upgrade to the latest 3.x version of EasyMock instead of going for the above changes.


Related Posts Plugin for WordPress, Blogger...