posted Nov 19, 2010, 12:39 AM by Kuwon Kang
IBM JZOS Batch Launcher User’s Guide |
posted Nov 19, 2010, 12:38 AM by Kuwon Kang
[
updated Nov 19, 2010, 12:42 AM
]
posted Nov 10, 2010, 9:09 PM by Kuwon Kang
| Advanced lb Worker properties | With JK 1.2.x, new load-balancing and fault-tolerant support has been added via 2 new properties, redirect and activation. Let's take an example environment: A cluster with two nodes (worker1+worker2), running a webserver + tomcat tandem on each node and a loadbalancer in front of the nodes. # The advanced router LB worker
worker.list=router
# Define a worker using ajp13
worker.worker1.port=8009
worker.worker1.host=node1.domain.org
worker.worker1.type=ajp13
worker.worker1.lbfactor=1
# Define prefered failover node for worker1
worker.worker1.redirect=worker2
# Define another worker using ajp13
worker.worker2.port=8009
worker.worker2.host=node2.domain.org
worker.worker2.type=ajp13
worker.worker2.lbfactor=1
# Disable worker2 for all requests except failover
worker.worker2.activation=disabled
# Define the LB worker
worker.router.type=lb
worker.router.balance_workers=worker1,worker2
The redirect flag on worker1 tells the lb_worker to redirect the requests to worker2 only if worker1 is in error state. In other cases worker2 will not receive any requests, thus acting like a hot standby.
|
|
posted Nov 10, 2010, 9:08 PM by Kuwon Kang
It's rather amazing that I could not find a single how-to that could detail the steps for using the Apache web server to load balance multiple Tomcat 5.5 instances on Windows. I found tons of articles- but they were either for older versions of Tomcat or Apache or for Unix flavors and none were accurate enough. Apache itself has fragmented documentation on the subject, and after much trial and error and pulling of hair, I succeeded. The least I can do is list the steps here for all others who have had trouble getting it right. The goal of this blog is to set up two Tomcat 5.5 instances with Apache in front, load balancing them. Please note that this does not cover clustering. I'll save that for another blog once I actually do it :-) Also, this is not a tutorial on load balancing. It will get you up and running- then you might want to look at the Tomcat documentation to find out what exactly all those options do. So, this is what you need to download: 1. Apache HTTP server 2.2.4 from The Apache HTTP Server Project. I prefer the zip over the Windows Installer. You are free to choose the Windows Installer if you wish, but modify the service instructions below accordingly. 2. Apache Tomcat 5.5.20 from Apache Tomcat downloads3. Mod JK Tomcat connector from here. Please note: You want to download the binary- click on JK 1.2 Binary Releases --> win32 --> jk-1.2.21 --> mod_jk-apache-2.2.4.so Now let's start by installing Tomcat first. 1. Extract the Tomcat zip. Hereafter, the directory you extracted to will be referred to as TOMCAT_HOME
2. Test Tomcat to see that it works. Go to TOMCAT_HOME\bin and run startup.bat You may need to add an environment variable called CATALINA_HOME which is set to TOMCAT_HOME in case Tomcat fails to start. 3. Open up your browser and access http://localhost:8080/ If you see the default page, then Tomcat Instance 1 is working fine. Shut down Tomcat. 4. Now set this up as a service. Go to your command prompt, change directory to TOMCAT_HOME\bin and set an environment variable called CATALINA_BASE. The value of this variable should again, be TOMCAT_HOME. For example:
SET CATALINA_BASE=C:\Tomcat-5.5.20
Then, execute the following: service install Tomcat5This will set up the Windows service for Tomcat. 5. Go to your Services and see that Tomcat 5 is listed. Start the service, and then verify again that http://localhost:8080 is up. That's all for the first Tomcat instance. Now for the second. 1. Make a directory called SecondInstance in TOMCAT_HOME
2. Copy the conf, logs, shared, temp, webapps and work directories from the TOMCAT_HOME directory into the SecondInstance directory. 3. Open up SecondInstance\conf\server.xml in a text editor. We've got to change the port numbers so that they don't conflict with the first instance. I just incremented by 10 and changed them as follows, but you could use other port numbers:
to
to
to
Change the SSL port if you need it as well.4. Now set up the second instance to run as a service. Go to the command prompt, change to the TOMCAT_HOME\bin directory. Set the CATALINA_BASE environment variable to TOMCAT_HOME\SecondInstance. For example: SET CATALINA_BASE=C:\Tomcat5.5.20\SecondInstanceThen, type: service install SecondTomcatGo to Services and start the SecondTomcat service. Test it out by pointing your browser to http://localhost:8090/ Works ok? Great! Your second tomcat instance is now ready to be used. Next, let's set up the Apache HTTP Server. It's pretty simple... 1. Run the installer you downloaded. The standard install will do. 2. Open the Apache Server Monitor and start the web server if it's not already running. 3. Point your browser to http://localhost/ to verify that Apache is running on port 80. 4. Stop Apache. Finally, we reach mod JK. Let's set it up first just to delegate requests to the two Tomcat instances, and we'll load balance it a bit later. 1. Copy the mod_jk-apache-2.2.4.so to the modules directory in your Apache installation. 2. Rename it to mod_jk.so 3. Open up httpd.conf in the conf directory of your Apache installation in a text edit, and add the following line at the end of the set of LoadModule statements: LoadModule jk_module modules/mod_jk.so4. Create a file called workers.properies in the conf directory. Add these lines to it: workers.tomcat_home=C:/tomcat-5.5.20
workers.java_home=C:/jdk1.5.0_03
worker.list=worker1,worker2worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker2.port=8019
worker.worker2.host=localhost
worker.worker2.type=ajp13This file defines which workers Apache can delegate to. We've listed worker1 and worker 2 to correspond to our two tomcat instances. Remember to set tomcat_home and java_home as well. 5. Specify the worker properties in httpd.conf: Add these lines just after the LoadModule definitions- # Path to workers.properties
JkWorkersFile c:/apache2.2/conf/workers.properties
# Path to jk logs
JkLogFile c:/apache2.2/mod_jk.log
# Jk log level [debug/error/info]
JkLogLevel info
# Jk log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions for forwarding
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"
JkMount /jsp-examples worker1
JkMount /jsp-examples/* worker1
JkMount /tomcat-docs worker2
JkMount /tomcat-docs/* worker2Defining these tells Apache where to look for definitions of its workers and tells it that any requests for the jsp-examples context should be handed off to the Tomcat instance represented by worker 1, and any requests for tomcat-docs context should be handed off to Tomcat Instance 2, represented by worker 2. 5.5 [Added on April 11 2007]Edit the server.xml for Tomcat and Tomcat's SecondInstance and add a jvmRoute attribute to the Engine element: for the first instance and for the second. 6. Start Tomcat Instance 1 and 2. Start up the Apache webserver. Point your browser to http://localhost/jsp-examples/ and then to http://localhost/tomcat-docs. You should see the respective pages load. To distinguish which Tomcat is serving you the page, the easiest thing to do is edit the index page in the tomcat-docs and jsp-examples of Tomcat 2 and change the title for example. Then you can verify that tomcat-docs is being served only by the second instance. Thats it!! Apache is now delegating requests to both Tomcats. Now for our last task- we will load balance it so that Apache distributes load for jsp-examples between both instances of Tomcat. It also serves as a failover mechanism. If Tomcat 1 is down for whatever reason, Apache will automatically keep delegating to Tomcat 2 so your application remains accessible. Load balancing is a simple configuration. First shut down your Tomcat instances and Apache as well. 1. Open workers.properties in a text editor. 2. Edit it so it looks like this (changed lines in bold)- workers.tomcat_home=C:/tomcat-5.5.20workers.java_home=C:/jdk1.5.0_03#worker.list=worker1,worker2
worker.list=balancer
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker1.lbfactor=1
worker.worker2.port=8019
worker.worker2.host=localhost
worker.worker2.type=ajp13
worker.worker2.lbfactor=1
worker.balancer.type=lb
worker.balancer.balance_workers=worker1,worker2
worker.balancer.method=B
We've changed the worker list to a single worker called balancer, and specified that the worker type of balancer is 'lb' or load balancer. The workers it manages are worker1 and worker2 (these do not need to appear in the workers list). And finally, we set the balance method to 'B' or balance by busy factor. Apache will delegate the next request to the Tomcat instance which is least busy. Please note that there are a couple of options for method- consult the Apache/Tomcat documentation which lists out options for workers properties to help you decide the best method for your type of application. 3. Open httpd.conf and comment out the previous JkMount directives. Replace them with these: JkMount /jsp-examples balancer
JkMount /jsp-examples/* balancerVery simple- we've just pointed Apache to a single worker- the balancer. 4. Start up both Tomcats and Apache. Access http://localhost/jsp-examples You will either be served by Tomcat 1 or Tomcat 2. To prove that both are capable of serving, shut down the first instance and refresh your browser. You should be served by instance two. Congratulations! You've successfully set up Apache load balancing multiple tomcat instances! SOURCE:- thought-bytes.blogspot.com |
posted Jun 20, 2010, 9:16 PM by Kuwon Kang
웹2.0 시대의 서비스 개념과 철학
웹2.0 시대에서 서비스 철학이 가져다 주는 의미
박민우(디아이지커뮤니케이션 이사) 2008/02/04 서비스 개념과 서비스 철학의 차이에 대해서 논하기에 앞서 많은 사람들이 개념과 철학에 대해서 혼돈해서 얘기하는 경우가 많다. 그래서 좀 더 명확하게 개념과 철학의 사전적인 의미부터 다시 정리할 필요가 있을 것 같다. 우선, 개념 [槪念, concept]은 어떤 집합에서 공통적인 성질을 빼내서 새로 만든 관념을 의미한다. 예를 들어 개 고양이 새 물고기의 공통적인 성질을 뽑아서 동물이라는 개념을 만들 수 있다. 웹2.0에서 개방, 참여, 공유라는 용어는 웹2.0 이전 시대와 비교해서 만들어진 웹2.0 시대의 공통적인 성질을 뽑았을 때 발견되는 현상이고, 이 현상을 묶어서 웹 2.0이란 개념이 완성되었다고 볼 수 있다. 이러한 의미에서 개념은 지식이라는 의미와 비슷하게 사용된다. 새로운 사항에 대해서 경험을 거듭하여 그 사항에 대해서 잘 알고 통하게 되는 경우 우리는 개념을 파악했다라고 표현하기도 한다. 그렇다면 철학은 개념과 어떤 차이가 있는가?
철학 [哲學, philosophy]은 고등학교 때 배웠듯이 "지적 호기심" 또는 “지혜에 대한 사랑" 등으로 정의된다. 하지만 물리학, 경제학 등 다른 학문들과 달리 철학은 무엇을 연구하는 학문인지 짐작 하기가 쉽지 않다. 그 이유는 이 학문의 대상이 결코 일정하지 않기 때문이다. 그렇다면 웹2.0에 대한 학문적 탐구를 우리는 웹2.0 철학이라고 얘기할 수 있는가? 물론 어떤 사물이나 현상에 대해서 학문적인 접근이나 탐구를 하지 못할 이유는 없을 것이다. 하지만 그 이전에 기존에 기 확립된 다른 학문들과 비교하여 학문적 가치에 대해서 고민을 해봐야 할 것이다. 그래서 철학이라는 용어를 사용하기 위해서는 좀더 많은 시간과 경험을 토대로 하여 학문적 가치를 이끌어내야 가능할 것이다. 서비스 개념과 서비스 철학
필자가 서두에 개념과 철학에 대해서 진부하게 재정의를 내린 이유는 서비스 철학과 서비스 개념에 대해서 얘기를 하고 싶기 때문이다. 우리는 고객 만족을 추구하는 서비스를 경험하면서 "oo음식점은 종업원들이 서비스 개념이 있어"라고 얘기하는 경우가 있다. 이러한 용어의 표현은 oo음식점의 종업들이 서비스에 대한 공통적인 성질에 대해서 충분한 이해를 하고 있다는 뜻이다. 그리고 그러한 행동의 결과는 고객들의 판단으로 확인된다. 하지만 서비스 철학은 다르다. 서비스 철학은 서비스를 제공하는 주체가 스스로 자기 확신을 가지고 그 사상을 서비스에 포함시켜서 나타나는 현상이다. 예를 들어 "xx 음식점은 맛은 있는데 서비스가 불친절해, 하지만 그 주인이 10년째 그 방식을 고집하고 있대"라는 표현에서 우리는 xx 음식점이 나름대로의 서비스 철학을 가지고 있다고 표현한다. 즉 오래된 시간과 경험을 통해서 인지되는 현상이고 고객이 그 현상을 이해하는 것이다. 웹2.0 시대에서 서비스 개념
다시 본론으로 돌아와서 웹2.0 시대 이후 이전보다 많은 사람들이 서비스를 개발하고 운영한다. 심지어는 full-time 블로거가 하나의 직업으로 인식되고 있는 시대에 살고 있다. 늘어나는 서비스들을 보면서 어떤 서비스는 개념조차 정리되지 않은 서비스가 있는가 하면, 어떤 서비스는 잘 만들어지긴 했지만 자신들의 서비스 철학이 없는 클론 서비스로 남기도 한다. 웹2.0에서 서비스 개념은 어떻게 이해할 것인가? 필자 역시 2년 전부터 웹2.0 관련하여 많은 강의를 하면서 지식의 정리는 충분히 되었다고 생각했지만, 실제로 개념을 정리하는 데는 보다 많은 시간이 필요했었다. 즉 웹2.0 관련 정보를 습득하고 지식들을 수집한다고 해서 개념 확립이 되지는 않더라는 것이다. 개념 확립을 위해서는 눈과 손으로 직접 경험을 하지 않고는 느끼기 힘든 부분이 존재한다. 그래서 블로그든 SNS든 UCC든 스스로가 파워유저가 되지 않으면, 남이 정의해준 개념을 지식으로 받아 들일뿐 스스로의 개념 확립은 어렵다고 본다. 이러한 개념을 정리하는데 있어서 에자일(Agile) 방법론은 그 효과가 분명하다는 생각이 든다. 에자일은 영어로 '민첩한' '재빠른' 이라는 뜻을 가진 단어이며 인터넷 업계에서는 경영환경의 변화에 신속하게 대처할 수 있는 유연한 인터넷 서비스의 효율적인 시스템이나 개발 프로세스를 뜻한다. 이 방법론이 좋은 이유는 짧은 시간에 효과적으로 서비스 개념을 파악할 수 있다는 장점이 있다. 기존 개발 방법론은 완성된 프로그램을 업데이트 한다라는 개념으로 접근을 하였지만, 에자일은 시대의 흐름에 맞춰서 서비스를 진화시키는 방식이기 때문에 기존의 프로그램에 대한 접근에서 서비스에 대한 접근으로 그 시각을 바꾸어주는 효과가 있다. 그래서 에자일에서는 서비스 완성이라는 목표점이 없기 때문에 버전을 필요로 하지 않는다. 100% 완성되지 않은 시점에서 서비스를 오픈하는 이유는 아무리 좋은 기획과 설계로 완성된 서비스라고 하더라도 만드는 사람의 상상력에는 한계가 있기 때문이다. 그래서 빨리 공개하고 고객들과 커뮤니케이션 하는 것이 서비스의 완성도를 높일 수 있다. 그리고 이러한 프로세스의 정립과 커뮤니케이션 과정이 바로 서비스 개념을 확립시킬 수 있는 좋은 도구가 된다. 웹 2.0 시대에서 서비스 철학
많은 서비스에 대한 경험과 지식을 통해서 쌓여진 서비스 개념을 기반으로 좋은 서비스를 만들 수 있다. 하지만 “좋은 서비스”와 “성공한 서비스”의 차이에는 서비스 철학이라는 것이 존재한다. 성공한 서비스 개념들, 예를 들면 네이버 지식인, 싸이월드, 블로그 등은 개발자의 관점에서 본다면 어째든 변형된 게시판 프로그램들 일 뿐이다. 그 난이도와 대용량 처리에 대한 수준만 다를 뿐이지 새로운 개념의 프로그램은 아닌 것이다. 하지만 게시판이 서비스 철학과 만날 때는 새로운 혁명을 일으키기도 한다. 서비스 철학의 유무가 아마추어와 프로를 구분하는 기준이기도 하다. 물론 서비스 철학을 가지고 있다고 해서 모든 서비스가 성공한다는 것은 아니다. 하지만 최소한 서비스 철학이 없는 서비스가 성공하기는 힘들다는 얘기를 하는 것이다. 최근에 웹 기반 프로젝트 관리 툴로 유명한 BaseCamp를 개발한 37singanls에서 출판된 "Getting Real" 이란 페이퍼는 서비스 철학에 대해서 많은 생각을 가지게 해준다. 원래 이 페이퍼의 목적은 보다 작고, 빠르고, 좋은 소프트웨어 구축을 위한 방법론이다. 하지만 그 이상의 가치로서, 이 페이퍼는 새로운 서비스를 세상에 내 놓는 과정에서 준비해야 될 많은 사상적인 부분들까지 이해하기 쉽게 제시하고 있다. Getting Real의 주요 내용을 요약하면 다음과 같다. * 열정은 돈으로 바꿀 수 없다. 투자 유치보다 스스로의 자금으로 시작하라.
* 한정된 자원으로 시작할 경우, 많은 제약이 따르고 제약은 혁신을 일으킨다.
* 일정과 예산을 늘리지 말고 범위를 축소시켜라. 기회는 얼마든지 온다.
* 조직을 작게 유지하라. 하나의 서비스는 3명이 팀을 이루어서 개발한다.
* 확장에 대한 고민은 나중에 하라. 그 시점이 되면 어차피 다시 설계해야 한다.
* 반은 엉망인 제품을 만들지 말고. 반만 만들어도 제대로 만들어라.
* 잘못된 결정을 두려워하지 마라. 우리는 지금 뇌수술을 하는 것이 아니라 그냥 웹 페이지를 만들고 있을 뿐이다. 요약된 내용 중에 주목할 만한 것은 서비스에 대한 구체적인 목적뿐만 아니라 그 구성원이 공통적으로 지녀야 할 덕목과 궁극적으로 가야 할 분명한 목표를 포함하고 있다. 이러한 사상들을 자신들의 서비스 방향과 충분히 접목되어 하나의 사상으로 정리가 될 때 우리는 서비스 철학을 갖추었다고 감히 얘기할 수 있을 것이다. 좋은 서비스 철학이든 그렇지 않은 서비스 철학이든 이것은 서비스를 운영하고 성공시킬 수 있는 근원적인 힘이 되어준다. 그래서 모든 서비스에는 서비스 철학이 필요하다. 스티브 잡스가 아이팟을 개발할 때 많은 관련자들이 어떤 기능이 제공되는지 어떤 기능을 추가할 계획이 있는지 쉴 새 없이 물었다. 잡스는 이렇게 대답했다고 한다. "우리는 수 천 개의 기능을 원하지 않습니다. 혁신은 정말 중요한 것을 제외한 나머지에 대해서 '아니오'라고 말하는 것 입니다" 그래서 기능의 추가에는 노력이 필요하고 불필요한 기능을 제거하는 데는 용기가 필요하다. @ |
posted Jun 20, 2010, 9:14 PM by Kuwon Kang
As the Internet becomes a primary mechanism for conducting business in the 21st
century, the scalability, maintainability, versatility, and availability of commerce systems become
chief concerns. IT departments will not be able to successfully adapt to changes in technology
and business if commerce systems are not designed with enough flexibility. The failure of a
commerce site could mean millions of dollars in lost revenues, which is unacceptable in today's fast-paced economy. 상당히 와닫는 설명이다. 21세기 엔터프라이즈 시스템의 치명적인 오류는 수억원에서 수십억원까지 막대한 손해 비용을 치른다. 요즘 이 모습을 종종 보곤한다... |
posted Jun 20, 2010, 9:12 PM by Kuwon Kang
 |
|
|
|
|
|
| Java theory and practice: Are all stateful Web applications broken?
The session state management mechanism provided by the Servlets framework, HttpSession, makes it easy to create stateful applications, but it is also quite easy to misuse. Many Web applications that use HttpSession for mutable data (such as JavaBeans classes) do so with insufficient coordination, exposing themselves to a host of potential concurrency hazards. |
|
Articles |
|
23 Sep 2008 |
|
|
| Java theory and practice: Going wild with generics, Part 2
Wildcards can be very confusing when it comes to generics in the Java language, and one of the most common mistakes is to fail to use one of the two forms of bounded wildcards ("super T" and "? extends T") when needed. You've made this mistake? Don't feel bad, even the experts have, and this month Brian Goetz shows you how to avoid it. |
|
Articles |
|
01 Jul 2008 |
|
|
| Java theory and practice: Going wild with generics, Part 1
One of the most complicated aspects of generics in the Java language is wildcards, and in particular, the treatment and confusing error messages surrounding wildcard capture. In this installment of Java theory and practice, veteran Java developer Brian Goetz deciphers some of the weirder-looking error messages emitted by javac and offers some tricks and workarounds that can simplify using generics. |
|
Articles |
|
06 May 2008 |
|
|
| Java theory and practice: Stick a fork in it, Part 2
One of the additions to the java.util.concurrent packages coming in Java 7 is a library for fork-join-style parallel decomposition. In part one of this series, author Brian Goetz shows how fork-join provides a natural mechanism for decomposing many algorithms to effectively exploit hardware parallelism. In this article, he'll cover the ParallelArray classes, which simplify parallel sorting and searching operations on in-memory data structures. |
|
Articles |
|
04 Mar 2008 |
|
|
| Java theory and practice: Stick a fork in it, Part 1
One of the additions to the java.util.concurrent packages coming in Java 7 is a framework for fork-join style parallel decomposition. The fork-join abstraction provides a natural mechanism for decomposing many algorithms to effectively exploit hardware parallelism. The next installment in this series covers the ParallelArray classes, which simplify parallel sorting and searching operations on in-memory data structures. |
|
Articles |
|
13 Nov 2007 |
|
|
| Java theory and practice: Managing volatility
The Java language contains two intrinsic synchronization mechanisms: synchronized blocks (and methods) and volatile variables. Both are provided for the purpose of rendering code thread-safe. Volatile variables are the weaker (but sometimes simpler or less expensive) of the two -- but also easier to use incorrectly. In this installment of Java theory and practice, Brian Goetz explores some patterns for using volatile variables correctly and offers some warnings about the limits of its applicability. |
|
Articles |
|
19 Jun 2007 |
|
|
| Java theory and practice: The closures debate
Everyone has a favorite feature idea or two for adding to the Java language. With the open-sourcing of the Java platform and the rise in popularity of other languages for server-side applications (JavaScript and Ruby, to name two), the debate over the future of the Java language has never been more vigorous. Should the Java language embrace major new additions, such as closures? Or is that too much messing with a good thing? In this month's Java theory and practice, Brian Goetz reviews the concepts involved and provides details on the two competing closures proposals. |
|
Articles |
|
24 Apr 2007 |
|
|
| Java theory and practice: Using Java 5 language features in earlier JDKs
Java 5 added a number of powerful language features: generics, enumerations, annotations, autoboxing, and the enhanced for loop. However, many shops are still tied to JDK 1.4 or earlier and may be for some time to come. But it's still be possible for those developers to take advantage of these powerful language features while continuing to deploy on earlier JVMs. Brian Goetz returns from his hiatus in this installment of Java theory and practice to demonstrate how. |
|
Articles |
|
27 Feb 2007 |
|
|
| Java theory and practice: Instrumenting applications with JMX
Debuggers and profilers can provide insight into an application's behavior, but we usually only break out these tools when there's a serious problem. Building monitoring hooks into an application can make it easier to understand what your programs are doing without breaking out the debugger. Now that Java Management Extensions (JMX) is built into the Java SE platform, and the jconsole viewer provides a universal monitoring GUI, using JMX to provide a window into your application is easier and more effective than ever. |
|
Articles |
|
19 Sep 2006 |
|
|
| Java theory and practice: Testing with leverage, Part 3
The first two installments in this series showed how static analysis tools like FindBugs can provide greater leverage in managing software quality by focusing on entire categories of bugs rather than on specific bug instances. In this final installment on testing, Brian Goetz examines another technique for smoking out bugs that violate design rules: aspects. |
|
Articles |
|
22 Aug 2006 |
|
|
| Java theory and practice: Testing with leverage, Part 2
June's Java theory and practice column demonstrated how static analysis tools like FindBugs can bring greater leverage to bear on managing software quality by focusing on entire categories of bugs rather than on specific bug instances. In this month's installment, resident exterminator Brian Goetz details the process of constructing and tuning a nontrivial bug pattern detector. |
|
Articles |
|
25 Jul 2006 |
|
|
| Java theory and practice: Testing with leverage, Part 1
Back in June 2004, veteran exterminator Brian Goetz introduced the FindBugs static code analysis tool, which can detect bugs even in well-tested software. This month, he revisits that topic and looks at how static analysis tools can change the way you manage software quality by aiming development resources at entire classes of bugs rather than specific instances. |
|
Articles |
|
20 Jun 2006 |
|
|
| Java theory and practice: Dealing with InterruptedException
Many Java language methods, such as Thread.sleep() and Object.wait(), throw InterruptedException. You can't ignore it because it's a checked exception, but what should you do with it? In this month's Java theory and practice, concurrency expert Brian Goetz explains what InterruptedException means, why it is thrown, and what you should do when you catch one. |
|
Articles |
|
23 May 2006 |
|
|
| Java theory and practice: Introduction to nonblocking algorithms
Java 5.0 makes it possible for the first time to develop nonblocking algorithms in the Java language, and the java.util.concurrent package uses this capability extensively. Nonblocking algorithms are concurrent algorithms that derive their thread safety not from locks, but from low-level atomic hardware primitives such as compare-and-swap. Nonblocking algorithms can be extremely difficult to design and implement, but they can offer better throughput and greater resistance to liveness problems such as deadlock and priority inversion. In this installment of Java theory and practice, concurrency guru Brian Goetz illustrates how several of the simpler nonblocking algorithms work. |
|
Articles |
|
18 Apr 2006 |
|
|
| Java theory and practice: Good housekeeping practices
Garbage collection is nearly everyone's favorite feature of the Java platform; it simplifies development and eliminates entire categories of potential code errors. But while garbage collection generally allows you to ignore resource management, sometimes you have to do some housekeeping on your own. In this month's Java theory and practice, Brian Goetz discusses the limitations of garbage collection and identifies situations when you have to do your own housecleaning. |
|
Articles |
|
21 Mar 2006 |
|
|
| Java theory and practice: The pseudo-typedef antipattern
The addition of generics to the Java language complicated the type system and increased the verbosity of many variable and method declarations. Because no "typedef" facility was provided for defining short names for types, some developers have turned to extension as a "poor man's typedef," with less than good results. In this month's Java theory and practice, Java expert Brian Goetz explains the limitations of this "antipattern." |
|
Articles |
|
21 Feb 2006 |
|
|
| Java theory and practice: Plugging memory leaks with soft references
In the previous installment of Java theory and practice, Java sanitation engineer Brian Goetz examined weak references, which let you put the garbage collector on notice that you want to maintain a reference to an object without preventing it from being garbage collected. This month, he explains another form of Reference object, soft references, which can also enlist the aid of the garbage collector in managing memory usage and eliminating potential memory leaks. |
|
Articles |
|
24 Jan 2006 |
|
|
| Java theory and practice: Plugging memory leaks with weak references
While programs in the Java language are theoretically immune from "memory leaks," there are situations in which objects are not garbage collected even though they are no longer part of the program's logical state. This month, sanitation engineer Brian Goetz explores a common cause of unintentional object retention and shows how to plug the leak with weak references. |
|
Articles |
|
22 Nov 2005 |
|
|
| Java theory and practice: Synchronization optimizations in Mustang
In the September installment of Java theory and practice, columnist Brian Goetz examined escape analysis, an optimization that has been on the "to-do" list for many JVMs for quite some time and which is expected in HotSpot in the Mustang (Java SE 6) release. Escape analysis can be used to convert heap-based object allocation into the less-expensive, stack-based allocations, but it can also be used to make other optimization decisions as well, including optimizing the use of synchronization. This month Brian introduces some of the synchronization optimizations slated for Mustang. Note: This column describes features of a future version of Sun's HotSpot JVM implementation. Specific features discussed herein may or may not appear in Java SE 6 ("Mustang"); some may be delayed until Java SE 7 ("Dolphin"). |
|
Articles |
|
18 Oct 2005 |
|
|
| Java theory and practice: Urban performance legends, revisited
The Java language is the target of a lot of abuse for performance. And while some of it may well be deserved, a tour of message board and newsgroup postings on the subject shows that there is a great deal of misunderstanding about how a Java Virtual Machine (JVM) actually works. In this month's Java theory and practice, Brian Goetz pokes some holes in the oft-repeated performance myth of slow allocation in JVMs. |
|
Articles |
|
27 Sep 2005 |
|
|
| Java theory and practice: Decorating with dynamic proxies
The dynamic proxy facility, part of the java.lang.reflect package and added to the JDK in version 1.3, allows programs to create proxy objects, which can implement one or more known interfaces and dispatch calls to interface methods programmatically using reflection instead of using the built-in virtual method dispatch. This process allows implementations to "intercept" method calls and reroute them or add functionality dynamically. This month, Brian Goetz explores several applications for dynamic proxies. |
|
Articles |
|
30 Aug 2005 |
|
|
| Java theory and practice: Be a good (event) listener
The Observer pattern, most often seen in Swing development, is also very useful for decoupling components in situations other than GUI applications. However, some common pitfalls with registering or invoking listeners exist. In this installment of Java theory and practice, Java therapist Brian Goetz offers some feel-good advice on how to be a good listener -- and how to be nice to your listeners, too. |
|
Articles |
|
26 Jul 2005 |
|
|
| Java theory and practice: Make database queries without the database
When you have a hammer, everything looks like a nail (as the old saying goes). But what if you don't have a hammer? Well, sometimes, you can borrow a hammer. Then, hammer in hand, you can bang the virtual nails with the borrowed hammer, return it, and no one is the wiser. In this month's Java theory and practice, Brian Goetz demonstrates how data manipulation hammers such as SQL or XQuery can be applied to ad-hoc data. |
|
Articles |
|
31 May 2005 |
|
|
| Java theory and practice: Enable initialization atomicity
Decisions made during API design can have an effect on the API's usability. In designing an API, you need to put yourself in your user's shoes, imagining how the API might be used, and try and make the common use cases convenient for the user. This month, columnist Brian Goetz discusses an API design technique, the self-return idiom, that can make life easier for users of your API in certain circumstances. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. |
|
Articles |
|
27 Apr 2005 |
|
|
| Java theory and practice: Screen-scraping with XQuery
XQuery is a W3C standard for extracting information from XML documents, currently spanning 14 working drafts. While the majority of interest in XQuery is centered around querying large bases of semi-structured document data, XQuery can be surprisingly effective for some much more mundane uses as well. In this month's Java theory and practice, columnist Brian Goetz shows you how XQuery can be used effectively as an HTML screen-scraping engine. |
|
Articles |
|
22 Mar 2005 |
|
|
| Java theory and practice: Anatomy of a flawed microbenchmark
Software engineers are notoriously obsessed, sometimes excessively, with performance. While sometimes performance is the most important requirement in a software project, as it might be when developing protocol routing software for a high-speed switch, most of the time performance needs to be balanced against other requirements, such as functionality, reliability, maintainability, extensibility, time to market, and other business and engineering considerations. In this month's Java theory and practice, columnist Brian Goetz explores why it is so much harder to measure the performance of Java language constructs than it looks. |
|
Articles |
|
22 Feb 2005 |
|
|
| Java theory and practice: Generics gotchas
Generic types, added in JDK 5.0, are a significant enhancement to type safety in the Java language. However, some aspects of generics may seem confusing, or even downright bizarre, to first-time users. In this month's Java theory and practice, Brian Goetz examines the common pitfalls that ensnare first-time users of generics. |
|
Articles |
|
25 Jan 2005 |
|
|
| Java theory and practice: Dynamic compilation and performance measurement
Writing and interpreting performance benchmarks for dynamically compiled languages, such as Java, is far more difficult than for statically compiled languages like C or C++. In this installment of Java theory and practice, Brian Goetz explores a few of the many ways in which dynamic compilation can complicate performance testing. |
|
Articles |
|
21 Dec 2004 |
|
|
| Java theory and practice: Going atomic
Until JDK 5.0, it was not possible to write wait-free, lock-free algorithms in the Java language without using native code. The addition of the atomic variable classes in java.util.concurrent changes that situation. Follow along with concurrency expert Brian Goetz as he explains how these new classes have enabled the development of highly scalable nonblocking algorithms in the Java language. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. |
|
Articles |
|
23 Nov 2004 |
|
|
| Java theory and practice: More flexible, scalable locking in JDK 5.0
JDK 5.0 offers developers some powerful new choices for developing high-performance concurrent applications. For example, the ReentrantLock class in java.util.concurrent.lock is offered as a replacement for the synchronized facility of the Java language -- it has the same memory semantics, the same locking semantics, better performance under contention, and features not offered by synchronized. Does this mean that we should forget about synchronized, and instead use ReentrantLock exclusively? Concurrency expert Brian Goetz returns from his summer hiatus to supply the answer. |
|
Articles |
|
26 Oct 2004 |
|
|
| Java theory and practice: State replication in the Web tier
How state will be managed and replicated in a clustered server application has a significant impact on the scalability of the application. Many Java applications store state in the HttpSession provided by the Servlet API. This article examines some of the options for HttpSession replication and how to most effectively use HttpSession to provide good scalability and performance. |
|
Articles |
|
29 Jul 2004 |
|
|
| Java theory and practice: Kill bugs dead
The FindBugs tool is a powerful tool for auditing your code for compliance with good design practices and represents a huge step forward in the state-of-the-art of real-world code analysis tools. |
|
Articles |
|
29 Jun 2004 |
|
|
| Java theory and practice: The exceptions debate
When should you use checked versus unchecked exceptions in Java classes? The prevailing wisdom is to use checked exceptions in nearly all cases, but some Java luminaries have begun to think otherwise. This month, columnist Brian Goetz examines the exceptions debate and offers guidance on when and how to use unchecked exceptions. |
|
Articles |
|
25 May 2004 |
|
|
| Java theory and practice: Coaxing J2EE out of the container
Most projects fall squarely into either the category of J2EE application or J2SE application. However, there are a number of J2EE technologies that can exist outside of the J2EE container, and some J2SE applications may benefit from them. This month, Brian Goetz looks at how some J2EE services can be used in J2SE applications. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. |
|
Articles |
|
20 Apr 2004 |
|
|
| Java theory and practice: Fixing the Java Memory Model, Part 2
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM). In Part 1 of this series, columnist Brian Goetz focused on some of the serious flaws that were found in the original JMM, which resulted in some surprisingly difficult semantics for concepts that were supposed to be simple. This month, he reveals how the semantics of volatile and final will change under the new JMM, changes that will bring their semantics in line with most developers' intuition. Some of these changes are already present in JDK 1.4; others will have to wait until JDK 1.5. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. |
|
Articles |
|
30 Mar 2004 |
|
|
| Java theory and practice: Fixing the Java Memory Model, Part 1
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM). Several serious flaws were found in the original JMM, resulting in some surprisingly difficult semantics for concepts that were supposed to be simple, like volatile, final, and synchronized. In this installment of Java theory and practice, Brian Goetz shows how the semantics of volatile and final will be strengthened in order to fix the JMM. Some of these changes have already been integrated in JDK 1.4; others are slated for inclusion in JDK 1.5. |
|
Articles |
|
24 Feb 2004 |
|
|
| Java theory and practice: Garbage collection and performance
The past two installments of Java theory and practice have discussed various techniques for garbage collection and the basics of the JDK 1.4.1 garbage collectors. This month, columnist Brian Goetz looks at the performance impact of the choice of collector, how various coding idioms interact with the garbage collector, and how allocation and other related costs have changed in Java virtual machines over the past several years. |
|
Articles |
|
27 Jan 2004 |
|
|
| Java theory and practice: Garbage collection in the HotSpot JVM
Brian Goetz examines how the 1.4.1 JVM actually handles garbage collection, including some of the new garbage collection options for multiprocessor systems. |
|
Articles |
|
25 Nov 2003 |
|
|
| Java theory and practice: A brief history of garbage collection
Garbage collection has been an integral part of many programming languages and has been in use since the early 1960s. In this article, Brian Goetz describes the most common techniques for garbage collection. |
|
Articles |
|
28 Oct 2003 |
|
|
| Java theory and practice: Characterizing thread safety
In July our concurrency expert Brian Goetz described the Hashtable and Vector classes as being conditionally thread-safe. Shouldn't a class either be thread-safe or not? Unfortunately, thread safety is not an all-or-nothing proposition, and it is surprisingly difficult to define. But, as Brian explains in this month's Java theory and practice, it is critically important that you make an effort to classify the thread safety of your classes in their Javadoc. |
|
Articles |
|
23 Sep 2003 |
|
|
| Java theory and practice: Building a better HashMap
Brian Goetz dives into the code of ConcurrentHashMap and looks at how it achieves excellent throughput and concurrency without compromising thread safety. |
|
Articles |
|
21 Aug 2003 |
|
|
| Java theory and practice: Concurrent collections classes
In addition to many other useful concurrency building blocks, Doug Lea's util.concurrent package contains high-performance, thread-safe implementations for workhorse collection types List and Map. This month, Brian Goetz shows you how many concurrent programs will benefit from simply replacing Hashtable or synchronizedMap with ConcurrentHashMap. |
|
Articles |
|
23 Jul 2003 |
|
|
| Java theory and practice: Whose object is it, anyway?
While garbage collection means that Java developers don't have to worry (much) about memory leaks, sometimes we still do have to worry about object ownership to prevent data races and unwanted side effects. In this article, Brian Goetz identifies some of the situations where Java developers must pay attention to object ownership. |
|
Articles |
|
24 Jun 2003 |
|
|
| Java theory and practice: Hashing it out
In this installment of Java theory and practice, Java developer Brian Goetz shows you the rules and guidelines you should follow when creating Java classes in order to define hashCode() and equals() effectively and appropriately. |
|
Articles |
|
27 May 2003 |
|
|
| Java theory and practice: Urban performance legends
Many pointers and tips about Java performance tuning are a lot like urban legends -- someone, somewhere, passes on a tip that has (or had) some basis in fact, but through its continued retelling, has lost what truth it once contained. Brian Goetz examines some of these urban performance legends and sets the record straight. |
|
Articles |
|
22 Apr 2003 |
|
|
| Java theory and practice: Performance management -- do you have a plan?
Brian Goetz discusses some of the most common performance mistakes he's seen in projects using the Java language. While there are many types of programming choices that can lead to performance problems, often mistakes of management and approach are the culprit. |
|
Articles |
|
25 Mar 2003 |
|
|
| Java theory and practice: To mutate or not to mutate?
In this article, Brian Goetz explains some of the benefits of immutability and some guidelines for constructing immutable classes. While immutability may not necessarily make sense for all classes, most programs have at least a few classes that would benefit from being immutable. |
|
Articles |
|
18 Feb 2003 |
|
|
| Java theory and practice: Where's your point?
Many programmers go their entire career without using fixed point or floating point numbers, with the possible exception of the odd timing test or benchmark. The Java language and class libraries support two sorts of non-integral numeric types -- IEEE 754 floating point and arbitrary-precision decimal. In this article, Brian Goetz looks at some of the traps and gotchas often encountered when using non-integral numeric types in Java programs. |
|
Articles |
|
01 Jan 2003 |
|
|
| Java theory and practice: Concurrency made simple (sort of)
Like many other application infrastructure services, concurrency utility classes such as work queues and thread pools are often needlessly rewritten from scratch for every project. This month, Brian Goetz offers an introduction to Doug Lea's util.concurrent package, a high-quality, widely used, open source package of concurrency utilities. |
|
Articles |
|
01 Nov 2002 |
|
|
| Java theory and practice: Is that your final answer?
The final keyword is often misused -- it is overused when declaring classes and methods, and underused when declaring instance fields. This month, Java practitioner Brian Goetz explores some guidelines for the effective use of final. |
|
Articles |
|
01 Oct 2002 |
|
|
| Java theory and practice: Hey, where'd my thread go?
If you're not careful, threads can disappear from server applications without a (stack) trace. In this article, threading expert Brian Goetz offers some techniques for both prevention and detection of threads going AWOL. |
|
Articles |
|
01 Sep 2002 |
|
|
| Java theory and practice: I have to document THAT?
The Java language takes an integrated approach to API documentation through the Javadoc comment convention. The Javadoc tool can help generate pretty API documentation, but the vast majority of Java API documentation out there is simply awful. Because it is part of the source code, the responsibility for the documentation of APIs falls squarely on the engineer. In this article, Brian rants about the current state of Java documentation practices and offers some guidelines on how to write more useful Javadoc. |
|
Articles |
|
01 Aug 2002 |
|
|
| Java theory and practice: Thread pools and work queues
One of the most common questions posted on our Multithreaded Java programming discussion forum is some version of how to create a thread pool. In nearly every server application, the question of thread pools and work queues comes up. In this article, Brian Goetz explores the motivations for thread pools, some basic implementation and tuning techniques, and some common hazards to avoid. |
|
Articles |
|
01 Jul 2002 |
|
|
| Java theory and practice: Safe construction techniques
Concurrent programming in Java applications is more complicated than it looks: there are several subtle (and not so subtle) ways to create data races and other concurrency hazards in Java programs. In this installment of Java theory and practice, Brian Goetz looks at a common threading hazard: allowing the this reference to escape during construction. This harmless-looking practice can cause unpredictable and undesirable results in your Java programs. |
|
Articles |
|
01 Jun 2002 |
|
|
| Java theory and practice: Understanding JTS -- Balancing safety and performance
In this final installment of his series on JTS, Brian Goetz looks at the facilities that J2EE offers for managing transaction demarcation and isolation and some guidelines for using them effectively. |
|
Articles |
|
01 May 2002 |
|
|
| Java theory and practice: Understanding JTS -- The magic behind the scenes
In Part 1 of this series on transactions, we covered the basics of what transactions are and why they are critical to building reliable distributed applications. In this installment, we'll explore how J2EE applications are structured into transactions, and how JTS and the J2EE container manage to make transaction services, including transaction demarcation, resource enlistment, and transaction propagation, nearly invisible to the component programmer. |
|
Articles |
|
01 Apr 2002 |
|
|
| Java theory and practice: Understanding JTS -- An introduction to transactions
The Java Transaction Service is a key element of the J2EE architecture. Together with the Java Transaction API, it enables us to build distributed applications that are robust to all sorts of system and network failures. This first installment of a three-part series covers the basics of what transactions are and why they are critical to building reliable distributed applications. |
|
Articles |
|
01 Mar 2002 |
|
|
| Java theory and practice: Should you use JMS in your next enterprise application?
Welcome to Java theory and practice, a new monthly column by veteran Java developer Brian Goetz. This column aims to explore that elusive juncture where design principles meet the requirements to solve real-world problems. Each month, we'll explore design patterns, principles of reliable software design, and why best practices are best, with an eye to how they are applied to real problems. This month, Brian takes a look at enterprise message queuing technology. |
|
|
posted Jun 20, 2010, 9:04 PM by Kuwon Kang
자바(Java™) 개발자들은 대부분 이클립스를 IDE로 사용한다. 이클립스 IDE는 실제로 플러그인이라고 부르는 상호 연관된 컴포넌트로 구성되어 있다. IDE의 기반이 되는 이 플러그인들은 그밖에도 데스크톱 애플리케이션을 만들 때 사용할 수 있다. 이클립스 기반 애플리케이션을 만들기 위해 필요로 하는 최소한의 플러그인 집합을 이클립스 리치 클라이언트 플랫폼(Eclipse Rich Client Platform)이라고 부른다. 하지만 플러그인은 그것들 스스로 동작하지는 못하고 자신들이 구동되고 동작할 수 있는 환경을 필요로 한다. 이클립스는 이런 환경으로 OSGi R4 명세서에 대한 구현체를 제공한다. 이클립스의 핵심이 OSGi에 의해 주도되었기 때문에, 이클립스 플러그인의 개념이 OSGi 프레임워크와 어떤 관련이 있는지 이해하는 것이 중요하다. 본 기사에서, 필자는 이클립스 플랫폼 입장에서 플러그인이라는 용어가 뜻하는 바가 무엇인지 살펴보는 것을 통해 이 관계를 자세히 설명하고자 한다. 그런 다음, 플러그인의 진화 과정을 이클립스 V2.1 플랫폼부터 OSGi 기반 구현체까지를 통틀어 살펴보겠다. 마지막으로 이클립스 플러그인에 적용되는 OSGi 제공 manifest.mf 옵션을 자세히 살펴보겠다. 플러그인이란? 이클립스는 온라인 도움말은 플러그인을 다음과 같이 정의한다. "플러그인은 구조화된 번들로 시스템의 기능을 수행하는 데 필요한 코드 또는 데이터다. 기능은 코드 라이브러리(퍼블릭 API를 가지고 있는 자바 클래스), 플랫폼 확장 또는 문서 등으로 달성될 수 있다. 플러그인은 확장 지점을 정의할 수 있다. 확장 지점은 다른 플러그인들이 기능을 추가할 수 있도록 잘 정의해둔 지점을 말한다."
집중해서 살펴보아야 할 것은 플러그인들이 구조화된 방법으로 기능을 수행한다는 것이다. 그것들은 로깅과 같은 서비스를 제공하거나 편집기 같은 사용자 인터페이스(UI)에서 가용한 일부 기능을 제공할 것이다. 그것들의 기능에 관계없이, 모든 플러그인은 똑같은 구조적인 방법으로 정의되어 있다. 위로 OSGi로의 진화 언급했다시피, 이클립스는 OSGi를 자신의 플러그인 시스템의 밑바탕으로 사용한다. 하지만 항상 그래왔던 것은 아니다. 이클립스 초기 버전도 플러그인의 집합체로 설계되었지만, 이클립스는 자신만의 사적인 플러그인 시스템을 내장하여 플러그인들의 상호작용을 관리했다. 그런데 이클립스 IDE의 요구사항이 점차 커짐에 따라 더 견고한 솔루션이 필요하다는 것이 명백해졌다. 새로운 시스템의 기본이 되는 요구사항은 동적으로 새로운 플러그인을 처리하고 현존하는 플러그인을 제거하는 것이었다. 많은 조사 끝에, 이클립스 제작자들은 사적인 플러그인 프레임워크를 교체할 OSGi 프레임워크 구현체를 구현하기로 결정했다. OSGi는 서비스 플랫폼에 대한 규약이다. 이클립스는 이 규약에 대한 많은 가용한 구현체 중 하나를 제공한다. 그리고 최신 OSGi R4 구현체에 대한 참조 구현을 제공한다. OSGi는 자바 기반 프레임워크로 오랜 시간 동작하며, 동적으로 수정을 가하고, 실행 중인 환경에 최소한의 정지를 요구하는 시스템에서 사용하려고 만들었다. 가장 최근에는, 전화기에서 자동차에 이르기까지 다양한 곳에서 찾아볼 수 있다. OSGi는 컴포넌트와 서비스 모델이며, 그 핵심을 그림 1과 같이 나타낼 수 있다. OSGi 명세서는 모듈화의 단위를 번들이라고 정의한다(별도의 언급이 없다면 본 글의 다음부터는 이클립스의 플러그인이라는 용어와 OSGi 용어인 번들을 같은 뜻으로 이해하기 바란다. 이클립스의 번들이 현재 OSGi 번들이기 때문이다). OSGi는 JVM(Java Virture Machine) 수준의 서비스 레지스트리를 제공하여 번들들을 공개하고, 찾고, 서비스로 묶을 수 있도록 한다. 그림 1. 호스트 운영체제, 자바, OSGi에서 레이어들의 상호 작용 OSGi 명세서는 번들의 생명 주기와 번들들이 어떻게 상호작용하는지를 정의한다. 이러한 규칙들은 특별한 자바 클래스 로더를 사용하도록 강제한다. 보통의 자바 애플리케이션에서, CLASSPATH에 있는 모든 클래스는 서로가 서로를 볼 수 있다. 하지만 그와 반대로, OSGi 클래스 로더는 번들간의 클래스의 상호작용을 OSGi 명세와 각각의 번들이 가지고 있는 manifest.mf 파일의 옵션을 사용하여(본 기사의 뒷 부분에서 살펴볼 것이다) 제한한다. 이클립스 IDE는 OSGi의 서브셋 중 모듈화와 번들 생명 주기를 주로 사용한다. OSGi가 제공하는 서비스 중 최소한의 것들만 사용할 수 있다. 그 대신, 이클립스는 자신만의 확장 지점 시스템을 제공하여 번들이 상호작용할 수 있도록 한다. 번들의 기능을 다른 확장 지점에 기여하는 형태로 제공할 수 있다. 번들은 또한 자신만의 확장 지점을 정의하여 다른 번들들이 기여할 수 있도록 할 수 있다. 이클립스에서 확장 지점 사용의 예로 Preference 창을 들 수 있다. 핵심 이클립스 플러그인이 중앙의 창을 제공하고 확장 지점들을 노출(expose)시킨다. 이 확장 지점에 부가적인 환경 설정 페이지가 기여(contribution)할 수 있도록 하는 것이다. 새로운 플러그인이 이클립스에 추가되면, 자신의 페이지를 기여할 수 있다. 이클립스의 확장 지점 모델은 기본이 되는 OSGi 서비스와는 다르다. 번들 확장 지점은 그것을 정의한 번들이 소유한다. 다른 번들들은 단순히 그것들에 기여하는 것이다. 그와는 반대로, 어떠한 번들도 OSGi 서비스를 구현하고 사용할 수 있다. 위로 OSGi를 사용하여 이클립스 구현하기 이클립스 버전 3.1 이전에는, 모든 플러그인의 plugin.xml 파일에 플러그인 종속성과 확장 지점 그리고 그것을 확장하는 것(extension)들을 정의하였다. OSGi를 사용하는 새로운 버전의 이클립스는 의존성 정보를 manifest.xml 파일로 빼내고, plugin.xml 파일에는 오직 확장 지점과 확장들에 대한 정보만 남겨두었다. 이 진화 과정을 보여주는 실제 예제를 살펴보는 게 좋겠다. Listing 1은 이클립스 V3.0의 org.eclipse.pde.ui.plug-in에서 발췌한 것이다. Listing 1. org.eclipse.pde 플러그인에서 발췌
id="org.eclipse.pde.ui"
name="%name"
version="3.0.2"
provider-name="%provider-name"
class="org.eclipse.pde.internal.ui.PDEPlugin">
name="%expoint.pluginContent.name"
schema="schema/pluginContent.exsd"/>
name="%expoint.newExtension.name"
schema="schema/newExtension.exsd"/>
name="%expoint.templates.name"
schema="schema/templates.exsd"/>
name="%expoint.samples.name"
schema="schema/samples.exsd"/>
point="org.eclipse.ui.perspectives">
name="%perspective.name"
icon="icons/eview16/plugins.gif"
class="org.eclipse.pde.internal.ui.PDEPerspective"
id="org.eclipse.pde.ui.PDEPerspective">
선언은 플러그인 안에 있는 모든 패키지를 노출시켜 다른 플러그인들이 사용할 수 있도록 한다. 플러그인 종속성 추가 구역은 org.eclipse.pde.ui 플러그인이 필요로 하는 필수 플러그인들을 나열한다.다음의 두 구역은 확장 지점을 정의하여 org.eclipse.pde.ui를 다른 플러그인들이 사용할 수 있도록 하고 있으며, 기여(contribution)들이 그것을 사용할 수 있도록 정의한다. 여기서는, 사용자 정의 이클립스 개발 환경(PDE) 작업 환경을 정의하는 것을 볼 수 있다.이클립스 V3.1에 있는 똑같은 플러그인의 정의를 살펴보자. Listing 2는 plugin.xml 파일을 보여준다. Listing 2. Plugin.xml
name="%expoint.pluginContent.name"
schema="schema/pluginContent.exsd"/>
name="%expoint.newExtension.name"
schema="schema/newExtension.exsd"/>
name="%expoint.templates.name"
schema="schema/templates.exsd"/>
name="%expoint.samples.name"
schema="schema/samples.exsd"/>
point="org.eclipse.ui.perspectives">
name="%perspective.name"
icon="icons/eview16/plugins.gif"
class="org.eclipse.pde.internal.ui.PDEPerspective"
id="org.eclipse.pde.ui.PDEPerspective">
익스포트(export)와 임포트(import) 정보가 사라진 것을 확인하라. 이 정보는 이제 Listing 3에 보이는 manifest.xml 파일로 옮겨갔다.Listing 3. Manifest.xmlManifest-Version: 1.0
Bundle-Name: %name
Bundle-SymbolicName: org.eclipse.pde.ui; singleton:=true
Bundle-Version: 3.1.0
Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jar
Bundle-Activator: org.eclipse.pde.internal.ui.PDEPlugin
Bundle-Vendor: %provider-name
Bundle-Localization: plugin
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.ui.ide,
org.eclipse.ui.views,
org.eclipse.jface.text,
org.eclipse.ui.workbench.texteditor,
org.eclipse.ui.editors,
org.eclipse.ant.core,
org.eclipse.core.resources,
org.eclipse.debug.core,
org.eclipse.debug.ui,
org.eclipse.jdt.core,
org.eclipse.jdt.debug.ui,
org.eclipse.jdt.launching,
org.eclipse.jdt.ui,
org.eclipse.pde,
org.eclipse.pde.build,
org.eclipse.search,
org.eclipse.team.core,
org.eclipse.ui,
org.eclipse.update.core,
org.eclipse.ui.forms,
org.eclipse.ant.ui,
org.eclipse.jdt.junit,
org.eclipse.ui.intro,
org.eclipse.ui.cheatsheets,
org.eclipse.update.configurator,
org.eclipse.help.base
Bundle-ManifestVersion: 2
Eclipse-AutoStart: true
Export-Package: org.eclipse.pde.internal.ui;x-internal:=true,
org.eclipse.pde.internal.ui.build;x-internal:=true, . . . org.eclipse.pde.ui,
org.eclipse.pde.ui.internal.samples;x-internal:=true,
org.eclipse.pde.ui.templates 여러 플러그인 추가 정보는 필요한 번들(Required-Bundles)이라는 이름으로 서술하고 있다. 그리고 * 패키지 노출은 명시적으로 노출할 패키지 목록으로 대체되었다. 플러그인 수준에서 의존성을, 명시적인 패키지 노출과 임포트를 필요로 하는 의존성으로 옮긴 것은 이클립스가 그 사실을 발표했을 때 상당히 많은 소동을 일으켰다. 근본적인 불만사항은 이전 버전의 이클립스에 존재했던 와 같은 무언가가 없다는 것이었다. 하지만 이것을 뺀 이유는 상당히 많다. 가장 중요한 이유는 노출할 패키지와 들여올 패키지를 기술함으로써 얻는 속도였다. 이전 버전의 이클립스는 jar 파일이 어떤 클래스 파일을 가지고 있는지 확인하기 위해 일일히 파일을 열고 찾아봐야했다. * 노출을 지원하지 않음으로써 원하지 않는 클래스를 노출하는 것을 한 번 방지할 수 있다. 플러그인 개발자들은 외부에서 사용 가능한 플러그인을 만들기 위해 신중하게 선택을 해야 한다. 이런 제약으로 인해 내부에서만 사용할 패키지들은 내부에 남아있게 된다. 위로 OSGi manifest 옵션 현재 OSGi R4 명세서는 거의 300쪽에 달하는 PDF 문서다. 이 명세서의 모든 부분을 살펴보는 것은 본 기사의 범위를 벗어난다. 이클립스 플러그인 개발자들을 위해 필요한 OSGi manifest.xml 옵션만을 살펴보겠다. Bundle-Activator
이 클래스는 번들을 시작하고 멈출 때 사용한다. 위의 플러그인 예제에서, org.eclipse.pde.internal.ui.PDEPlugin 클래스라고 설정되어 있다. 이 클래스는 org.eclipse.core.runtime.Plugin을 상속받았고 BundleActivator 인터페이스를 구현하였다.
Bundle-ClassPath
이 속성은 번들이 사용할 CLASSPATH를 기술한다. 이 속성은 번들 jar 파일에 들어있는 디렉터리나 jar 파일에 대한 참조를 포함하고 있을 것이다. 마침표를 사용해 번들의 루트를 나타낼 수 있다. 이클립스 PDE 번들 예제의 경우, 번들 jar 파일에 들어있는 org.eclipse.pde.ui_3.1.0.jar 파일을 기술했다. 플러그인의 소스 버전을 워크스페이스로 가져오면, 가져오는 과정 중에 번들 CLASSPATH를 Bundle-ClassPath:에 추가해 준다. 이렇게 함으로써, 개발 중인 플러그인 버전이 컴파일된 번들 클래스를 선택하도록 할 수 있다.
Bundle-Version
이 속성은 번들의 버전 번호를 기술한다. 패키지 추가와 필요한 번들 명세에는 번들 버전 번호를 포함하도록 되어 있다.
Export-Package
이 속성은 다른 플러그인들이 사용할 수 있도록 외부로 노출할 모든 패키지를 기술한다.
Import-Package
이 속성은 필요로 하는 플러그인에서 사용할 패키지들을 명시적으로 기술한다. 기본적으로, 번들이 기능을 시작하려면 모든 패키지가 반드시 의존성을 해결한 상태(resolved)여야 한다. 패키지가 존재하지 않은 경우에 대비해 특정 패키지들은 부가적인 것으로 설정할 수도 있다. 명시적으로 가져오는 클래스들은 Require-Bundle 플러그인들에서 가져온 것들보다 먼저 의존성을 해결한다.
Require-Bundle
이 속성은 해당 번들에서 사용하기 위해 가져올 번들과 해당 번들들이 노출한 패키지를 기술한다. 기술되어 있는 번들들은 명시적 패키지 추가 작업 이후에 처리한다.
이클립스에서 제공하는 부가적인 manifest 옵션 버디 클래스 로더 옵션 하이버네이트 플러그인을 만든다고 해보자. 그리고 나서 하이버네이트가 의존성을 가지는 도메인 클래스들을 포함하고 있는 플러그인을 만든다. 그리고 하이버네이트 플러그인에 다음과 같은 줄을 추가한다. Eclipse-BuddyPolicy: registered. 그리고 다음을 도메인 클래스와 리소스를 가지고 있는 플러그인의 manifest 파일에 추가한다. Eclipse-RegisterBuddy: hibernate. 해당 설정으로 플러그인은 선언적으로 그 자신을 하이버네이트 플러그인에 노출시켰다. 이 때 하이버네이트 플러그인은 그 사실을 전혀 알지 못한다. 이제 하이버네이트 플러그인은 자신이 필요한 것들을 가져오겠다고 명시하지도 않았지만 그것들을 사용할 수 있다. OSGi 명세서가 가지고 있는 manifest.mf 설정 옵션으로는 이클립스 플랫폼이 필요로 하는 모든 기능을 제공하지 못한다. 그 결과, 이클립스 제작진은 몇몇 확장 옵션을 추가했다(그리고 이것들을 OSGi 명세서 다음 버전에 추가할 수 있도록 제안했다). Export-Package Header Extensions
이클립스는 두 개의 OSGi resolver 메서드 default와 strict를 가지고 있고 이것은 osgi.resolver가 기술할 수 있는 속성들이다. 이클립스는 Export-Package에 두 개의 확장인 x-internal과 x-friends를 가지고 있다. Strict 모드를 사용할 때만 이 두 속성을 반드시 명시해야 한다.
x-internal
이 속성의 기본값은 false다. 이 옵션을 사용하여 내부 패키지를 true로 설정하면 이클립스 PDE가 그것들을 사용하는 것을을 막아준다.
x-friends
이 옵션은 x-internal과 비슷하다. 하지만 이 옵션을 가지고 있는 번들들은 노출된 패키지를 사용할 수 있도록 허가한다. 다른 번들들은 사용할 수 없다. x-internal 옵션이 x-friends에 비해 우선시된다.
Eclipse-AutoStart
기본적으로, 이클립스는 필요할 때 번들을 읽어온다. 따라서 번들들은 자신이 가지고 있는 클래스가 그것을 추가한 번들에 의해 필요해질 때 로딩된다. 이 속성의 값을 ??로 설정하면 이클립스 시작시에 해당 번들을 로딩한다. 또한 번들이 가지고 있는 예외 클래스, 리소스 그리고 무엇이든지 그것들을 가지고 있는 번들을 시작할 필요 없이 로딩하도록 명시할 수 있다.
Eclipse-PlatformFilter
이 속성은 번들을 시작할 때 반드시 true 값이 나와야 하는 조건을 기술한다. 표현식에는 다음 정보를 포함시킬 수 있다.
언어를 뜻하는 osgi.nl
운영체제를 뜻하는 osgi.os
아키텍처를 뜻하는 osgi.arch
윈도우 기반 시스템을 뜻하는 osgi.ws
이 속성을 사용하는 예제로 SWT_AWT 브릿지(bridge)를 사용하는 번들이 동작하기 전에 운영체제가 MAC OS X이 아님을 확인하는 것이 가능하다(본 기사를 작성하는 시점에 MAC OS X의 SWT 구현체는 이 기능을 지원하지 않았다).
Eclipse-BuddyPolicy
이 옵션은 번들의 클래스 로딩 정책을 기술한다. 일반적으로 번들은 자신의 내부 클래스들과 외부에서 가져온 것들만을 볼 수 있다. 이클립스 뉴스그룹에서 버디 클래스 로딩을 설명할 때 사용한 가장 유명한 예제는 하이버네이트다. 하이버네이트 프레임워크는 사용자가 작성한 클래스와 리소스를 봐야지 하이버네이트 자신의 일부를 봐야 하는 것이 아니다. 이런 경우 중 하나가 하이버네이트 쿼리 언어(HQL)에 동적으로 클래스를 채워넣는 프로젝트를 사용할 때다. 기본적으로, 하이버네이트는 하이버네이트 jar 파일을 가지고 있는 플러그인의 외부 클래스들은 볼 수가 없다. 그리고 하이버네이트 맵을 허용하지 않는 클래스를 가지고 있는 플러그인 생성 때문에 하이버네이트 플러그인의 수정을 요구하게 된다. 다행히도, 이 문제를 버디 클래스 로더 옵션 절에서 설명한 버디 클래스 로더 옵션으로 해결할 수 있다. 위로 이클립스와 OSGi의 미래 이클립스는 OSGi 사용으로 인해 큰 장점을 얻었다. 동적으로 컴포넌트의 생명 주기를 관리하는 견고한 시스템이 되었다. 동적으로 WAR 파일을 서버에 배포하여 서블릿, JSP 그리고 이클립스 스타일 플러그인들으로 된 HTTP 리소스가 매일 같이 새롭게 개발되고 있다. 이클립스 재단은 OSGi 명세서를 주도하여 스스로가 사용하고 다른 참여자들도 OSGi를 사용할 수 있도록 하는 핵심 역할을 맡게 되었다. 내부적인 이클립스 플러그인 프레임워크에서 OSGi로 진화하면서, OSGi 명세서에 많은 부가적인 것들을 만들어냈고 그것들이 배포된 OSGi R4 명세서의 일부가 되었다. 그 결과, 이클립스 Equinox 프로젝트는 앞서가는 OSGi 레퍼런스 구현체가 되었다. 이런 진화는 OSGi를 제어하기 위한 자바 표준 요청(JSR) 291이 만들어진 것과 같이 이클립스와 OSGi의 파트너십이 계속해서 성공적으로 이어나갈 것임을 보장한다. |
|
JZOS Batch Launcher.pdf
