[JBoss-dev] [ jboss-Bugs-593916 ] Redeployment does not work
Bugs item #593916, was opened at 2002-08-12 08:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593916group_id=22866 Category: JBossSOAP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Dr. Christoph Georg Jung (cgjung) Assigned to: Dr. Christoph Georg Jung (cgjung) Summary: Redeployment does not work Initial Comment: Some people get cannot redeploy existing module messages. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593916group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-563120 ] ClassCastException after redeploy
Bugs item #563120, was opened at 2002-05-31 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=563120group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: JD Brennan (jazzdevotee) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException after redeploy Initial Comment: Linux (2.2 kernel) JDK 1.4 = === JBoss Bootstrap Environment JBOSS_HOME: /opt/jboss-3.0.0 JAVA: /opt/j2sdk1.4.0/bin/java JAVA_OPTS: -server -Dprogram.name=run.sh CLASSPATH: /opt/jboss- 3.0.0/bin/run.jar:/opt/j2sdk1.4.0/lib/tools.jar = === 15:15:05,459 INFO [Server] JBoss Release: JBoss- 3.0.0 CVSTag=JBoss_3_0_0 Steps: 1) call a bean that serializes object X that implements interface Y somewhere (I store it in a mysql database). 2) call a bean that deserializes the object and casts it to the interface Y. 3) redeploy the ejb jar file that contains the bean (hot redeploy. Don't restart JBoss. 4) repeat step 2 Excepted: Same result as Step 2 Actual: ClassCastException -- Comment By: Steve Harvey (sgharvey) Date: 2002-08-12 03:09 Message: Logged In: YES user_id=593359 Fixed in 3.0.1? I had the same problem, with a SLSB trying to cast the result of a JNDI lookup into an EB home type, throwing CCE after redeployment. I added reflection code to the SLSB to examine the class loader delegation chain for both the IF class and looked up object. The IF class CL was a UnifiedClassLoader instance with its originating jar as repository, but the looked up object had a copy of jnpserver.jar as the repository for its UCL instance. Upon redeployment, only the IF class CL got a new UCL instance. Upon switching to the IBM 1.3 JDK from Sun's 1.4, I witnessed the same behaviour, minus the CCE being thrown. Then I noticed that JBoss-3.0.1 was out and tried it and the problem went totally away, no CCE, and both CL instances identical. This was all on Linux 2.2 . -- Comment By: Kenny Smith (subsstuff1) Date: 2002-06-04 18:07 Message: Logged In: YES user_id=548391 hell no spoke to soon - problem still exists, disguised as a different exception: 00:03:26,130 ERROR [STDERR] java.lang.ClassCastException 00:03:26,130 ERROR [STDERR] at com.sun.corba.se.internal.javax.rmi.PortableR emoteObject.narrow(PortableRemoteObject.java:293) 00:03:26,140 ERROR [STDERR] at javax.rmi.PortableRemoteObject.narrow(Portabl eRemoteObject.java:134) 00:03:26,150 ERROR [STDERR] at com.foo.account.AccountUtil.getHome(Unknown Source) 00:03:26,160 ERROR [STDERR] at com.foo.account.AccountRegistryBean.createAccount (Unknown Source) 00:03:26,170 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0( Native Method) 00:03:26,180 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(N ativeMethodAccessorImpl.java:39) 00:03:26,190 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo ke(DelegatingMethodAccessorImpl.java:25) 00:03:26,200 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:3 24) 00:03:26,210 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$Conta inerInterceptor.invoke(StatelessSessionContainer.java:664) 00:03:26,220 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedCo nnectionInterceptor.invoke (CachedConnectionInterceptor.java:186) 00:03:26,230 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanc eInterceptor.invoke (StatelessSessionInstanceInterceptor.java:77) 00:03:26,240 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.i nvokeNext(AbstractTxInterceptor.java:96) 00:03:26,250 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWit hTransactions(TxInterceptorCMT.java:167) 00:03:26,260 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:61) 00:03:26,270 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.inv oke(SecurityInterceptor.java:129) 00:03:26,280 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(L ogInterceptor.java:166) 00:03:26,300 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invok e(StatelessSessionContainer.java:313) 00:03:26,310 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java :705) 00:03:26,320 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MB eanServerImpl.java:491) 00:03:26,330 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker. invoke(JRMPInvoker.java:362) 00:03:26,340 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor30.invoke( Unknown Source) 00:03:26,350 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
[JBoss-dev] [ jboss-Bugs-562972 ] Error in PortableRemoteObject.narrow()
Bugs item #562972, was opened at 2002-05-31 12:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=562972group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 8
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in PortableRemoteObject.narrow()
Initial Comment:
18:30:30,517 ERROR [STDERR] java.lang.ClassCastException
18:30:30,518 ERROR [STDERR] at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
18:30:30,519 ERROR [STDERR] at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
When running narrow after lookup from a servlet.
--
Comment By: Steve Harvey (sgharvey)
Date: 2002-08-12 03:50
Message:
Logged In: YES
user_id=593359
If you are using 3.0.0, have you tried 3.0.1?
I went through the same thing as Matt about a week ago,
except I also examined the class loader delegation chains
for both obj and the homeIF class with code like:
try {
// traverse the chain of delegated
classloaders // towards the bootstrap
Class currClass = clazz;
ClassLoader cl;
while ( (cl = currClass.getClassLoader()) != null ) {
System.out.println(label+:classloader is + cl);
currClass = cl.getClass();
}
} catch ( Exception e ) {
System.out.println(looking for CLs, got + e);
}
and got discrepancies (more details in my followup for bug
563120) which went away (with the ClassCastException) with
3.0.1 . I too was getting CCE whether or not I used
PortableRemoteObject.narrow.
- Steve
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 11:33
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
look to hard at it. There is a
chance that JBoss could be responsible for this bug, but I don't feel like searching
in the code and my next project
is on Oracle 9iAS. If I get some more time, I will look into this more.
A good test would be to download java 1.3 and see if the bug goes away. My guess is
that is does.
Matt
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 11:30
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
look to hard at it. There is a
chance that JBoss could be responsible for this bug, but I don't feel like searching
in the code and my next project
is on Oracle 9iAS. If I get some more time, I will look into this more.
A good test would be to download java 1.3 and see if the bug goes away. My guess is
that is does.
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-August-2002
Number of tests run: 897
Successful tests: 893
Errors:1
Failures: 3
[time of test: 12 August 2002 0:42 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-562972 ] Error in PortableRemoteObject.narrow()
Bugs item #562972, was opened at 2002-05-31 09:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=562972group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 8
Submitted By: Marius Kotsbak (mkotsbak)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in PortableRemoteObject.narrow()
Initial Comment:
18:30:30,517 ERROR [STDERR] java.lang.ClassCastException
18:30:30,518 ERROR [STDERR] at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
18:30:30,519 ERROR [STDERR] at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
When running narrow after lookup from a servlet.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-12 07:40
Message:
Logged In: NO
I get the same error as before with 3.0.0. Does the problem for you go away on both
IBM's 1.3 JVM and Sun's 1.4
JVM? Also I am on Sun's 1.4.0_01 JVM on W2K.
Matt
--
Comment By: Steve Harvey (sgharvey)
Date: 2002-08-12 00:50
Message:
Logged In: YES
user_id=593359
If you are using 3.0.0, have you tried 3.0.1?
I went through the same thing as Matt about a week ago,
except I also examined the class loader delegation chains
for both obj and the homeIF class with code like:
try {
// traverse the chain of delegated
classloaders // towards the bootstrap
Class currClass = clazz;
ClassLoader cl;
while ( (cl = currClass.getClassLoader()) != null ) {
System.out.println(label+:classloader is + cl);
currClass = cl.getClass();
}
} catch ( Exception e ) {
System.out.println(looking for CLs, got + e);
}
and got discrepancies (more details in my followup for bug
563120) which went away (with the ClassCastException) with
3.0.1 . I too was getting CCE whether or not I used
PortableRemoteObject.narrow.
- Steve
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 08:33
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
look to hard at it. There is a
chance that JBoss could be responsible for this bug, but I don't feel like searching
in the code and my next project
is on Oracle 9iAS. If I get some more time, I will look into this more.
A good test would be to download java 1.3 and see if the bug goes away. My guess is
that is does.
Matt
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-08-09 08:30
Message:
Logged In: NO
This bug is killing my development efforts, but it doesn't look like JBoss fault, but
rather the VM's. First a few
investigative notes. This ClassCastException happens on both remote and local
interfaces using
PortableRemoteObject and without. PortableRemoteObject has nothing to do with this
bug. If some investigative
code is put in like this in the setSessionContext:
Context ctx = new InitialContext();
Object obj = ctx.lookup(local/BeanAHome);
Class[] c = obj.getClass().getInterfaces();
System.out.println(obj.getClass().getSuperclass().getName());
for (int i=0; ic.length; i++) {
System.out.println(c[i].getName());
}
BeanAHome home = (BeanAHome)obj;
We find the following out. First, as expected, obj is of java.lang.reflect.Proxy
class. Next we check to see what
interfaces it implements. The output show com.mycompany.BeanAHome as an implemented
interface in the
Proxy. However, when a cast is made to this object an exception occurs. This makes
no sense because
reflection shows it implements the desired interface.
I have looked at Sun's bug parade have not found anything like this. I however didn't
RE: [JBoss-dev] Castor XML users; can you drop some knowledge
On Fri, 9 Aug 2002, James Higginbotham wrote: It just so happens that I was doing some of this work yesterday. I will send an email to you directly with a zip archive (as not to spam the general jboss group) of a generated XSD from your sample, and simple .bat to kick off Castor's src generator, and the resulting classes. James Could you send me a copy? Always wanting to learn more... --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Possible Jetty race condition? Or threading mystery? Help!!
I've been investigating the Interrupted while requesting permit exception
that now occurs in recent jboss 3 versions under heavy load and wonder if
it is due to a race condition in the jetty thread pool. In any case it
seems clear that the Interrupt() is called from Jetty's
HttpConnection.close() method.
Here's some annotated trace info (some from modifying Thread to tell us
what is going on). This is all about thread 4ac866. It appears to being
used by 2 HttpConnections more or less simultaneously (??)
--we start by HttpConnection recording it's thread.
2002-08-12 10:17:08,829 INFO [org.mortbay.http.HttpConnection] setting
_handlingThread to
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@462080
--later, it is done with this thread so it interrupts it. Note we are
using HttpConnection 462080
2002-08-12 10:17:08,833 INFO [org.mortbay.http.HttpConnection]
interrupting handling thread:
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
from thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@462080
--Here's Thread telling us all about the interrupt call
2002-08-12 10:17:08,834 ERROR [STDERR] Interrupt called--
on thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
from thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
2002-08-12 10:17:08,835 ERROR [STDERR] java.lang.Exception: Stack trace
from interrupt
2002-08-12 10:17:08,836 ERROR [STDERR] at
java.lang.Thread.interrupt(Thread.java:665)
2002-08-12 10:17:08,836 ERROR [STDERR] at
org.mortbay.http.HttpConnection.close(HttpConnection.java:248)
2002-08-12 10:17:08,837 ERROR [STDERR] at
org.mortbay.http.HttpConnection.destroy(HttpConnection.java:1102)
2002-08-12 10:17:08,837 ERROR [STDERR] at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:1066)
2002-08-12 10:17:08,838 ERROR [STDERR] at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:808)
2002-08-12 10:17:08,838 ERROR [STDERR] at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:186)
2002-08-12 10:17:08,838 ERROR [STDERR] at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:322)
2002-08-12 10:17:08,839 ERROR [STDERR] at
org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:713)
2002-08-12 10:17:08,840 ERROR [STDERR] at
java.lang.Thread.run(Thread.java:479)
--The interrupt completed successfully, we are still in HttpConnection
462080
2002-08-12 10:17:08,841 INFO [org.mortbay.http.HttpConnection] finished
interrupting handling thread:
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
from thread
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50079,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@462080
stuff about another thread and HttpConnection removed
--I don't know for sure if this activity is for this thread.
2002-08-12 10:17:08,944 DEBUG [org.jboss.system.Registry] lookup
-1570654348=jboss.j2ee:service=EJB,jndiName=CategoryHome
2002-08-12 10:17:08,945 DEBUG
[org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory]
Using properties: {user=postgres, password=}
--Now our thread is being used by HttpConnection@4dfd19, repeatedly
2002-08-12 10:17:08,971 INFO [org.mortbay.http.HttpConnection] setting
_handlingThread to
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50083,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@4dfd19
2002-08-12 10:17:08,976 INFO [org.mortbay.http.HttpConnection] setting
_handlingThread to
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50083,localport=8080]
in HttpConnection: org.mortbay.http.HttpConnection@4dfd19
2002-08-12 10:17:08,982 INFO [org.mortbay.http.HttpConnection] setting
_handlingThread to
Threadorg.mortbay.util.ThreadPool$PoolThread@4ac866[SocketListener-49,5,jboss]:
jobrunner:
SocketListener-49|0|Socket[addr=localhost/127.0.0.1,port=50083,localport=8080]
in HttpConnection:
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-August-2002
Number of tests run: 897
Successful tests: 893
Errors:1
Failures: 3
[time of test: 12 August 2002 12:38 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XA Resources
Thanks!! I want to get this in our testsuite as soon as possible. I'm not sure how best to do this. Right now the only xa thingy we ship with is the jmxra adapter. I lean toward modifying the test so it only tests jca adapters, since that is the only thing we can deploy in jboss. Then we can work on writing driver-specific jca wrappers to work around the particular spec violations in each driver. Is it important to do work on the connection before trying to commit? If it is unnecessary it will be easier to make the test more generic. If it is necessary I think it will be easiest to test the adapter inside jboss by deploying it using the normal .rar deployment mechanism. Any thoughts? Thanks david jencks On 2002.08.11 17:54:21 -0400 Igor Fedorenko wrote: Ok, attached is jboss xa compatibility test, version 0.0 pre-alpha :-) Main test is org.jboss.tm.XATest. It is supposed to be resource-manager independent and uses two interfaces org.jboss.tm.test.ResourceManager and org.jboss.tm.test.XAConnection to access/test real resource managers. There is an implementation of these interfaces for JDBC and JMS. I have defined few basic tests as well as tests for bugs #590816 and #585632. Of course more tests are needed. Test is configured by property file which specifies what implementation of org.jboss.tm.test.ResourceManager to be used and configuration of the implementation itself. You can find example configuration for oracle, jbossmq and weblogic-jms. Hope this would be helpful. As usual, questions, comments and suggestions are welcome. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com Scott M Stark wrote: Do it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 9:06 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XA Resources By the way, why do not we setup XA compatibility tests we can run against different resource managers? I see two types of tests -- tests that use XAResource directly and tests that check TransactionImpl. If this sounds reasonable I can try to write something we can start with. --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
David Jencks wrote: Thanks!! I want to get this in our testsuite as soon as possible. I'm not sure how best to do this. Right now the only xa thingy we ship with is the jmxra adapter. Just to make sure that we are talking about same testing approach: XATest has a test case for all interesting interection between transaction manager and resource manager, in particular for all sequences of xa calls that caused us trouble (as bugs 585632 and 590816). We also have configurations of the test for all resource managers we would like to support (oracle, swift, sap, mssql, and so on). Each time we change anything in transaction manager we run tests with resource managers to see if they are compatible. Once we find an incompatibility with specific rm we either change transaction manager to avoid the problem or write adaptor/wrapper for problematic rm. We need to find volunteers for all resource managers we want to test with. We also need to find a way to initiate tests and to gather results. I think I can do oracle 817 with various jdbc drivers/configurations... I lean toward modifying the test so it only tests jca adapters, since that is the only thing we can deploy in jboss. Then we can work on writing driver-specific jca wrappers to work around the particular spec violations in each driver. Do you have jca adapter for jdbc xa data sources and jms xa connection factories? If this is the case, then sure it is the way to go (and shame on me that I did not do that). At the same time I find that oracle-specific jca adaptor would be overkill and all oracle-specific problems can be solved with a wrapper for oracle jdbc driver. As far as I understood, wrapper for informix jdbc driver solves all informix specific problems. Is it important to do work on the connection before trying to commit? If it is unnecessary it will be easier to make the test more generic. If it is necessary I think it will be easiest to test the adapter inside jboss by deploying it using the normal .rar deployment mechanism. If we did not do any work on a connection, resource manager is supposed to return XA_RDONLY from XAResource.prepare and transaction manager does not have to commit the connection. The point is that both resource manager and transaction manager behave differently, and I think it is important to test both XA_OK and XA_RDONLY. Btw, how does deployment of .rar help to test work on a connection? To be honest, I do not have any experience with XA or JCA, but I've read some docs :-) Any thoughts? Thanks david jencks On 2002.08.11 17:54:21 -0400 Igor Fedorenko wrote: Ok, attached is jboss xa compatibility test, version 0.0 pre-alpha :-) Main test is org.jboss.tm.XATest. It is supposed to be resource-manager independent and uses two interfaces org.jboss.tm.test.ResourceManager and org.jboss.tm.test.XAConnection to access/test real resource managers. There is an implementation of these interfaces for JDBC and JMS. I have defined few basic tests as well as tests for bugs #590816 and #585632. Of course more tests are needed. Test is configured by property file which specifies what implementation of org.jboss.tm.test.ResourceManager to be used and configuration of the implementation itself. You can find example configuration for oracle, jbossmq and weblogic-jms. Hope this would be helpful. As usual, questions, comments and suggestions are welcome. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com Scott M Stark wrote: Do it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 9:06 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XA Resources By the way, why do not we setup XA compatibility tests we can run against different resource managers? I see two types of tests -- tests that use XAResource directly and tests that check TransactionImpl. If this sounds reasonable I can try to write something we can start with. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XA Resources
On 2002.08.12 18:09:17 -0400 Igor Fedorenko wrote: David Jencks wrote: Thanks!! I want to get this in our testsuite as soon as possible. I'm not sure how best to do this. Right now the only xa thingy we ship with is the jmxra adapter. Just to make sure that we are talking about same testing approach: I think so, although we might have slightly different viewpoints. XATest has a test case for all interesting interection between transaction manager and resource manager, in particular for all sequences of xa calls that caused us trouble (as bugs 585632 and 590816). We also have configurations of the test for all resource managers we would like to support (oracle, swift, sap, mssql, and so on). Each time we change anything in transaction manager we run tests with resource managers to see if they are compatible. Once we find an incompatibility with specific rm we either change transaction manager to avoid the problem or write adaptor/wrapper for problematic rm. We need to find volunteers for all resource managers we want to test with. We also need to find a way to initiate tests and to gather results. Yes, I haven't thought of a good way to do that. I still want it in our test suite. I think I can do oracle 817 with various jdbc drivers/configurations... I lean toward modifying the test so it only tests jca adapters, since that is the only thing we can deploy in jboss. Then we can work on writing driver-specific jca wrappers to work around the particular spec violations in each driver. Do you have jca adapter for jdbc xa data sources and jms xa connection factories? If this is the case, then sure it is the way to go (and shame on me that I did not do that). Yes, this is how everything connection-like is now deployed in jboss. The jms adapter jmsra is in connector/src/main/org/jboss/resource/adapter/jms. The current jdbc xa wrapper adapter sucks and I am working on a replacement based on the jdbc Local wrapper that will be easy to customize. At the same time I find that oracle-specific jca adaptor would be overkill and all oracle-specific problems can be solved with a wrapper for oracle jdbc driver. As far as I understood, wrapper for informix jdbc driver solves all informix specific problems. I think with a suitable base xa wrapper these customizations for specific drivers will be very easy. Is it important to do work on the connection before trying to commit? If it is unnecessary it will be easier to make the test more generic. If it is necessary I think it will be easiest to test the adapter inside jboss by deploying it using the normal .rar deployment mechanism. If we did not do any work on a connection, resource manager is supposed to return XA_RDONLY from XAResource.prepare and transaction manager does not have to commit the connection. The point is that both resource manager and transaction manager behave differently, and I think it is important to test both XA_OK and XA_RDONLY. Good point. I definitely agree. Btw, how does deployment of .rar help to test work on a connection? With a jca adapter, you theres a part of the application server between the connection factory (e.g. datasource) and ManagedConnectionFactory (similar to an XADataSource. This part, called ConnectionManager, manages pooling, security, and transactions. I think our ConnectionManager has the hooks we need to run all your tests, if not we can add them easily. You need a ConnectionManager in order to get a ConnectionFactory (datasource) so you can get a connection to do some work. Since the only things we can deploy in jboss are jca adapters, even if they are wrapping xa drivers of some other kind, I think it makes sense to only test jca adapters. To be honest, I do not have any experience with XA or JCA, but I've read some docs :-) Reading the xa docs didn't do me that much good;-) I think I understand the jca stuff ok. Thanks david Any thoughts? Thanks david jencks On 2002.08.11 17:54:21 -0400 Igor Fedorenko wrote: Ok, attached is jboss xa compatibility test, version 0.0 pre-alpha :-) Main test is org.jboss.tm.XATest. It is supposed to be resource-manager independent and uses two interfaces org.jboss.tm.test.ResourceManager and org.jboss.tm.test.XAConnection to access/test real resource managers. There is an implementation of these interfaces for JDBC and JMS. I have defined few basic tests as well as tests for bugs #590816 and #585632. Of course more tests are needed. Test is configured by property file which specifies what implementation of org.jboss.tm.test.ResourceManager to be used and configuration of the implementation itself. You can find example configuration for oracle, jbossmq and weblogic-jms. Hope this would be helpful. As usual, questions, comments and suggestions are welcome. -- Igor Fedorenko Think smart. Think automated. Think
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 13-August-2002
Number of tests run: 909 Successful tests: 887 Errors:16 Failures: 6 [time of test: 13 August 2002 2:20 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-557867 ] Failed redeploy corrupts server
Bugs item #557867, was opened at 2002-05-19 01:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=557867group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Brian Topping (topping) Assigned to: Nobody/Anonymous (nobody) Summary: Failed redeploy corrupts server Initial Comment: When redeploying an EAR file, it is possible to have a failure in undeploy that causes irreparable damage to the deployer state. The following lines were found in the server log files: 01:24:58,038 INFO [MainDeployer] Undeploying file:/C:/dev/jboss- 3.0.0RC2/server/default/deploy/samples.ear 01:24:58,038 INFO [EjbModule] Stopping 01:24:58,058 INFO [EjbModule] Stopped 01:24:58,058 INFO [Jetty] Stopped SecurityHandler in WebApplicationContext[/samples- web,jar:njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear ^/samples-web.war!/] 01:24:58,058 INFO [Jetty] Stopped WebInfProtect 01:24:58,058 INFO [Jetty] Stopped FilterHandler in WebApplicationContext[/samples- web,jar:njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^/ samples-web.war!/] 01:24:58,058 INFO [Jetty] SimpleServlet: destroy 01:24:58,058 INFO [Jetty] Stopped ServletHandler in WebApplicationContext[/samples- web,jar:njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^ /samples-web.war!/] 01:24:58,068 INFO [Jetty] Stopped ResourceHandler in WebApplicationContext[/samples- web,jar:njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear ^/samples-web.war!/] 01:24:58,068 INFO [Jetty] Stopped NotFoundHandler in WebApplicationContext[/samples- web,jar:njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear ^/samples-web.war!/] 01:24:58,068 INFO [Jetty] Deregister jboss.web:Jetty=0,JBossWebApplicationContext=1,context= /samples-web 01:24:58,068 INFO [Jetty] Successfully undeployed njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^/samples-web.war 01:24:58,068 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:/C:/dev/jboss- 3.0.0RC2/server/default/deploy/samples.ear 01:24:58,068 INFO [EjbModule] Destroying 01:24:58,078 INFO [EjbModule] Remove JSR-77 EJB Module: jboss.management.single:J2EEApplication=samples.ear,J2E EServer=Single,j2eeType=EJBModule,name=samples-ejb.jar 01:24:58,088 INFO [EJBModule] Stopping 01:24:58,088 INFO [EJBModule] Stopped 01:24:58,088 INFO [EjbModule] Destroyed 01:24:58,088 INFO [MainDeployer] not deleting localUrl, it is null or not a copy: njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^/samples- ejb.jar 01:24:58,088 INFO [MainDeployer] Undeployed njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^/samples-ejb.jar 01:24:58,088 INFO [MainDeployer] not deleting localUrl, it is null or not a copy: njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^/samples- web.war 01:24:58,088 INFO [MainDeployer] Undeployed njar:file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear^/samples-web.war 01:24:58,088 INFO [MainDeployer] could not delete directory file:/C:/dev/jboss- 3.0.0RC2/server/default/tmp/deploy/server/default/deplo y/samples.ear/76.samples.ear restart will delete it 01:24:58,088 INFO [MainDeployer] Undeployed file:/C:/dev/jboss- 3.0.0RC2/server/default/deploy/samples.ear Afterwards, a new ear file was copied to the deploy directory, which failed with no apparent reason (see bug #557836). Restarting the server did not solve the problem. Shutting down server, then removing inflated ear tree from tmp directory did not help, nor did shutting down the server and destroying the entire tmp directory and redeploying the ear file. The only option appears to be to reinstall the entire server tree when this happens. -- Comment By: Brian Topping (topping) Date: 2002-08-13 00:27 Message: Logged In: YES user_id=99236 I guess I just know now to delete the tmp directory whenever JB starts acting all nutty. Things got a lot easier once I learned how to chant properly around the server :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=557867group_id=22866 --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech
