نحن ننفذ OSGI على منصة Karaf

OSGI ليست صعبة

لقد قابلت عدة مرات أن OSGI صعب. وعلاوة على ذلك ، كان هو نفسه ذات مرة مثل هذا الرأي. عام 2009 ، ليكون بالضبط. في ذلك الوقت ، جمعنا مشاريع باستخدام Maven Tycho ، ونشرناها على الإعتدال. وكان الأمر أصعب من تطوير وتجميع مشاريع لـ JavaEE (في تلك اللحظة ، ظهر إصدار EJB 3 فقط ، والذي تحولنا إليه). كان الاعتدال أقل ملاءمة بكثير من Weblogic ، على سبيل المثال ، ولم تكن فوائد OSGI واضحة بالنسبة لي في ذلك الوقت.

ولكن بعد ذلك ، بعد سنوات عديدة ، اضطررت لبدء مشروع في وظيفة جديدة ، تم تصميمها على أساس Apache Camel و Apache Karaf. لم تكن فكرتي ، فقد عرفت الجمل لفترة طويلة بحلول ذلك الوقت ، وقررت أن أقرأ عن Karaf ، حتى بدون عرض. لقد قرأت ذلك في إحدى الأمسيات وأدركت - إنه بسيط وجاهز ، وهو نفس الحل تقريبًا لبعض مشكلات JavaEE النموذجية ، على غرار ما فعلته ذات مرة على ركبتي باستخدام Weblogic WLST و Jython و Maven Aether.

لذلك ، لنفترض أنك قررت تجربة OSGI على منصة Karaf. من أين نبدأ؟

إذا كنت تريد فهم أعمق

يمكنك بالطبع البدء بقراءة الوثائق. وهذا ممكن مع حبري - كانت هناك مقالات جيدة للغاية هنا ، دعنا نقول هذا منذ زمن طويل. لكن بشكل عام ، تلقى الكاف حتى الآن القليل من الاهتمام غير المستحق. كان هناك بضع ملاحظات أكثر هذا أو هذا . من الأفضل تخطي ذكر الكرف. كما يقولون ، لا تقرأ الصحف السوفيتية خلال الليل ... لأنهم سيخبرونك أن الكرف هو إطار عمل لـ OSGI - لذلك لا تصدقه. أطر عمل OSGI هي Apache Felix أو Eclipse Equinox ، والتي يعمل على أساسها الكرف. يمكنك اختيار أي منهم.

تجدر الإشارة إلى أنه عند ذكر Jboss Fuse ، أو Apache ServiceMix ، ينبغي قراءتها على أنها "Karaf ، مع المكونات المثبتة مسبقًا" ، أي في الواقع - نفس الشيء ، التي تم جمعها فقط من قبل البائع. لا أوصي بالبدء بهذا في الممارسة العملية ، لكن من الممكن تمامًا قراءة مقالات المراجعة حول ServiceMix ، على سبيل المثال.

بادئ ذي بدء ، سأحاول هنا تحديد باختصار ما هو OSGI وما يمكن استخدامه من أجله.

بشكل عام ، OSGI هي أداة لإنشاء تطبيقات Java من الوحدات النمطية. يمكن اعتبار تناظرية وثيقة ، على سبيل المثال ، JavaEE ، وإلى حد ما ، يمكن لحاويات OSGI تنفيذ وحدات JavaEE (على سبيل المثال ، تطبيقات الويب في شكل حرب) ، ومن ناحية أخرى ، تحتوي العديد من حاويات JavaEE على OSGI داخل كوسيلة لتنفيذ وحدات "لأنفسهم ". أي أن JavaEE و OSGI هما أشياء مشابهة للتوافق ، ومكملة بنجاح.

جزء مهم من أي نظام وحدات هو تعريف الوحدة نفسها. في حالة OSGI ، تُسمى الوحدة حزمة ، وهي أرشيف جرة معروف جيدًا لجميع المطورين مع بعض الإضافات (أي أنه مشابه جدًا هنا ، على سبيل المثال ، للحرب أو الأذن). عن طريق القياس مع JavaEE ، يمكن للحزم تصدير واستيراد خدمات ، والتي هي أساسًا من أساليب الفصل (أي ، الخدمة عبارة عن واجهة ، أو كل الطرق العامة للفصل).

