설정후, shift + F2만 누르면 브라우져가 떠서. 보기가 편하다!!

 

출처 :

http://www.cs.laurentian.ca/badams/c1047/eclipse-tutorials/javadoc-tutorial.html

 

 

Viewing Javadoc for the JDK API

To view the standard Java JDK API documentation for all the classes that come with Java open up the tree in the "Package Explorer" for the JRE System Library, select rt.jar (the runtime library)

From the "Navigate" menu select "Open External Javadoc" and you will see the Java API documentation. The default location of the documentation is Sun's website so the URL in the browser will be something like

http://java.sun.com/j2se/1.5.0/docs/api/index.html

We want to use our own local version of the documentation in

file:/C:/Program Files/Java/jdk1.5.0_04/docs/api/

so that we don't need to connect to the internet each time we want to view the documentation.

To make the change right click on the rt.jar entry in the "Package Explorer" and select "Properties" to get the dialog box

We need to change the URL in the "Javadoc location path". You can either type in the local value directly or use its browse button to navigate to

Click "OK" and you should have the dialog box

showing the local URL

file:/C:/Program Files/Java/jdk1.5.0_04/docs/api/

Click "Apply" and then "OK".

Now to see the API documentation select rt.jar and choose "Open External Javadoc" from the "Navigate" menu (shortcut is Shift F2). Your local URL will now be shown in the browser address bar.

Viewing Documentation in the Editor Window

It is possible to show Java documentation in the editor window. From the "Package Explorer" open the docs directory for project geoproject and double click the file index.html. The editor window will now show

Viewing Documentation From Source Code

Another way to view documentation for a particular class in your source code is to select the class name and the press "Shift F2". To try this load the file Circle.java into the Editor. Select the word Point

Now press "Shift F2". The documentation for the Point class will now appear in a browser window.

In the same way you can also select a package name and the package documentation will appear.

Posted by '김용환'
,

아파치에서 서비스를 막고, 특정 페이지만 다로 403, 404 페이지를 보여주기..

 

Location 태그를 이용하면 된다.

 

 

 

 

 <Location ~ "wt.nhn">
    Order deny,allow
    Deny from all
    ErrorDocument 403 /common/under/wt_under.html
    ErrorDocument 404 /common/under/wt_under.html
</Location>

 

 

 

이와는 별개로 사실은 다른 시도가 있었다.

 

SetEnv FOO 1

SetEnvIf FOO 1 under

 

<File ~ (*.txt)>

     Order deny,allow
    Deny from env=under
    ErrorDocument 403 /common/under/wt_under.html

</File>

 

이렇게 해보려고 했다.

 

실제 어떤 property를 apache에서 지정하고, 해당되는 변수의 값으로 먼가를 하려고 했지만.. 할 수 없는 구조이다.

그것은 아파치는 실제 그런 기능이 없다. (-D로 주는 property를 제외하고는...)

 

SetEnv의 역할은 environment variable, 즉 환경변수만을 지정할 뿐이다.

SetEnvIf의 역할은 HTTP Request Header에서의 필드만을 Filter만 할 뿐..

 

SetEnv와 SetEnvIf는 전혀 상관성이 없었다.

 

이외.

 

PassEnv라는 것이 있었으나.

이것은 shell에서의 환경변수만을 그대로 아파치에게 넘겨주는 것뿐이니...

 

참조할 것.

 

Property를 주는 것은 httpd를 띄울 때 -D 에 넣어서 실행시켜야 한다. 아니면, httpd.conf 파일을 약간 수정할 것~^^

 

 

 

'web' 카테고리의 다른 글

HTTPClient에서의 Cookie 사용하기  (0) 2008.03.26
아파치에서 동적, 정적 모듈 확인하기.  (0) 2007.12.11
subversion 설치 스크립트  (0) 2007.12.04
php 설치 스크립트  (0) 2007.12.04
php, asp, jsp 확장자 바꿔보기  (0) 2007.12.04
Posted by '김용환'
,

 

cvs 리파지토리에서 새롭게 branch를 따려고 하니. 다음의 문제가 발생했다.

 

 : cvs checkout: failed to create lock directory for
`/usr/local/cvsrepo/project'
(/usr/local/cvsrepo/project/#cvs.lock): Permission denied
: cvs checkout: failed to obtain dir lock in repository
`/usr/local/cvsrepo/project'
: cvs [checkout aborted]: read lock failed - giving up

 

 

문제는 권한 문제.

cvs서버에 들어가서 권한에 대해서 잘 처리한다.

 

