yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2018/01 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
60*60*24*30秒ルール
2009/12/27(Sun)23:51:22
 内閣が「1ヶ月ルール」を無視して中国側との会見を設定したことについて、「天皇の政治利用」との批判がなされています。問題山積みの内閣の状況からすれば、この問題はさして重要なものとはみなされていないようで、事実として数週間もしないうちにほとんど忘れ去られています。私も当初は静観するつもりでしたが、今後またもや同様の状況が発生した際、いちいち同様の騒ぎを繰り返すのは大変非合理的ですので、あえてここで取り上げておきます。
 まず「1ヶ月ルール」とは何かといいますと、外国の要人が天皇との会見を希望する場合に、事の大小や相手国の立場にかかわらず、1ヶ月以上前に文書によって申請しなければならないという慣例のことです。これは1995年(自民・社民・さきがけ政権時)に文書化されたものですが、特に拘束力はなく守られない場合もあったため、2004年に天皇が腫瘍摘出手術を行ってからは、健康上の理由もあって厳格に適用されるようになったとされています。ただ、2005年のスマトラ沖地震によってタイが大きな被害を受けた際には、事情が事情だけにルールの適用が見送られ、タイ側との会見が実現しています。
 本件が政治利用であるとされるのは、米国などを含めてあらゆる国に対して等しくこのルールを適用してきたはずが、「政治的な重要性」を理由に本ルールを無視し、中国側との会見が設定されたためのようです。
 結局、本件については宮内庁長官の羽毛田氏が「政治的利用じゃないかといわれれば、そうかなという気もする」「こういうことは二度とあって欲しくない」などと発言し、これに対して小沢氏が反論、これに羽毛田氏が再反論するなど、泥沼化の様相を見せはしたものの、うやむやのまま終息に向かっている状況です。どちらの言い分が守られるべきかも合意を見ておらず、再び似たような状況が発生する可能性は否定できません。
 ここで私の意見を述べておくなら、私は小沢氏と羽毛田氏の両方の言い分を支持しません。「1ヶ月ルール」に対する主張だけを見比べてみれば、小沢氏の方に正当性があるものの、氏が述べた理由は完全に破綻しており、およそ支持できるものではないためです。
 まず重要な点として、この「1ヶ月ルール」は何らかの法によって厳密に定められたわけではなく、ただの慣例に過ぎません。したがって、慣例に反するようなケースが発生することは十分に予想できたはずで、法的義務も何もない慣例ルールを絶対視して「ルールに反するのは天皇の政治利用」などとは本末転倒もはなはだしい言い分です。
 ましてや、法で厳密に定められたわけでもない慣例を絶対視し、これを義務として扱うのであれば、慣例を定める立場にある者が天皇に関して立法に匹敵する権限を持つことになりかねず、天皇の権力が恣意的に利用されてしまう恐れがあります。そして実際、現状ではあくまで慣例は慣例に過ぎないはずが、それを無視すればこれだけ批判の大合唱を浴びるとなれば、実質的に慣例を破る行為は非常に難しく、現状でもその懸念は存在しているといえるでしょう。
 この点からすれば、小沢氏が怒って「あいつ(羽毛田氏)こそどうかしている。天皇の権威をかさにきている」と吐き捨てたのは、言い方にこそトゲがありますが、ある意味では事実です。1つの庁の長官である役人が、厳密に法にて定められたわけでも何でもない「慣例」の遵守を政府に対して強要する権限など、持っていようはずがありません。
 そもそも、私はこうした「慣例」自体に大きな疑念を持っています。今回の問題が発覚するまで、一体どれほどの国民が「1ヶ月ルール」なるものの存在を認識していたのでしょうか。かく言う私も全く知りませんでした。また、社民党党首の福島氏が本ルールを知らなかったと言っていることからして、議員の間にも知らない人は存在するようです。
 これは一体何を意味するのでしょうか。すなわち、国民も議員も知らない場所で、下手すると立法並みの権限を持つ「慣例」がひっそりと作られ、既成事実とされていっているのです。これはあくまで慣例に過ぎないはずですが、前述の通り破ることは非常に困難です。小沢氏らの政治利用以前の問題として、このような慣例至上主義こそ権力の恣意的な利用に結びつきかねません。
 また、「天皇の健康上の理由」なる言い分にも注意が必要です。確かに、「公務」なるものによって天皇という尊い一個人の健康が損なわれるのは避けるべきですから、健康への配慮に反対する理由はありません。しかしながら、健康問題を理由とした慣例をなし崩し的に認めてしまうと、やはり上記のような問題が発生する可能性がありますし、最悪の場合には天皇の健康を名目にした権力利用が行われてしまわないとも限りません。これでは「健康に配慮」どころか、健康までもが道具にされてしまいます。したがって、健康問題を含むいかなる理由があろうと、慣例には慣例以上の価値を持たせてはいけません
 そもそも本件自体、実際には単に「慣例」に反しただけに過ぎず、厳密に法によって定められた規定を破る違法行為を行ったわけでもなく、法による規制でも何でもない「慣例」を無視した程度で違憲批判もへったくれもなく、本来なら別に政治問題にも何にもならなかったところを、宮内庁や長官の羽毛田氏が無駄に騒ぎ立てて政治問題に仕立て上げてしまった部分があります。さらに、これを政府・与党攻撃の好機と見た野党が「悪乗り」し、マスコミも騒ぎに便乗し、慣例問題よりもまず「中国憎し」が頭にある人々も騒ぎを大きくし、無用な騒動を作り出してしまいました。こうなると、天皇会見問題が別の意味で「政治問題」化してしまうのですから、皮肉としか言いようがありません。
 一方、小沢氏や政府側の言い分の不当性にも触れておかなくてはなりません。例えば小沢氏は、本会見を「天皇陛下ご自身に聞いてみたら、手違いで遅れたかもしれないが会いましょうと必ずおっしゃると思う」などと正当化していますが、これは全く本質的な主張ではないばかりか、別の疑念を生み出しています。小沢氏が「天皇がやると言ったら正当で、そうでなければ不当である」と考えているなら、天皇の立場上まずあり得ないとはいえ、仮に天皇が拒絶したなら自分の非を認めるのでしょうか。もしくは、仮に天皇が会見を断った場合、天皇が会見に同意した相手とのみ会見を設定すべきと考えているのでしょうか。そうなると、それこそ天皇の権力が恣意的に使われる事態になりかねませんが、小沢氏がいかなる考えを持っているのかが気になります。
 さらには、政府は「中国は重要だから政治的利用ではない」などといった主張も行っているようですが、この言い分は完全に破綻していると言わざるを得ません。もし本気でそのようなことを言っているのであれば、今回のようなゴタゴタが二度と発生しては困りますので、政府は「1ヶ月ルールに縛られない重要な国リスト」と「慣例を無視するまでもない取るに足らない国リスト」を一覧にして公開し、どの国なら慣例を無視するまでもないほど重要でないのか明確にしなくてはなりません。それができないのであれば、このような意味の分からない主張はやめるべきです。
 そして私は何より、今回の件によって「慣例」に過ぎないものが法と同等の権威を持ってしまうことを強く危惧しています。実際にそのような意見もマスコミなどを中心に散見され、見過ごせない状態になっています。もし1ヶ月ルールに合理性があり、これを絶対に遵守する必要があるというのなら、国民の代表たる議会が法的なルールとして明確に定めれば良いことです。いつ、どこで、誰が、どのように、何の目的で作ったとも知れない「慣例」が法律並みに機能し、しかもそれを役人が運用できるのであれば、それは不健全な状態であると言わざるを得ません。

 GlassFish v3の目玉といえば、ここまでに使ってみたServlet 3.0やJSF 2.0の他、EJB 3.1とJPA 2.0が代表的です。当初はEJBを動かすことができませんでしたが、DIの方法を色々と試してみたところ、何とかEJBとJPAが動作しましたので、その覚書をしたためておきます。
 Servlet 3.0とEJB 3.1の面白い点として、以前まではこれらをそれぞれwarとjarに格納し、earを作ってデプロイする仕組みとなっていましたが、今回からはEJBをclasses以下に配置し、すべてwarとして格納してデプロイしてしまっても正しく認識されます。その際にapplication.xmlもweb.xmlも書く必要がないため、単純なServlet + EJBであればXMLを1つも書かなくても動作してしまいます。このような仕様となったためか、GlassFish v3 PreviewのAdminコンソールでは「Enterprise Application」や「EJB Application」などといった区分がなくなっており、すべて「Applications」として管理されています(正式版でどうなるのかは不明)。その際、リストの「Engines」項目に[ejb, jpa, web]などと表示され、何が含まれているのかが分かるようになっています。
 JPAを使用する場合はpersistence.xmlを書かなくてはなりませんが、EJB + JPA + Servletであっても必要なXMLはこれだけです。しかも全部classesに格納できるため、構成が非常にすっきりします。さらに、デバッグに便利なディレクトリデプロイを使用する場合、warのルートになるであろうディレクトリ1つ指定するだけで平然と動くため、動作テストを行うにも大変便利です。
 本来ならJPA 2.0の目玉である悲観的ロックやCriteria APIなども使ってみるべき場面ですが、なぜかGlassFishの調子が非常に悪く、v2であれば明らかに動作するコードでも例外を投げてきたり、persistence.xmlでcreate-tablesを設定していてもテーブルを作ってくれる時と作ってくれない時があったり(何度もリデプロイを繰り返すと「そのうち作成される」という素敵な状態)、ジェネリックス対応のcreateQueryなどに至っては実装されていなかったりするため、今後の楽しみにしておきます。
 今回はとにかくEJB + JPA + Servletを動かすのみであるため、以下のような大変単純な構成としました。
