Clean Code that Works.

음..

원래 하고 싶었던 건은(화면에 권한에 따라 보여질 뷰를 달리 하기 위해서)
<sec:authorize access="hasRole('ROLE_ADMIN') or ( '${bbs.username}' == principal.username)" />
이것을 적용하고 싶었지만
두껍게 한 부분을 .. 아마도
spEL 과 jstl EL 차이때문에 인식하지 못하고 에러를 뿜어 낸다.

그리하여,
Iterator iter = ((SecurityContext)session.getAttribute( "SPRING_SECURITY_CONTEXT")).getAuthentication().getAuthorities().iterator();
            while ( iter.hasNext()) {
                String role = ((GrantedAuthority) iter.next()).getAuthority();
                if ( role.equals( "ROLE_ADMIN") || sessionUsername.equals( username)) {
                    returnFlag = true;
                    break;
                }
            }

위와 같은 코드가 탄생 -_-..
세션에 있는 authorities 정보에서 권한을 직접 비교하도록 하였다.
비교해서 있으면 true 없으면 false..

값에 따라서 화면에 보여질 것도 제어 할 수 있도록 하고,
스프링 시큐리티 보면서 도메인 ACL은 아직 손을 못대고 있는데..
이번달에는 꼭 할 수 있도록 해야겠다.


일반적으로... 멀티 파일 업로드 할때 인풋 네임으로 같은 네임을 쓰는데..
스프링에서 commonsmultirpartResolver에서 에러를 뿜어낸다.
동일한 name은 안되요!! 하고.

이때는 commonsmultirpartResolver를 상속해서 MultipartParsingResult() 를 override 하면 된다.

트랙백 걸린 블로그를 참조해서 하도록 하자.

기타 스프링(2.5)에서 싱글 및 멀티파일업로드 구현시 참고가 되는 블로그.
이동하기

스프링과 jQuery를 사용하여 파일 업로드 프로그레스바를 구현 하는 방법
업로드 할때 사용하는 CommonsMultipartResolver를 상속해서 리스너를 추가 해준다.

동작 원리는
  1. 파일 업로드, 파일 업로드 진행상황 가져오기(Ajax, 인터벌로 주기적으로 가져오기)
  2. 리스너가 세션에 진행 상황을 기록
  3. 주기적으로 가져온 업로드 진행 상황을 프로그레스바에 기록.
대충 요롷게 돌아 간다.
근대 업로드 끝나도 브라우저가 잠시 멈추는 현상이 발생!!!
크왁!!

왜이렉!!

일단 이거 해결하고
멀티파일 업로드로 바꾸고
좀더 컴포넌트 한 화면으로 변경할 것.


스프링 책만 봐서 그런지 영~~ 개념이 안잡힌다.

ㅋㅋㅋ

스프링 인 액션 2.0에서 발췌

스프링(Spring)은 로드 존슨(Rod Johnson)이 그의 책 "Expert One-on-One: J2EE Design and Development"를 통해 소개한 오픈 소스 프레임워크로서 엔터프라이즈 애플리케이션 개발의 복잡함을 겨냥해 만들어졌다. 스프링은 EJB로만 할 수 있었던 작업을 평범한 자바빈을 사용해서 할 수 있게 해 준다. 스프링이 서버측 개발에만 유용한 것은 아니다. 간소함, 테스트의 용이함, 낮은 결합도라는 견지에서 보면 모든 자바 애플리케이션이 스프링의 덕을 볼 수 있다.

스프링이 제공하는 기능은 다양하지만 근간을 놓고 보면 스프링은 가벼운 종속객체 주입 및 애스펙트 기반 컨테이너이자 프레임워크다. 간단해 보이지만 스프링의 핵심을 잘 나타내는 말이다. 스프링을 좀 더 잘 이해하기 위해 이 말을 하나씩 쪼개서 살펴보자.

  • 가벼운 - 스프링은 크기와 오버헤드 측면에서 가볍다. 스프링 프레임워크 대부분이 2.5MB 정도 밖에 안 되는 하나의 JAR파일로 배포될 수 있다. 그리고 스프링의 프로세싱 오버헤드는 미미하다. 게다가 스프링 애플리케이션은 스프리 고유 클래스에 종속되지 않는다.
  • 종속객체 주입 - 스프링은 종속객체 주입(DI)이라는 기술을 통해 낮은 결합도를 유지할 수 있게 해준다. DI가 적용된다는 것은 어떤 객체에 의존 관계가 있는 다른 객체를 생성하거나 찾아오지 않아도 종속객체가 주어진다는 것을 의미한다. DI를 JNDI와 반대로 생각하면 이해하기 편할 것이다. 즉, 객체가 컨테이너에서 종속객체를 찾아오는 것이 아니라, 요청하지 않아도 인스턴스가 생성되면 컨테이너가 그 객체에 필요한 종속객체를 찾아 주는 것이다.
  • 애스펙트 지향 - 스프링에서 지원하는 애스펙트 지향 프로그램(AOP)은 애플리케이션 비즈니스 로직과 시스템 서비스(감시, 트랜잭션 관리 등)를 분리해 응집도가높은 개발을 가능하게 해 준다. 애플리케이션 객체는 원래 해야 할 일인 비즈니스 로직만 수행하고 로깅이나 트랜잭션 관련 처리 작업과 같은 시스템 관련된 작업을 떠맡을 필요가 없어진다.
  • 컨테이너 - 스프링은 애플리케이션 객체의 생명주기(lifeCycle)와 구성설정(Configuration)을 포함하고 관리하는 측면에서 일종의 컨테이너다. 스프링에서 애플리케이션 객체를 생성하고, 설정하고, 상호 간에 관련을 맺는 방법을 정의할 수 있다.
  • 프레임워크 - 스프링은 간단한 컴포넌트들을 이용해 복잡한 애플리케이션을 구성하고 조립할 수 있게 해 준다. 스프링에서 애플리케이션 객체들은 일반적으로 XML 파일에서 선언적으로 조립된다. 스프링은 개발자가 애플리케이션 로직 개발에 집중할 수 있도록 다양한 기반 기능(트랜잭션 관리, 퍼시스턴스 프레임워크 통합 등)을 제공한다.

다시 한 번 말하자면, 스프링의 기저를 파고들어가 보면 결합도가 낮은 애플리케이션을 개발할 수 있게 해 주는 프레임워크를 발견하게 된다. 이처럼 결합도를 낮춰 준다는 것만으로도(관리와 테스트의 용이성을 포함해서) 스프링은 상당히 훌륭한 애플리케이션 개발 프레임워크라고 할 수 있다.

그러나 여기에 더해 스프링 프레임워크에는 풍부한 기능의 애플리케이션 개발 플랫폼을 생성할 수 있는, DI와 AOP를 근간으로 하는 여러 가지 모듈이 존재한다.