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: 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