/WEB-INF
 /classes
  /com
   /yamicha
    /ejb31test
     EJB31Test.java
     EJB31Servlet.java
     Persistence20Table.java
  /META-INF
   persistence.xml
 当初、META-INFをルートに置くかclassesに置くかで迷いましたが、Servletのclasses内にEntityクラスを置く場合には、META-INFもclassesに置くのが正解でした。これ以外のXMLは不要で、すべてアノテーションで代用しています。
 Servlet 3.0のアノテーション及びEJBをclassesに置いている以外の点は、ほとんど以前までのEJBと同じです。ただ、以前のTopLinkはEclipseLinkに名称変更されており、persistence.xmlもそれに伴ってプロパティ名などが変わっています。
<?xml version="1.0" encoding="UTF-8"?>

<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
  <persistence-unit name="MySQL" transaction-type="JTA">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <jta-data-source>jdbc/MySQL</jta-data-source>
    <properties>
      <property name="eclipselink.jdbc.driver"
        value="com.mysql.jdbc.Driver" />
      <property name="eclipselink.ddl-generation"
        value="create-tables" />
      <property name="eclipselink.ddl-generation.output-mode"
        value="database" />
      <property name="eclipselink.target-database" value="MySQL" />
      <property name="eclipselink.logging.level" value="FINE"/>
    </properties>
  </persistence-unit>
