Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Anita, Try this when you have some time. 1. Remove your .m2 2. mvn install from root. 3. cd to testsuite and run mvn -N install 4. cd to itests and run mvn -N install 5. cd to cxfPojoWS and run mvn -o install It's impossible to execute 5 with -o flag as the project needs to download cxf stuff from the remote repo. since you can't use the -o flag it will pick up the remote jar for geronimo-kernel. If you search all the sub directories after running 5, you will see 2 jars for geronimo-kernel, one built locally and one from the remote repo. Basically you are dead in the water. After this, you will have to replace the remote jar with the local jar and re-run mvn install to actually run the test. So basically The only way to make sure that the local jars/cars are used is to do an offile build is not possible. thanks, dims On 12/18/06, anita kulshreshtha [EMAIL PROTECTED] wrote: --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Dims, Yes, it is not straightforward to do an offline build.. This is what many of us do: 1. If starting from an empty repo do a full online build. Delete modules, configs and assemblies directory from .m2 repo. Do an offline build of these items (sometimes car plugin). 2. After an svn update, build the files that changed from their respective modules directory online. This will download any new jars. Delete the modules, configs, and assemblies from .m2 repo and do an offline full build. Not pretty but works.. I started using this after my local classes went missing.. I have been looking at the code to figure out why the incompatibility was not caught by the compatibility test in GBeanDataTest. Does anyone know? Thanks Anita --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Try this when you have some time. 1. Remove your .m2 2. mvn install from root. 3. cd to testsuite and run mvn -N install 4. cd to itests and run mvn -N install 5. cd to cxfPojoWS and run mvn -o install It's impossible to execute 5 with -o flag as the project needs to download cxf stuff from the remote repo. since you can't use the -o flag it will pick up the remote jar for geronimo-kernel. If you search all the sub directories after running 5, you will see 2 jars for geronimo-kernel, one built locally and one from the remote repo. Basically you are dead in the water. After this, you will have to replace the remote jar with the local jar and re-run mvn install to actually run the test. So basically The only way to make sure that the local jars/cars are used is to do an offile build is not possible. thanks, dims On 12/18/06, anita kulshreshtha [EMAIL PROTECTED] wrote: --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time:
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
This is a very sad state of affairs, as we are spending more time getting this convoluted maven build to work than writing code, just as many have pointed out and I'm sure will cause jdillon and anyone doing CTS testing ulcers. Is it not time to split the Geronimo 2.0 build into separate maven-plugin, modules, applications, configs and assembly build steps??? We are using multiple groupIds, so why not split up the builds for each unique groupId? -Donald anita kulshreshtha wrote: Dims, Yes, it is not straightforward to do an offline build.. This is what many of us do: 1. If starting from an empty repo do a full online build. Delete modules, configs and assemblies directory from .m2 repo. Do an offline build of these items (sometimes car plugin). 2. After an svn update, build the files that changed from their respective modules directory online. This will download any new jars. Delete the modules, configs, and assemblies from .m2 repo and do an offline full build. Not pretty but works.. I started using this after my local classes went missing.. I have been looking at the code to figure out why the incompatibility was not caught by the compatibility test in GBeanDataTest. Does anyone know? Thanks Anita --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Try this when you have some time. 1. Remove your .m2 2. mvn install from root. 3. cd to testsuite and run mvn -N install 4. cd to itests and run mvn -N install 5. cd to cxfPojoWS and run mvn -o install It's impossible to execute 5 with -o flag as the project needs to download cxf stuff from the remote repo. since you can't use the -o flag it will pick up the remote jar for geronimo-kernel. If you search all the sub directories after running 5, you will see 2 jars for geronimo-kernel, one built locally and one from the remote repo. Basically you are dead in the water. After this, you will have to replace the remote jar with the local jar and re-run mvn install to actually run the test. So basically The only way to make sure that the local jars/cars are used is to do an offile build is not possible. thanks, dims On 12/18/06, anita kulshreshtha [EMAIL PROTECTED] wrote: --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Anecdotal evidence: i spent 4 days to get the builds working and took me 2 hours to fix the code problems related to the cxfPojoWS. thanks, -- dims On 12/19/06, Donald Woods [EMAIL PROTECTED] wrote: This is a very sad state of affairs, as we are spending more time getting this convoluted maven build to work than writing code, just as many have pointed out and I'm sure will cause jdillon and anyone doing CTS testing ulcers. Is it not time to split the Geronimo 2.0 build into separate maven-plugin, modules, applications, configs and assembly build steps??? We are using multiple groupIds, so why not split up the builds for each unique groupId? -Donald anita kulshreshtha wrote: Dims, Yes, it is not straightforward to do an offline build.. This is what many of us do: 1. If starting from an empty repo do a full online build. Delete modules, configs and assemblies directory from .m2 repo. Do an offline build of these items (sometimes car plugin). 2. After an svn update, build the files that changed from their respective modules directory online. This will download any new jars. Delete the modules, configs, and assemblies from .m2 repo and do an offline full build. Not pretty but works.. I started using this after my local classes went missing.. I have been looking at the code to figure out why the incompatibility was not caught by the compatibility test in GBeanDataTest. Does anyone know? Thanks Anita --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Try this when you have some time. 1. Remove your .m2 2. mvn install from root. 3. cd to testsuite and run mvn -N install 4. cd to itests and run mvn -N install 5. cd to cxfPojoWS and run mvn -o install It's impossible to execute 5 with -o flag as the project needs to download cxf stuff from the remote repo. since you can't use the -o flag it will pick up the remote jar for geronimo-kernel. If you search all the sub directories after running 5, you will see 2 jars for geronimo-kernel, one built locally and one from the remote repo. Basically you are dead in the water. After this, you will have to replace the remote jar with the local jar and re-run mvn install to actually run the test. So basically The only way to make sure that the local jars/cars are used is to do an offile build is not possible. thanks, dims On 12/18/06, anita kulshreshtha [EMAIL PROTECTED] wrote: --- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
--- Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
After doing the latest svn update and getting Jecnks changes for jetty6, G on trunk compiled and ran successfully too. This is from a totally clean repo. Cheers Prasad On 12/16/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:279) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to worry about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no compatibility right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171)
Trunk runtime error GBeanInstanceState- deserializing GBeanState
This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:279) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:150) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:242) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:366) Caused by: java.io.InvalidClassException: org.apache.geronimo.gbean.GOperationInfo; local class incompatible: stream classdesc serialVersionUID = -5593225815559 931812, local class serialVersionUID = 5185515581104192976 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:919) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1813) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:279) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:150) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:242) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:366) Caused by: java.io.InvalidClassException: org.apache.geronimo.gbean.GOperationInfo; local class incompatible: stream classdesc serialVersionUID = -5593225815559 931812, local class serialVersionUID = 5185515581104192976 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:279) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:150) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:242) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:366) Caused by: java.io.InvalidClassException: org.apache.geronimo.gbean.GOperationInfo; local class incompatible: stream classdesc serialVersionUID = -5593225815559 931812, local class serialVersionUID = 5185515581104192976 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
I see this exact same problem as well. latest svn after nukeing .m2 repo. Will try again! -- dims Booting Geronimo Kernel (in Java 1.5.0_10)... 15:48:36,953 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:279) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:150) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:242) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:366) Caused by: java.io.InvalidClassException: org.apache.geronimo.gbean.GOperationInfo; local class incompatible: stream classdesc serialVersionUID = -5593225815559931812, local class serialVersionUID = 5185515581104192976 at java.io.ObjectStreamClass.initNonProxy(Unknown Source) at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) at java.io.ObjectInputStream.readClassDesc(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.util.HashSet.readObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.defaultReadObject(Unknown Source) at org.apache.geronimo.gbean.GBeanInfo.readObject(GBeanInfo.java:283) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.apache.geronimo.gbean.GBeanData$V1Externalizable.readGBeanInfo(GBeanData.java:352) at org.apache.geronimo.gbean.GBeanData$V0Externalizable.readExternal(GBeanData.java:281) at org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:252) at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:111) ... 17 more Server Startup failed java.lang.IllegalStateException: GBean is not running:
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote: This might be the sporadic problem after all. I just rebuilt again without any changes (still rev 487523) and the problem doesn't exist with the new images. Here's what I did this time: - mvn clean - from my local repo remove o/a/g/modules, configs, assemblies, and applications rather than removing the entire local repo. - mvn -Dstage=bootstrap - still failed in the geronimo-jetty6 SecurityTest (yes, I know I should have skipped the tests but I wanted to see if the failure/restart was in any way related to the failures) - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true Joe Joe Bohn wrote: This is happening in trunk rev 487523. I'm not sure it is the same problem I reported earlier .. in fact I think it may be different and possibly related to the serialized UID change made earlier today. I was keeping careful track of what I did in case I hit the problem that I'm mentioned in other threads with the GBeanInfo object Here's what I did: - mvn clean - completely remove my local repository. - mvn -Dstage=bootstrap - this failed in modules/geronimo-jetty6 test case for SecurityTest ... expecting a 500 returned instead of a 404 that was returned. - mvn -Dstage=bootstrap -Dmaven.test.skip=true -Dmaven.itest.skip=true - mvn -Dstage=assemble -Dmaven.test.skip=true -Dmaven.itest.skip=true I then extracted the zip images created and began hitting this error attempting to start any of the generated assemblies and received the following attempting to start each of the server images. I'm building again just in case this is like the earlier problem that seems to disappear on a rebuild for no known reason. Booting Geronimo Kernel (in Java 1.5.0_06)... 13:29:19,163 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSH OT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize GBeanState at org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120) at org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65) at org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:279) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:150) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:126) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:242) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:366) Caused by: java.io.InvalidClassException: org.apache.geronimo.gbean.GOperationInfo; local class incompatible: stream classdesc serialVersionUID = -5593225815559 931812,
