azizkhani.net

I know that I know nothing

ROW LEVEL SECURITY (BEST SOLUTION?)

clock October 25, 2012 19:21 by author Administrator

 

HELP ME
here might be special rows in a database which should only visible and accessible by users with special privileges. To avoid unnecessary round-trips, we currently modify the SQL queries to join with our authorization data to get only the visible rows for the current user.

But this concepts doesn't feel 'right' to me, because we mix business code with security related code which should be orthogonal and independent from each other.

 

  • What solutions are available/possible?
  • How do you implement row-level security (especially in combination with hibernate)?

The idea is that you can implement row level functionality in two ways: directly setting restrictions in your repository or binding the restrictions via AOP. The latter is preferred because security layer should be separated from business logic (orthogonal concerns).

 

In Hibernate you can use the concept of filters which are applied transparently and repository doesn't know about them. You can add such filters via AOP. The other way is intercepting session.createCriteria() and adding Restrictions to the Criteria transparently using AOP.

 



Spring and hibernate 4 integration

clock October 25, 2012 18:29 by author Administrator

add this dependancy

 

    <!-- Hibernate framework -->
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>4.1.4.Final</version>
        </dependency>
        <dependency>
            <groupId>javax.persistence</groupId>
            <artifactId>persistence-api</artifactId>
            <version>1.0.2</version>
        </dependency>
        <!-- end hibernate -->

 

and then change spring configuration like this

 



    <tx:annotation-driven transaction-manager="hibernateTransactionManager" />
    <bean id="dataSource"  class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName" value="${hibernate.connection.driver_class}" />
        <property name="url" value="${hibernate.connection.url}" />
        <property name="username" value="${hibernate.connection.username}" />
        <property name="password" value="${hibernate.connection.password}" />
    </bean>
    <bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="mappingLocations">
            <list>
                <value>/WEB-INF/classes/hibernate/**/*.hbm.xml</value>
            </list>
        </property>

        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.connection.driver_class"> ${hibernate.connection.driver_class}</prop>
                <prop key="hibernate.connection.url"> ${hibernate.connection.url}</prop>
                <prop key="hibernate.connection.username"> ${hibernate.connection.username}</prop>
                <prop key="hibernate.connection.password"> ${hibernate.connection.password}</prop>
                <!-- <prop key="hibernate.connection.internal_logon"> ${hibernate.connection.internal_logon}</prop> -->
                <prop key="hibernate.dialect"> ${hibernate.dialect}</prop>
                <prop key="hibernate.show_sql"> ${hibernate.show_sql}</prop>
                <prop key="hibernate.hbm2ddl.auto"> ${hibernate.hbm2ddl_auto}</prop>
                <!-- <prop key="hibernate.default_schema"> ${hibernate.default_schema}</prop> -->
            </props>
        </property>
    </bean>

    <bean id="hibernateTransactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>

 

and now

 

package org.azizkhani.dao;

import java.util.List;

import org.azizkhani.core.QueryResult;

public interface IGenericRepository<T> {
    public List<T> getAll();
    public List<T> getAll(String where, String order, int pageNumber,int pageSize);
    public QueryResult<T> getAllGrid(String where, String order, int pageNumber,int pageSize);
    public T loadByEntityId(int entityId);
    public T single(String where);
    public void add(T entity);
    public void delete(T entity);
    public void deleteByEntityId(int entityId);
    public void update(T entity);
    public int count();
}

 

implementation

 

package org.azizkhani.dao.impl.hibernate;

import java.util.List;

import org.azizkhani.common.utility.HQLUtility;
import org.azizkhani.core.QueryResult;
import org.azizkhani.dao.IGenericRepository;
import org.hibernate.Criteria;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;

@Repository
public abstract class GenericRepository<T>  implements IGenericRepository<T> {
    protected Class<T> domainClass = getDomainClass();

    protected abstract Class<T> getDomainClass();
   
    @Autowired
    private SessionFactory sessionFactory;
   

    @Override
    public List<T> getAll() {
        Criteria criteria = getSession().createCriteria(domainClass.getName());
        return criteria.list();
    }

    public Session getSession() {
        try {
            return sessionFactory.getCurrentSession();
        } catch (Exception e) {
            System.out.println(e.getMessage().toString());
        }
        return sessionFactory.openSession();
    }

