3
Es ist notwendig, einen Teil von EAR (nämlich - Krieg) in OSGI-Bundle umzuwandeln und seine Interoperabilität beizubehalten. Glassfish 3.0.1 hat bereits osgi-web-container Modul und es ist mir gelungen, Standalone-OSGI-Krieg zu implementieren.korrekte Möglichkeit, EAR-Modul in OSGI-Bundle zu verwandeln
Aber im Falle eines Ex-Enterprise-Krieges sieht es ein bisschen schwierig für mich aus.
- Was mache ich mit EJB-Anrufe von in zukünftigen OSGI-Krieg? Ist es genug zu ersetzen
@EJBInjektionen mit echten JNDI Lookups? - Was ist mit APIs und Bibliotheken freigegeben über EAR? Ich könnte teilen und sie neu anordnen, aber immer noch werde ich haben mindestens ein Glas von beiden benötigt EAR und OSGI Krieg. Dupliziere es, mach es als OSGI-Bundle selbst und mache es für Ohr irgendwie verfügbar, stell es GF domain's library path?
- Irgendwelche anderen Ideen, Ratschläge, die dieses hybride Arbeiten machen konnten?
Vielen Dank! Werde versuchen. Ich glaube, du bist derselbe Sahoo, der die http://www.java.net/blogs/ss141213/ besitzt? Wenn ja, würde ich Ihre Antwort zehn Mal abstimmen, wenn ich könnte :) Und hier ist eine kleine Frage: Ist Ihre Antwort auf GF 3.0.1 anwendbar oder impliziert sie 3.1 Builds? Ich würde gerne bei der offiziellen Version 3.0.1 bleiben, wenn möglich. – Osw
Ja, ich bin leider derselbe Bösewicht. Was ich gesagt habe, gilt auch für 3.0.1, obwohl ich sehr empfehlen werde, auf 3.1 zu aktualisieren, wenn es sehr bald herauskommt, weil ich eine Reihe von Problemen in osgi-web-container in Version 3.1 behoben habe. – Sahoo