問題タブ [jrebel]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - IntellijIDEAJavaクラスが保存時に自動コンパイルされない
昨日、EclipseからIntelliJIDEAに切り替えました。
WebSphereServer7でもJRebelを使用しています。
Javaファイルを変更して[保存]をクリックすると、JRebelがファイルを取得するために、IntelliJがファイルを再コンパイルしないことを除いて、すべてが正常に機能しているように見えます。
Eclipseの「自動ビルド」機能はこの問題を解決しました。
IntelliJ IDEAでは、CTRL+ SHIFT+9を押して、JRebelが取得するために関連するクラスを再コンパイルする必要があります。2つのファイル間で変更を行う場合は、それぞれのファイルでこれを行う必要があります。IntelliJはすべて保存メカニズムを使用しているため、手動で再コンパイルする方法を知るのは非常に困難ですが、どちらもあまり興味がありません。
IntelliJにこれを独自に行わせる方法はありませんか?
java - IntellijでもjRebelが必要ですか?
これで、Websphereサーバーで実行されているJavaEEプロジェクトに保存時に自動増分コンパイルできるようになりました。
サーバーの起動に突然問題が発生したため、 jRebelをアンインストールしました。また、Intellijが自動コンパイルされているため、変更を「ほぼ」効果的に確認できることに気付きました( Eclipseよりも遅い)。
それで、jRebelはIntellijでも必要ですか?Websphereの設定は、下の図で確認できます。追加したEarファイルは1つだけであり、展開バージョンではありませんが、これは機能していることに注意してください。どういうわけか、jrebelはまだここで活躍していますか?jrebel.xmlはまだ存在しています。