chown -R 그룹 /usr/local/cvsrepo/project

또는

chmod -R ug+ws /usr/local/cvsrepo/project

 

이렇게 해결하면 된다.

 

* 참조내용

http://www.mooreds.com/wordpress/archives/000234

'svn' 카테고리의 다른 글

Setting property in svn repository  (0) 2009.04.17
php 로깅 관련  (0) 2008.01.18
[펌] svn 사용법  (0) 2006.01.17
svn 명령시 깨지는 글자나 나타날 때.  (0) 2005.11.01
http://www.abbeyworkshop.com/howto/misc/svn01/  (0) 2005.06.10
Posted by '김용환'
,

subversion 설치 스크립트

web 2007. 12. 4. 20:20

 #!/bin/csh

set WWW_HOME="/home/www"
set SRC_HOME="${WWW_HOME}/src"

echo ">> Install Subversion"
cd ${SRC_HOME}
\rm -rf subversion*

# subversion을 깔기 위해서는 apr,apr-util library가 필요하다.
# 혹시 예전 버젼이면,  다음을 사용하라
# wget http://ftp.kaist.ac.kr/pub/Apache/apr/apr-0.9.17.tar.gz
# wget http://mirror.apache-kr.org/apr/apr-util-0.9.15.tar.gz
# 만약 apr을 설치하면, .configure가 바뀌어 진다....
# ./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util
wget http://subversion.tigris.org/downloads/subversion-1.4.3.tar.gz
tar zxf subversion-1.4.3.tar.gz
cd subversion-1.4.3
chmod 755 configure
./configure
make
sleep 1
make install

Posted by '김용환'
,

php 설치 스크립트

web 2007. 12. 4. 20:19

 #!/bin/csh

set WWW_HOME="/home/www"
set SRC_HOME="${WWW_HOME}/src"
set SCRIPT_HOME="${WWW_HOME}/script"
set PHP_VERSION="5.1.0"
set APACHE_HOME="/usr/local/apache2"
set MYSQL = "$1"

wget http://xmlsoft.org/sources/libxml2-2.6.13-1.i386.rpm
wget http://xmlsoft.org/sources/libxml2-devel-2.6.13-1.i386.rpm
wget http://xmlsoft.org/sources/libxml2-python-2.6.13-1.i386.rpm

rpm -Uvh ./libxml2-*

echo ">> Install PHP ${PHP_VERSION}"
cd ${SRC_HOME}
\rm -rf php-${PHP_VERSION}
tar zxf php-${PHP_VERSION}.tar.gz
cd php-${PHP_VERSION}
chmod 755 configure
./configure --prefix=/usr/local/php --with-regex=php --with-apxs2=/usr/local/apache/bin/apxs --with-exec-dir=/usr/local/apache/bin --with-config-file-path=/usr/local/apache/conf --with-language=korea --with-charset=euc_kr --enable-track-vars=yes --enable-ftp  --with-zlib --with-gd
make
sleep 1
make install

Posted by '김용환'
,

웹에서  .php 가 아니라 .abc 로 바꾸는 방법이 있는줄 알았는데,

 

일부 인코딩된 핵심 라이브러리에서 .php , jsp, asp 확장자를 사용하므로 임의로 변경하실 수 없습니다.

 

따라서 소스 자체를 수정하는 것이 좋다.

 

a.php이면,  소스를 a.abc로 수정하고.

 

    AddType application/x-httpd-php .abc

 

 

이런식으로 수정할 것.

 

 

 

Posted by '김용환'
,

bash if 문 비교

unix and linux 2007. 11. 30. 10:02

 

shell script 상에서 항상 혼란스러워 하는 것중의 하나가 바로 scalar 비교이다.

결과가 없으면 string type이 아니라,  scalar type이다. 그러므로, "$aaa" == "" 이렇게 비교를 해야 한다..

쩝쩝..

 

 

http://linuxcommand.org/wss0100.php

 

 

Stay Out Of Trouble

by William Shotts, Jr.

Now that our scripts are getting a little more complicated, I want to point out some common mistakes that you might run into. To do this, create the following script called trouble.bash. Be sure to enter it exactly as written.

#!/bin/bash

number=1

if [ $number = "1" ]; then
    echo "Number equals 1"
else
    echo "Number does not equal 1"
fi
       

When you run this script, it should output the line "Number equals 1" because, well, number equals 1. If you don't get the expected output, check your typing; you made a mistake.

Empty variables

Edit the script to change line 3 from:

number=1
       

to:

number=
       

and run the script again. This time you should get the following:

[me@linuxbox me]$ ./trouble.bash
/trouble.bash: [: =: unary operator expected.
Number does not equal 1

As you can see, bash displayed an error message when we ran the script. You probably think that by removing the "1" on line 3 it created a syntax error on line 3, but it didn't. Let's look at the error message again:

./trouble.bash: [: =: unary operator expected

We can see that ./trouble.bash is reporting the error and the error has to do with "[". Remember that "[" is an abbreviation for the test shell builtin. From this we can determine that the error is occurring on line 5 not line 3.

First, let me say there is nothing wrong with line 3. number= is perfectly good syntax. You will sometimes want to set a variable's value to nothing. You can confirm the validity of this by trying it on the command line:

[me@linuxbox me]$ number=
[me@linuxbox me]$

See, no error message. So what's wrong with line 5? It worked before.

To understand this error, we have to see what the shell sees. Remember that the shell spends a lot of its life substituting text. In line 5, the shell substitutes the value of number where it sees $number. In our first try (when number=1), the shell substituted 1 for $number like so:

if [ 1 = "1" ]; then
       

However, when we set number to nothing (number=), the shell saw this after the substitution:

if [ = "1" ]; then
       

which is an error. It also explains the rest of the error message we received. The "=" is a binary operator; that is, it expects two items to operate upon - one on each side. What the shell was trying to tell us was that there was only one item and there should have been a unary operator (like "!") that only operates on a single item.

To fix this problem, change line 5 to read:

if [ "$number" = "1" ]; then
       

Now when the shell performs the substitution it will see:

if [ "" = "1" ]; then
       

which correctly expresses our intent.

This brings up an important thing to remember when you are writing your scripts. Consider what happens if a variable is set to equal nothing.

Missing quotes

Edit line 6 to remove the trailing quote from the end of the line:

   echo "Number equals 1
       

and run the script again. You should get this:

[me@linuxbox me]$ ./trouble.bash
./trouble.bash: line 8: unexpected EOF while looking for matching "
./trouble.bash: line 10 systax error: unexpected end of file

Here we have another case of a mistake in one line causing a problem later in the script. What happens is the shell keeps looking for the closing quotation mark to tell it where the end of the string is, but runs into the end of the file before it finds it.

These errors can be a real pain to find in a long script. This is one reason you should test your scripts frequently when you are writing them so there is less new code to test. I also find that text editors with syntax highlighting (like nedit or kate) make these kinds of bugs easier to find.

Isolating problems

Finding bugs in your programs can sometimes be very difficult and frustrating. Here are a couple of techniques that you will find useful:

Isolate blocks of code by "commenting them out." This trick involves putting comment characters at the beginning of lines of code to stop the shell from reading them. Frequently, you will do this to a block of code to see if a particular problem goes away. By doing this, you can isolate which part of a program is causing (or not causing) a problem.

For example, when we were looking for our missing quotation we could have done this:

#!/bin/bash

number=1

if [ $number = "1" ]; then
    echo "Number equals 1
#else
#   echo "Number does not equal 1"
fi
       

By commenting out the else clause and running the script, we could show that the problem was not in the else clause even though the error message suggested that it was.

Use echo commands to verify your assumptions. As you gain experience tracking down bugs, you will discover that bugs are often not where you first expect to find them. A common problem will be that you will make a false assumption about the performance of your program. You will see a problem develop at a certain point in your program and assume that the problem is there. This is often incorrect, as we have seen. To combat this, you should place echo commands in your code while you are debugging, to produce messages that confirm the program is doing what is expected. There are two kinds of messages that you should insert.

The first type simply announces that you have reached a certain point in the program. We saw this in our earlier discussion on stubbing. It is useful to know that program flow is happening the way we expect.

The second type displays the value of a variable (or variables) used in a calculation or test. You will often find that a portion of your program will fail because something that you assumed was correct earlier in your program is, in fact, incorrect and is causing your program to fail later on.

Watching your script run

It is possible to have bash show you what it is doing when you run your script. To do this, add a "-x" to the first line of your script, like this:

#!/bin/bash -x
       

Now, when you run your script, bash will display each line (with substitutions performed) as it executes it. This technique is called tracing. Here is what it looks like:

[me@linuxbox me]$ ./trouble.bash
+ number=1
+ '[' 1 = 1 ']'
+ echo 'Number equals 1'
Number equals 1

Alternately, you can use the set command within your script to turn tracing on and off. Use set -x to turn tracing on and set +x to turn tracing off. For example.:

#!/bin/bash

number=1

set -x
if [ $number = "1" ]; then
    echo "Number equals 1"
else
    echo "Number does not equal 1"
fi
set +x
       
Posted by '김용환'
,

리딩업

Trend 2007. 11. 30. 10:01

리딩 업(Leading Up)

마이클 어셈 지음 | 김광수 옮김
모라비안바젤 2002.04.13
평점

 

남북전쟁시 리장군이 고수한 원칙

1. 과거에 완수한 일, 현재 진행중인 일, 그리고 앞으로의 계획에 대해 상사에게 지속적으로 보고하라
2. 상사를 향한 감정이 어떻든, 상사의 지위에 걸맞게 예우하라
3. 비록 당신이 옳다 하더라도 당신의 평판에 악영향을 미칠 가능성이 있다면, 아무리 사소한 문제라도 상사와 말다툼을 자제하라
4. 자신의 경쟁우위를 가능한 정확하게 파악하라. 그러면 지나친 과신이나 지나친 신중함을 피할 수 있으며, 당신의 정확한 판단력에 대한 상사의 신뢰를 유지할 수 있다.

 

 

상향리더쉽을 갖고자 하는 사람들의 보편적인 지침

1. 누군가의 개인적인 경험을 본보기로 삼아라
2. 모든 상사들에게 정보와 의도를 낱낱이 얘기하라
3. 모든 상사들과 자주 만나라
4. 하급자들의 말에 귀를 기울이고 실수를 통해서도 배워라
5. 모든 하급자들은 용기백배하게 만드는 능력을 키워라
6. 상사의 입장이 되어 나 자신의 역할을 내려다봄으로써 하급자들을 어떻게 바라보아야 하는지 배워라
7. 원칙을 시험해 보기 전에 일단 당신 자신의 원칙을 다듬어라

 

<상사의 지원을 받기 위한 법칙>

1. 당신의 계획을 철저하게 분석해서 완벽하게 준비해 놓는 것이다.
2. 계획한 과정이 조직에 필요한 이유와, 최소한의 변동과 인원으로 성취할 수 있는 방법을 조심스럽게 의논하는 것이다.

이 포스트를.. 파일로 저장

Posted by '김용환'
,

apache 문제.

web 2007. 11. 29. 00:18

 

 

 [Wed Nov 28 15:00:37 2007] [error] (28)No space left on device: mod_security: Could not create modsec_auditlog_lock
[Wed Nov 28 15:02:21 2007] [error] (28)No space left on device: mod_security: Could not create modsec_auditlog_lock
[Wed Nov 28 15:02:21 2007] [error] (28)No space left on device: mod_security: Could not create modsec_auditlog_lock

 

=>

 

 

 

ipcs | perl -ane '`ipcrm -s $F[1]` if $F[2] == "apache" and $F[1] =~ /\d+/ and $F[1] != 0'

 

 

 

Posted by '김용환'
,

친절한

Trend 2007. 11. 27. 10:39

행복한 대화법

신영란 지음
바른지식 2006.09.13
평점

상사와 친해지는 법~~ 좋은 자료이다.

 

 

<상사와 친해지는 법>

 

1. 상사의 성격이나 일하는 스타일을 파악하여 적극적으로 협력할 것
2. 일을 처리하기 전 미리 상사의 의향을 파악하여 수정할 일이 없도록 할 것
3. 일을 안심하고 맡길 수 있도록 평소에 업무에 대한 실력을 쌓을 것
4. 주어진 역할, 해야 할 일은 구실을 찾지 말고 지체없이 처리할 것
5. 시키는 일만 하지 말고, 좋은 아이디어를 첨가하도록 노력할 것
6. 일을 미리 찾아내는 버릇을 들일 것
7. 드러내 놓고 반발하기 보다는 유머 감각을 발휘하여 웃는 낯으로 설득할 것
8. 항상 절도 있고, 에의 바른 태도를 잃지 말 것
9. 상사와의 접촉 기회를 많이 갖고 친밀감을 쌓을 것
10. 개인의 능력을 과시하기 보다는 조직 전체의 발전을 위해서 일하는 자세를 가질 것

 

상사와의 친밀감은 굉장히 중요한 요소라고 생각이 든다. 그 이유는 사람은 논리적이 아니라 감정적이기 때문이다. 상사와 자주 만나고, 개인의 능력보다는 조직 전체의 발전을 위해서 일하는 모습, 진정 조직을 위하는 모습이야 말로 상사와잘 지낼 수 있고, 리딩업이 가능하다.

 

 

 

이 포스트를.. 파일로 저장

Posted by '김용환'
,