You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/12/15 20:54:04 UTC
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
java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:468)
at
org.apache.geronimo.gbean.GBeanInfo.readObject(GBeanInfo.java:283)
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.readObject(ObjectInputStream.java:339)
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
[ ] 0% 10s Startup failed
java.lang.IllegalStateException: GBean is not running:
org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
ee-system/2.0-SNAPSHOT/car
at
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
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)
java.lang.IllegalStateException: GBean is not running:
org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
ee-system/2.0-SNAPSHOT/car
at
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
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)
Server shutdown begun
Server shutdown completed
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Davanum Srinivas <da...@gmail.com>.
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:
org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car
at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
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)
java.lang.IllegalStateException: GBean is not running:
org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car
at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
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)
Server shutdown begun
Server shutdown completed
Exception Detail
================
org.apache.maven.plugin.MojoExecutionException: Failed to start Geronimo server
at org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.doExecute(StartServerMojo.java:278)
at org.apache.geronimo.mavenplugins.geronimo.reporting.ReportingMojoSupport.execute(ReportingMojoSupport.java:91)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:87)
at org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo$1.run(StartServerMojo.java:239)
On 12/15/06, Prasad Kashyap <go...@gmail.com> 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 <jo...@earthlink.net> 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
> > > 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
> > > java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:468)
> > > at
> > > org.apache.geronimo.gbean.GBeanInfo.readObject(GBeanInfo.java:283)
> > > 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.readObject(ObjectInputStream.java:339)
> > > 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
> > > [ ] 0% 10s Startup failed
> > > java.lang.IllegalStateException: GBean is not running:
> > > org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
> > >
> > > ee-system/2.0-SNAPSHOT/car
> > > at
> > > org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> > > at
> > > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
> > >
> > > 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)
> > > java.lang.IllegalStateException: GBean is not running:
> > > org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
> > >
> > > ee-system/2.0-SNAPSHOT/car
> > > at
> > > org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> > > at
> > > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
> > >
> > > 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)
> > > Server shutdown begun
> > > Server shutdown completed
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Davanum Srinivas <da...@gmail.com>.
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 <dr...@yahoo.com> 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 <da...@gmail.com> 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 <a_...@yahoo.com> wrote:
> >>> --- Davanum Srinivas <da...@gmail.com> 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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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
> > === message truncated ===
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
>
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Donald Woods <dr...@yahoo.com>.
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 <da...@gmail.com> 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 <a_...@yahoo.com> wrote:
>>> --- Davanum Srinivas <da...@gmail.com> 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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by anita kulshreshtha <a_...@yahoo.com>.
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 <da...@gmail.com> 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 <a_...@yahoo.com> wrote:
> > --- Davanum Srinivas <da...@gmail.com> 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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Davanum Srinivas <da...@gmail.com>.
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 <a_...@yahoo.com> wrote:
> --- Davanum Srinivas <da...@gmail.com> 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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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)
> > > >
> >
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Prasad Kashyap <go...@gmail.com>.
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 <da...@gmail.com> 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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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)
> >
> > === message truncated ===
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- Davanum Srinivas <da...@gmail.com> 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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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)
> > >
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Davanum Srinivas <da...@gmail.com>.
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 <a_...@yahoo.com> 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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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)
>
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by anita kulshreshtha <a_...@yahoo.com>.
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 <jo...@earthlink.net> 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 <jo...@earthlink.net> 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)
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Joe Bohn <jo...@earthlink.net>.
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 <jo...@earthlink.net> 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
>> > 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
>> > java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:468)
>> > at
>> > org.apache.geronimo.gbean.GBeanInfo.readObject(GBeanInfo.java:283)
>> > 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.readObject(ObjectInputStream.java:339)
>> > 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
>> > [ ] 0% 10s Startup failed
>> > java.lang.IllegalStateException: GBean is not running:
>> >
>> org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
>>
>> >
>> > ee-system/2.0-SNAPSHOT/car
>> > at
>> >
>> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
>>
>> > at
>> >
>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
>>
>> >
>> > 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)
>> > java.lang.IllegalStateException: GBean is not running:
>> >
>> org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
>>
>> >
>> > ee-system/2.0-SNAPSHOT/car
>> > at
>> >
>> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
>>
>> > at
>> >
>> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
>>
>> >
>> > 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)
>> > Server shutdown begun
>> > Server shutdown completed
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Prasad Kashyap <go...@gmail.com>.
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 <jo...@earthlink.net> 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
> > 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
> > java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:468)
> > at
> > org.apache.geronimo.gbean.GBeanInfo.readObject(GBeanInfo.java:283)
> > 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.readObject(ObjectInputStream.java:339)
> > 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
> > [ ] 0% 10s Startup failed
> > java.lang.IllegalStateException: GBean is not running:
> > org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
> >
> > ee-system/2.0-SNAPSHOT/car
> > at
> > org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> > at
> > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
> >
> > 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)
> > java.lang.IllegalStateException: GBean is not running:
> > org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
> >
> > ee-system/2.0-SNAPSHOT/car
> > at
> > org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> > at
> > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
> >
> > 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)
> > Server shutdown begun
> > Server shutdown completed
> >
> >
> >
> >
> >
> >
> >
>
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Posted by Joe Bohn <jo...@earthlink.net>.
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
> 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
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:468)
> at
> org.apache.geronimo.gbean.GBeanInfo.readObject(GBeanInfo.java:283)
> 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.readObject(ObjectInputStream.java:339)
> 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
> [ ] 0% 10s Startup failed
> java.lang.IllegalStateException: GBean is not running:
> org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
>
> ee-system/2.0-SNAPSHOT/car
> at
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> at
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
>
> 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)
> java.lang.IllegalStateException: GBean is not running:
> org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/j2
>
> ee-system/2.0-SNAPSHOT/car
> at
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> at
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:152)
>
> 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)
> Server shutdown begun
> Server shutdown completed
>
>
>
>
>
>
>