[JBoss-dev] [ jboss-Bugs-522617 ] Redeploy broken with tmp/deploy changes

[<no...@so...>]

Bugs item #522617, was opened at 2002-02-25 12:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=522617&group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 7
Submitted By: Scott M Stark (starksm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redeploy broken with tmp/deploy changes

Initial Comment:
With the change to use the original component jar name 
under the tmp/deploy directory we have regressed back 
to the ZipFile cache bug. Because the same file name 
is used for the initial deploy and subsequent deploys 
the jar contents are cached by the ZipFile under 
jdk1.3 and redeploy either fails with a 
java.lang.InternalError jzentry == 0, or the contents 
are not updated. I also see the same problem under 
jdk1.4 where I thought this issue was supposed to be 
fixed.

Its simple to produce the problem. Run the 
org.jboss.test.hello.test.HelloTimingStressTestCase 
one, change the print statements in the 
org.jboss.test.hello.ejb.HelloBean class, rerun the 
HelloTimingStressTestCase and the reploy fails.

Two solutions are:
1. Make the orig path name a directory under 
tmp/deploy and place uniqued jars under the directory. 
For example:
origJar: /test/lib/hello.jar
deployJar : 
jboss.home/tmp/deploy/test/lib/hello.jar/00.hello.jar
redeployJar : 
jboss.home/tmp/deploy/test/lib/hello.jar/01.hello.jar

The benefit of this approach is that one can
still assign security permissions on a per component
jar basis.

2. Only use the orig path upto the last directory.
For example:
origJar: /test/lib/hello.jar
deployJar : jboss.home/tmp/deploy/test/lib/00.hello.jar
redeployJar : 
jboss.home/tmp/deploy/test/lib/01.hello.jar

This might be simpler but it limits the ability to set 
security permissions to the container directory. This 
is not that big a restriction as this is usually how 
one does permissions.


----------------------------------------------------------------------

>Comment By: Scott M Stark (starksm)
Date: 2002-02-25 15:01

Message:
Logged In: YES 
user_id=175228

I see the same thing on win2k if I rerun without modifying 
the hello.jar so I think that issue is a seperate class 
loader problem. Comitting the name change will fix the jar 
caching problem and then we can move on to why the straight 
redeploy fails.

----------------------------------------------------------------------

Comment By: David Jencks (d_jencks)
Date: 2002-02-25 14:37

Message:
Logged In: YES 
user_id=60525

I'm confused.  I find that if I redeploy hello.jar and rerun
the tests, I get 
java.rmi.ServerException: argument type mismatch; nested
exception is: 
	java.lang.IllegalArgumentException: argument type mismatch
java.lang.IllegalArgumentException: argument type mismatch
	at java.lang.reflect.Method.invoke(Native Method)
	at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessi...

This is with or without implementing solution (1), and with
or without changing/recompiling hello.jar.

Is this a windows only problem?

I think the argument mismatch may be caused by a classloader
issue like with calling an ejb from an mbean, but I haven't
investigated.

Want me to commit suggestion(1) anyway?

david jencks

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=522617&group_id=22866