بيانات تعريف الحزمة مألوفة لدى الجميع META-INF / MANIFEST.MF. لا تتقاطع رؤوس بيان OSGI مع رؤوس JRE ، على التوالي ، خارج حزمة حاوية OSGI جرة عادية. من المهم أن هناك دائمًا بين البيانات الوصفية:

Bundle-SymbolicName: com.example.myosgi Bundle-Version: 1.0.0 

هذه هي "إحداثيات" الحزمة ، وحقيقة أنه يمكن أن يكون لدينا إصداران أو أكثر مثبتان في وقت واحد ويعملان من نفس الحزمة في حاوية واحدة أمر مهم.

على غرار JavaEE ، يكون للحزم دورة حياة تبدو كما يلي: بالإضافة إلى الخدمات ، يمكن للحزم أيضًا استيراد وتصدير الحزم (الحزم ، بالمعنى المعتاد لعبارة java). يتم تعريف الحزم التي تم تصديرها داخل الحزمة ، ويتم إتاحتها للمكونات الأخرى عند تثبيت الحزمة على النظام. يتم تعريف العناصر المستوردة في مكان ما من الخارج ، ويجب أن يتم تصديرها من قبل شخص ما ، وتقديمها إلى الحزمة بواسطة الحاوية قبل أن تبدأ العمل.

قد يتم الإعلان عن واردات الطرود اختيارية ، بالإضافة إلى واردات الخدمة. ومن المهم للغاية أن الاستيراد والتصدير يحتوي على إشارة إلى الإصدار (أو مجموعة من الإصدارات).

الاختلافات من JavaEE

حسنًا ، من الجيد أن يكونوا متشابهين - فهمنا. وكيف تختلف؟

في رأيي ، الفارق الرئيسي هو أن OSGI يعطينا المزيد من المرونة. بمجرد أن تكون الحزمة في حالة البدء ، تكون الإمكانيات محدودة فقط بخيالك. لنفترض أنه يمكنك بسهولة إنشاء سلاسل رسائل (نعم ، نعم ، أعرف عن ManagedExecutorService) ، تجمعات الاتصال بقواعد البيانات ، إلخ. لا تتحكم الحاوية في جميع الموارد بالقدر نفسه الذي تستخدمه JavaEE.

يمكنك تصدير خدمات جديدة في هذه العملية. حاول القول في JavaEE بشكل حيوي إنشاء servlet جديدة؟ وهنا ، من الممكن تمامًا ، علاوة على ذلك ، سيتم اكتشاف حاوية servlet التي تم إنشاؤها على أساس رصيف الميناء على الفور بواسطة servlet التي قمت بإنشائها وستكون متاحة للعملاء على عنوان URL محدد.

على الرغم من أن هذا تبسيط بسيط ، ولكن إذا كان تطبيق JavaEE في شكله الكلاسيكي يتكون أساسًا من مكونات:

• السلبي ، في انتظار مكالمة من العميل
• محددة بشكل ثابت ، وهذا هو ، في وقت نشر التطبيق.

من ناحية أخرى ، قد يحتوي تطبيق يستند إلى OSGI على:

• المكونات المجدولة النشطة وغير النشطة ، إجراء الاستطلاعات ، جيدًا ، الاستماع إلى مأخذ توصيل ، إلخ
• يمكن تعريف الخدمات ونشرها بشكل حيوي
• يمكنك الاشتراك في الأحداث الإطارية ، على سبيل المثال ، الاستماع إلى تسجيل الخدمات ، والحزم ، وما إلى ذلك ، وتلقي روابط إلى حزم وخدمات أخرى ، والمزيد.

نعم ، على JavaEE ، الكثير من هذا ممكن جزئيًا أيضًا (على سبيل المثال ، من خلال JNDI) ، ولكن في حالة OSGI ، في الواقع العملي أصبح الأمر أسهل. على الرغم من وجود بعض المخاطر على الأرجح هنا.

الاختلافات بين الكراف و OSGI النقي

