OSGi có không tương thích về cơ bản với JSR-223 Scripting Language Discovery không?

Question

Gần đây tôi đã viết một ngôn ngữ kịch bản chuyên gia nhỏ và đã sử dụng Maven để xuất một gói tuân thủ OSGi cũng xuất một bộ mô tả dịch vụ vào tệp đăng ký dịch vụ "META-INF/services/javax.script.ScriptEngineFactory".

Vấn đề là mặc dù các gói nhập và xuất OSGi là tốt, đăng ký dịch vụ có vẻ không tương thích với OSGi (vì OSGi giữ các gói của nó khỏi đường dẫn lớp chung và sử dụng các trình nạp lớp riêng biệt cho các mô-đun).

Câu hỏi của tôi là tôi đúng khi nghĩ rằng OSGi không tương thích với cơ chế Khám phá dịch vụ và nếu không, tôi có thể thêm gì vào siêu dữ liệu gói của mình để ScriptEngineManager.getEngineFactories() liệt kê công cụ tập lệnh của tôi trong môi trường OSGi?

Answer 1

Apache Sling sử dụng cơ chế này trong môi trường OSGi để quản lý các công cụ tập lệnh tương thích JSR-233 của mình, chủ yếu thông qua lớp ScriptEngineManagerFactory [1]. Xem thêm [2] cho một công cụ kịch bản lệnh tùy chỉnh.

Việc thêm công cụ tập lệnh của bạn vào Sling sẽ hoạt động nếu nó tương thích với JSR-233. Cách đơn giản nhất để kiểm tra đó có thể là tuân theo hướng dẫn "Sling trong 15 phút" [3] sử dụng ngôn ngữ của bạn thay vì ngôn ngữ javascript phía máy chủ được sử dụng ở đó.

[1] http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/ScriptEngineManagerFactory.java

[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/javascript

[3] http://sling.apache.org/site/discover-sling-in-15-minutes.html

Answer 2

Matt F. viết blog về một giải pháp thay thế [1]

Khi cung cấp kịch bản trong một Ứng dụng Java, các công cụ tạo kịch bản phù hợp với JSR 223 (ví dụ: Groovy, JRuby, Scala, ...) có thể dễ dàng được nhúng bằng cách sử dụng somethi ng dọc theo dòng của

ScriptEngineManager scriptEngineManager = new ScriptEngineManager(); 
ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy"); 

Tuy nhiên, trong một ứng dụng OSGi-base, ScriptEngineManager thất bại trong việc khám phá scripting engine, nằm trong gói cài đặt, do cách nó phát hiện ra động cơ có sẵn trên đường dẫn lớp. May mắn thay, dự án Apache Felix đã giải quyết vấn đề này, có

• OSGiScriptEngineManager [2]
• OSGiScriptEngineFactory [3]
• OSGiScriptEngine [4]

mà cung cấp một OSGi- cách tương thích để khám phá và tải các công cụ tạo tập lệnh được cài đặt dưới dạng các gói OSGi.

ScriptEngineManager scriptEngineManager = new OSGiScriptEngineManager(bundleContext); 
ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy"); 

[1] http://devnotesblog.wordpress.com/2011/09/07/scripting-using-jsr-223-in-an-osgi-environment/

[2] http://svn.apache.org/repos/asf/felix/trunk/mishell/src/main/java/org/apache/felix/mishell/OSGiScriptEngineManager.java

[3] http://svn.apache.org/repos/asf/felix/trunk/mishell/src/main/java/org/apache/felix/mishell/OSGiScriptEngineFactory.java

[4] http://svn.apache.org/repos/asf/felix/trunk/mishell/src/main/java/org/apache/felix/mishell/OSGiScriptEngine.java

Answer 3

Chỉ để kêu vang trong đó có một tiêu chuẩn chung sol ution để tiêu thụ các loại dịch vụ trong một môi trường OSGi, như ScriptEngineFactory không phải là trường hợp duy nhất như vậy. Nó là một phần của thông số Enterprise OSGi. và việc triển khai tham chiếu có thể tìm thấy tại đây: http://aries.apache.org/modules/spi-fly.html

Điều tầm thường là tạo lại chức năng của lớp Apache Spring thông qua cơ chế này, và phương pháp này là sạch hơn và hợp lý hơn, nhưng tôi hiểu mong muốn tránh thực hiện lại bánh xe để nói.