인피니스팬 커뮤니티 여러분께,
인피니스팬 6.0.0 첫번째 릴리즈 후보(CR1) 버전을 기쁘게 발표합니다.
많은 분들이 릴리즈 후보버전에 대해서 알고있듯이, 이 버전은 안정화된 6.0.0 버전을 위한 다수의 버그 수정과 기능 확장을 포함하고 있습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련된 분들과 기여하신 모든 분들께 감사드립니다.
윌(Will)
원문:
Tuesday, 8 October 2013, Infinispan 6.0.0.CR1 is available!
2013년 10월 9일 수요일
2013년 10월 4일 금요일
인피니스팬 6.0.0.Beta2가 나왔습니다!
인피니스팬 커뮤니티 여러분께,
"일찍 릴리즈하라. 자주 릴리즈하라. 그리고 고객의 말에 귀기울여라"라는 소프트웨어 개발 철학에 확신을 가지면서, 오늘 인피니스팬 6.0.0.Beta2를 릴리즈합니다. 이는 주로 첫번째 베타에서 질풍같이 기능들을 추가한 이후에 안정화를 위한 릴리즈입니다. Beta2는 핫로드 원격 클라이언트와 LevelDB 캐시 스토어와 관련한 작은 버그 수정들을 포함하고 있습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
감사합니다.
블라디미르(Vladimir)
원문:
Friday, 27 September 2013, Infinispan 6.0.0.Beta2 is released!
------------------
역자주. 원문은 2013년 9월 27일에 작성되었습니다.
"일찍 릴리즈하라. 자주 릴리즈하라. 그리고 고객의 말에 귀기울여라"라는 소프트웨어 개발 철학에 확신을 가지면서, 오늘 인피니스팬 6.0.0.Beta2를 릴리즈합니다. 이는 주로 첫번째 베타에서 질풍같이 기능들을 추가한 이후에 안정화를 위한 릴리즈입니다. Beta2는 핫로드 원격 클라이언트와 LevelDB 캐시 스토어와 관련한 작은 버그 수정들을 포함하고 있습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
감사합니다.
블라디미르(Vladimir)
원문:
Friday, 27 September 2013, Infinispan 6.0.0.Beta2 is released!
------------------
역자주. 원문은 2013년 9월 27일에 작성되었습니다.
내장 및 원격 질의
인피니스팬 메일링 리스트를 받아보고 있다면, 아마 질의에 관한 새로운 개발진행에 대해 살짝 엿들었을 것이다. 새로운 DSL, 핫로드 클라이언트를 사용한 원격 질의, 구글의 프로토콜 버퍼(protobuf)에 기반한 새로운 마샬러들이 그것이고, 지금이 이것들의 베일을 제대로 벗길 때이다!
새로운 질의 DSL
인피니스팬 버전 6.0부터, 캐시된 엔트리에 대해서 단순 필터링 DSL에 기반한 질의를 수행하는 새로운 (실험적인) 방법을 제공한다. 이 새로운 DSL의 목적은 질의를 더 간단히 작성하게 하고, 기저의 질의 메커니즘을 모르게 하여 미래에 루씬 이외의 대안적인 질의 엔진을 제공 가능케 하는 동시에 여전히 같은 질의 언어/API를 사용할 수 있도록 하는 데 있다. 이전의 하이버네이트 서치와 루씬 기반의 접근은 여전히 존재하며 계속 지원될 것이다. 사실 이 새로운 DSL은 현재 그 위에서 구현되었있다. 앞으로는 맵리듀스에 기반한 인덱스를 사용하지 않는 검색이 생길 것이며, 어쩌면 다른 뛰어난 검색 기술도 가능할 것이다.
내장모드에서 DSL 기반 질의를 실행하는 것은 현재의 루씬 기반 질의를 실행하는 것과 거의 동일하다. 필요한 작업은 infinispan-query-dsl.jar와 infinispan-query.jar를 클래스패스에 넣고, 캐시의 인덱싱을 활성화 하고 캐시에 저장될 POJO에 어노테이션을 붙이는 것이 전부다.
다른 방법으로, 사용자 가이드에서 설명했듯이 인덱싱은 (그리고 다른 모든 것도) XML을 사용해 설정 가능하다. 그래서 여기서는 자세히 들어가지 않는다.
하이버네이트 서치 어노테이션을 붙인 엔티티는 아래와 같을 것이다.
DSL 기반 질의를 실행하기 위해 아래처럼 (캐시 범위의) SearchManager로부터 QueryFactory 얻고 질의를 만든다.
이것이 전부이다. DSL이 실제로 무엇을 할 수 있는지에 관한 호기심을 불러 일으켰으리라 생각된다. FilterConditionEndContext에서 지원 필터 동작 리스트를 확인할 수 있다. 하위 조건들을 포함하여 불린 연산으로 복수개의 조건을 조합하는 것도 역시 가능하다.
이 DSL은 상당히 멋지고, 사용자 피드백에 기반하여 미래에 계속 확장될 것이다. 이는 또한 결과 페이징, 소팅, 프로젝션, 내장 객체에 대한 지원을 제공하며, 모두 QueryDslConditionsTest에서 확인 가능하다. 적절한 사용자 가이드가 나오기 전까지는 이 클래스를 살펴 보기를 권한다. 그러나 이것은 관계형 데이터베이스가 아니다. 모든 질의는 단일 대상 엔티티 (그리고 그것의 내장 엔티티들) 범위에서 쓰여진다는 것을 명심하라. 조인은 (아직) 없고, 상관 하위질의도 없고, 그룹핑이나 aggregation도 없다.
좀 더 들어가서, 아마도 이 새 DSL에 관해서 가장 흥미로운 것은 핫로드 클라이언트를 통해 원격으로 사용하는 것일것이다. 이 도약을 위해서 먼저 캐시 엔트리를 저장하고 그것들을 마샬링하는 공통 형식을 채택했어야만 했다. 이는 또한 사용 언어간 제약에 없고, 객체 스키마의 진화를 지원할 만큼 충분히 탄탄하여야 한다. 하지만, 아마도 무엇보다 이 형식은 단지 불명확한 blob이기 보다는 하나의 스키마를 가져야 했다. 그렇지 않으면 인덱싱과 검색이 의미없다. 프로토콜 버퍼로 들어가보자.
프로토콜 버퍼 마샬러
자바 핫로드 클라이언트를 사용하기 위해 RemoteCacheManager를 설정하는 것은 간단하다.
아래 순서대로 하면 User 인스턴스를 프로토콜 버퍼 형식으로 원격 캐시에 저장하고 불러올 수 있다.
1. 사용자 엔티티를 위한 Protobuf 타입을 .proto파일에 선언하고 컴파일하여 .protobin 바이너리 기술자(binary descriptor)로 만든다.
2. 그 바이너리 기술자를 아래와 같이 RemoteCacheManager의 ProtoStreamMarshaller 인스턴스에 등록한다.
3. 엔티티마다 마샬러를 등록한다.
2, 3번 단계는 Protostream 라이브러리가 동작하는 방법과 매우 가깝다. 그것은 아주 간단하지만 여기서 자세히 살펴볼 수는 없다. UserMarshaller 예제를 살펴보는 것이 많은 도움이 될 것이다.
사용자 객체를 프로토콜 버퍼 형식으로 유지하는 것은 다른 언어로 쓰여진 클라이언트들이 그것들을 사용할 수 있다는 데에 이점이 있다. 이것이 흥미롭게 들리지 않는 사람이라도 그것들이 쉽게 인덱싱 될 수 있다는 사실은 매력적이라고 생각할 것이다.
핫로드 클라이언트를 통한 원격 질의
RemoteCacheManagery를 위에서 설명한대로 설정하고, 다음 단계에서 원격 질의를 활성화 한다.
1. DSL jar를 클라이언트의 클래스패스에, infinispan-remote-query-server.jar를 서버의 클래스패스에 그리고 infinispan-remote-query-client.jar를 양쪽에 추가한다.
2. 캐시 설정에서 인덱싱을 활성화 한다. 내장모드도 동일하다.
3. 서버에서 (EmbeddedCacheManager 마다 하나의 인스턴스가 존재하는) ProtobufMetadataManager MBean의 registerProtofile 메소드를 사용하여 protobuf 바이너리 기술자를 등록한다.
캐시안에 들어온 모든 데이터는 엔티티에 하이버네이트 서치 어노테이션을 붙이지 않고 인덱싱 된다. 사실 이 클래스들은 자바 클라이언트에만 의미가 있으며 서버에는 존재하지도 않는다.
핫로드 클라이언트를 통해 질의를 실행하는 것은 내장모드와 아주 비슷하다. DSL은 사실 같다. 단지 작은 차이점은 QueryFactory를 얻는 방법이다.
이것보숑! 오늘의 여행일정이 끝났다. 인피니스팬 질의를 계속 눈여겨 보며, 당신의 커맨트를 공유해달라.
원문:
Thursday, 26 September 2013, Embedded and remote queries in Infinispan 6.0.0.Beta1
새로운 질의 DSL
인피니스팬 버전 6.0부터, 캐시된 엔트리에 대해서 단순 필터링 DSL에 기반한 질의를 수행하는 새로운 (실험적인) 방법을 제공한다. 이 새로운 DSL의 목적은 질의를 더 간단히 작성하게 하고, 기저의 질의 메커니즘을 모르게 하여 미래에 루씬 이외의 대안적인 질의 엔진을 제공 가능케 하는 동시에 여전히 같은 질의 언어/API를 사용할 수 있도록 하는 데 있다. 이전의 하이버네이트 서치와 루씬 기반의 접근은 여전히 존재하며 계속 지원될 것이다. 사실 이 새로운 DSL은 현재 그 위에서 구현되었있다. 앞으로는 맵리듀스에 기반한 인덱스를 사용하지 않는 검색이 생길 것이며, 어쩌면 다른 뛰어난 검색 기술도 가능할 것이다.
내장모드에서 DSL 기반 질의를 실행하는 것은 현재의 루씬 기반 질의를 실행하는 것과 거의 동일하다. 필요한 작업은 infinispan-query-dsl.jar와 infinispan-query.jar를 클래스패스에 넣고, 캐시의 인덱싱을 활성화 하고 캐시에 저장될 POJO에 어노테이션을 붙이는 것이 전부다.
ConfigurationBuilder cfg =newConfigurationBuilder(); cfg.indexing().enable(); DefaultCacheManager cacheManager =newDefaultCacheManager(cfg.build()); Cache cache = cacheManager.getCache();
다른 방법으로, 사용자 가이드에서 설명했듯이 인덱싱은 (그리고 다른 모든 것도) XML을 사용해 설정 가능하다. 그래서 여기서는 자세히 들어가지 않는다.
하이버네이트 서치 어노테이션을 붙인 엔티티는 아래와 같을 것이다.
import org.hibernate.search.annotations.*;
...
@Indexed
public class User {
@Field(store = Store.YES, analyze = Analyze.NO)
private String name;
@Field(store = Store.YES, analyze = Analyze.NO, indexNullAs = Field.DEFAULT_NULL_TOKEN)
private String surname;
@IndexedEmbedded(indexNullAs = Field.DEFAULT_NULL_TOKEN)
private List addresses;
// .. the rest omitted for brevity
}
DSL 기반 질의를 실행하기 위해 아래처럼 (캐시 범위의) SearchManager로부터 QueryFactory 얻고 질의를 만든다.
import org.infinispan.query.Search;
import org.infinispan.query.dsl.QueryFactory;
import org.infinispan.query.dsl.Query;
...
QueryFactory qf = Search.getSearchManager(cache).getQueryFactory();
Query q = qf.from(User.class)
.having("name").eq("John")
.toBuilder().build();
List list = q.list();
assertEquals(1, list.size());
assertEquals("John", list.get(0).getName());
assertEquals("Doe", list.get(0).getSurname());
이것이 전부이다. DSL이 실제로 무엇을 할 수 있는지에 관한 호기심을 불러 일으켰으리라 생각된다. FilterConditionEndContext에서 지원 필터 동작 리스트를 확인할 수 있다. 하위 조건들을 포함하여 불린 연산으로 복수개의 조건을 조합하는 것도 역시 가능하다.
Query q = qf.from(User.class)
.having("name").eq("John")
.and().having("surname").eq("Doe")
.and().not(qf.having("address.street").like("%Tanzania%").or().having("address.postCode").in("TZ13", "TZ22"))
.toBuilder().build();
이 DSL은 상당히 멋지고, 사용자 피드백에 기반하여 미래에 계속 확장될 것이다. 이는 또한 결과 페이징, 소팅, 프로젝션, 내장 객체에 대한 지원을 제공하며, 모두 QueryDslConditionsTest에서 확인 가능하다. 적절한 사용자 가이드가 나오기 전까지는 이 클래스를 살펴 보기를 권한다. 그러나 이것은 관계형 데이터베이스가 아니다. 모든 질의는 단일 대상 엔티티 (그리고 그것의 내장 엔티티들) 범위에서 쓰여진다는 것을 명심하라. 조인은 (아직) 없고, 상관 하위질의도 없고, 그룹핑이나 aggregation도 없다.
좀 더 들어가서, 아마도 이 새 DSL에 관해서 가장 흥미로운 것은 핫로드 클라이언트를 통해 원격으로 사용하는 것일것이다. 이 도약을 위해서 먼저 캐시 엔트리를 저장하고 그것들을 마샬링하는 공통 형식을 채택했어야만 했다. 이는 또한 사용 언어간 제약에 없고, 객체 스키마의 진화를 지원할 만큼 충분히 탄탄하여야 한다. 하지만, 아마도 무엇보다 이 형식은 단지 불명확한 blob이기 보다는 하나의 스키마를 가져야 했다. 그렇지 않으면 인덱싱과 검색이 의미없다. 프로토콜 버퍼로 들어가보자.
프로토콜 버퍼 마샬러
자바 핫로드 클라이언트를 사용하기 위해 RemoteCacheManager를 설정하는 것은 간단하다.
import org.infinispan.client.hotrod.configuration.ConfigurationBuilder;
...
ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder.addServer()
.host("127.0.0.1").port(11234)
.marshaller(new ProtoStreamMarshaller());
아래 순서대로 하면 User 인스턴스를 프로토콜 버퍼 형식으로 원격 캐시에 저장하고 불러올 수 있다.
1. 사용자 엔티티를 위한 Protobuf 타입을 .proto파일에 선언하고 컴파일하여 .protobin 바이너리 기술자(binary descriptor)로 만든다.
2. 그 바이너리 기술자를 아래와 같이 RemoteCacheManager의 ProtoStreamMarshaller 인스턴스에 등록한다.
ProtoStreamMarshaller.getSerializationContext(remoteCacheManager)
.registerProtofile("my-test-schema.protobin");
3. 엔티티마다 마샬러를 등록한다.
ProtoStreamMarshaller.getSerializationContext(remoteCacheManager)
.registerMarshaller(User.class, new UserMarshaller());
2, 3번 단계는 Protostream 라이브러리가 동작하는 방법과 매우 가깝다. 그것은 아주 간단하지만 여기서 자세히 살펴볼 수는 없다. UserMarshaller 예제를 살펴보는 것이 많은 도움이 될 것이다.
사용자 객체를 프로토콜 버퍼 형식으로 유지하는 것은 다른 언어로 쓰여진 클라이언트들이 그것들을 사용할 수 있다는 데에 이점이 있다. 이것이 흥미롭게 들리지 않는 사람이라도 그것들이 쉽게 인덱싱 될 수 있다는 사실은 매력적이라고 생각할 것이다.
핫로드 클라이언트를 통한 원격 질의
RemoteCacheManagery를 위에서 설명한대로 설정하고, 다음 단계에서 원격 질의를 활성화 한다.
1. DSL jar를 클라이언트의 클래스패스에, infinispan-remote-query-server.jar를 서버의 클래스패스에 그리고 infinispan-remote-query-client.jar를 양쪽에 추가한다.
2. 캐시 설정에서 인덱싱을 활성화 한다. 내장모드도 동일하다.
3. 서버에서 (EmbeddedCacheManager 마다 하나의 인스턴스가 존재하는) ProtobufMetadataManager MBean의 registerProtofile 메소드를 사용하여 protobuf 바이너리 기술자를 등록한다.
캐시안에 들어온 모든 데이터는 엔티티에 하이버네이트 서치 어노테이션을 붙이지 않고 인덱싱 된다. 사실 이 클래스들은 자바 클라이언트에만 의미가 있으며 서버에는 존재하지도 않는다.
핫로드 클라이언트를 통해 질의를 실행하는 것은 내장모드와 아주 비슷하다. DSL은 사실 같다. 단지 작은 차이점은 QueryFactory를 얻는 방법이다.
import org.infinispan.client.hotrod.Search;
import org.infinispan.query.dsl.QueryFactory;
import org.infinispan.query.dsl.Query;
...
remoteCache.put(2, new User("John", "Doe", 33));
QueryFactory qf = Search.getQueryFactory(remoteCache);
Query query = qf.from(User.class)
.having("name").eq("John")
.toBuilder().build();
List list = query.list();
assertEquals(1, list.size());
assertEquals("John", list.get(0).getName());
assertEquals("Doe", list.get(0).getSurname());
이것보숑! 오늘의 여행일정이 끝났다. 인피니스팬 질의를 계속 눈여겨 보며, 당신의 커맨트를 공유해달라.
원문:
Thursday, 26 September 2013, Embedded and remote queries in Infinispan 6.0.0.Beta1
불균질적인(heterogenous) 클러스터
인피니스팬 클러스터에 참여하는 것의 기본적인 규칙중 하나는 모두가 같은 만큼의 공유를 해야한다는 것이었다. 물론, 각 노드는 다른 캐시 셋을 실행할 수 있었다. (즉 클러스터는 대칭적일 필요는 없었다) 하지만 노드가 분산 캐시를 시작할 때, 다른 모든 캐시 멤버들과 똑 같은 키의 공유에 대한 소유권을 자동적으로 가져왔다.
6.0.0.Beta1에서 ISPN-3051의 구현으로 이젠 더이상 그렇지 않다. 새로운 capacityFactor 세팅을 사용하여 각 노드는 이제 많거나 적은 키들을 소유하도록 맞춰질 수 있다. 기본값은 1.0이고 노드들은 설정 API를 통해 크거나 작은 같을 정할 수 있다.
또는 다음와 같이 XML설정을 할 수 있다.
하나의 노드가 소유하고 있는 키의 개수가 정확히 capacity factor에 비례한다고 보장할 수 없다는 것을 염두에 두라. 특별히 ConsistentHashFactory의 커스텀 구현체는 완전히 capacityFactor 설정을 무시할 수 있다. 하지만 ConsistentHashFactory의 기본 구현체는 가능한 그것을 지키려고 할 것이다.
적용 사례로 흥미로운 것은 capacity factor가 0인 노드들이다. 노드가 짧은 시간동안만 살아있어서 데이터를 소유하기에는 적합하지 않는 상황에서, 트랜잭션을 사용하고 싶지만 핫로드 또는 다른 원격 프로토콜이 사용 불가능할 때 이것이 유용할 수 있다. 사이트간 복제 또한 하나의 예인데, "사이트 마스터"가 사이트간에 커맨드 전달만 처리하고 사용자 요청은 처리하지 말아야 할때 capacity factor를 0으로 설정하는 것이 적합하다.
주의사항: 인피니스팬 서버 6.0.0.Beta1도 이 기능을 지원한다. 하지만 설정은 애플리케이션 서버의 이름 규칙에 따라 capacity-factor로 불린다.
원문:
Friday, 20 September 2013, Heterogenous clusters with Infinispan 6.0.0.Beta1
6.0.0.Beta1에서 ISPN-3051의 구현으로 이젠 더이상 그렇지 않다. 새로운 capacityFactor 세팅을 사용하여 각 노드는 이제 많거나 적은 키들을 소유하도록 맞춰질 수 있다. 기본값은 1.0이고 노드들은 설정 API를 통해 크거나 작은 같을 정할 수 있다.
또는 다음와 같이 XML설정을 할 수 있다.
하나의 노드가 소유하고 있는 키의 개수가 정확히 capacity factor에 비례한다고 보장할 수 없다는 것을 염두에 두라. 특별히 ConsistentHashFactory의 커스텀 구현체는 완전히 capacityFactor 설정을 무시할 수 있다. 하지만 ConsistentHashFactory의 기본 구현체는 가능한 그것을 지키려고 할 것이다.
적용 사례로 흥미로운 것은 capacity factor가 0인 노드들이다. 노드가 짧은 시간동안만 살아있어서 데이터를 소유하기에는 적합하지 않는 상황에서, 트랜잭션을 사용하고 싶지만 핫로드 또는 다른 원격 프로토콜이 사용 불가능할 때 이것이 유용할 수 있다. 사이트간 복제 또한 하나의 예인데, "사이트 마스터"가 사이트간에 커맨드 전달만 처리하고 사용자 요청은 처리하지 말아야 할때 capacity factor를 0으로 설정하는 것이 적합하다.
주의사항: 인피니스팬 서버 6.0.0.Beta1도 이 기능을 지원한다. 하지만 설정은 애플리케이션 서버의 이름 규칙에 따라 capacity-factor로 불린다.
원문:
Friday, 20 September 2013, Heterogenous clusters with Infinispan 6.0.0.Beta1
인피니스팬 6.0.0.Beta1이 나왔습니다!
인피니스팬 커뮤니티 여러분께,
(2013년 9월 19일 현재) 인피니스팬 6.0.0의 첫번째 베타버전을 발표합니다. 6.0.0을 위한 기능과 API 변경이 완료되었다는 점에서 중요한 마일스톤입니다.
이번 릴리즈에 포함된 것은,
이번 릴리즈와 함께 인피니스팬 웹사이트가 새로와졌습니다.
그밖에 다른 것들로는, 새로운 사이트는 인피니스팬이 배포되는 방법에 있어서 생긴 변화를 반영하고 있습니다. 몇 개의 캐시스토어와 핫로드 클라이언트가 분리된 깃허브 저장소로 옮겨지고 자체적인 릴리즈 주기를 따르게 됩니다..
마지막으로, 인피니스팬의 원격 질의 기능을 제시간에 완료하기 위해 필요했던 하이버네이트 팀의 지원(무리한 기간 내의 기능확장, 버그 수정, 릴리즈)에 큰 감사의 뜻을 전하고 싶습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
미르차(Mircea)
원문:
Thursday, 19 September 2013, Infinispan 6.0.0.Beta1 is out!
------------------
역자주. 원문은 2013년 9월 19일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
(2013년 9월 19일 현재) 인피니스팬 6.0.0의 첫번째 베타버전을 발표합니다. 6.0.0을 위한 기능과 API 변경이 완료되었다는 점에서 중요한 마일스톤입니다.
이번 릴리즈에 포함된 것은,
- JMX를 통한 인덱스 관리를 포함하여 완료된 원격 질의 기능 구현. 애드리안 니스토어(Adrian Nistor)가 이것에 관한 글을 블로그에 올릴 것이다.
- 클러스터내 노드 간에 다른 양의 데이터를 설정하게 하는 노드당 세그먼트 개수 설정
이번 릴리즈와 함께 인피니스팬 웹사이트가 새로와졌습니다.
- Awestruct로 만들어짐. 정말 뛰어나고 사용하기 편함.
- GitHub 페이지에 호스팅됨. 빠르고 쉬움.
- 트위터의 부트스트랩의 JBoss.org 커뮤니티 스타일 사용
- 컨플루언스에서 AsciiDoc으로 문서 형식이 바뀜
그밖에 다른 것들로는, 새로운 사이트는 인피니스팬이 배포되는 방법에 있어서 생긴 변화를 반영하고 있습니다. 몇 개의 캐시스토어와 핫로드 클라이언트가 분리된 깃허브 저장소로 옮겨지고 자체적인 릴리즈 주기를 따르게 됩니다..
마지막으로, 인피니스팬의 원격 질의 기능을 제시간에 완료하기 위해 필요했던 하이버네이트 팀의 지원(무리한 기간 내의 기능확장, 버그 수정, 릴리즈)에 큰 감사의 뜻을 전하고 싶습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
미르차(Mircea)
원문:
Thursday, 19 September 2013, Infinispan 6.0.0.Beta1 is out!
------------------
역자주. 원문은 2013년 9월 19일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
새로운 영속 API(persistence API)
기존의 CacheLoader/CacheStore API는 인피니스팬 4.0 부터 있어왔다. 인피니스팬의 이번 릴리즈에서는 영속성과의 통합을 간결하게 하는 것과 상당한 성능 향상을 위한 문을 여는 두가지 면에서 큰 진전이 있었다.
무엇이 새로운가
새로운 영속성 통합이 가져온 것들을 보자.
- JSR-107에 맞춤: 이제 JSR-107의 loader와 writer과 비슷한 CacheLoader와 CacheWriter 인터페이스를 가지게 되었고, 이는 JCache를 따르는 벤더 사이에서 포팅 가능한 스토어를 작성하는데 많은 도움이 될 것이다.
- 간단해진 트랜잭션 통합: 모든 잠금은 이제 인피니스팬 레이어에서 처리된다. 그래서 구현체는 스토어에 대한 동시 접근을 조절하는 것을 고려할 필요가 없다. (기존의 LockSupportCacheStore는 이런 이유로 삭제되었다)
- 병렬 순회(parallel iteration): 이제 스토어 내의 엔트리를 여러 스레드가 병렬적으로 순회 가능하다. 맵리듀스 작업들은 클러스터내 노드와 동일 노드 안에서(복수개의 스레드로) 두 경우 다 병렬적으로 실행하므로 직접적인 이득을 보게 된다.
- 감소된 직렬화 (적은 CPU 사용): 새로운 API는 저장된 엔트리를 직렬화된 형식으로 노출하게 한다. 만약 한 엔트리가 단지 원격으로 보내지기위한 목적으로 영속적인 저장소로부터 불려진다면, 이제는 그것을 (스토어로부터 읽을 때) 역직렬화(deserialization) 하고 (원격으로 보낼때) 다시 직열화(serialization) 하지 않는다. 이제 스토어로부터 읽은 직열화된 형식을 직접 원격으로 쓴다.
API
이제 API를 좀 더 자세히 살펴보자.
위의 그림은 API의 주요 클래스들을 보여준다.
- ByteBuffer - 객체위에 직렬화된 형식을 추상화 한다.
- MarshalledEntry - 캐시에 추가된 하나의 키-밸류 쌍에 상응하여 영속 스토어에 저장된 정보를 추상화 한다. 직렬화된 ByteBuffer와 역직렬화된 객체에 포함된 정보를 읽기 위한 메소드를 제공한다. 보통 스토어로부터 읽혀진 데이터는 MarshalledEntry 구현체 안에서 직렬화된 형식으로 가지고 있다가 나중에 필요할 때 역직렬화 된다.
- CacheWriter와 CacheLoader는 스토어에서 읽기와 쓰기에 관한 기본적인 메소드를 제공한다.
- AdvancedCacheLoader와 AdvancedCacheWriter는 병렬 순회(parallel iteration), 만료된 엔트리 삭제, 캐시 비우기 등 스토리지 안에서 대량으로 조작하기 위한 동작을 제공한다.
제공자는 이런 인터페이스들중 어떤 것을 구현할 것인지 선택할 수도 있다.
- AdvancedCacheWriter를 구현하지 않으면 해당 writer가 만료된 엔트리를 제거하거나, 캐시 비우기를 할 때 쓰이지 않는다.
- AdvancedCacheLoader를 구현하지 않으면 해당 로더에 저장된 정보들이 프리로딩이나 맵리듀스 작업에 쓰이지 않게된다.
만약 현재 존재하는 스토어를 새로운 API로 이전하려한다면, SingleFileStore를 보는 것이 많은 도움이 될 것이다.
설정
마지막으로 스토어를 설정하는 방법이 바뀌었다.
- v5.x의 loader 엘리먼트는 persistence로 대체되었다.
- loader와 writer 둘 다 store 엘리먼트를 통해 설정된다. (v5.x에서는 loader와 store 엘리먼트가 있었다.)
- preload와 shared 속성이 각 스토어에 설정되어 복수의 스토어 체인을 설정할 때 더 유연함을 준다.
미르차(Mircea)
원문:
Monday, 16 September 2013, New persistence API in Infinispan 6.0.0.Alpha4
새로운 CacheLoader/CacheWriter API와 함께 인피니스팬 6.0.0.Alpha4가 나왔습니다!
(2013년 9월 9일) 인피니스팬 6.0.0.Alpha4가 아주 중요한 몇 개의 변경과 함께 나왔습니다. 특히 캐시 스토어와 관련이 있습니다. JSR-107과 좀 더 좋게 어울리기 위해(이전의 CacheStore가 CacheWriter로 변경), 그리고 새로운 구현을 쉽게 하기 위해 캐시스토어/로더 API를 완전히 개조하였습니다. 새로운 CacheLoader와 CacheWriter 인터페이스는 개발자가 구현할 때 중요한 동작에 집중하게 도와주고 코딩 시간을 줄입니다. 벌크 동작을 분리하거나 또는 선택적으로 구현하기를 바라는 그런 구현체들을 비우기 위해 AdvancedCacheLoader와 AdvancedCacheWriter도 만들었습니다. 미르차(Mircea)가 몇 일 안에 이 주제에 대해 자세히 설명하는 글을 올릴 예정입니다.
이번 인피니스팬 버전은 다른 몇 가지 것을 포함하고 있습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
감사합니다,
갤더(Galder)
원문:
Monday, 9 September 2013, Infinispan 6.0.0.Alpha4 out with new CacheLoader/CacheWriter API!
------------------
역자주. 원문은 2013년 9월 9일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
이번 인피니스팬 버전은 다른 몇 가지 것을 포함하고 있습니다.
- 인피니스팬 REST 클러스터 관련 업그레이드
- REST 동작을 위한 Cache-Control 헤더 지원
- 원격 질의 서버 모듈과 핫로드 클라이언트 갱신
- REST와 LevelDB 스토어를 인피니스팬 서버에 추가
- KeyFilters를 캐시 리스너에 적용 가능
- 캐시 리스너 이벤트를 주 데이터 소유자만 발생 가능하도록 함
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
감사합니다,
갤더(Galder)
원문:
Monday, 9 September 2013, Infinispan 6.0.0.Alpha4 out with new CacheLoader/CacheWriter API!
------------------
역자주. 원문은 2013년 9월 9일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
인피니스팬 6.0.0.Alpha3이 나왔습니다!
인피니스팬 커뮤니티 여러분께,
(2013년 8월 22일 현재) 인피니스팬 6.0.0의 마지막 알파버전을 발표합니다.
이번 릴리즈가 포함하는 것은,
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
댄
원문Thursday, 22 August 2013, Infinispan 6.0.0.Alpha3 is out!
------------------
역자주. 원문은 2013년 8월 22일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
(2013년 8월 22일 현재) 인피니스팬 6.0.0의 마지막 알파버전을 발표합니다.
이번 릴리즈가 포함하는 것은,
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
댄
원문Thursday, 22 August 2013, Infinispan 6.0.0.Alpha3 is out!
------------------
역자주. 원문은 2013년 8월 22일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
인피니스팬 6.0.0.Alpha2가 나왔습니다!
인피니스팬 커뮤니티 여러분께,
(2013년 8월 5일 현재) 인피니스팬 6.0.0의 두번째 알파버전을 발표합니다. 그리고 이번 릴리즈 역시 아파치 소프트웨어 라이센스 버전 2.0을 사용합니다.
이번 릴리즈의 새로운 기능은,
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
댄
원문
Monday, 5 August 2013, Infinispan 6.0.0.Alpha2 is out!
------------------
역자주. 원문은 2013년 8월 5일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
(2013년 8월 5일 현재) 인피니스팬 6.0.0의 두번째 알파버전을 발표합니다. 그리고 이번 릴리즈 역시 아파치 소프트웨어 라이센스 버전 2.0을 사용합니다.
이번 릴리즈의 새로운 기능은,
- 내장/원격 두 가지 모드와 핫로드 상에서 사용가능한 새로운 질의 DSL
- JSR-107의 공개 리뷰 드래프트 버전인 JCache 0.8 지원
- 필수적이지 않은 캐시스토어 구현체를 별도 저장소로 옮겨서 배포 크기를 줄임
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
댄
원문
Monday, 5 August 2013, Infinispan 6.0.0.Alpha2 is out!
------------------
역자주. 원문은 2013년 8월 5일에 작성되었으며 2013년 10월 4일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
더 빠른 (부가적 의존성 없는) 파일 캐시 스토어
어제(2013.7.17) 아드리안이 발표하였듯이, 새로운 인피니스팬 6.0.0.Alpha1는 부가적인 의존성을 필요로 하지 않는 새로운 파일 기반 캐시스토어를 포함한다. 이는 의도한 대로 동작하지 않았고, 그리고 생성하는 파일 개수 때문에 큰 문제를 발생시켰던 기존의 FileCacheStore를 완전히 대체한다.
이 새로운 캐시스토어는 (비동기 캐시스토어 향상에도 기여했던) 칼스텐 블리스(Karsten Blees)가 제공하였는데, SingleFileCacheStore라고 이름지어졌고 모든 데이터를 하나의 파일에 둔다. 키와 이 파일안에서 값들의 위치에 대한 인덱스를 메모리 유지하며 데이터를 찾는다. 이 설계는 기존의 FileCacheStore와 심지어는 LevelDB 기반 JNI 캐시스토어보다 성능이 좋다.
파일 기반 캐시스토어의 일반적인 용도는 메모리 크기나 시간 제약에 의해 메모리로부터 제거된 데이터를 로컬 캐시 스토어에 저장하려고 하는 것이다. 우리는 몇 개의 다른 캐시 스토어 구현체가 이 메모리로부터 넘쳐나오는 데이터를 읽고 쓰는 것을 얼마나 빠르게 처리하는지 테스트했고 결과는 아래와 같다.
그 차이는 매우 놀랍다. 하지만 위에서 힌트를 주었듯이 이 성능 향상을 위해서는 비용이 따른다. 메모리상에 파일 내 키와 위치의 인덱스를 유지 해야만 하기 위해 추가 메모리가 필요하고, 가비지 컬렉션에 대한 잠재적인 영향이 있을 수 있다는 것은 비용이 된다. 그래서 SingleFileCacheStore는 키가 아주 클 경우에는 추천하지 않는다.
이 메모리 소비 문제를 완화하기 위해, 캐시스토어의 크기는 저장할 엔트리의 최대 개수를 제공함으로써 선택적으로 제한될 수 있다. 하지만 이 파라미터는 인피니스팬이 캐시로 사용될 때만 동작한다. 캐시로 사용될 때, 인피니스팬에 있지 않은 데이터는 믿을만한 데이터 스토어로부터 재계산되거나 다시 불려와서 인피니스팬 캐시에 저장된다. 이 제약의 원인은, 일단 엔트리의 최대 개수가 도달되면, 캐시 스토어의 예전 데이터는 삭제된다. 그래서 만약 인피니스팬이 믿을만한 데이터 스토어로 쓰인다면 데이터를 잃어버리게 되고 이것은 좋지 않다.
기존의 FileCacheStore 사용자는 궁금해할 것이다. 기존 FileCacheStore은 어떻게 될 것인가? 아직은 어떻게 될지 확신할 수 없다. 하지만 FileCacheStore의 데이터를 SingleFileCacheStore로 이전하기 위한 방법이 있는지 찾고 있다. 벌써 몇 개의 흥미로운 아이디어를 받았고, 다음 인피니스팬 6.0 이전 릴리즈에 조사할 예정이다.
그래서 만약 FileCacheStore를 사용한다면, SingleFileCacheStore를 한 번 사용해보고 어떤지 우리에게 알려달라. 전환하는 것은 쉽다. ^^
갤더(Galder)
원문:
Thursday, 18 July 2013, Faster file cache store (no extra dependencies!) in 6.0.0.Alpha1
이 새로운 캐시스토어는 (비동기 캐시스토어 향상에도 기여했던) 칼스텐 블리스(Karsten Blees)가 제공하였는데, SingleFileCacheStore라고 이름지어졌고 모든 데이터를 하나의 파일에 둔다. 키와 이 파일안에서 값들의 위치에 대한 인덱스를 메모리 유지하며 데이터를 찾는다. 이 설계는 기존의 FileCacheStore와 심지어는 LevelDB 기반 JNI 캐시스토어보다 성능이 좋다.
파일 기반 캐시스토어의 일반적인 용도는 메모리 크기나 시간 제약에 의해 메모리로부터 제거된 데이터를 로컬 캐시 스토어에 저장하려고 하는 것이다. 우리는 몇 개의 다른 캐시 스토어 구현체가 이 메모리로부터 넘쳐나오는 데이터를 읽고 쓰는 것을 얼마나 빠르게 처리하는지 테스트했고 결과는 아래와 같다.
- FileCacheStore: 0.75k reads/s, 0.285k writes/s
- LevelDB-JNI impl: 46k reads/s, 15.2k writes/s
- SingleFileCacheStore: 458k reads/s, 137k writes/s
그 차이는 매우 놀랍다. 하지만 위에서 힌트를 주었듯이 이 성능 향상을 위해서는 비용이 따른다. 메모리상에 파일 내 키와 위치의 인덱스를 유지 해야만 하기 위해 추가 메모리가 필요하고, 가비지 컬렉션에 대한 잠재적인 영향이 있을 수 있다는 것은 비용이 된다. 그래서 SingleFileCacheStore는 키가 아주 클 경우에는 추천하지 않는다.
이 메모리 소비 문제를 완화하기 위해, 캐시스토어의 크기는 저장할 엔트리의 최대 개수를 제공함으로써 선택적으로 제한될 수 있다. 하지만 이 파라미터는 인피니스팬이 캐시로 사용될 때만 동작한다. 캐시로 사용될 때, 인피니스팬에 있지 않은 데이터는 믿을만한 데이터 스토어로부터 재계산되거나 다시 불려와서 인피니스팬 캐시에 저장된다. 이 제약의 원인은, 일단 엔트리의 최대 개수가 도달되면, 캐시 스토어의 예전 데이터는 삭제된다. 그래서 만약 인피니스팬이 믿을만한 데이터 스토어로 쓰인다면 데이터를 잃어버리게 되고 이것은 좋지 않다.
기존의 FileCacheStore 사용자는 궁금해할 것이다. 기존 FileCacheStore은 어떻게 될 것인가? 아직은 어떻게 될지 확신할 수 없다. 하지만 FileCacheStore의 데이터를 SingleFileCacheStore로 이전하기 위한 방법이 있는지 찾고 있다. 벌써 몇 개의 흥미로운 아이디어를 받았고, 다음 인피니스팬 6.0 이전 릴리즈에 조사할 예정이다.
그래서 만약 FileCacheStore를 사용한다면, SingleFileCacheStore를 한 번 사용해보고 어떤지 우리에게 알려달라. 전환하는 것은 쉽다. ^^
갤더(Galder)
원문:
Thursday, 18 July 2013, Faster file cache store (no extra dependencies!) in 6.0.0.Alpha1
2013년 10월 3일 목요일
인피니스팬 6.0.0.Alpha1이 나왔습니다!
인피니스팬 커뮤니티 여러분께,
(2013년 7월 17일 현재) 인피니스팬 6.0.0의 첫번째 알파버전을 발표합니다. 이번 릴리즈부터 인피니스팬 라이센스는 아파치 소프트웨어 라이센스 버전 2.0으로 전환됩니다.
약 30개의 버그 해결로 안정성이 증가한 한편, 이번 릴리즈는 다음과 같은 새로운 기능을 포함하고 있습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
아드리안
원문:
Wednesday, 17 July 2013, Infinispan 6.0.0.Alpha1 is out!
------------------
역자주. 원문은 2013년 7월 17일에 작성되었으며 2013년 10월 3일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
(2013년 7월 17일 현재) 인피니스팬 6.0.0의 첫번째 알파버전을 발표합니다. 이번 릴리즈부터 인피니스팬 라이센스는 아파치 소프트웨어 라이센스 버전 2.0으로 전환됩니다.
약 30개의 버그 해결로 안정성이 증가한 한편, 이번 릴리즈는 다음과 같은 새로운 기능을 포함하고 있습니다.
- 더 효율적인 FileCacheStore 구현체 (Karsten Blees가 제공)
- CloudTM 프로젝트 범위에서 개발된 새로운 사용과 성능 통계에 관한 확장
- protobuf에 기한한 새롭고 실험적인 핫로드(Hot Rod) 마샬러. 이것은 주로 새로운 원격 질의 기능에 의해 사용될 예정이며, 다른 프로젝트에 의해 재사용될 여지가 있으므로 인피니스팬 아래에 protostream이라는 이름의 독립 프로젝트로 격상되었습니다.
이번 릴리즈에 포함된 기능과 수정된 버그 등의 완전한 리스트를 확인하려면 릴리즈 노트를 참고하세요. 최근 릴리즈를 찾으려면 다운로드 페이지를, 질문을 하기 위해서는 포럼이나 메일링 리스트를 확인하거나 또는 IRC에서 직접 우리를 찾으면 됩니다.
관련되거나 기여해주신 모든 분들께 감사드립니다.
아드리안
원문:
Wednesday, 17 July 2013, Infinispan 6.0.0.Alpha1 is out!
------------------
역자주. 원문은 2013년 7월 17일에 작성되었으며 2013년 10월 3일 현재 인피니스팬 6.0.0.Beta2가 나온 상태입니다.
인피니스팬, 아파치 소프트웨어 라이센스 채택
인피니스팬 6.0부터 이 프로젝트는 현재의 LPGL(GNU Lesser General Public License) 라이센스 v.2.1에서 아파치 라이센스(Apache License) 라이센스 v.2.0으로 옮겨간다.
약간의 제약이 있는 LPGL에서 좀 더 자유로운 아파치 라이센스로 전환하는 것은 인피니스팬을 LPGL이 아닌 오픈소스로 통합하고자하는 다양한 오픈소스 커뮤니티의 계속적인 요청에 대한 응답이다. 좀 더 자유로운 라이센스로 인피니스팬 커뮤니티와 그 생태계가 넓어지게 될 것이다.
여러분들의 궁금증을 위해 아래에 간단히 FAQ를 더한다.
(Q) 여전히 오픈소스인가?
(A) 그렇다. 인피니스팬 소스코드는 앞으로도 항상 열려있고 자유로운 접근이 가능할 것이다.
(Q) 비지니스 친화적인가?
(A) 아파치 라이센스는 보통 LPGL보다 더 비지니스 친화적이라 여겨진다.
(Q) 기존의 사용자들에게는 어떠한 영향이 있는가?
(A) 영향이 없다. 자유롭게 쓰고, 프로젝트에 기여(contribute)하고 참여(participate) 할 수 있다.
(Q) 컨트리뷰터에게는 영향이 있나?
(A) JBoss 컨트리뷰터 라이센스 동의(JBoss Contributor License Agreement)에 의거하여, 인피니스팬에 대한 모든 과거의 기여물들은 아파치 라이센스로 바뀌게 된다. 이후로의 기여도 역시 아파치 라이센스 아래에 있게 된다.
이 라이센스 변경은 강력하고 포괄적인 오픈소스 커뮤니티를 만들고 유지하기 위한 우리의 계속적인 노력의 한 부분이다. 이 움직임과 관련하여 여러분들이 우리와 함께하길 바란다.
인피니스팬 팀을 대표하여,
마닉 술타니(Manik Surtani)
원문: Tuesday, 28 May 2013, Infinispan to adopt the Apache Software License
약간의 제약이 있는 LPGL에서 좀 더 자유로운 아파치 라이센스로 전환하는 것은 인피니스팬을 LPGL이 아닌 오픈소스로 통합하고자하는 다양한 오픈소스 커뮤니티의 계속적인 요청에 대한 응답이다. 좀 더 자유로운 라이센스로 인피니스팬 커뮤니티와 그 생태계가 넓어지게 될 것이다.
여러분들의 궁금증을 위해 아래에 간단히 FAQ를 더한다.
(Q) 여전히 오픈소스인가?
(A) 그렇다. 인피니스팬 소스코드는 앞으로도 항상 열려있고 자유로운 접근이 가능할 것이다.
(Q) 비지니스 친화적인가?
(A) 아파치 라이센스는 보통 LPGL보다 더 비지니스 친화적이라 여겨진다.
(Q) 기존의 사용자들에게는 어떠한 영향이 있는가?
(A) 영향이 없다. 자유롭게 쓰고, 프로젝트에 기여(contribute)하고 참여(participate) 할 수 있다.
(Q) 컨트리뷰터에게는 영향이 있나?
(A) JBoss 컨트리뷰터 라이센스 동의(JBoss Contributor License Agreement)에 의거하여, 인피니스팬에 대한 모든 과거의 기여물들은 아파치 라이센스로 바뀌게 된다. 이후로의 기여도 역시 아파치 라이센스 아래에 있게 된다.
이 라이센스 변경은 강력하고 포괄적인 오픈소스 커뮤니티를 만들고 유지하기 위한 우리의 계속적인 노력의 한 부분이다. 이 움직임과 관련하여 여러분들이 우리와 함께하길 바란다.
인피니스팬 팀을 대표하여,
마닉 술타니(Manik Surtani)
원문: Tuesday, 28 May 2013, Infinispan to adopt the Apache Software License
한국어 인피니스팬 블로그
이 블로그는 공식 인피니스팬 블로그(infinispan.blogspot.com)의 포스팅의 일부를 한국어로 제공합니다.
또한 기회가 되는대로 한국 JBoss User Group의 인피니스팬 소모임에서 작성/ 번역하는 자료와 소식도 게시하려고 합니다.
흔쾌히 번역을 허락해준 인피니스팬 프로젝트 창시자 마닉 술타니와 현재 프로젝트 리더 미르차 마르커스에게 감사드립니다.
-----------------
This blog offers Korean translation of some articles on the official Infinispan blog.
Additionally, news from Infinispan study group under Korean JBoss User Group and postings written by the members of it will be posted from time to time.
Special thanks to Manik Surtani, the founder of Infinispan project, and Mircea Markus, the leader of the project, for permission to translate without any hesitation.
또한 기회가 되는대로 한국 JBoss User Group의 인피니스팬 소모임에서 작성/ 번역하는 자료와 소식도 게시하려고 합니다.
흔쾌히 번역을 허락해준 인피니스팬 프로젝트 창시자 마닉 술타니와 현재 프로젝트 리더 미르차 마르커스에게 감사드립니다.
-----------------
This blog offers Korean translation of some articles on the official Infinispan blog.
Additionally, news from Infinispan study group under Korean JBoss User Group and postings written by the members of it will be posted from time to time.
Special thanks to Manik Surtani, the founder of Infinispan project, and Mircea Markus, the leader of the project, for permission to translate without any hesitation.
피드 구독하기:
글 (Atom)