خطأ AXIS2 / JAX-WS عند عدم إمكانية تشغيل ملف XML باستخدام عناصر نصية كبيرة

Question

أنا عالق تماما وتحتاج إلى مساعدتكم ... لقد قمت بإنشاء كعب Webservice مع Jaxb 2.x لخدمة ترسل ملف ثنائي (صور JPG المشفرة Base64) في رسالة الصابون. عمل كل شيء على ما يرام وتمكنت من تلقي الصور وعرض الصور، حتى حاولت تصدير تطبيق Eclipse RCP إلى منتج، مما تسبب في ارتباط imediatly (كالعادة، javax.xml.namespace.qname وبعضها أكثر).

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

كشفت نظرة فاحصة، أن القارئ (OMSTAXWRAPPER)، الذي يستخدم في كعب CONE الذي تم إنشاؤه بواسطة AXIS2-Jaxb، الآن لا يقرأ نص Base64 بالكامل ولكن فقط أول 10000 بايت. ثم لا يجد النهاية الصحيحة للعنصر ويطرح استثناء.

كما ذكرنا قبل - هذا لم يحدث في البداية، لذلك آمل أن يكون مجرد معلمة أو خيار. شكرا جزيلا مقدما لكل مساعدة أو تلميح!

يحررلم يكن Jaxb، لقد استخدمت Jaxws و Wsimport لإنشاء كعب ملف WSDL ...

Answer 1

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

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

بدلا من ذلك، يجب أن يكون من الممكن إقناع AXIS2 لاستخدام SAIJ API القياسي بدلا من استخدام AXIOM. Saaj أبطأ، ولكن يجب أن يكون أقل عربات التي تجرها الدواب.

اقتراحي النهائي هو التخلي عن AXIS2 لعملائك، واستخدم شيئا أكثر خفيفة الوزن. وثب يوفر واجهة برمجة تطبيقات عميل لطيفة للغاية، وهي حاليا أداة اختياري للتحدث إلى خدمات الويب البعيدة. وهو يدعم AXIOM و SAIJ، بالإضافة إلى MTOM، وهو خفيف الوزن بما فيه الكفاية أنه من السهل جدا معرفة سبب خاطئ شيء ما.