سؤال

بمجرد استرجاع مثيل خدمة OSGI من سياق الحزمة، فإنه يتم إبطاله عند إيقاف الخدمة؟

تظهر اختباراتي الأولية أن مثيل الخدمة يمكن استخدامه حتى بعد إيقاف حزمة الخدمة، مما يتناقض مع فهمي الطبيعة الديناميكية ل OSGI.

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

هل هناك أي مخاطر في استخدام مثيل الخدمة بعد إيقاف الخدمة؟

هل كانت مفيدة؟

المحلول

هذا سؤال جيد للغاية لذا قمت بحفره في المواصفات بحثا عن إجابة نهائية. اتضح أن هناك قسم كامل يتحدث عن هذه المشكلة - انظر القسم 5.4 المراجع التي لا معنى لها بدءا من الصفحة 132 من مواصفات منصة خدمة OSGI الأساسية، الإصدار 4، الإصدار 4.2.

للإجابة على سؤالك وفقا للمواصفات:

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

ولمنع المشاكل المحتملة:

يجب أن تستمع الحزم إلى الأحداث التي تم إنشاؤها بواسطة الإطار لتنظيف وإزالة المراجع التي لا معنى لها.

توفر المواصفات أيضا بعض النصائح كيفية تقليل عواقب المراجع التي لا معنى لها.

نصائح أخرى

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

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

يقول مواصفات OSGI:

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

لذلك يجب أن لا تكون قادرا على الحصول على خدمة من حزمة توقف. ولكن من الناحية الفنية قد يكون من الممكن استخدامه، على الأقل طالما كنت تعقد إشارة إلى كائن الخدمة (لا أحد يستطيع أن يأخذها بعيدا عنك ولن يكون GC'd). لكنني لا أعتقد أنه يتم حفظه لاستخدام الخدمة. قد يعتمد ذلك على موارد الحزمة الأخرى، التي لا تتوفر بعد توقف الحزمة.

بمجرد استرجاع مثيل خدمة OSGI من سياق الحزمة، فإنه يتم إبطاله عند إيقاف الخدمة؟

لا، المرجع نفسه لا يصبح إبطالا. طالما أن شيئا ما داخل الحاوية يحتفظ به، فيمكن أن يكون أيضا GC'ed.

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

تظهر اختباراتي الأولية أن مثيل الخدمة يمكن استخدامه حتى بعد إيقاف حزمة الخدمة> التي تتعارض مع فهمي للطبيعة الديناميكية لأوسجي.

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

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

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

هل هناك أي مخاطر في استخدام مثيل الخدمة بعد إيقاف الخدمة؟

هذا يعتمد فقط على تنفيذ الخدمة؛ ومع ذلك، من خلال القيام بذلك في حزمة، يمكنك تلقائيا إنشاء حزمة لا تتفق مع المواصفات.

في الممارسة العملية، يتم تنفيذ العديد من الخدمات لإطلاق الموارد والمراجع ولن تستجيب بشكل صحيح بعد الآن.

فيما يتعلق بسؤالك ما إذا كان من الخطر استخدام مثيل الخدمة بعد إيقاف الخدمة. للإشارة من 4.2 المواصفات الأساسية (5.4 المراجع التي لا معنى لها):

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

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

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

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

يجب ألا يتم إظهار مرجع الخدمة كمرجع. يجب عليك دائما البحث عن خدمة في وقت التشغيل. هذا يربطك إلى ASGI API ومع ذلك، لا يريد whihc دائما.

إلقاء نظرة على - Osgi Servicetracker - خدمات إعلانية Osgi - مخطط Osgi - Spring DM - Peaberry - Ipojo

التي تعتني جميعها بالديناميكية بالنسبة لك، ومعظمها بدون API OSGI لاستخدامها.

يعتبر،

لين تويلين

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top