    public QueryResult<T> getAllGrid(String where, String order, int pageNumber, int pageSize) {
        Session session = getSession();
        StringBuffer jql = new StringBuffer("from " + domainClass.getName()
                + " e ");
        HQLUtility.toHQL(jql, where, order);
        Query query = session.createQuery(jql.toString());
        if (pageSize > 0)
        {
            query.setFirstResult(pageNumber * pageSize);
            query.setMaxResults(pageSize);
        }
        List<T> list = query.list();

        StringBuffer jqlCount = new StringBuffer("select count(*)  from "
                + domainClass.getName() + " e ");
        HQLUtility.toHQL(jqlCount, where, "");
        int count = ((Long) getSession().createQuery(jqlCount.toString())
                .uniqueResult()).intValue();

        return new QueryResult<T>(pageNumber, count, pageSize, list);
    }

    @Override
    public List<T> getAll(String where, String order, int pageNumber, int pageSize) {
        Session session = getSession();
        StringBuffer jql = new StringBuffer("from " + domainClass.getName()
                + " e ");
        HQLUtility.toHQL(jql, where, order);
        Query query = session.createQuery(jql.toString());
        if (pageSize > 0)
        {
            query.setFirstResult(pageNumber * pageSize);
            query.setMaxResults(pageSize);
        }
        return query.list();
    }
    @Transactional(readOnly=true)
    @Override
    public T loadByEntityId(int entityId) {
        return (T) getSession().load(domainClass, entityId);
    }

    @Override
    public T single(String where) {
        return null;
    }

