불친절한자수씨

참고자료: http://wiki.alfresco.com/wiki/Full-Text_Search_Configuration

각 프로퍼티의 인덱싱 행위는 컨텐츠 모델에서 설정될 수 있다. 기본적으로 원자적으로 인덱싱 된다. 프로퍼티 값은 인덱스 안에 저장되지 않고, 프로퍼티는 인덱싱 될 때, 토큰화 된다.

The following example shows how indexing can be controlled.

Enabled="false"

false 이면, 인덱스에 이 프로퍼티를 위한 엔트리는 없다.

Atomic="true"

true 이면, 프로퍼티는 트랜잭션 내에서 인덱싱되며, false 이면 프로퍼티는 백그라운드에서 인덱싱 된다.

(Indexing of content that requires transformation before being indexed (e.g. PDFs) will only obey Atomic=true if the transformation takes less time than the value specified for lucene.maxAtomicTransformationTime. See #General.)

Stored="true"

true 이면, 프로퍼티 값은 인덱스 내에 저장되고, 루씬 로우 레벨 쿼리 API를 통해 얻을 수 있다.

(This can be useful while debugging systems to see exactly what is being indexed, but do not set this to true on production systems.)

Tokenised="true"

"true" 이면, 프로퍼티의 문자열 값은 인덱싱 전에 토큰화 된다.

"false" 이면, 단일 문자열로 인덱싱 된다.

"both" 이면, 두 가지 형태로 인덱에 존재하기 된다.

마찬가지로 개인 참고용으로 정리합니다.

참고자료: https://wiki.alfresco.com/wiki/Default_Permissions_Model_Reference#Base_permissions

sys:base

기본 퍼미션

• _ReadProperties: 노드의 속성 읽기에 대한 접근을 제한. 컨텐츠 접근은 개별적으로 제어됨. 모든 속성은 동일한 접근 제한을 가짐.
• _ReadChildren: 자식 노드의 읽기에 대한 접근을 제한. 개별 자식 노드에 설정된 권한이 우선 적용됨. 이 권한이 부여되지 않으면 자식노드를 탐색할 수 없음.
• _WriteProperties: 노드의 모든 속성에 대한 쓰기에 대한 접근을 제한. 컨텐츠 접근은 개별적으로 제어됨. 모든 속성은 동일한 접근 제한을 가짐
• _ReadContent: 노드에 대한 모든 컨텐츠의 읽기에 대한 접근을 제한
• _WriteContent: 노드에 대한 모든 컨텐츠의 생성과 갱신에 대한 접근을 제한
• _ExecuteContent: 컨텐츠 실행에 대한 접근을 제한
• _DeleteNode: 노드 삭제에 대한 접근을 제한. 현재 노드의 모든 자식 노드를 삭제할 권한을 가지거나 부모로 부터 자식 노드를 삭제할 수 있는지를 체크하지 않음.
• _DeleteChildren: 자식 노드의 삭제에 대한 접근을 제한
• _CreateChildren: 새로운 자식 노드 생성에 대한 접근을 제한
• _LinkChildren: 이미 존재하는 노드에 보조 어소시에이션 생성에 대한 접근을 제한
• _DeleteAssociations: 노드에 대한 non-child-associations 삭제에 대한 접근을 제한
• _ReadAssociations: 노드에 대한 non-child-associations 읽기에 대한 접근을 제한
• _CreateAssociations: 노드에 대한 non-child-associations 생성에 대한 접근을 제한
• _ReadPermissions: 노드에서 읽기 권한에 대한 접근을 제한
• _ChangePermissions: 노드에서 쓰기 권한에 대한 접근을 제한

cm:lockable

기본 권한

• _Lock: 노드 잠금에 대한 접근을 제한
• _Unlock: 노드 잠금 해제에 대한 접근을 제한

개인적인 정리용으로...

출처: http://wiki.alfresco.com/wiki/Web_Scripts

기본

• shortname: 사람이 읽을 수 있는 Web Script 이름
• description (선택적인): Web Script 설명
• url (하나 혹은 여러 개): Web Script가 바인딩되는 URI 템플릿.
• format (선택적인): 응답의 content-type URI를 통해 어떻게 지정할 수 있는지를 제어
• argument 는 query string 파라미터로 content-type 을 지정
• ex) /helloworld?to=dave&format=xml
• extension 은 URI extension 으로 content-type 을 지정
• ex) /hello/world.xml?to=dave
• any 는 위의 둘 중 하나가 사용될 수 있음
• 지정되지 않으면 기본 값은 any 로 설정
• authentication (선택적인): 인증 레벨이 필요할 경우 사용
• none 은 인증이 필요 없음을 지정
• guest 은 최소한 guest 인증을 필요로 함
• user 는 최소한 지정된 사용자 인증을 필요로 함
• admin 은 최소한 지정된 관리자 인증을 필요로 함

확장

• transaction (선택적인): 트랜잭션 레벨을 지정
• none 은 트랜잭션이 필요 없음을 지정
• required 는 트랜잭션이 필요함을 지정
• requiresnew 는 새로운 트랜잭션이 필요함을 지정
• 지정되지 않으면 기본 값은 none 으로 설정
• family (선택적인): 유사하거나 관련이 있는 web scripts 들을 분류하기 위한 태그
• cache (선택적인): 캐싱 레벨을 지정
• never (선택적인): 캐싱을 모두 적용해야 하는지 여부를 지정
• true (기본 값) 는 web script 의 응답이 캐시되지 않음을 지정
• false 는 web script 의 응답이 캐시할 수 있음을 지정
• public (선택적인): 인증 응답이 공개 캐시에 캐시해야 하는지 여부를 지정
• true (기본 값) / false
• mustrevalidate (선택적인): 캐시가 freshness 를 보장하기 위해 web scritp 응답의 버전을 재검증해야 하는지 여부를 지정
• true (기본 값) / false
• negotiate (0개 이상): Accept 헤더 MIME-type 과 응답의 특정 web script 형식의 연관
• kind (선택적인): web script 의 종류 재정의를 위한 식별
• lifecycle (선택적인): web script 의 라이프사이클을 지정
• none 은 web script 가 라이프사이클의 일부가 아님을 지정
• sample 은 web script 가 샘플로 만들어졌으며, 제품으로 사용하지 않음을 지정
• draft 는 web script 가 실험 중이거나 변경/정지 될 수 있음을 지정
• public_api 는 Alfresco 의 공개 API 이며, 안정적이고 잘 테스트되었음을 지정
• draft_public_api 는 공개 API가 될 것이지만, 실험 중이거나 변경/정지 될 수 있음을 지정
• deprecated 는 향후 버전에서 제거될 수 있으니 사용을 피하도록 함을 지정
• internal 은 Alfresco 내부에서만 사용됨을 지정

Presets에 정의된 컴포넌트가 생성되는 시점을 못찾아서 삽질을 했었는데, 드디어 발견했다.

[installLocation]\tomcat\webapps\share\sire_index.jsp

위의 소스에서 수행하는 작업은 "userid"를 세션에서 조회하여 해당 페이지가 존재하는지를 체크하고 없다면 "PresetsManager"를 통해서 "preset"를 구성한다. 그 후, 해당 페이지로 리다이렉트,,,

가장 중요한건 FrameworkUtil.getServiceRegistry().getPresetsManager().constructPreset("user-dashboard", tokens); 를 발견했다거...

http://blogs.alfresco.com/wp/developer/2011/11/01/spring-surf-presets/ 를 이해한대로 정리해봅니다.

배경

대시보드와 같이 사용자 별로 유니크한 페이지에서 사용자가 최초로 접속할 때 생성되어야 하는 것들은 "presets"을 이용한다.

Presets는 "spring-surf-presets-context.xml"에 "org.springframework.extensions.surf.PresetsManager" 클래스를 통해 관리된다.

기본적으로 "presets.xml" 는 "classes/alfresco/site-data/presets" 이나 "classes/alfresco/web-extension/site-data/presets" 에 위치한다. 기본적인 구조는 아래와 같다.

Presets 예시

PresetsManager 빈은 "constructPresets" 메소드를 호출하여 Presets 환경을 설정한다. 다른 방법으로는 custom Spring Surf JSP 태그를 이용하는 것이다. 이 방법은 아래와 같이 사용할 수 있다.

preset은 다수의 인스턴스를 생성하기 원하는 objects를 초기 정의 시에만 제공되어 진다. 

"source-id" 속성을 정의하여 컴포넌트의 scope를 설정할 수 있다.

Presets Manager 대안

Presets Manager를 커스터마이징 하기를 원한다면 Spring Surf FVT application을 사용한다.

"PresetsManager"는 "ModelObjects"를 생성하고 저장하는 "ModelObjectService"를 필요로 한다. 기본적으로 "PresetsManager"는 로컬 파일 시스템에 접근하는 것이 포함되어 있지 않은 "MultiObjectServer"를 사용한다. "ModelObjectService"는 "Store"를 필요로 하는 "Persister"를 필요로 하는 "PersisterService"를 필요로 한다.

<bean id="presets.model.object.service"> <property name="objectPersistenceService" ref="presets.object.persistence.service"/> </bean> <bean id="presets.object.persistence.service" > <property name="persisterService" ref="presets.persister.service"/> </bean> <bean id="presets.persister.service" > <property name="persister" ref="presets.persister"/> <property name="webFrameworkConfig" ref="webframework.config.element"/> </bean> <bean id="presets.persister" parent="webframework.sitedata.persister.abstract"> <property name="store" ref="presets.store"/> <property name="pathPrefix"><value>/</value></property> </bean> <bean id="presets.store" > <property name="root"><value>./WEB-INF</value></property> <property name="path"><value>/presetConstructs</value></property> </bean>

기본 "PresetsManager"를 오버라이드하고 "ModelObjectService"가 참조되기를 보장한다.

<bean id="webframework.presets.manager" > <property name="modelObjectService" ref="presets.model.object.service"/> <property name="searchPath" ref="webframework.presets.searchpath"/> <property name="files"> <list> <value>presets.xml</value> </list> </property> </bean>

마지막으로 새로운 persist를 사용할 수 있도록 추가하는 기본 "Autowire" 서비스를 오버라이드 한다.

<bean id="webframework.service.autowire" parent="webframework.service.autowire.abstract"> <property> <list> <ref bean="webframework.sitedata.persister.classpath"/> <ref bean="presets.persister"/> </list> </property> </bean>

흠... 일단은 뭔말인지는 알겠음...

이클립스에서 m2e 플러그인을 사용할 경우, 알프레스코 플러그인이 아래와 같이 빨간 빛을 내는 경우가 있습니다.

컴파일에는 문제가 생기지 않지만 빨간 엑스박스가 자꾸 눈에 걸립니다...

m2e 위키에서는 다음과 같은 방법을 제안합니다. 읽어보시고 더 좋은 방안이 있으시면,,, 공유 좀,,,

(http://wiki.eclipse.org/M2E_plugin_execution_not_covered)

하지만 귀찮으니 걍 "Mark goal set-version as ignored in Eclipse build in Eclipse preference..." 를 클릭하여 에러를 무시합니다.

해당 설정은 프로젝트 properties 에 "Maven > Lifecycle Mapping" 에서 확인할 수 있습니다.

빨간불 끄는 것도 일이네요,,,

출처: http://docs.alfresco.com/4.1/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Ftasks%2Fmysql-config.html

1. MySQL database connector 설치

MySQL database connector 는 MySQL 을 사용하는 Alfresco 설치 시에 필요합니다. database connector 는 MySQL database 가 Alfresco 서버와 talk 하는 것을 허용합니다.(-ㅁ-,,,)

a. MySQL download site (http://dev.mysql.com/) 에서 mysql-connector-java-5.x.x-bin.jar 를 다운받습니다.

b. Tomcat 라이브러리 디렉토리 (<TOMCAT_HOME>/lib) 에 JAR 파일을 복사합니다.

2. "alfresco" 라는 이름의 데이터베이스를 생성합니다.

MySQL 과 non-US-ASCII 문자를 사용한다면, 인코딩 설정이 필요합니다. 데이터베이스는 반드시 "UTF-8" 문자셋과 "utf8_bin" collation 으로 만들어져야 합니다. JDBC URL 에 "?useUnicode=yes&characterEncoding=UTF-8" 파라미터를 사용해야 합니다.

3. "alfresco" 라는 이름으로 사용자를 생성합니다.

4. 패스워드도 "alfresco" 라고 설정합니다.

5. "<classpathRoot>/alfresco-global.properties.sample" 파일을 엽니다.

6. 해당 라인으로 이동합니다.

#dir.root=/srv/alfresco/alf_data

7. 기존의 경로에서 Alfresco 데이터가 저장되기 원하는 디렉토리로 변경합니다.

ex) dir.root=C:/Alfresco/alf_data

8. 다음 데이터베이스 설정을 변경합니다.

9. 다른 데이터베이스 설정을 변경합니다.

10. (선택적...) 대소문자 구분을 활성화 시킬 수 있습니다.

기본적으로 Alfresco 는 대소문자 구분을 하지 않습니다. 데이터베이스가 대소문자 구분하기 원한다면, alfresco-global.properties 파일을 다음과 같이 수정합니다.

11. .sample 확장자를 지우고 저장합니다. (alfresco-global.properties)

12. Alfresco 서버를 재시작합니다.

JDBC 에러가 발생한다면, MySQL JDBC 드라이버가 시스템 경로에 없거나, 애플리케이션 서버의 lib 디렉토리에 없을 때 발생합니다.

James 공식 홈페이지(http://james.apache.org/server/3/dev-build.html)에는 대충 설명되어 있어서 따로 정리합니다.

실행위치는 james-server 를 내려받은 최상단 pom.xml 이 있는 곳입니다.

Goals 에 clean 을 설정하는 이유는 혹시라도 모를 문제 발생을 미연에 방지하고자 사용합니다.

Profiles 에 with-assembly 는 "zip, targ.gz, war" 파일을 생성해 줍니다.

기본설정으로 빌드를 하면 메모리 부족을 확인할 수 있을 것 입니다.

VM arguments 에 다음과 같이 설정합니다.

지겹지겹...

요즘 회사에서 메일엔진 부분을 맡고 있다. 

간혹 본문이 깨져서 들어오거나 들어오지 않는 경우가 있어 확인해보니 헤더에 base64 로 인코딩을 한다고 정의해 놓고 본문을 인코딩 안하고 한 경우가 대다수이다.

그전에 개발하시던 팀장님은 이런 경우에 대한 처리를 해 놓으셨는데, 역시 실전은 케바케...

케바케가 발생한 부분은 본문부가 base64 인지 체크하는 로직이였다. 기존 로직은 55 bytes 를 가지고 와서 base64 디코딩을 해서 익셉션이 발생하느냐 안하느냐를 체크...

조금 더 정확하게 체크하기 위해 base64 를 조사해보았다.

(참고자료: http://bbolmin.tistory.com/46)

8bit 로 이루어진 데이터를 6bit 씩 짤라서 총 64개의 문자열로 표현하는 방식. 

base64 로 인코딩된 문자열이 8자리라면 총 48bit... 디코딩을 하게되면 6 bytes 데이터가 된다.

결국 55자리라면 330bit... 디코딩을 하게되면 41 bytes 와 잉여 데이터가 2 bits 가 남게 된다.

나이가 들어 계산이 어렵다고 판단하여 8과 6의 배수 bytes 를 읽어들이면 되지 않을까???(지금까지는...)

그래서 기존 55 bytes 가 아닌 48 bytes 를 읽어들여 base64 인코딩을 판단하도록 로직을 변경...

참고로... 어차피 base64 로 인코딩된 데이터는 A~Z, a~z, 0~9, /, = 으로만 이루어져 있다.

아래와 같은 로직을 추가한다면 조금 더 정밀해지긴 할텐데... 케바케가 무서워 그냥 48 bytes 를 처리하는 로직처리만 했다.