एम्बेडेड ग्लासफ़िश का उपयोग करके परीक्षण चलाते समय, जेपीए प्रदाता मेवेन-सिक्योरफायर-प्लगइन लक्ष्य (जिसे परीक्षण चरण चलाने के लिए उपयोग किया जाता है) निष्पादित करने से पहले कमांड लाइन पर प्रदर्शित क्लासपाथ का उपयोग नहीं करता है। एंबेडेड ग्लासफ़िश उन कलाकृतियों को तैनात करता है जो एक परीक्षण स्कोप के हिस्से के रूप में उपलब्ध हैं, ScatteredArchive के रूप में। यह बिखरा हुआ संग्रह आमतौर पर java.io.tmpdir निर्देशिका में gfembed<a_random_number>tmp नाम से बनाया गया है, जब तक कि एम्बेडेड ग्लासफ़िश कॉन्फ़िगरेशन ने ग्लासफ़िश स्थापना रूट और ग्लासफ़िश डोमेन का स्थान निर्दिष्ट नहीं किया हो।
जब एम्बेडेड ग्लासफ़िश डोमेन तैनात किए गए बिखरे हुए संग्रह के साथ तैयार किया जाता है, तो तैनात फ़ाइलों को आम तौर पर एक विस्फोटित निर्देशिका में कॉपी किया जाता है जिसमें आवेदन द्वारा आवश्यक सभी वर्ग (सभी निर्भरताओं सहित) होते हैं। यह निर्देशिका आमतौर पर GF_EMBED_DOMAIN_HOME/applications/<application_name> निर्देशिका में मौजूद होती है। आपके src/main/resources/META-INF और src/test/resources/META-INF निर्देशिकाओं से persistence.xml फ़ाइलों को यहां <application-name>/META-INF निर्देशिका में कॉपी किया गया है। राज्य की जरूरत नहीं है, जो पिछली बार कॉपी हो जाता है, या जो ओवरराइट नहीं किया जाता है वह वह है जिसे परीक्षण के दौरान जेपीए प्रदाता द्वारा उपयोग किया जाता है। यह हमेशा src/main/resources/META-INF में फ़ाइल होता है।
आप दो तरह से इस स्थिति पर काबू पाने के कर सकते हैं:
1. एक कस्टम Glassfish डोमेन विन्यास फाइल
आप एक डोमेन विन्यास फाइल निर्दिष्ट कर सकते हैं (domain.xml) कि jdbc/mylog के लिए डेटा स्रोत परिभाषा में शामिल होंगे का उपयोग करना । यही वह है जो मैं वर्तमान में इसके लिए बहुत लचीला हूं और डोमेन कॉन्फ़िगरेशन फ़ाइल में अन्य कॉन्फ़िगरेशन भी हो सकते हैं।कॉन्फ़िग फ़ाइल, की जरूरत है निर्दिष्ट निम्नलिखित तरीके से परीक्षण सेटअप के भाग के रूप:
Map<String, Object> props = new HashMap<String, Object>();
props.put("org.glassfish.ejb.embedded.glassfish.installation.root", "./glassfish-install/glassfish");
container = EJBContainer.createEJBContainer(props);
context = container.getContext();
datasource = (DataSource) context.lookup("jdbc/mylog"); //You can lookup the datasource too, to confirm that your setup is successful.
आगे उल्लिखित glassfish-install निर्देशिका और उसकी उप-निर्देशिका glassfish Maven परियोजना जड़ में मौजूद है (और भी संस्करण नियंत्रण में जाँच कर रहे हैं); glassfish निर्देशिका में domain1 नाम के ग्लासफ़िश डोमेन की निर्देशिका संरचना का प्रतिनिधित्व करने के लिए domain1/config की निर्देशिका संरचना होना चाहिए। परियोजना में संरचना नीचे स्क्रीनशॉट में देखी जा सकती है। अन्य संबंधित फाइलें (जेडीबीसी संसाधन एडाप्टर जेएआरएस और जैसे), ग्लासफ़िश इंस्टॉलेशन डायरेक्टरी से प्राप्त की जा सकती हैं, लेकिन आमतौर पर इन्हें सही तरीके से कॉन्फ़िगर किए गए एम्बेडेड ग्लासफ़िश रनटाइम द्वारा सही स्थान पर रखा जा सकता है।
Glassfish डोमेन विन्यास फाइल की सामग्री को डिफ़ॉल्ट एक एम्बेडेड Glassfish द्वारा प्रयोग किया जाता से अलग हैं, (मेरे USECASE में जोड़ा प्रासंगिक प्रविष्टियों जहाँ मैं एकीकरण परीक्षण प्रदर्शन डेटा स्रोत और कनेक्शन पूल विन्यास के लिए छोड़कर, घटना आप के बजाय एक Glassfish स्थापना से एक को कॉपी करने की संभव के रूप में कम से कम परिवर्तन रखने के लिए, इच्छा में
<domain log-root="${com.sun.aas.instanceRoot}/logs" application-root="${com.sun.aas.instanceRoot}/applications" version="10.0">
<system-applications/>
<applications/>
<resources>
<jdbc-resource pool-name="MyPool" jndi-name="jdbc/mylog"/>
...
<jdbc-connection-pool driver-classname="" datasource-classname="org.apache.derby.jdbc.ClientDataSource" res-type="javax.sql.DataSource" description="" name="MyPool" ping="true">
<property name="User" value="APP"></property>
<property name="RetrieveMessageText" value="true"></property>
<property name="CreateDatabase" value="true"></property>
<property name="ServerName" value="localhost"></property>
<property name="Ssl" value="off"></property>
<property name="SecurityMechanism" value="4"></property>
<property name="TraceFileAppend" value="false"></property>
<property name="TraceLevel" value="-1"></property>
<property name="PortNumber" value="1527"></property>
<property name="LoginTimeout" value="0"></property>
<property name="Password" value="APP"></property>
<property name="databaseName" value="MYDB"></property>
</jdbc-connection-pool>
...
</resources>
<servers>
<server name="server" config-ref="server-config">
<resource-ref ref="jdbc/__TimerPool"/>
<resource-ref ref="jdbc/__default"/>
<resource-ref ref="jdbc/mylog"/>
</server>
</servers>
...
...
default domain.xml file can be downloaded from the java.net site, और संशोधित,: नीचे तैनात किया गया है)। persistence.xml फ़ाइलों
एक से अधिक
2. प्रतिलिपि बनाई जा रही बैकअप के लिए Maven पोम फाइल करने के लिए लक्ष्यों को जोड़ने के लिए, और src/test/resources/META-INF से src/main/resources/META-INF को persistence.xml फ़ाइल की प्रतिलिपि, test चरण से पहले कर सकते हैं। परीक्षण चरण पूरा होने के बाद, मूल बहाल किया जाता है। मैं इसके विवरण में नहीं जाऊंगा, क्योंकि इसी तरह के समाधान पर पहले से ही a related StackOverflow question में चर्चा की गई है। मैंने एकीकरण परीक्षणों के लिए इस दृष्टिकोण का उपयोग नहीं किया क्योंकि मुझे कस्टम क्षेत्र के निर्माण की तरह persistence.xml में किए जा सकने वाले परिवर्तनों से परे परिवर्तनों की आवश्यकता थी। मैं यूनिट-टेस्ट के लिए इसका उपयोग करता हूं, हालांकि इस तथ्य के कारण कि जेपीए प्रदाता persistence.xml फ़ाइल से target/test-classes की बजाय फ़ाइल क्लासपाथ ऑर्डर में पहले दिखाई देने के बावजूद लाएगा। यदि आप अपने जेपीए प्रदाता के रूप में हाइबरनेट का उपयोग करते हैं, तो org.hibernate.ejb लॉगर के लिए TRACE लॉगिंग सक्षम करना (Ejb3Configuration कक्षा लुकअप करने के लिए ज़िम्मेदार है) आपको यह विश्वास दिलाएगी कि test-classes में फ़ाइल नहीं ली जाएगी।
नोट:
जवाब में से अधिकांश मान लिया गया Glassfish 3.1 लेकिन साथ ही आगामी संस्करणों के लिए अच्छा पकड़ सकता है।
मेरे पास विभिन्न आर्किटेक्चर स्थितियों के तहत एक समान समस्या थी और गंदे समाधान को एक persistence.xml दोनों में लगातार विलय, उत्पादन और परीक्षण में विलय करना था। –