    @Override
    public void add(T entity) {
        Session session = getSession();
        session.beginTransaction();
        session.save(entity);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public void delete(T entity) {
        getSession().delete(entity);
    }

    @Override
    public void deleteByEntityId(int entityId) {
        Session session = getSession();
        session.beginTransaction();
        Object obj = session.load(domainClass, entityId);
        session.delete(obj);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public void update(T entity) {
        Session session = getSession();
        session.beginTransaction();
        session.update(entity);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public int count() {
        int count = ((Long) getSession().createQuery(
                "select count(*) from " + domainClass.getName()).uniqueResult())
                .intValue();
        return count;
    }
}



 

 





creating and manipulating Microsoft Office(Word docx, Powerpoint pptx, and Excel xlsx) in java

clock October 25, 2012 18:03 by author Administrator

Create complex Word (.docx) documents programatically with docx4j

lvdpal's  Creating Word documents with Docx4j, which covers tables in some detail

Jos Dirksen's  Create complex Word (.docx) documents programatically with docx4j

Joshua Born's  Creating Word Documents in Java

Glen Smith's  Creating Word docx documents dynamically from Grails (or Java)

  Spring MVC (Russian)

java api

http://poi.apache.org/

http://www.docx4java.org/trac/docx4j



Decorator Design Pattern Case Study

clock October 24, 2012 22:36 by author Administrator



Decorator pattern is basically a way to extend functionality of an object by decorating with other objects which can wrap the target object and add their own behavior to it. If you never used or heard of decorators, I highly recommend reading chapter 3 of Head First Design Patterns.

Pretty much like other patterns mentioned in my posts before, JavaEE has an easy an elegant way to use the decorator pattern. Lets start with a simple stateless session bean.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    
    public void startService(){
        System.out.println("do something important here...");
    }
}

To start implementing the decorator pattern, we need an interface so we can bind the decorators and the object to be decorated together.


package com.devchronicles.decorator;

/**
 *
 * @author murat
 */
public interface ServiceInterface {
    public void startService();
}

The interface has the method which the decorators will add functionality on. Next we need some changes on our existing EventService bean to make it decoratable.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService implements ServiceInterface{
    
    public void startService(){
        System.out.println("do something important here...");
    }
}


Now we are ready to add as much as decorator we need. All we need to do is to annotate our class, implement the ServiceInterface and to inject our service delegate.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator //declares this class as a decorator
public class DecoratorService implements ServiceInterface{ //must implement the service interface
    
    @Inject //inject the service
    @Delegate //and annotate as the delegate
    ServiceInterface service;

    @Override
    public void startService() { //implement the startService method to add functionality
        System.out.println("decorating the existing service!");
        service.startService(); //let the execution chain continue
    } 
}

Several decorators can be using the service interface.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator
public class Decorator2Service implements ServiceInterface{
     @Inject
    @Delegate
    ServiceInterface service;

    @Override
    public void startService() {
        System.out.println("decorating the service even further!!!");
        service.startService();
    }
}

Most of the configuration can be done via annotation in JavaEE6. However we still need to add some xml configuration to make decorators work. It might seem disappointing since we already annotated our decorators but still the configuration is pretty simple and needed in order to declare the order of execution. Add the following lines to the empty beans.xml.


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
           <decorators>
               <class>com.devchronicles.decorator.DecoratorService</class>
           <class>com.devchronicles.decorator.Decorator2Service</class>
           </decorators>
</beans>

When the startService method of our EventService is executed, the decorators will decorate the ejb and add their own behavior to the execution.

...

INFO: WEB0671: Loading application [Decorator] at [/Decorator]
INFO: Decorator was successfully deployed in 2,534 milliseconds.
INFO: decorating the existing service!
INFO: decorating the service even further!!!
INFO: do something important here...
...

Reference: JavaEE Revisits Design Patterns: Decorator



Factory Design Pattern Case Study

clock October 18, 2012 21:52 by author Administrator

I had a job to check our project code quality. And have to report it back to my team leader for any obstacle that i found in the project. I found a lot of leaks and i think would be good to be discussed on the blog. Not to mock the author, but to learn and improve ourselves together.

Like this code, this is the part that i found in our code.

 

public ContactInfoBean(final Reseller resellerInfo) {

       switch(resellerInfo.getType()) {

           case PROGRAM_CONTACT:
                   readExecutiveInfo(resellerInfo);
               break;
           case FILE_CONTACT:
                  readOperationalInfo(resellerInfo);
               break;
           default:

               break;

       }

   }

The code works fine, and do its job pretty well. But some problem will appear by using this code-style. This class will grow tailing the biz changes, as usual, the bigger one class, the “merrier” to maintain it is. And most likely this class, will be having more than one purpose, can be called low-cohesion.

Better OOP Approach

Well the better approach for the case above would be using the Factory Design Pattern. We can let the factory of READER to generate every single instance according to their type. It would be easier to grow the instance type, since we just need to create a new class and do a little modification in the Factory class. The caller class, wont grow and will stand still at its current shape.

public interface InfoReader {

      public void readInfo();

}


public class ExecutiveReader implements InfoReader {

      public void readInfo() {
           // override
      }

}

 


public class OperationalReader implements InfoReader {

        public void readInfo() {
         // override
        }

}

And The Factory

public class InfoReaderFactory {

      private static final int PROGRAM_CONTACT = 1;

      private static final int FILE_CONTACT = 2;

      public static InfoReader getInstance(Reseller resellerInfo) {

              InfoReader instance = null;

             switch (resellerInfo.getType()) {

                 case PROGRAM_CONTACT:

                       instance = new ExecutiveReader();

                    break;

                 case FILE_CONTACT:

                     instance = new OperationalReader();

                   break;

                default:

                    throw new IllegalArgumentException('Unknown Reseller');

      }

     return instance;

   }

}

And now The Caller

InfoReader reader = InfoReaderFactory.getInstance(resellerInfo);

reader.readInfo();


The Benefits

With the Factory Design Pattern to handle this case, we can achieve some benefits,

  • Specifying a class for one task, means, easier to maintain since one class is for one purpose only (modularity/High Cohesion). i.e: Operational Reader is only to read data for Operational only, no other purpose. Just in case, one day in the future we need another Reader (say: NonOperationalReader). We just need create a new Class that extends (or implements) the InfoReader class and then we can override our own readInfo() function. This Caller class will have no impact. We just need to do some modification in the Factory code.


public class InfoReaderFactory {
    private static final int PROGRAM_CONTACT = 1;
    private static final int FILE_CONTACT = 2;
    private static final int NEW_READER = 3;

    public static InfoReader getInstance(ResellerInfo resellerInfo) {
        InfoReader instance = null;
        switch (resellerInfo.getType()) {
          case PROGRAM_CONTACT:
              instance = new ExecutiveReader();
              break;
          case FILE_CONTACT:
              instance = new OperationalReader();
              break;
          case NEW_READER:
              instance = new NonOperationalReader();
              break;
          default:
              throw new IllegalArgumentException('Unknown Reseller');
        }
        return instance;
    }
}

Higher Reusability of Parent’s Component (Inheritance): Since we have parent class (InfoReader), we can put common functions and thingies inside this InfoReader class, and later all of the derivative classes (ExecutiveReader and OperationalReader) can reuse the common components from InfoReader . Avoid code redundancy and can minimize coding time. Eventhough this one depends on how you do the code and cant be guaranteed.


But, It’s Run Perfectly, Should We Change It?

Obviously the answer is big NO. This is only the case study and for your further experience and knowledge. OOP is good, do it anywhere it’s applicable. But the most important thing is, if it’s running, dont change it. It would be ridiculous if you ruin the entire working code just to pursue some OOP approach. Dont be naive also, no one can achieve the perfect code. The most important is we know what is the better approach.

 

 

ref:http://namingexception.wordpress.com/2012/10/17/case-study-factory-design-pattern/



linq order by desc and get first row

clock October 15, 2012 21:46 by author Administrator

SortedDictionary<int, int> result = new SortedDictionary<int, int>();

int max=result.OrderByDescending(t => t.Value).FirstOrDefault().Key;



Things Great Engineers (almost) Never Say

clock October 12, 2012 22:48 by author Administrator
  • “I’ve used _____ but I have no idea how it works”
    – Great engineers gained their skills through probing and curiosity.  They go ‘under the hood’ of the products they use just to understand how things work, even if that information will never be very useful to them.  It is unclear whether this need to dig deeper is a choice or a compulsion, but it seems that it is a trait of the best talent.
  • “______ works, I just don’t know how to explain it”
    – Not only do the greats know how things work, but most of them derive genuine pleasure in telling others why and how things workThis is often true even if the other person doesn’t care to know.  Over the course of my career I’ve listened to engineers talk for thousands of hours, and in almost all cases my conversations with the most talented go much longer.  I actually made a point of scheduling an extra fifteen to twenty minutes on my calendar when I will be speaking to someone who appears to be great on paper, as I know that the person will go deep into some technical details and nuances that will come up in conversation.
  • “I will need ______ (tool/condition) to complete this task”
    – The masters of development will have the ability to improvise and adjust on the fly to arrive at a solution in non-ideal conditions.  When you hear of engineers being compared to MacGyver they are speaking of this very rare skill.  Greats will figure out a way based on minimal resources and will be aware of alternatives to their first choice of tool.
  • “I’ve learned all I want/will ever need to know about ________ “
    – Continuous learning and improvement is probably the most obvious differentiation between the good and the great.  They don’t just get to a high level and then rest.  The best engineers understand that industry progress causes them to never stop learning, and if they are not gaining enough new knowledge in their day jobs they will invest the time to learn during off hours.
  • “There is no solution” – The greats will continue looking at a problem different ways to come up with an answer instead of conceding.  This characteristic can be both a blessing and a curse.
  • “I hate programming” - At times a great engineer will hate their job or employer, but their love of solving problems with code is what brought them to this skill level.
  • “I’m an expert in _____” (when it’s not true, and even sometimes when it is true) – The strongest engineers have no need or desire to lie or exaggerate the depth of their skills.  Much of the great talent will be reluctant to say they are an expert in anything, as they are aware others could know more.
  • “I don’t understand the business” – The stronger engineers will always want to know how their code impacts the employer and is able to describe their contribution and value to the organization.
  • “I don’t pay particular attention to industry trends” – Being both great and relevant (in demand) is only possible if you keep an eye on where the industry is headed.  When speaking to talented engineers, the topic of which new technologies are actually viable and which are a passing phase will often come up.

If you find yourself using any of these lines on a regular basis, give some thought to why.  Quoting one of these lines in a job interview could be a serious mistake.

 

 

Reference: Things Great Engineers (almost) Never Say



kent beck

clock October 7, 2012 23:35 by author Administrator

when my search space gets big and uncertain i need a pen and paper, not a computer



maven test

clock October 7, 2012 22:42 by author Administrator

go to directory that have .pom

write this line

mvn -Dtest=TestApp1#testPrintHelloWorld test


package com.core;
 
public class App {
	public static void main(String[] args) {
 
		System.out.println(getHelloWorld());
 
	}
 
	public static String getHelloWorld() {
 
		return "Hello World";
 
	}
 
	public static String getHelloWorld2() {
 
		return "Hello World 2";
 
	}
}


package com.core;
 
import junit.framework.Assert;
import org.junit.Test;
 
public class TestApp1 {
 
	@Test
	public void testPrintHelloWorld() {
 
		Assert.assertEquals(App.getHelloWorld(), "Hello World");
 
	}
 
}


http://maven.apache.org/index.html


java captcha

clock October 5, 2012 18:46 by author Administrator

http://jcaptcha.sourceforge.net/jcaptcha-samples/index.html



About the author

 Welcome to this web site . This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog


Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...

RecentPosts

Month List

Sign In