今日の役に立たない一言 - Today’s Trifle! -

古い記事ではさまざまなテーマを書いていますが、2007年以降はプログラミング関連の話がほとんどです。

Spring Boot で javax.persistence パッケージでコンパイルエラーになる

専門学校で教えてて、数人が同じエラーを出していたのでメモ。

import javax.persistence.XXX; のところで「見つかりません」のエラーが発生。

ぐぐってみたら、ここがヒット。

java - Spring Boot - javax Import statements not working correctly - Stack Overflow

単に、pom.xml に以下の依存関係を追加し忘れているだけだった。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Matomo(アクセス解析ツール)にログインできない問題を解決した

Matomoというアクセス解析ツールを使ってるんだが、Chromeがパスワードを忘れてしまって、Matomoをアップデートした影響でログインできなくなってしまった。

パスワードをリセットしたのはいいが、「リンクを送信しました」とメッセージが出て、そのリンクをクリックしないとリセットしたパスワードが有効にならないらしい。

しかし、Matomoを設置しているVPSにはメールサーバーを設置してないから、メールを送信できない。

mysqlで直接パスワードを変更しても、そのパスワードが有効になってないらしく、ログインできない。

困った。

何か方法はないかと考えて、要するにメールで送信されているURLを取得すればなんとかなるだろうと思った。

パスワードをリセットしたあとにメールを送信しているところを検索する。

$ grep 'mail->send()' `find . -name '*.php' -print`

PasswordResetter.php というクラスでメールを送信しているらしいので、そこをちょっと変更する。

メールを送信したところで、メール本文をファイルに出力する。

        @$mail->send();
        error_log($bodyText, "3", "/tmp/matomo.log");

これで、パスワードをリセットしたときに送信される本文が保存された。

ファイルを開いて、リンク部分をコピーしてブラウザに貼り付けてアクセスしたら、無事に「パスワードが変更されました。」と表示されて、ログインできるようになった。

xmlrpc.phpで投稿するときに「parse error. not well formed」が出るときの対策

XMLRPCでWordPressに記事を投稿したときに、こんなエラーが出た。
うまくいくときもあれば、エラーになるときもある。

警告: main::Post 記事投稿で失敗, status=parse error. not well formed
org.apache.xmlrpc.XmlRpcException: 構文解析エラー。not well formed
	at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:197)

HTMLタグが多いときに発生している雰囲気。

いろいろとぐぐってみたら、こんな対策が。

石けんで髪を洗う | 山頂晴れて - 楽天ブログ

これの3番めにあるモジュールの訂正。

xmlrpc.php の27行目あたりを修正しろと。
この部分を、

$HTTP_RAW_POST_DATA = trim($HTTP_RAW_POST_DATA);

このように。

$HTTP_RAW_POST_DATA = mysql_escape_string(trim($HTTP_RAW_POST_DATA));

これで投稿はできるようになったけど、HTMLのタグがエスケープされててきちんと表示されないし。

だめじゃん。

で、いまのところ解決策は見つからないまま。

同じコードで問題なく記事を投稿できるWordPressもあるんだけど、できないWordPressもある。

いろいろと謎である。

タイトルに「対策」と書いたのに、対策を書けないまま。

タイトル詐欺である。

XMLRPCでカテゴリとタグ付きでブログ記事を投稿する方法

ブログに記事を投稿するのに、カテゴリとタグを指定して投稿しようとしたんだけど、なかなかうまくいかなくて試行錯誤して、やっとうまくいったのでまとめとく。

カテゴリとタグをString配列にしてMapに格納するのがポイントだったらしい。

	XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
	String url = "http://memo.satoshis.jp/xmlrpc.php";
	config.setServerURL(new URL(url));

	XmlRpcClient client = new XmlRpcClient();
	client.setConfig(config);
	Hashtable<Object,Object> hash = new Hashtable<>();
	hash.put("post_title", title);// 記事のタイトル
	hash.put("post_content", contents);// 本文
	hash.put("post_author", "1"); //
	hash.put("post_status", "publish"); // 一般公開

	Map<String, Object> terms = new HashMap<>();
	terms.put("category", categories); // カテゴリをString配列で
	terms.put("post_tag", tags); // タグをString配列で
	hash.put("terms_names", terms);

	Object[] params = new Object[5];
	params[0] = "1"; // BlogID
	params[1] = "userid";
	params[2] = "password";
	params[3] = hash;
	params[4] = true;
	Object result = client.execute("wp.newPost", params);

mysqldが起動しなくなったときの対処方法

クラウド上で動かしているmysqlでcreate databaseとdrop database の操作を繰り返してたら、mysqlが無応答になってしまった。
CentOSをリブートしてみたけど、やはりmysqldが起動しない。

ぐぐってみたら、こちらがヒット。

[手順] MySQL データベースでの InnoDB 破損を修復するには – ヘルプセンター

バックアップして、my.cnfを変更して、復旧させる方法らしい。

# mkdir /root/mysql_backup
# cp -a /var/lib/mysql/* /root/mysql_backup/
# vi /etc/my.cnf
[mysqld]
innodb_force_recovery = 1

このあとで mysqld を起動させるってことだけど、やはり起動しない。

# /etc/rc.d/init.d/mysqld start
MySQL Daemon failed to start.
Starting mysqld:

さらなる情報をもとめてぐぐる
こちらがヒット。

Resolved - MYSQL database is not starting since today morning | Plesk Forum

forcing InnoDB Recovery solution has not working for me. I have fixed the issue as follows:

1) remove the syslog entry under --> /etc/mysql/conf.d/mysqld_safe_syslog.cnf
2) backup & remove both ib_logfile0 & ib_logfile1 files under --> /var/lib/mysql
3) remov entry innodb_force_recovery = 1 from --> etc/mysql/my.cnf
4) command --> sudo service mysql start
5) server is starting and works fine again without loosing any data

1にあるファイルはなかったので無視。
2のバックアップはすでにやっている。追加で ib_logfile[01] を削除した。
3のmy.cnfの修正、さきほど追加した1行を削除。
4でmysqldを起動。

サクッと起動した!

ib_logfile[01]が壊れていたらしい。

再起動後、削除したファイルは復活してた。

# ls -l /var/lib/mysql/ib_logfile*
-rw-rw---- 1 mysql mysql 50331648 Aug  1 14:20 /var/lib/mysql/ib_logfile0
-rw-rw---- 1 mysql mysql 50331648 Aug  1 13:45 /var/lib/mysql/ib_logfile1