تمديد تطبيقات الويب Java مع الإضافات

Question

لدي تطبيق الويب هذا الذي نما إلى فوضى لا يمكن السيطرة عليها.

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

تحتاج جميع الوحدات إلى أن تكون وحدة منفصلة للنشر ، من الناحية المثالية ملف حرب أو جرة.

حاولت فقط إنشاء العديد من ملفات الحرب العادية ، لكن Tomcat يحتفظ (وفقًا لمواصفات Servlet) هذه ملفات الحرب منفصلة تمامًا عن بعضها البعض ، بحيث لا يمكنها مشاركة فصولهم ، على سبيل المثال.

أحتاج إلى الإضافات لتتمكن من رؤية ClassPath "الرئيسي".

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

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

أود أن يكونوا متجذرين بموجب بادئة عنوان URL "الرئيسي" ، لكن هذا ليس ضروريًا.

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

Answer 1

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

Answer 2

ألقِ نظرة على بوابات جافا - http://developers.sun.com/portalserver/reference/techart/jsr168/ - باختصار ، مواصفات تسمح بتشغيل التشغيل البيني بين ما هي تطبيقات الويب J2EE المستقلة بذاتها

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

Answer 3

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

يتيح لك Tomcat أيضًا تكوين تطبيقات السياق المتقاطع إذا كنت بحاجة إلى الانتقال من حرب إلى أخرى بطريقة شفافة نسبيًا ...

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

Answer 4

تتمحور مشكلتك الأساسية حول الأصول الجسدية الثابتة للنظام - الباقي ببساطة ، بفعالية ، الجرار.

يتم فصل الحروب ، في Tomcat ، مع قائدي صفات منفصلة ولكنها أيضًا منفصلة على مستوى الجلسة (كل حرب هي تطبيق ويب Indvidual ، وله حالة جلسة خاصة به).

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

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

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

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

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

Answer 5

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

يمكنك توجيه حرب أخرى طالما أن تلك الحرب تسمح لشخص ما بذلك.

الأسماك الزجاجية وحروب متعددة من الأذن: هذا منطقي.

إذا وضعت الفصول الرئيسية في classpath المشتركة من tomcat ، فيمكنك وضع المكونات الإضافية الفردية في ملفات حرب منفصلة.

يمكن أن يكون التطبيق الرئيسي أيضًا جزءًا من servlet tomcat الذي تحدده في server.xml. يمكن أن يكون هذا هو Servlet الرئيسي ويمكن التحكم في جميع الحروب الأخرى بواسطة هذا Servlet.

هل هذا منطقي ؟

BR ،
~ أ

Answer 6

اعتمادًا على تعقيد وظيفة البرنامج المساعد ، سأدرس أيضًا خدمة ويب ، على سبيل المثال تم تنفيذه باستخدام المحور.

ثم يتم تكوين تطبيقك الرئيسي باستخدام عنوان URL إلى تطبيق الويب (المكون الإضافي) الذي يوفر الخدمة.

الميزة ، كما أراها ، ذات شقين:

• يمكنك الحصول على واجهة برمجة تطبيقات لطيفة ونظيفة وقابلة للتصحيح بين الحربين ، وهي رسائل الصابون/XML
• يمكنك ترقية مكون إضافي واحد دون الاضطرار إلى اختبار تطبيقك بالكامل

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

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

Answer 7

أحاول أيضًا تطوير إطار عمل مشترك أو مجردة حيث يمكنني إضافة مكونات إضافية (أو وحدات) في وقت التشغيل وتعزيز WebApp الحالي.

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

هناك خيار آخر يتمثل في ملف JAR وكتابة بعض التعليمات البرمجية المخصصة لنسخ ملف JAR إلى مجلد Web-Inf/LIB وتحميل الفئات إلى classloader الحالي. المشكلة هي كيفية نشر ملفات غير Java مثل JSP أو ملفات التكوين. لذلك ، هناك حلان ، أ. استخدم قوالب السرعة بدلاً من JSP (ب.) اكتب بعض التعليمات البرمجية المخصصة لقراءة JSP من ClassPath بدلاً من مسار السياق.

وحدات OSGI أو Spring Dynamic لطيفة ، لكن في هذا الوقت ، تبدو معقدة للغاية بالنسبة لي. سوف أنظر إلى ذلك مرة أخرى ، إذا شعرت به.

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

قد يكون ، يمكنك استخدام UN JAR المكون الإضافي في نشر الوقت ونسخ الملفات إلى الدلائل الصحيحة.

Answer 8

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

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

لسوء الحظ ، حتى نهج OSGI لا يحل ما نبحث عنه. كيفية توسيع نموذج مستمر والنماذج الحالية في وقت التشغيل.