Re: [JBoss-user] JUnitEJB and ear scoping

2003-09-22 Thread Stefan Puiu
Hello,

I wanted to alter the JUnitEJB classes to do just that, but since that 
has already been done I'll check out the classes you pointed me to. 
Thank you very much, you've been very helpful.

Scott M Stark wrote:

You can try the JBoss testsuite variation of the EJBTestCase that 
allows the
jndi name of the session runner to be changed per deployment and uses the
thread context class loader to load the test case rather than 
Class.forName
which causes problems.

See the testsuite/src/main/org/jboss/test/util/ejb package in the current
3.2 cvs tree. The 3.2.2RC4 release includes this as well, but that 
version
is still using the Class.forName call.





---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


Re: [JBoss-user] JUnitEJB and ear scoping

2003-09-20 Thread Scott M Stark
You can try the JBoss testsuite variation of the EJBTestCase that allows the
jndi name of the session runner to be changed per deployment and uses the
thread context class loader to load the test case rather than Class.forName
which causes problems.
See the testsuite/src/main/org/jboss/test/util/ejb package in the current
3.2 cvs tree. The 3.2.2RC4 release includes this as well, but that version
is still using the Class.forName call.
--

Scott Stark
Chief Technology Officer
JBoss Group, LLC

Stefan Puiu wrote:

Hello again, it seems the stack trace in the first attachment (and the 
exception that caused it) are log4j-related, the line that triggers the 
ClassCastException is the following:

[EMAIL PROTECTED] ra]$ cat src/main/org/eupki/ra/test/RASetup.java | nl -b 
a| grep -w "71" -A 1
   71logger = (EupkiLogger)EupkiLogger.getLogger(
   72 RASetup.class.getName());

Anyway, I still have the packaging issue which is now solved by putting 
only the junitejb.jar (which is 7 KB large) in the ear. However, if I 
package JUnitEJB in each ear then I'd get a JNDI name clash when 
deploying all modules, so it's not a good solution. Other suggestions?

Stefan Puiu wrote:



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


Re: [JBoss-user] JUnitEJB and ear scoping

2003-09-16 Thread Stefan Puiu
Hello again, it seems the stack trace in the first attachment (and the 
exception that caused it) are log4j-related, the line that triggers the 
ClassCastException is the following:

[EMAIL PROTECTED] ra]$ cat src/main/org/eupki/ra/test/RASetup.java | nl -b 
a| grep -w "71" -A 1
   71logger = (EupkiLogger)EupkiLogger.getLogger(
   72 RASetup.class.getName());

Anyway, I still have the packaging issue which is now solved by putting 
only the junitejb.jar (which is 7 KB large) in the ear. However, if I 
package JUnitEJB in each ear then I'd get a JNDI name clash when 
deploying all modules, so it's not a good solution. Other suggestions?

Stefan Puiu wrote:

Hello list,

I'm running JBoss 3.2.1 with the 1.4.2 Sun JDK (I think it was 
compiled with 1.4.1) on a Mandrake Linux 9.1 box.

Some issues with common classes between our modules led to the 
necessity of using ear scoping in our ears. Now the problem is we run 
JUnitEJB tests with classes in the ear, and junitejb.jar and junit.jar 
are deployed separately (at least JUnitEJB needs to be redeployed each 
time the app gets redeployed, I don't know about Junit though). I 
start the JBoss server and deploy my application, but when I run it 
sometimes I'd get an error saying "test class not found". From what I 
know, ear scoping means using a different repository for the classes 
in the ear archive, does this mean that the EJBTestRunner will not be 
able to find the test class using the default class loader, which 
looks in the default class repository? What are the best solutions for 
this?

The junit.jar is a bit too large and I'm not too willing to put it in 
our ear files, so I tried to only put the junitejb.jar, but then I'd 
get the error message in the first attachment (a ClassCastException, 
which means I'm back in the classloader issues business! what a 
joy...). How should I package the classes? Before using ear scoping 
the junit and junitejb jar files were being deployed each time the 
application was deployed, because otherwise the EJBTestRunner session 
bean would run into classloader issues when redeploying the app 
(InvalidInvocation exceptions).

In the second attachment you have a stack trace (ant + junit stack 
trace) of the "test class not found" remote exception thrown back by 
the EJBTestRunner session bean to the test case I run.



ra-setup:
   [junit] .E
   [junit] Time: 1.305
   [junit] There was 1 error:
   [junit] 1) testSetUp(org.eupki.ra.test.RASetup)java.lang.ClassCastException
   [junit] at org.eupki.ra.test.RASetup.testSetUp(RASetup.java:71)
   [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   [junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   [junit] at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
   [junit] at 
net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
   [junit] at 
net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
   [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   [junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   [junit] at 
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:629)
   [junit] at 
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
   [junit] at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
   [junit] at 
org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:144)
   [junit] at 
org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62)
   [junit] at 
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
   [junit] at 
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:117)
   [junit] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
   [junit] at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
   [junit] at 
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322)
   [junit] at org.jboss.ejb.Container.invoke(Container.java:674)
   [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   [junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   [junit] at 
org.jboss.mx.capabilit