eclipse - JRebel Config Center を表示できません
私はしばらく JRebel と Eclipse Juno を使用してきましたが、今では壊れているようです。JRebel Config Center または JRebel に関連するその他のビューを開こうとすると、「JRebel Config Center ビューは JRebel Config Center パースペクティブでのみ開くことができます!」というメッセージしか表示されません。
関連しているかどうかはわかりませんが、私のライセンスは先週期限切れになり、数日前に古いライセンス ファイルを新しいものに置き換えました。ライセンスを更新する前に機能していたことは知っていますが、後で機能したかどうかはわかりません。
java - JRebelのトラブルシューティング方法は?
JBoss 5にアプリケーション(いくつかの戦争)がありますが、JRebelで常に正しくデプロイされるとは限りません。動作する場合と動作しない場合があります。JRebelが起動しないときは、理由がわかりません。エラーはどこにもありません(コンソール、ログ、Eclipseの問題など)。JRebelログは非常に不可解であり、ヒントをまったく提供しません。何度も再起動、再構築、Eclipseが更新され、JBossに公開された後、JBossが起動し、すべてが正常に機能しています。
だから、私の質問は、JRebelのトラブルシューティングをどのように行うかです。明らかに、私はより安定した開発環境を持ちたいと思っています。
JRebelバージョン5.1.0を使用したEclipseHelios
jrebel - JRebel は、更新サイトのバージョンではなく、古いバージョンを覆い隠します
http://update.zeroturnaround.com/update-site/を RAD 8 プラグイン インストーラーに貼り付けると、最新バージョンしか表示されず、同様に機能せず、メンテナンスを強制する必要がある場合に適切ではありません。物事が常に特定の方法で機能することを確認するための特定のバージョン。
プラグイン/jrebel プラグインの古いバージョンを入手するにはどうすればよいですか??
サイトに情報がありません...
eclipse - jRebel が Application および Session Scoped Bean のロードを中断する
jRebel なしで開始すると、jetty のデバッグ ログには、次のような MyApplicationScopedBean を参照する多くのメッセージが含まれます。
しかし、jRebel を使用すると、ログには MyApplicationScopedBean に関する文字列が 1 つだけ含まれます。
なぜそれが起こる可能性があるのですか?
Maven プラグインは次のとおりです。
java - JRebelはHTMLを更新しません
Intellij IDEA(Ledaプレビュー、122.746)でJRebelプラグインを使用してJRebel5.0.0を使用しています。サーバーはGlassFishv3.1です。私のアプリケーションはWicketを使用しており、HTMLテンプレートはクラスと同じ場所に配置されています。
問題は、更新されたクラスはプロジェクトの再構築後に正常に再ロードされますが、更新されたHTMLは再ロードされないことです。たとえば、ページクラスとHTMLの両方に要素を追加すると、Wicketから例外が発生し、この要素はコードで参照されているが、マークアップには存在しないという例外が発生します。
更新されたHTMLリソースと再コンパイルされたクラスは同じディレクトリ(私がチェックした)になり、このディレクトリはに存在しrebel.xmlます(そして、再コンパイルされたクラスは実際に更新されるため、この設定は有効です)。
何が問題なのでしょう?
java - Eclipse がワークスペースで常にプロジェクトを再構築しているのはなぜですか?
JRebel を使用して、Java コードの変更を JVM にすばやく再読み込みします。これはうまくいっています!
ただし、IDE として Eclipse も使用しています。そして、なんらかの理由で、注釈を追加したり、メソッドを削除したり、その他の小さなコード変更を行ったりしただけで、Eclipse はワークスペース内のプロジェクト全体を実際に再構築できます...この再構築フェーズのために、すべてのクラスが再生成され、必要になります。 JRebel によってリロードされます。
愚かな小さなコード変更でも Eclipse が常にプロジェクトを再構築する理由をデバッグする方法はありますか? 私はエクリプスインディゴを使用しています。
ありがとう、ヨッヘン
scala - RAM ディスクからすべてを実行すると、scala のコンパイル時間が短縮されますか?
シナリオ:
私が開発に使用するマシンには、32Gb の DDR3 RAM、i7 3770、SSD が搭載されています。プロジェクトは大規模で、ほとんどの場合、インクリメンタル コンパイル中に Scala は高速にコンパイルされますが、1 つの変更が数百のファイルの再コンパイルにつながる場合があり、すべてをコンパイルするのに時間がかかり、jrebel がすべての変更されたファイルをリロードするのに時間がかかります。
質問:
RAMFS (Mac) にすべてを配置すると、コンパイルと jrebel のリロードが大幅に高速化されますか?
私の計画は、プロジェクトに直接関連するすべてのものを RAMFS パーティション (.ivy、プロジェクト ソース、.sbt、さらには JDK のコピーなど) に配置することでした。起動時または手動ですべてを実行するスクリプトを作成しますが、それは問題になりません。また、ファイル同期タスクをセットアップするので、OS に障害が発生した場合でも変更が失われる心配はありません。
アップデート:
- ログによると、java および scala ソースのうち約 400 がクリーン後にコンパイルされます。
- コア モジュールのファイルを変更した後、50 秒で 130 個のファイルを再コンパイルします。
- jrebel のリロードには #1 の後は 72 秒、#2 の後は 50 秒かかります
- -Drebel.check_class_hash=true を追加すると、#2 の後に jrebel が瞬時にリロードされます。
私はこれらの結果に非常に満足していますが、170 秒かかるコンパイル プロセスで約 5 秒間だけ CPU 使用率が最大 70% になり、コンパイル中の全体的な CPU 使用率が 20% になるため、scala コンパイルをさらに高速化する方法にまだ関心があります。
アップデート:
JVM、ソース、.ivy2、および .sbt フォルダーを RAMDISK に配置した後、コンパイル時間のみがわずかに改善されていることに気付きました: 132 秒から 122 秒 (クリーン後)。だから、苦労する価値はありません。
ノート:
クリーン後に依存関係の解決が失われないようにするためにこのアプローチを使用しているため、これは依存関係の解決を除外しています。