アジャイルとモジュール性の関係Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
PojoSRはJavaにサービスレジストリを持ち込む
原文(投稿日：2011/10/13)へのリンク Karl Pauls氏が PojoSR 0.1.6をリリースした。これは、完全なOSGiランタイムスタックを必要とせずにOSGi バンドルをロードでき、サービスを一緒に繋ぐことができるようにする。PojoSR が完全なOSGiプラットフォームと違うのは、ネストしたクラスローダーを使わないことである。なので構造化したOSGi環境でしばしば動かなくなる Hibernateのような行儀の悪いライブラリでも正常に動き続ける。 クラスパス(classpath )上で走っている通常のアプリケーションと違って、 PojoSRによって、フラットなクラスパス ビューからアプリケーションを μServicesで作られたクラスパス ビューへ移行できる。 Declarative Services やApache Felix Gogoシェルのような既存のOSGi バン
モジュール指向勉強会-コードリーディングを始める前に-
The document discusses Eclipse Demo Camp on September 6th at 19:00. It provides examples of code organization for a Kanban board application using YAML configuration files, OSGi bundles, and data storage with ZIP files. Code examples demonstrate parsing YAML configuration, translating data types, and loading/dumping lane data to ZIP storage. Links are included for additional OSGi documentation and
【ハウツー】概説 Springプロダクト(2) - 柔軟な配備を可能にするSpring DM (1) OSGi ? | エンタープライズ | マイコミジャーナル
本企画では、巨大になったSpringの主要プロダクトを順に取り上げ、その役割や使い方を簡単に紹介している。 第1回目となる前回はSpringの歴史を追いながら、どのようなプロダクトがあるのかを概観した。そして今回からはいよいよ、各プロダクトの紹介に入っていく。 最初に取り上げるのは「Spring Dynamic Modules」。名前を聞いただけでは想像しづらいプロダクトだが、本稿をご覧になれば、その意義をご理解いただけるはずだ。 アプリケーションのダウンタイムを減らすために SpringFrameworkなどのDIコンテナは、アプリケーションの開発スタイルに進化をもたらした。モジュールごとの実装・テストを容易にし、シンプルで俊敏なアプリケーションの開発が容易になった。しかし、アプリケーションのデプロイのスタイルは依然進化していない。 アプリケーションサーバにJavaアプリケーションをデプ
InfoQ: Modular Java：動的なモジュール化
これからの当然の結果として、同じ名前の異なった Classオブジェクトを持つVM中に、複数のクラスローダを持つことができる、ということである。com.infoq.example.Appという名前のクラスを、同じVM上のバンドルcom.infoq.exampleのバージョン１とバージョン２の両方によってエクスポートできる。バージョン１にバインドされたクライアントバンドルは、バージョン１のクラスを得る。バージョン２にバインドされたクライアントバンドルは、バージョン２のクラスを得る。このことは、モジュールシステムにかなり普通に起きることである。同じVM上で、あるコードは、ライブラリの古いバージョンをロードする必要があり、一方（他のバンドルにある）新しいコードは、ライブラリの新しいバージョンが必要な場合である。幸いにも、OSGiは、そのような推移的な依存性を管理し、非互換なクラスに起因する問題がな
Modular Java：それは何なのか？
一般に、モジュールにはバージョン番号が割り当てられる。多くのオープンソースプロジェクトはlog4j-1.2.15.jarのように名付けられたリリースをつくる。これによって開発者は、実行時の手動検査によってではあるが、オープンソースライブラリの特定のあるバージョンが使われているかどうかをクラスパスを調査することによって決定することができる。しかし、プログラムは異なるバージョンのライブラリに対してコンパイルされていることが多い：暗黙の仮定はlog4j-1.2.3.jarに対してコンパイルしてlog4j-1.2.15.jarに対して動かしても挙動としては互換性がある、ということだ。次のマイナーバージョンにアップグレードするだけなら一般には互換性がある（これが log4j 1.3 での問題が結果として互換性のない新しいブランチ 2.0を作り出すことになった理由である）。これらの多くは一般的に制約よ
JSR277とOSGiは一つになるか？
JSR277とOSGi (別名JSR291)の状況に関する4月のニュース(source)が、JSR277の専門家グループのメーリングリスト(source)で新たな議論の火付け役となった(source)。それは、今のところ今年一番の月間投稿数を記録している。この出来事の主なドライバの一人はBryan Atsatt氏(source)である。彼は、JSR277 (モジュール) とJSR294 (スーパーパッケージ) の両方の専門家グループのメンバである。彼は、JSR277はOSGiにとって最適になりうる(source)と主張する。 最初の仕様は、実際には2つの部分からなります。それは、API/フレームワークと新しい配布形式の実装です。あいにくその区別はひどくあいまいな方法で示されています。さらに悪いことに、新しい配布形式 (".jam"ファイル) が、主役を務めることが多いのです。 それでは、J
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サイボウズ株式会社
Module classloading
Efficient data transfer through zero copy
OSGi 4.3がジェネリックスとCapabilityを導入
Gemini JPA
Bundle.update: Java EEがOSGi化し、JSR 294 が凍結に
Java 7モジュール・システムの懸念点