بالإضافة إلى إطار الكراف ، هناك الكثير من الأشياء المفيدة. في جوهرها ، تعد kaf أداة لإدارة إطار عمل OSGI بشكل مريح - تثبيت الحزم (بما في ذلك المجموعات) هناك ، وتهيئتها ، والمراقبة ، ووصف نموذج الدور وضمان الأمن ، وما شابه ذلك.

ودعونا نمارس بالفعل؟

حسنًا ، دعنا نبدأ التثبيت فورًا. لا يوجد الكثير للكتابة هنا - اذهب إلى karaf.apache.org ، قم بتنزيل حزمة التوزيع ، قم بفكها. تختلف إصدارات الكراف في دعم مواصفات OSGI المختلفة (4 أو 5 أو 6) وإصدارات Java. لا أوصي بعائلة 2.x ، ولكن هنا 3 (إذا كان لديك جافا 8 ، مثل بلدي) ، ويمكن استخدام 4 ، على الرغم من أن عائلة 4.x فقط تتطور (الإصدار الحالي 4.2.2 ، يدعم OSGI 6 وجافا تصل إلى 10).

يعمل Karaf بشكل جيد في نظامي التشغيل Windows و Linux ، كل ما تحتاجه لإنشاء خدمة وتشغيل تلقائي متاح. تم الإعلان أيضًا عن دعم MacOS والعديد من أنواع Unix الأخرى.

يمكنك عادة بدء تشغيل الكرف على الفور إذا كنت على الإنترنت. إذا لم يكن الأمر كذلك ، فعادةً ما يكون من المفيد إصلاح ملف التكوين ، مع الإشارة إلى المكان الذي قمت فيه بتخزين مستودع (مستودعات) التخزين. عادةً ، سيكون Nexus للشركات ، أو يقول Artifactory ، من يحب ما. يوجد تكوين الكارفة في مجلد التوزيع. أسماء ملفات التكوين ليست واضحة جدًا ، ولكن في هذه الحالة ، تحتاج إلى ملف org.ops4j.pax.url.mvn.cfg. تنسيق هذا الملف هو خصائص جافا.

يمكنك تحديد مستودع (مستودعات) على حد سواء في ملف التكوين نفسه ، أو سرد قائمة عناوين URL في الإعدادات ، أو ببساطة إظهار أين تكمن الإعدادات الخاصة بك. هناك ، سيأخذ موقع الكاراف موقع وكيلك ، وهو أمر ضروري عادة لمعرفته على الإنترانت.

يحتاج كافار إلى عدة منافذ ، هذه هي HTTP و HTTPS (إذا تم تكوين الويب ، بشكل افتراضي لا) و SSH و RMI و JMX. إذا كانت مشغولة بك ، أو كنت ترغب في تشغيل عدة نسخ على المضيف نفسه ، فسيتعين عليك تغييرها أيضًا. هناك ما يقرب من خمسة من هذه المنافذ.

المنافذ مثل jmx و rmi - هنا: org.apache.karaf.management.cfg، ssh - org.apache.karaf.shell.cfg ، لتغيير منافذ http / https ، ستحتاج إلى إنشاء (على الأرجح) منافذ etc / file org.ops4j.pax.web.cfg ، واكتب القيمة org.osgi.service.http.port = المنفذ الذي تحتاجه فيه.

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

يمكنك بدء تشغيل Karaf على الفور باستخدام وحدة التحكم ، أو الأمر karaf ، أو يمكنك تشغيله في الخلفية باستخدام أمر start server ، ثم الاتصال به عبر SSH. هذا SSH قياسي تمامًا ، مع دعم لـ SCP و SFTP. يمكنك تنفيذ الأوامر ونسخ الملفات جيئة وذهابا. من الممكن الاتصال بأي عميل ، على سبيل المثال ، أداتي المفضلة هي Far NetBox. تسجيل الدخول متاح عن طريق تسجيل الدخول وكلمة المرور ، وكذلك عن طريق المفاتيح. في الجملونات jsch ، مع كل ما يدل عليه.

