Repetitive code for different Database Entities with same implementation I have this code in LogInService

public User isValid(User user) {
        if(user == null)
            return user;

        User db_user = userDao.getUserByUsername(user.getUsername());
        if (db_user != null) {
            try {
                if (PasswordHash.validatePassword(user.getPassword(),db_user.getPassword())) {
                    return db_user;
                }
            } catch(Exception e){ e.printStackTrace(); }
        }

        return null;
    }

    public Administrator isValid(Administrator admin){
        if(admin == null)
            return admin;

        Administrator db_admin = adminDao.getAdminByUsername(admin.getUsername());

        if(db_admin != null){
            try{
                if (PasswordHash.validatePassword(admin.getPassword(),db_admin.getPassword())) {
                    return db_admin;
                }
            }catch(Exception e){ e.printStackTrace(); }
        }

        return null;
    }


Where we use a null to check if the user is valid.

My problem now is this. Users and Admins are a different entities but for them to be logged in into the system they have to login. both user and admin has the same method of logging in checking.

My question is there anyway I can refactor this repetitive code inside my Service layer class? or should create a different service layer for Admins to logged in?
Fix your method name getUser, getAdmin for starters. If you do not use the returned User object for example except for checking if it is null then consider returning boolean. But I suspect there are more fields in User and Admin.
Fix your parameter types.
Why are you passing in User if you get the user from the data store. If it is only for grouping user name and password try defining a value object. 
Once you saved your User type from the burden of holding the password remove password field from the User object. The returned type of the authentication method should not contain the password but contain roles of the user etc. Passwords are an authentication concern, whereas Roles etc are an authorization concern.
Unsuccessful authentication attempt is an exceptional case. Returning null from a service in an exceptional case burdens the user of the service with remembering the null check. In this case having a NullPointerException is not the worst that could happen. Not having the exception and letting unauthenticated users access your secure resources is worse.
In the below code:

if(user == null)
     return user;


If you want to return null say so. Do not confuse the reader of your code. (Reader of the code is probably yourself in a few months.)

Why are you returning null. If null is not a valid argument, as in this case, throw an IllegalArgumentException. I will give you an example to demonstrate the importance of this. Since you did not provide the code that uses this service it will be an imaginary usage:

User user = new User(); 
user.setUsername(request.getParameter("username"); 
user.setPassword(request.getParameter("pass"); 


UserDb = null;
user = loginService.isValid(user); // I'm guessing usage is as horrible as this

if (userDb == null) {
   return UNSUCCESSFUL_LOGIN; 
}

saveUserToSession(userDb);
return WELCOME_PAGE; 


Programmer made a mistake but the user sees "Login Unsuccessfull" message for correct username and password. 
Do not get the real password hash out of your datastore and do not pass around the cleartext password. 

User db_user = userDao.getUserByUsername(user.getUsername());


Instead your dao method should be something like this:

User db_user = userDao.getUserByUsername(username, passwordHash);


which eventually translates to some sql or ldap or hql or whatever query like this

select blah1, blah2, blah3 
 from myschema.myusertable 
 where username=:username and hashedpass=:hashedpass


This reduces the chance of your hashed passwords to leak into logs or such, removes the need to pass around passwords in the clear makes it harder for you to let users know if a username is valid without knowing the password. I am not a security person, so I will not comment on its effect on the timing attacks. But need to know is a good Object Oriented design principle.
Do a shortcut return here:  

    if (db_user != null) {
    //several lines of code
     }
     return null;

This should return a boolean. If it doesn't and you cannot change it or find one that does you can always wrap it. 

     PasswordHash.validatePassword(user.getPassword(),db_user.getPassword())

Do not catch Exception as it is too general and include unchecked exceptions such as nullpointerexception and illegalargumentexception.

 } catch(Exception e){ e.printStackTrace(); }

Exception.printStackTrace(); is not proper exception logging. It has no use case in any production environment. 


My suggestion   

 public User getUser(UserCredential credential) throws SecurityException {
    if (credential == null) throw new IllegalArgumentException("credential required");

    User user = userDao.getUser(credential);

    if (user == null) throw new InvalidCredentialException();

    return user;
  }

static class UserCredential {
    //fields, all of them final
   // ..........
     UserCredential(String userName, String hashedPass) {
        //You can use org.apache.commons.lang.Validate to shorten
       //some common validations
         Validate.notNull(userName);
         Validate.notNull(hashedPass);
          this.userName = userName;
          this.hashedPass = hashedPass;
     }
    //getters no setters
   // ..........
 }


By validating the constructor arguments you catch some errors more easily and remove the need to check them again when used as a parameter type.

String userName = request.getParameter("username");

// case 1
user.setUsername(userName); 
User userDb = loginService.isValid(user);

// case 2
User user = loginService.getUserValid(new UserCredential(userName, hashedPassword));


Note what happens in each case if you misspell the request parameter name. In the second case you will get an illegal argument exception close to the source of the illegal argument whereas in the first case you may tell user his password wrong or you may get some unspecified error in the depths of your ORM or JDBC driver or something.