ड्रॉपविज़ार्ड/जर्सी - परीक्षण चलाने पर सार्वजनिक विधि के लिए अनुपलब्ध निर्भरता

Question

ड्रॉपविज़ार्ड का उपयोग करते हुए संसाधन परीक्षण चलाने पर मुझे "अनुपलब्ध निर्भरता" अपवाद का सामना करना पड़ा: 0.6.1 (जर्सी 1.15), क्या किसी को इस मामले पर अनुभव हुआ है?

मेरे परीक्षण फ़ाइल:

public class MyResourceImplTest extends ResourceTest { 
    ........ 
    @Override 
    protected void setUpResources() throws Exception { 
     addResource(new MyResourceImpl(new myConfiguration())); 
    } 
} 

अपवाद:

Dec 13, 2012 2:10:41 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer <init> 
INFO: Creating low level InMemory test container configured at the base URI http://localhost:9998/ 
Dec 13, 2012 2:10:42 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer start 
INFO: Starting low level InMemory test container 
Dec 13, 2012 2:10:42 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate 
INFO: Initiating Jersey application, version 'Jersey: 1.15 10/30/2012 02:40 PM' 
Dec 13, 2012 2:10:42 PM com.sun.jersey.spi.inject.Errors processErrorMessages 
SEVERE: The following errors and warnings have been detected with resource and/or provider classes: 
    SEVERE: Missing dependency for method public javax.ws.rs.core.StreamingOutput com.****************.********(javax.servlet.http.HttpServletRequest,java.lang.String,java.lang.String) at parameter at index 0 
Dec 13, 2012 2:10:42 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer stop 
INFO: Stopping low level InMemory test container 

Answer 1

मेरी समस्या यह थी कि, मैंने एक HttpServletRequest इंजेक्शन दिया जो इनमेमरी कंटेनर द्वारा समर्थित है, मुझे इस मामले में परीक्षण contatiner के रूप में जेट्टी grizzlyWebTestContainer या जेटी का उपयोग करने की आवश्यकता होगी। मुझे यह नहीं मिला कि वह न तो काम कर रहा है, क्योंकि जर्सी-टेस्ट-फ्रेमवर्क-ग्रिज़ली में पेश होने से ड्रॉपविज़ार्ड के खिलाफ बहुत निर्भरता संघर्ष हुए। मैं फिर से सभी संघर्षों को हल करने की कोशिश नहीं कर रहा हूं, क्योंकि जब मैं भविष्य में ड्रॉपविज़ार्ड को अपग्रेड करता हूं, तो यह फिर से हो सकता है।

दिन के अंत में, मैंने अपनी वेब सेवाओं का परीक्षण करने के लिए कुछ एकीकरण परीक्षण (पायथन में) के साथ जेनकिंस नौकरी समाप्त कर दी। जैसे। तैनाती के बाद, कुछ http अनुरोधों में आग, प्रतिक्रिया कोड और प्रतिक्रिया सामग्री की जांच करें। यह रास्ता बहुत आसान हो जाता है।

Answer 2

जर्सी की तरह लग रहा इंजेक्षन करने के लिए एक HttpServletRequest

अपने अंतिम बिंदुओं में से एक कॉन्फ़िगर किया गया है में सक्षम नहीं है इस तरह?

public StreamingOutput something(@Context HttpServletRequest request, String a, String b) {} 

यदि हां, तो आप अपने डिजाइन पर पुनर्विचार कर सकते हैं, और बदले के लिए

@Context 
private HttpContext context; 

public StreamingOutput something(String a, String b) { 

    System.out.println("Request info "+context.getRequest().getAbsolutePath()); 

} 

जिसमें अधिक स्पष्ट दृष्टिकोण उपज सकता है चुनते हैं। जब तक आप Class संसाधन पंजीकरण पर भरोसा करते हैं तो आपको प्रति अनुरोध एक नया उदाहरण गारंटी दी जाती है जिसे थ्रेडिंग समस्याओं से बचना चाहिए।

Answer 3

जिस तरह से मैं इसके आसपास आया था, संदर्भ के बिना एक अमूर्त बेस-क्लास संसाधन को परिभाषित करना था, और फिर अपनी वास्तविक सेवा के लिए एक छोटी व्युत्पन्न कक्षा को लागू करना था।

@Path("/contextMethod") 
@Produces(MediaType.APPLICATION_JSON) 
@Consumes(MediaType.APPLICATION_JSON) 
public class MyResourceWithContext extends BaseResource { 
    @Context 
    private HttpServletRequest request; 

    protected String getUserID() 
    { 
     return request.getRemoteUser(); 
    } 
} 

जब आप अपने परीक्षण चलाने के लिए, आप तो बस के परीक्षण के लिए एक वैकल्पिक व्युत्पन्न वर्ग को लागू है, जो का उपयोग नहीं करता HttpServletRequest। यहां बोनस लाभ यह है कि आपकी व्युत्पन्न टेस्टेबल क्लास कुछ उपयुक्त टेस्ट परिदृश्य बनाने के लिए संदर्भ के लिए एक हार्डकोडेड मान इंजेक्स्ट (कहें) कर सकती है।