أوصي بوجود نافذة وحدة تحكم إضافية على الفور لعرض السجلات الموجودة في data / log / karaf.log (والملفات الأخرى عادة ما تكون موجودة ، على الرغم من أن هذا قابل للتخصيص). السجلات مفيدة لك ، من الرسائل القصيرة في وحدة التحكم ، وليس كل شيء واضح.

أنصح بتثبيت الويب على الفور ، ووحدة التحكم hawtio على الويب. هذان الشيئان سوف يسهلان عليك التنقل فيما يحدث في الحاوية وتوجيه العملية من هناك إلى حد كبير (على سبيل المكافأة ، ستحصل على jolokia والقدرة على المراقبة عبر http). يتم تثبيت hawtio بواسطة أمرين من وحدة التحكم في kafaf ( كما هو موضح هنا ) ، وللأسف ، لم يعد إصدار kaf 3.x معتمدًا اليوم (سيتعين عليك البحث عن الإصدارات الأقدم من hawtio).

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

حسنا ، لقد بدأت ، ماذا بعد؟

في الواقع ، ماذا تتوقع؟ قلت أنه سيكون سه. تبويب يعمل ، إذا كان ذلك.

حان الوقت لتثبيت بعض التطبيقات. يعد تطبيق OSGI حزمة أو يتكون من عدة حزم. يمكن لـ Karaf نشر التطبيقات بعدة صيغ:

• حزمة جرة ، مع أو بدون بيان OSGI
• XML تحتوي على Spring DM أو Blueprint
• xml يحتوي على ما يسمى الميزة ، وهي عبارة عن مجموعة من الحزم والميزات والموارد الأخرى (ملفات التكوين)
• .kar أرشيف يحتوي على العديد من الميزات ومستودع مخضرم مع التبعيات
• تطبيقات JavaEE (تحت بعض الشروط الإضافية) ، على سبيل المثال .war

هناك عدة طرق للقيام بذلك:

• ضع التطبيق في مجلد النشر
• تثبيت من وحدة التحكم باستخدام الأمر install
• تثبيت ميزة مع الأمر من الميزة: تثبيت وحدة التحكم
• كار: تثبيت

حسنًا ، بشكل عام ، يشبه هذا تمامًا ما يمكن أن تفعله حاوية JavaEE النموذجية ، لكنه أكثر ملاءمة إلى حد ما (يمكنني القول إنها أكثر ملاءمة).

جرة بسيطة

الخيار الأسهل هو تثبيت جرة عادية. إذا كان لديك في مستودع maven ، فإن الأمر يكفي للتثبيت:

 install mvn:groupId/artifactId/version 

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

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

تستخدم هذه الطريقة لتثبيت مكونات مثل Apache Commons Lang ، على سبيل المثال:

 install mvn:org.apache.commons.lang3/commons-lang/3.8.1 

لكنها لم تنجح :) إليك الإحداثيات الصحيحة:

 install mvn:org.apache.commons/commons-lang3/3.8.1 

دعونا نرى ما حدث: list -u ستظهر لنا الحزم ومصادرها:

 karaf@root()> list -u START LEVEL 100 , List Threshold: 50 ID | State | Lvl | Version | Name | Update location ------------------------------------------------------------------------------------------------- 87 | Installed | 80 | 3.8.1 | Apache Commons Lang | mvn:org.apache.commons/commons-lang3/3.8.1 88 | Installed | 80 | 3.6.0 | Apache Commons Lang | mvn:org.apache.commons/commons-lang3/3.6 

كما ترى ، من الممكن تمامًا تثبيت إصدارين من مكون واحد. تحديث الموقع - هذا هو المكان الذي حصلنا فيه على الحزمة ، وحيث يمكن تحديثها إذا لزم الأمر.

جرة وسياق الربيع

إذا كان هناك سياق ربيعي داخل مرطبانك ، فإن الأمور تصبح أكثر إثارة للاهتمام. يبحث Karaf Deployer تلقائيًا عن سياقات xml في المجلد META-INF / spring ، ويقوم بإنشائها إذا تم العثور على جميع الحزم الخارجية المطلوبة بواسطة الحزمة بنجاح.

