naucika's ECM

MT 환경이 아닌경우, 아래와 같이 bootstrap 을 만들어서 사용자 기본 경로나, 카테고리등을 생성하고 있었으나, MT환경으로 전화되면서 추가 태넌트가 생길때 아래와 같은 bootstrap 이 작동되지 않는 문제가 생겼다. true REMOVE_EXISTING /${spaces.company_home.childname} alfresco/module/${project.artifactId}/bootstrap/companys_initilize.xml /cm:categoryRoot/cm:generalclassifiable alfresco/module/${project.artifactId}/bootstrap/wocategory_initilize.xml MT환경에서의 bootstrap 이 어떻게 작동하나 찾아..

얼마전에 경험한 일입니다. 1시간정도 쓰다보면, 갑자기 401 세션 오류가 발생하면서, 로그아웃이 되는 현상이 자주 발견되었습니다. SSO는 물론이거니와, share 쪽의 session-timout 이나, alf 의 session-time 여러가지 설정을 확인해 봤지만, 한시간 정도에 끊길만한 껀덕지가 없더군요. 계속 이 문제 때문에 골머리를 썩고 있었더랩니다. 결국, share 는 alf 의 rest-api 를 호출할때마다, alf 에서 발행한 티켓을 붙여서 호출하고 있었고, 문제는 이 alf 의 티켓이 invalidation 된다는 이유였습니다. 그래서 alf 의 티켓 설정을 확인해서 아예 expire 모드를 false 로 영구보관을 설정했습니다. 그래도. 안되더군요.. 간헐적으로 짧은 시간이 지나면..

다양한 방법을 강구 했으나, 최종 낙찰은 그냥 무식하게 Filter 하나 낑겨 넣고, 일단 OAuth2 쪽에 인증 확인하는 방법으로 구현했습니다. OAuth2 Provider 도 만들어야 해서 도무지 시간이 나질 않네요. 다 공개하긴 X팔리고, 걍 몇가지 코드만 적어 놓겠습니다. @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest)servletRequest; HttpServletResponse res..

이번에 외부 레거시가 우리쪽 서버로 인증이 필요로 하게 되었습니다. OAuth2 표준 방식으로 연결한다는데, 아무리 찾아봐도 Alfresco 내부엔 OAuth Provider 가 안보이길래, 이참에 전체 분석을 좀 해봤습니다. 물론 짧은 시간내 대충 찾아본거라, 정답은 아니겠지만 구조 정도는 확인할 수 있어 보이긴 합니다. ㅎㅎ A : 사용자 폼전송시, Share 의 LoginController 를 통해, Alfresco의 인증모듈로 인증을 합니다. 이때, 데이터는 물론 Person 에 대한 ALF Content 를 사용함. (Alfresco 전용 티켓 발행 + Spring acegi를 통한 권한관리 FLOW) B : SSO AuthencationFilter 를 통해, 내부 인증과정을 우회하여 다른 별도..

■ 주의사항 각 서버간의 DATETIME 동기화를 반드시 확인하자. (안맞음 헛짓거리 함)커뮤니케이션 버젼은 캐시 클러스터링을 지원하지 않는다. (4.1X 기준) 물론, ehcache 를 사용할 수 없고, default 캐시를 사용하도록 되어 있다. 즉슨, 아래 가이드대로 ehcache 설정을 하더라도 동작하지 않는다. 동작하도록 하는 방법은 enterprise 에서 일부 관련 소스와 jar 들을 빼오면 되나, 여기선 언급하지 않는다. :-)OS의 max fil open (ulimt) 반드시 확인할 것. (1024 보다 작으면 캐시가 비워진다)■ /shared/classes/alfresco/extension/ehcahe-custom.xml각 로컬서버 하위 캐싱을 RMI로 동기화 한다.캐싱자체가 동기화 되..

몇년전까지 열심히 기록해 두었다가, 워낙 바쁘다 보니 내버려 두었는데요. 한참후에 가보니, 내 블로그가 패쇄되었더군요. 더군다나 Tistory 측에 문의했더니, 스팸성 글 때문에 복구도 안된답니다. 한참을 상심끝에 다시 Tistory 를 쓸까 말까 하다, 다시 쓰기로 했습니다. 그런데 오래되다보니, 영 글쓰기가 어색하네요. ㅎㅎ.

알프레스코의 기본 테이블인 ALF_NODE 와 ALF_PROPERITES 및 TRANSACTION 테이블은 과도한 데이터가 쌓일 경우, 조회뿐만 아니라, CRUD에서 WAIT 때문에, 도저히 성능이 안되더군요. 첨엔 Creator 기준으로 사용자별로 분배를 했지만, System/Admin 계정 문제등으로 제대로 파티셔닝이 안되어, 그냥 ID 기준으로 Hashing 을 사용하고, properties 는 alf_node 기준으로 FK대상으로 분배했습니다. 1. 주테이블을 파티셔닝으로 생성//1. alf_node 를 생성자별로 파티션을 분할함. CREATE TABLE ALFRESCO.ALF_NODE_PART2 ( ID NUMBER(19,0) NOT NULL, VERSION NUMBER(19,0) NOT NUL..