Guiceが、コードで独自のバインディングを実行して独自のモジュールを手動で作成する方法が気に入っています。一方、CDIは、sestバインディングへのプログラムによるアクセスではなく、魔法に依存しているようです。私は間違っていますか、またはWELDで同じ効果をどのように達成できますか？
コードサンプルをいただければ幸いです...
明確化
http://code.google.com/p/google-guice/でGuiceによって提供されたビルダーパターンスタイルを使用して、プログラムでモジュール（Guice用語申し訳ありませんがCDI用語がわかりません）を構築したいと思っていました。
私は動的システムを構築していますが、Weldがクラスパスなどを動的にスキャンして型を見つけて登録するのではなく、型（インターフェイスなど）や定数などをバインドできるようにする必要があります。CDIは静的であると思います。javax.injectパッケージには、プログラムで型を実装にバインドできるインターフェースは含まれていません。
明確化パート2
元の質問の基本的な前提は、注釈が焼き付けられており、イネクターを支援するために注釈に定義されているルールを変更できないという単純な観察でした。私は当初、CDIクラスパススキャナーが内部使用の定義を構築するために使用するのと同じインターフェイスへのパブリックアクセスを望んでいました。基本的には、アノテーションを読み取ってコンテナーの定義を作成できるレイヤーが必要です。デフォルトのプロバイダーは、現在行われていることを実行するプロバイダーである可能性がありますが、他の戦略が必要な場合は、これを実行する可能性があります。
現在のアプローチの問題の1つは、異なるアノテーションを持つコンポーネント（クラス）を再利用して異なるコラボレーターを選択できないという制限です。ジャンプする前に、このステートメントを修飾させてください。そうです、プロバイダーなどで実行できますが、これにより、より多くのアーティファクトが発生します。もっと簡単な方法があるはずです。
例1
この例が不十分な場合は申し訳ありませんが、私のユースケースははるかに複雑であり、詳細が邪魔になり、はるかに長く読むことができます。
引数のために次のようないくつかのパラメータを持つURL書き換えコンポーネントがあると想像してください
- このパターンをそのパターンに置き換えます。
- 多分htmlクリーナー
この同じコンポーネントに2つの異なる置換ルールを注入したいが、htmlクリーナーインジェクターを使用したい場合は、行き詰まります。確かにこれを回避する方法はありますが、もちろんより多くのコードであるアーティファクトが必要です。
残念ながら、すべてのバインディングルールはインスタンスではなくクラスにあるため、クラスを要求するたびに、機能的に同等のインスタンスが返されます。
溶接
この質問は少し前に書かれたもので、Weldをあきらめました。魔法がどのように行われるかを指示する方法は間違っていると思います。いつ、どのようにこのアクションを繰り返したいかを制御する方法を提供せずに、これがどのように発生するかを彼らが私に指示するという事実は好きではありません。私はこの柔軟性の欠如が好きではありません。