وبالتالي ، فإن جميع الخدمات التي كانت داخل السياقات ستبدأ بالفعل. إذا كان لديك Camel Spring هناك ، على سبيل المثال ، فستبدأ مسارات Camel أيضًا. هذا يعني أننا نقول خدمة REST أو خدمة الاستماع على منفذ TCP ، يمكنك البدء بالفعل. بالطبع ، لن ينجح إطلاق العديد من الخدمات التي تستمع إلى منفذ واحد بهذه الطريقة.

مجرد سياق ربيع XML

إذا كان لديك ، على سبيل المثال ، تعريفات JDBC DataSources داخل Spring Context ، فيمكنك تثبيتها بشكل منفصل في Karaf. أي خذ ملف xml يحتوي فقط على مصدر بيانات في شكل <bean> ، أو أي مجموعة أخرى من المكونات ، يمكنك وضعه في مجلد النشر. سيتم إطلاق السياق بالطريقة القياسية. المشكلة الوحيدة هي أن DataSources التي تم إنشاؤها بهذه الطريقة لن تكون مرئية للحزم الأخرى. يجب أن يتم تصديرها إلى OSGI كخدمات. حول هذا - في وقت لاحق قليلا.

الربيع م

ما هو الفرق بين Spring DM (الإصدار الذي يدعم OSGI) والربيع الكلاسيكي؟ لذلك في الحالة الكلاسيكية ، يتم إنشاء كل الحبوب في السياق في مرحلة التهيئة للسياق. جديدة لا يمكن أن تظهر ، القديمة لن تذهب إلى أي مكان. في حالة OSGI ، يمكن تثبيت حزم جديدة وإزالة الحزم القديمة. أصبحت البيئة أكثر ديناميكية ، تحتاج إلى الاستجابة بطريقة أو بأخرى.

تسمى طريقة الاستجابة الخدمات. عادة ما تكون الخدمة عبارة عن واجهة معيّنة ، مع طرقها الخاصة ، والتي يتم نشرها بواسطة بعض الحزمة. تحتوي الخدمة على بيانات وصفية تسمح بالبحث عنها وتمييزها عن خدمة أخرى تنفذ واجهة مماثلة (من الواضح ، من مصدر بيانات آخر). بيانات التعريف هي مجموعة بسيطة من خصائص القيمة الرئيسية.

نظرًا لأن الخدمات يمكن أن تظهر وتختفي ، يمكن لأولئك الذين يحتاجون إليها إما الاشتراك في الخدمات عند بدء التشغيل أو الاستماع إلى الأحداث للتعرف على مظهرها أو اختفائها. على مستوى Spring DM ، في XML ، يتم تطبيق ذلك كعنصرين ، خدمة ومرجع ، هدفهما الأساسي بسيط للغاية: نشر الحبة الموجودة من السياق كخدمة ، والاشتراك في خدمة خارجية عن طريق نشرها في سياق الربيع الحالي.

وفقًا لذلك ، عند تهيئة هذه الحزمة ، ستجد الحاوية الخدمات الخارجية التي تحتاج إليها ، وتنشر الحزم المطبقة بداخلها ، مما يجعلها في متناول من الخارج. تبدأ الحزمة فقط بعد حل روابط الخدمة.

في الواقع ، كل شيء أكثر تعقيدًا قليلاً ، لأن الحزمة يمكن أن تستخدم قائمة من الخدمات المشابهة ، والاشتراك في القائمة على الفور. أي الخدمة ، بشكل عام ، لها خاصية مثل الأصل ، والتي تأخذ القيمة 0..N. في هذه الحالة ، يصف الاشتراك ، حيث يشار إلى 0..1 ، خدمة اختيارية ، وفي هذه الحالة تبدأ الحزمة بنجاح حتى إذا لم تكن هناك خدمة من هذا القبيل في النظام (وبدلاً من وجود رابط إليها ، ستحصل على كعب روتين).

لاحظ أن الخدمة ليست سوى واجهة (أو يمكنك نشر فئات فقط) ، لذلك يمكنك نشر java.util.Map مع البيانات كخدمة.

