Major Péter wrote:
> Why would I have an application.xml for an EJB module? So if I
> understand correctly the EJB module (containing the session beans and
> packaged as ejb) and the domain module (containing the entity beans and
> packaged as jar) are both handled as EJB modules, and this is causing my
> problem?
>
Yes. Please check the complete contents of the test-classes dir.
> Now I copied the application.xml generated by the maven-ear-plugin into
> ejb/src/test/resources/META-INF (and removed the webmodules from the
> xml), and tried to run mvn test, but still the test-classes.jar problem.
> (I'm just guessing this is anyhow a proper way to do so)
>
You don't need application.xml. I was just trying to guess on what
could've gone wrong.
> Is there any other way to test my EJB? Using a different API?
>
We should make it work :).
Can you check the content of the exploded ear? It will be called
ejb-app<digits> and located in "java.io.temp" dir.
thanks,
-marina
> Thanks,
> Peter
>
> 2010-06-17 22:57 keltezéssel, Marina Vatkina írta:
>
>> Uh-oh...
>>
>> There is no ear support in EJB embeddable API, only a bunch of entries
>> on your classpath. When there is more than 1 EJB module found, a temp
>> exploded ear is created. Those parts that are not ejb modules, are
>> considered "libraries" and copied over to the lib/ subdirectory of that
>> ear, *and if such parts are directories" they are renamed to have ".jar"
>> at the end (this is how our deployment back end wants it to be).
>>
>> This explains test-classes to test-classes.jar transformation. What I
>> don't understand is the fact that the code that processed test-classes
>> first recognized it to be a library, but deployment didn't. Do you have
>> an application.xml anywhere on the classpath?
>>
>> thanks,
>> -marina
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>