2011-07-01 11 views
27

परिनियोजन करें जब मैं ejd-कान, वेब-कान को ग्लासफ़िश सर्वर पर तैनात करने का प्रयास करता हूं। मैंने वेब प्रोजेक्ट में एक ईजेबी क्लाइंट निर्भरता जोड़ा। ईजेबी-कान सफलतापूर्वक तैनात है। लेकिन जब मैं वेब कान को तैनात करने की कोशिश करता हूं, तो यह अपवाद फेंकता है।sun.reflect.annotation.TypeNotPresentExceptionProxy त्रुटि जब वेब-कान

sun.reflect.annotation.TypeNotPresentExceptionProxy 
java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy 
    at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) 
    at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) 
    at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) 
    at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) 
    at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) 
    at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) 
    at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) 
    at java.lang.Class.getAnnotations(Class.java:3050) 
    at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:285) 
    at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195) 
    at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134) 
    at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606) 
    at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:459) 
    at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432) 
    at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408) 
    at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383) 
    at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246) 
    at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255) 
    at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:216) 
    at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165) 
    at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:180) 
    at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) 
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) 
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) 
    at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) 
    at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) 
    at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) 
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) 
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) 
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) 
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) 
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) 
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) 
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) 
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) 
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) 
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) 
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) 
    at com.sun.grizzly.ContextTask.run(ContextTask.java:71) 
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) 
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) 
    at java.lang.Thread.run(Thread.java:662) 

कोई विचार?

उत्तर

21

हाल ही में जुनीट के साथ एक ही अपवाद था। स्थिति इस तरह था:

@SuiteClasses({MyTestClass.class}) 
public class MySuite { 
    ... 
} 

समस्या है कि JVM (एक और जार फ़ाइल याद आ रही थी) MyTestClass कार्रवाई करने के लिए है क्योंकि यह classpath में निर्भरता याद आ रही थी असमर्थ था है। लेकिन अपवाद ने कोई जानकारी नहीं दी कि किस वर्ग में गायब था।

समाधान लिए किया गया था अस्थायी रूप से MySuite करने के लिए एक स्थिर प्रारंभ ब्लॉक, कि MyTestClass को दर्शाता जोड़ें:

@SuiteClasses({MyTestClass.class}) 
public class MySuite { 
    static { 
     new MyTestClass(); 
    } 
} 

इस का कारण बनता है JVM पहले स्थिर ब्लॉक को चलाने के लिए, MyTestClass का दृष्टांत करने की कोशिश करता है, लापता वर्ग पता लगाना और एक उचित अपवाद की रिपोर्ट करें। फिर आप लापता निर्भरता जोड़ सकते हैं और अस्थायी स्थिर ब्लॉक को हटा सकते हैं।

1

समाधान: Glassfish सर्वर से डिबग साथ

  1. कनेक्ट
  2. लाइन
    • java.lang.Class.initAnnotationsIfNecessary (Class.java:3070)
  3. में
  4. को तोड़ने के बिंदु अपना आवेदन तैनात करें।

जबकि आप तैनाती करते समय इस ब्रेक पॉइंट पर कई बार रुकेंगे। देखें संदर्भ और तैनाती त्रुटि उत्पन्न होने से पहले अंतिम याद रखें। पिछले "" "कक्षा में एनोटेशन की जांच करें। आप एनोटेशन पार्सर.परसे क्लासएरे विधि में ब्रेक पॉइंट भी डाल सकते हैं, लेकिन यह संकलित कोड है और विधि पर ब्रेक पॉइंट बहुत धीमा है। (विधि के ब्रेक पॉइंट के साथ मेरे मामले में मैं आखिरी बार आवेदन नहीं कर सका)।

33

मुझे लगता है कि सबसे अच्छा तरीका है java.lang.TypeNotPresentException के निर्माता में एक को तोड़ने बिंदु डाल दिया और मूल कारण

+0

मेरे मामले में, मूल कारण था: java.lang.ClassNotFoundException: com.github.springtestdbunit.DbUnitTestExecutionListener –

+0

धन्यवाद, प्रयोगशाला! मैंने TypeNotPresentExceptionProxy में उत्साह स्थापित किया और क्लास नॉटफाउंड अपवाद प्राप्त किया, इसलिए मुझे पता चला कि कौन सी कक्षा गुम थी। – rwitzel

+0

हैलो, आप ग्रहण डीबगर का उपयोग कर संकलित TypeNotPresentExceptionProxy क्लास में उस ब्रेक पॉइंट को कैसे डालते हैं? (डब्ल्यूएएस लिबर्टी प्रिफल ऐप सर्वर के साथ काम करना) धन्यवाद! – icordoba

1

यह भी निम्न स्थिति में हो सकता है पता करने के लिए प्रकार फेंकने योग्य का दूसरा तर्क की जाँच करने के लिए है:

प्रोजेक्ट ए कुछ लाइब्रेरी है, जो आपके ग्रहण में एक मैवेन प्रोजेक्ट है। इसमें org.exmaple.Foo नाम की एक कक्षा है जो src/test/java/ निर्देशिका में है।

आपकी प्रोजेक्ट बी में जहां त्रुटि होती है तो आप इस कक्षा तक पहुंचने का प्रयास कर रहे हैं। लेकिन यह संभव नहीं है।

ग्रहण शिकायत नहीं करेगा क्योंकि यह दोनों वर्गों को "जानता है"। यदि आप प्रोजेक्ट पर mvn clean install चला रहे हैं जो मैवेन काम नहीं करता है तो आपको एक उचित त्रुटि संदेश मिलेगा।

मुझे लगता है कि यह युग केप्लर के बाद से हो सकता है लेकिन मुझे यकीन नहीं है। कम से कम यह अभी भी लुना में मौजूद है :)

0

यह मुद्दा जार फ़ाइल के साथ विवादित है। युद्ध फ़ाइल lib फ़ोल्डर के अंदर जार फ़ाइलों की सूची सत्यापित करें। अनावश्यक और विरोधाभासी जार फ़ाइलों को हटा दें। फिर तैनाती सफल होगी।

2

हम वास्तव में एक ही अपवाद में भाग गए। हमारे पास एक प्रोजेक्ट है जिसे हम वर्तमान में जावा से कोटलिन में स्थानांतरित करते हैं। प्रोजेक्ट में, सभी टेस्ट क्लास कोटलिन में लिखे गए थे और इसलिए हमने फ़ोल्डर src/test/kotlin नाम दिया। हमने Kotlin documentation में 'कंपाइलिंग कोटलिन और जावा स्रोत' अनुभाग के अनुसार हमारे पोम को भी कॉन्फ़िगर किया।

हम क्या भूल गया था परीक्षण निर्देशिका 'केवल संकलन Kotlin स्रोत कोड' खंड में वर्णित परिभाषा थी:

<build> <testSourceDirectory>${project.basedir}/src/test/kotlin</testSourceDirectory> </build>

यह भी एक सा भ्रमित किया गया है कि इंटेलीजे ऑटो संकलन सभी परीक्षण कक्षाओं संकलित आवश्यकतानुसार और बाद में मेवेन बिल्ड भी सफल रहा। केवल mvn clean test के बाद TypeNotPresentExceptionProxy हुआ।