</persistence>
 後はごく普通のEJBとServlet 3.0です。
// WEB-INF\classes\com\yamicha\ejb31test\EJB31Test.java
package com.yamicha.ejb31test;

import javax.ejb.*;
import javax.annotation.*;
import javax.persistence.*;
import java.util.List;

@Remote @Stateless(name="EJB31Test" , mappedName="ejb/EJB31Test")
	public class EJB31Test{
	@PersistenceContext(unitName="MySQL") private EntityManager em;

	public void addRecord(String msg){
		em.persist(new Persistence20Table(msg));
	}
	public List<Persistence20Table> getRecords(){
		return (List<Persistence20Table>)
			em.createQuery(
			"SELECT p FROM Persistence20Table p").
			getResultList();
		// JPA 2.0 にはせっかく以下のような
		// TypedQuery<T> createQuery(String , Class<T>)
		// おあつらえむきのものがあるのに
		// どういうわけか JAR に含まれていない...
	}
}

// WEB-INF\classes\com\yamicha\ejb31test\Persistence20Table.java
package com.yamicha.ejb31test;

import javax.sql.*;
import javax.persistence.*;

@Entity @Table(name="per20table" , schema="yamicha")
	public class Persistence20Table
	implements java.io.Serializable{
	private int id;
	private String name;

	public Persistence20Table(){
	}
	public Persistence20Table(String s){
		name = s;
	}

	@Id @Column(name="id") @GeneratedValue public int getId(){
		return id;
	}
	@Column(name="name") public String getName(){
		return name;
	}

	public void setId(int i){
		id = i;
	}
	public void setName(String s){
		name = s;
	}
}


// WEB-INF\classes\com\yamicha\ejb31test\EJB31Servlet.java
package com.yamicha.ejb31test;

import javax.servlet.annotation.*;
import javax.ejb.*;
import javax.annotation.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.persistence.*;
import java.io.*;
import java.util.List;

@WebServlet(name="ejb31servlet" , urlPatterns={"/*"})
	public class EJB31Servlet extends HttpServlet{
	@EJB(beanName="EJB31Test") private EJB31Test test;

	public void doGet(HttpServletRequest request ,
		HttpServletResponse response) throws IOException{
		response.setContentType("text/plain");
		PrintWriter out = response.getWriter();

		test.addRecord("EJB 3.1");
		test.addRecord("Java Persistence API 2.0");
		test.addRecord("Servlet 3.0");
		test.addRecord("JSF 2.0");

		List<Persistence20Table> records = test.getRecords();
		for(Persistence20Table record : records)
			out.println(record.getName());

		out.close();
	}
}
 よりいっそう「必要な部分だけ書けば動く」ようになっており、昔の惨劇としか言いようがなかったEJBとは大違いです。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

- Blog by yamicha.com -