من بين أشياء أخرى ، تتيح لك الخدمة تحديد البيانات الأولية ، ويسمح لك المرجع بالبحث عن خدمة بواسطة هذه البيانات التعريفية.

مخطط

Blueprint هو أحدث إصدار من برنامج DM DM ، وهو أبسط قليلاً. وهي ، إذا كان لديك عناصر XML مخصصة في الربيع ، فلن تكون هنا ، غير ضرورية. هذا في بعض الأحيان لا يزال يسبب إزعاج ، ولكن بصراحة - بشكل غير منتظم. إذا كنت لا تهاجر مشروعًا من Spring ، فيمكنك البدء على الفور باستخدام Blueprint.

الجوهر هنا هو نفسه - إنه XML ، الذي يصف المكونات التي يتم من خلالها تجميع سياق الحزمة. بالنسبة لأولئك الذين يعرفون الربيع ، لا يوجد شيء غير مألوف على الإطلاق.

فيما يلي مثال عن كيفية وصف مصدر البيانات وتصديره كخدمة:

 <?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <bean id="dataSource" class="oracle.jdbc.pool.OracleDataSource"> <property name="URL" value="URL"/> <property name="user" value="USER"/> <property name="password" value="PASSWORD"/> </bean> <service interface="javax.sql.DataSource" ref="dataSource" id="ds"> <service-properties> <entry key="osgi.jndi.service.name" value="jdbc/ds"/> </service-properties> </service> </blueprint> 

حسنًا ، لقد نشرنا هذا الملف في مجلد النشر ، ونظرنا في نتائج أمر القائمة. ورأوا أن الحزمة لم تبدأ - في وضع Indtalled. نحاول البدء ونصلك رسالة خطأ.

الآن في قائمة الحزم في حالة فشل. ما الأمر؟ من الواضح أنه يحتاج أيضًا إلى تبعيات ، في هذه الحالة ، إلى Jar مع فئات Oracle JDBC ، أو بشكل أكثر دقة ، الحزمة oracle.jdbc.pool.
نعثر على الجرة اللازمة في المستودع ، أو ننزّلها من موقع Oracle ، ونثبتها ، كما هو موضح سابقًا. بدأ مصدر البيانات الخاص بنا.

كيفية استخدام كل هذا؟ يسمى ارتباط الخدمة في مرجع Blueprint (في مكان ما ، في سياق حزمة أخرى):

 <reference id="dataSource" interface="javax.sql.DataSource"/> 

ثم ، تصبح هذه الحبة ، كالعادة ، تبعية للفاصوليا الأخرى (في مثال الجمل المربى):

 <bean id="sql" class="org.apache.camel.component.sql.SqlComponent"> <property name="dataSource" ref="dataSource"/> </bean> 

جرة والمنشط

تتمثل الطريقة الأساسية لتهيئة الحزم في استخدام فصل يقوم بتنفيذ واجهة Activator. هذا هو واجهة دورة حياة نموذجية تحتوي على طرق البدء والإيقاف التي تمر السياق . بداخلها ، عادة ما تبدأ الحزمة مؤشرات الترابط الخاصة بها ، إذا لزم الأمر ، وتبدأ الاستماع إلى المنافذ ، وتشترك في الخدمات الخارجية باستخدام واجهة برمجة تطبيقات OSGI ، وهكذا. ربما تكون هذه هي الطريقة الأكثر تعقيدًا والأكثر أساسية وأكثر مرونة. لمدة ثلاث سنوات لم أكن بحاجة إليها.

الإعدادات والتكوين

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

 <property name="url" value="${oracle.ds.url}"/> <property name="user" value="${oracle.ds.user}"/> <property name="password" value="${oracle.ds.password}"/> 

الحل بسيط للغاية ، ومشابه للحل المستخدم في الربيع الكلاسيكي: عند نقطة معينة في دورة حياة السياق ، يتم استبدال قيم الخاصية من مصادر مختلفة.

على هذا سننهي الجزء الأول. إذا كان هناك اهتمام بهذا الموضوع ، فستستمر. سننظر في كيفية تجميع التطبيقات من الحزم وتكوين ومراقبة ونشر الأنظمة تلقائيًا على هذا النظام الأساسي.