كيف يمكنني تخزين معلمات تكوين Java EE خارج الأذن أو الحرب؟

Question

أريد تخزين التكوين لمشروع ويب خارج مشروع الويب (ملف الأذن / الحرب). يجب أن لا يعرف التطبيق في الحاوية التي تعمل (WebSphere / JBoss وما إلى ذلك).

ما هي أفضل طريقة للتعامل مع هذا؟

هل Jndi طريقة نظيفة؟ إذا كان JNDI يمكن أن يحل مشاكلي، كيف يجب أن أقوم بتكوينه؟ (كائنات مخصصة؟)

في حالتي، هناك مفتاح بسيط فقط => أزواج القيمة (سلسلة، سلسلة) لنقاط النهاية الصابون / WS.

Answer 1

انظر الى هذا سؤال لقراءة ملف خصائص خارج ملف الحرب.

انظر الى هذا سؤال لقراءة القيم المتغيرة من JNDI. أعتقد أن هذا هو الحل الأفضل. يمكنك قراءة متغير سلسلة مع هذا الرمز:

Context initialContext = new InitialContext();
String myvar = (String) initialContext.lookup("java:comp/env/myvar");

سيعمل الرمز أعلاه على جميع الحاويات. في Tomcat تعلن ما يلي في CONF / SERVERM.XML:

<GlobalNamingResources ...>
  <Environment name="myvar" value="..."
         type="java.lang.String" override="false"/>
</GlobalNamingResources>

سيؤدي ما سبق إلى إنشاء مورد عالمي. من الممكن أيضا تحديد مورد في سياق التطبيق. في معظم الحاويات، تتوفر موارد JNDI من خلال وحدة تحكم إدارة MBEANS. يقدم البعض منهم واجهة رسومية لتحريرها. عند معظم إعادة تشغيل التطبيق مطلوبة، عند إجراء تغيير.

كيف يتم تعريف موارد JNDI وتحريرها محددة حاوية. إنها مهمة Configurator / المسؤول لتطبيق الإعدادات المناسبة.

هذه هي الفوائد التي تقدمها JNDI:

• يمكنك تحديد القيم الافتراضية للمعلمات في ملف الحرب / الأذن.
• يتم تكوين المعلمات بسهولة في الحاوية.
• لا تحتاج إلى إعادة تشغيل الحاوية عند تعديل قيمة المعلمة.

Answer 2

كان لدينا متطلبات تكوين مماثلة عند نشر WebApp للمطورين المختلفين، وعلى EC2 Amazon: كيف نقوم بفصل التكوين من التعليمات البرمجية الثنائية؟ في تجربتي، فإن JNDI معقدة للغاية، ويختلف الكثير بين الحاويات لاستخدامها. أيضا، يعد التحرير اليدوي XML عرضة للغاية لأخطاء بناء الجملة، لذلك كانت الفكرة قد ألقيت بها. لقد قررنا ذلك بتصميم بناء على عدد قليل من القواعد:

1) اسم بسيط فقط = يجب استخدام إدخالات القيمة

2) يجب تحميل تكوينات جديدة من خلال تغيير معلمة واحدة فقط

3) يجب أن تكون حربنا الثنائية إعادة تشكيلها مع إعادة توحيدها

4) لن يتم تعبئتها المعلمات الحساسة (كلمات المرور) في الثنائي

باستخدام ملفات .properties لجميع التكوين، واستخدام System.getProperty("domain"); لتحميل ملفات الخصائص المناسبة، كنا قادرين على تلبية المتطلبات. ومع ذلك، فإن خاصية النظام لا تشير إلى عنوان URL للملف، بدلا من ذلك، أنشأنا مفهوما نسميه "المجال" لتحديد التكوين للاستخدام. موقع التكوين هو دائما:
$HOME/appName/config/$DOMAIN.properties.

لذلك إذا أردت تشغيل تطبيقي باستخدام التكوين الخاص بي، فأبدأ التطبيق عن طريق تعيين المجال إلى اسمي:
-Ddomain=jason
عند بدء التشغيل، يقوم التطبيق بتحميل الملف:
/home/jason/appName/config/jason.properties
يتيح هذا للمطورين مشاركة التكوينات حتى نتمكن من إعادة إنشاء نفس الحالة من التطبيق للاختبار والنشر دون إعادة ترجمة أو إعادة التعبئة. ثم يتم استخدام قيمة المجال لتحميل .Properties من موقع قياسي، خارج الحرب المجمعة.

يمكنني إعادة إنشاء بيئة الإنتاج بالكامل في محطة العمل الخاصة بي باستخدام تكوين الإنتاج مثل:
-Ddomain=ec2والتي سوف تحميل:
/home/jason/appName/config/ec2.properties

يسمح لنا الإعداد هذا بإجراء دورات DEV / QA / إصدار مع مجموعة من الثنائيات المجمعة بالضبط، باستخدام تكوينات مختلفة في كل بيئة. لا يوجد خطر من وجود كلمات مرور / وما إلى ذلك المجمعة في الثنائيات، ويمكن للأشخاص مشاركة تكويناتهم لإعادة إنشاء القضايا التي نراها.

Answer 3

يمكنني استخدام متغير بيئة للإشارة إلى عنوان URL (والذي ربما ملف: // URL) يحتوي على التكوين الخاص بي. هذا بسيط للغاية الإعداد ولا يتطلب البنية التحتية JNDI.

إليك بعض التعليمات البرمجية (المكتوبة من الذاكرة - لم أسترم / اختبارها):

public void loadConfiguration() {
   String configUrlStr = System.getenv("CONFIG_URL"); // You'd want to use a more
                                                      // Specific variable name.
   if(configUrlStr == null || configUrlStr.equals("") {
       // You would probably want better exception handling, too.
       throw new RuntimeException("CONFIG_URL is not set in the environment."); 
   }


   try {
       URI uri = new URI(configUrlStr);
       File configFile = new File(uri);
       if(!configFile.exists()) {
          throw new RuntimeException("CONFIG_URL points to non-existant file");
       }
       if(!configFile.canRead()) {
          throw new RuntimeException("CONFIG_URL points to a file that cannot be read.");
       }
       this.readConfiguration(configFile);
   } catch (URISyntaxException e) {
       throw new RuntimeException("Malformed URL/URI in CONFIG_URL");
   }



}

Answer 4

يمكنك تخزين فقط ثم هو ملف خصائص Java العادي الموجود على مسار الفصل ويوم تحميل الخصائص فقط؟

انها واضحة وبسيطة جدا .. ما لم أفهم شيئا

Answer 5

أماكني المفضلة هي: متغيرات البيئة وملفات الخصائص (كما اقترحها Jared و Kgiannakakis أعلاه.)

جدول بيانات جدول البيانات خصائص البيئة

ومع ذلك، تتمثل إحدى حلول أبسط أخرى في الحصول على خصائص بيئة تخزين جدول البيانات.

إذا كان تطبيقك يستخدم قاعدة البيانات

• هذا سهل نسبيا للإعداد
• يعطي طريقة سهلة حقا للسيطرة / تغيير القيم
• يمكن دمجها في العملية جيدا عن طريق جعلها جزءا من البرامج النصية DB