2012-07-20 50 views
1

我正在使用我公司內部開發的一組API來與組織中的一些常見中央服務進行通信。這些API可以通過運行時配置動態配置,以根據系統的需要使用多種傳輸協議。直接Java和Grails之間的思考差異

內部API的集合被耦合到IBM WebService thinclient.jar以配置和調用所有必需的Web服務。我獲得了獨立原型平穩運行,但需要將這些功能集成到Grails正在開發的其他幾個服務中。

這是事情崩潰的地方。在我編寫的代碼中,我們只調用一個工廠方法並使用它來獲得客戶端會話,然後繼續我們的業務邏輯。簡單。使用調試器並深入API調用,我可以看到這獲得了通用傳輸配置,然後將其綁定到SOAP傳輸配置。從這裏開始,路徑不同,不管它是純粹的獨立Java服務還是Grails應用程序中運行的服務。

  • 在純Java獨立,這則綁定到 com.ibm.ws.webservice.engine.client.Service,其中 initService()方法被調用,事情正常工作。

  • 在Grails的應用程序,與包括相同的Java代碼,同一個地方 在代碼中調用 com.springsource.loaded.ri.ReflectiveIntercepter再經過 很多穿梭在彈簧API回來的,它終於拋出一個 java.lang.reflect.InvocationTargetException。

有沒有人有任何關於如何獲得在Grails中反射的行爲與在直的Java中一樣的技巧或想法?

我已經嘗試了很多變化,以達到這一點,我即將結束我的繩索。理想情況下,管理我們的業務邏輯和與這些內部系統一起談判的Java代碼的Grails服務將是最容易管理的,所以我寧願讓所有東西(Grails和我的Java服務代碼)一起工作。我簡單地嘗試了構建一個獨立的服務代碼JAR以及它的所有依賴關係,但是在Grails中嘗試使用它時鏈接了依賴關係衝突。我的最後一個選擇是將我的Java服務與Grails服務中的業務邏輯分開開來,只需將Grails服務調用到Java服務即可。這並不理想。

回答

1

當你跌入答案很簡單... ;-)

Grails的服務運行正常,如果我設置IDEA運行配置使用-noreloading選項。

grails -noreloading run-app 

這會阻止Grails/IDEA離開鉤子以動態地重新加載類。

有沒有關於這是Grails還是SpringSource Loader類中的bug的任何想法?