missing class while booting
by Dimitris Andreadis
17:29:46,156 INFO [MetaDataAwareProfile] Using profile
root:X:\cvs\jboss-public\jboss-head\build\output\jboss-5.0.0.GA\server\minimal
Exception in thread "main" java.lang.NoSuchMethodError:
org.jboss.managed.plugins.DefaultFieldsImpl.setValue(Ljava/io/Serializable;)V
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.initBootstrapMDs(ProfileServiceBootstrap.java:479)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:188)
at
org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:404)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:595)
17:29:46,421 INFO [ServerImpl] Runtime shutdown hook called, forceHalt:
true
17:29:47,000 INFO [ServerImpl] Shutdown complete
Shutdown complete
Halting VM
15 years, 5 months
ejb3 metadata elements
by Alexey Loubyansky
I am at the final steps cleaning jboss_5_0.xsd and the dtd. I would like
to clarify which elements are NOT needed (ejb2 legacy) in jboss_5_0.xsd.
Please, review and let me know.
For example, 'jboss' element (jbossType)
- container-configurations, invoker-proxy-bindings are removed
session element
- configuration-name - can't be removed w/o removing cluster-config (do
we need cluster-config in the xsd?)
- invoker-bindings - removed
- security-proxy - removed
Are there elements from the following list which should be removed?
<xsd:element name="security-identity"
type="javaee:security-identityType" minOccurs="0"/>
<xsd:element name="local-binding" type="jboss:local-bindingType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="remote-binding" type="jboss:remote-bindingType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="business-local" type="javaee:string" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="business-remote" type="javaee:string" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="jndi-name" type="javaee:jndi-nameType" minOccurs="0"/>
<xsd:element name="home-jndi-name" type="javaee:jndi-nameType"
minOccurs="0"/>
<xsd:element name="call-by-value" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="exception-on-rollback" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="timer-persistence" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="local-jndi-name" type="jboss:local-jndi-nameType"
minOccurs="0"/>
<xsd:element name="local-home-jndi-name" type="javaee:jndi-nameType"
minOccurs="0"/>
<xsd:element name="jndi-binding-policy"
type="jboss:jndi-binding-policyType" minOccurs="0"/>
<xsd:element name="clustered" type="jboss:clusteredType" minOccurs="0"/>
<xsd:element name="cluster-config" type="jboss:cluster-configType"
minOccurs="0"/>
<xsd:element name="security-domain" type="jboss:security-domainType"
minOccurs="0"/>
<xsd:element name="method-attributes" type="jboss:method-attributesType"
minOccurs="0"/>
<xsd:element name="depends" type="jboss:dependsType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="annotation" type="jboss:annotationType" minOccurs="0"/>
<xsd:element name="ignore-dependency" type="jboss:ignore-dependencyType"
minOccurs="0"/>
<xsd:element name="aop-domain-name" type="jboss:aop-domain-nameType"
minOccurs="0"/>
<xsd:element name="cache-config" type="jboss:cache-configType"
minOccurs="0"/>
<xsd:element name="pool-config" type="jboss:pool-configType" minOccurs="0"/>
<xsd:element name="concurrent" type="jboss:concurrentType" minOccurs="0"/>
<xsd:element name="jndi-ref" type="jboss:jndi-refType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="port-component" type="jboss:port-componentType"
minOccurs="0" maxOccurs="1"/>
<xsd:element name="ejb-timeout-identity"
type="jboss:security-identityType" minOccurs="0" maxOccurs="1"/>
<xsd:element name="ior-security-config"
type="jboss:ior-security-configType" minOccurs="0"/>
message-driven
- configuration-name - can't be removed w/o removing cluster-config (do
we need cluster-config in the xsd?)
- invoker-bindings - removed
- security-proxy - removed
Are there elements from the following list which should be removed?
<xsd:element name="local-jndi-name" type="jboss:local-jndi-nameType"
minOccurs="0"/>
<xsd:element name="jndi-binding-policy"
type="jboss:jndi-binding-policyType" minOccurs="0"/>
<xsd:element name="mdb-user" type="jboss:mdb-userType" minOccurs="0"/>
<xsd:element name="mdb-passwd" type="jboss:mdb-passwdType" minOccurs="0"/>
<xsd:element name="mdb-client-id" type="jboss:mdb-client-idType"
minOccurs="0"/>
<xsd:element name="mdb-subscription-id"
type="jboss:mdb-subscription-idType" minOccurs="0"/>
<xsd:element name="resource-adapter-name"
type="jboss:resource-adapter-nameType" minOccurs="0"/>
<xsd:element name="exception-on-rollback" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="timer-persistence" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="ejb-ref" type="jboss:ejb-refType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="ejb-local-ref" type="jboss:ejb-local-refType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="service-ref" type="jboss:service-refType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="security-identity" type="jboss:security-identityType"
minOccurs="0"/>
<xsd:element name="resource-ref" type="jboss:resource-refType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="resource-env-ref" type="jboss:resource-env-refType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="message-destination-ref"
type="jboss:message-destination-refType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="security-identity" type="jboss:security-identityType"
minOccurs="0" maxOccurs="1"/>
<xsd:element name="security-domain" type="jboss:security-domainType"
minOccurs="0"/>
<xsd:element name="method-attributes" type="jboss:method-attributesType"
minOccurs="0"/>
<xsd:element name="depends" type="jboss:dependsType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="ior-security-config"
type="jboss:ior-security-configType" minOccurs="0"/>
<xsd:element name="ejb-timeout-identity"
type="jboss:security-identityType" minOccurs="0" maxOccurs="1"/>
<xsd:element name="annotation" type="jboss:annotationType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="ignore-dependency" type="jboss:ignore-dependencyType"
minOccurs="0"/>
<xsd:element name="aop-domain-name" type="jboss:aop-domain-nameType"
minOccurs="0"/>
<xsd:element name="pool-config" type="jboss:pool-configType" minOccurs="0"/>
<xsd:element name="jndi-ref" type="jboss:jndi-refType" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="activation-config" type="jboss:activation-configType"
minOccurs="0"/>
<xsd:element name="default-activation-config"
type="jboss:activation-configType" minOccurs="0"/>
<xsd:element name="create-destination" type="xsd:boolean" minOccurs="0"/>
Thanks,
Alexey
15 years, 5 months
BeanMetaDataICF boot DEBUG messages
by Dimitris Andreadis
Don't know if you have noticed; boot log has quite a few of those stacktraces:
20:57:56,265 DEBUG [BeanMetaDataICF] Using bean class:, class
org.jboss.beans.metadata.plugins.AbstractBeanMetaData for bean:
AbstractBeanMetaData@88a970{name=AOPJBossIntegration
bean=org.jboss.aop.asintegration.jboss5.JBoss5Integration properties=
classLoader=AbstractClassLoaderMetaData@18f1be9{classloader=AbstractDependencyValueMetaData@2c06b2{value=aop-classloader:0.0.0}}
constructor=null autowireCandidate=true}
20:57:56,265 DEBUG [BeanMetaDataICF] Using bean class:, class
org.jboss.beans.metadata.plugins.AbstractBeanMetaData for bean:
AbstractBeanMetaData@88a970{name=AOPJBossIntegration
bean=org.jboss.aop.asintegration.jboss5.JBoss5Integration properties=
classLoader=AbstractClassLoaderMetaData@18f1be9{classloader=AbstractDependencyValueMetaData@2c06b2{value=aop-classloader:0.0.0}}
constructor=null autowireCandidate=true}
20:57:56,265 DEBUG [BeanMetaDataICF] Using bean class:, class
org.jboss.beans.metadata.plugins.AbstractBeanMetaData for bean:
AbstractBeanMetaData@6bb93c{name=DefaultAspectManager
bean=org.jboss.aop.microcontainer.beans.metadata.DefaultAspectManager
properties=[managerProperty, managerBean]
classLoader=AbstractClassLoaderMetaData@18f1be9{classloader=AbstractDependencyValueMetaData@2c06b2{value=aop-classloader:0.0.0}}
constructor=null autowireCandidate=true}
20:57:56,265 DEBUG [BeanMetaDataICF] Using bean class:, class
org.jboss.beans.metadata.plugins.AbstractBeanMetaData for bean:
AbstractBeanMetaData@6bb93c{name=DefaultAspectManager
bean=org.jboss.aop.microcontainer.beans.metadata.DefaultAspectManager
properties=[managerProperty, managerBean]
classLoader=AbstractClassLoaderMetaData@18f1be9{classloader=AbstractDependencyValueMetaData@2c06b2{value=aop-classloader:0.0.0}}
constructor=null autowireCandidate=true}
20:57:56,265 DEBUG [BeanMetaDataICF] Failed to get property value for bean:
org.jboss.beans.metadata.plugins.AbstractBeanMetaData, property: properties
java.lang.IllegalArgumentException: Property is not readable: propertyReplace for
org.jboss.beans.metadata.plugins.AbstractPropertyMetaData
at org.jboss.beans.info.plugins.DefaultPropertyInfo.get(DefaultPropertyInfo.java:131)
at org.jboss.beans.info.plugins.BeanInfoUtil.getNestedTarget(BeanInfoUtil.java:78)
at org.jboss.beans.info.plugins.BeanInfoUtil.get(BeanInfoUtil.java:142)
at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:284)
at
org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCompositeValue(DefaultMetaValueFactory.java:444)
at
org.jboss.metatype.plugins.values.DefaultMetaValueFactory.internalCreate(DefaultMetaValueFactory.java:997)
at
org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCollectionValue(DefaultMetaValueFactory.java:231)
at
org.jboss.metatype.plugins.values.DefaultMetaValueFactory.internalCreate(DefaultMetaValueFactory.java:1003)
at
org.jboss.metatype.plugins.values.DefaultMetaValueFactory.create(DefaultMetaValueFactory.java:515)
at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getValue(BeanMetaDataICF.java:165)
at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getValue(BeanMetaDataICF.java:48)
at
org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator.populateValues(AbstractManagedObjectPopulator.java:201)
at
org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator.populateManagedObject(AbstractManagedObjectPopulator.java:130)
at
org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:327)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.getManagedObjectValue(AbstractInstanceClassFactory.java:305)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.getManagedObjectArray(AbstractInstanceClassFactory.java:321)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.getValue(AbstractInstanceClassFactory.java:242)
at
org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator.populateValues(AbstractManagedObjectPopulator.java:201)
at
org.jboss.managed.plugins.factory.AbstractManagedObjectPopulator.populateManagedObject(AbstractManagedObjectPopulator.java:130)
at
org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:327)
at
org.jboss.managed.api.factory.ManagedObjectFactory.initManagedObject(ManagedObjectFactory.java:77)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.initBootstrapMDs(ProfileServiceBootstrap.java:434)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:188)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:404)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:595)
15 years, 5 months
subversion 1.5 diffs
by Scott Stark
So I'm reading through the current svn manual merging section, and it says:
"In the examples that follow, we're assuming that both your Subversion
client and server are
running Subversion 1.5 (or later). If either client or server is older
than version 1.5, things
are more complicated: the system won't track changes automatically, and
you'll have to
use painful manual methods to achieve similar results. That is, you'll
always need to use
the detailed merge syntax to specify specific ranges of revisions to
replicate (see the sec-
tion called “Merge Syntax: Full Disclosure” later in this chapter), and
take special care to
keep track of what's already been merged and what hasn't. For this
reason, we strongly re-
commend that you make sure your client and server are at least at
version 1.5. "
Of course we are running 1.4.2. It looks like the big change was
tracking merge information via an svn:mergeinfo property?
15 years, 5 months
Re: Excessive logging in AS 4.2.3 and AS 5
by Jay Balunas
----- "Brian Stansberry" <brian.stansberry(a)redhat.com> wrote:
> I see 3 different issues here:
>
> 1) Code that does per-request logging at DEBUG level instead of TRACE.
>
> That's in violation of the logging standards and should be fixed.
+1 and that is what we are seeing to some extent. We don't regularly need to known every time a class is loaded, or a persistence connection is closed.
>
> 2) How much we log at DEBUG as part of service startup/shutdown.
> IMHO,
> this is not a huge problem. We should probably clean it up some, but
>
> the point of the logging is to make problem diagnosis easier, not to
> produce small logs for infrequent events.
Start up time in no little issue, but in general I agree. if there is extra logging during start up thats fine. The real issue is the reoccurring logs
>
> 3) The default loggging level for server.log. If #1 is broken, then
> having it be INFO makes sense, otherwise we punish users for our
> problems. If #1 is fixed, then different people can have different
> preferences, which I expect we're about to debate here. :-) My
> personal
> one is to leave it at DEBUG, unless we can make it configurable via
> system property substitution. Otherwise all testsuite runs will log
> at
> INFO unless we introduce testsuite hacks to replace the logging conf.
IMO - I would like to see it at info, and use an ant command to adjust the debug level for hudson builds. Why punish our users so that the continuous builds log enough.
>
> Jay Balunas wrote:
> > I personally think that this give a poor first impression of AS.
> Especially since it does not show in console, so users will not be
> immediately aware of the cause until they investigate the logs.
> >
> > my $.02
> >
> > Jay
> >
> > ----- "Galder Zamarreno" <galder.zamarreno(a)redhat.com> wrote:
> >
> >> Hi,
> >>
> >> Jay Balunas wrote:
> >>> I posted this up to the Design of POJO Server forum, but I'm not
> >> sure if that was the correct place there was not a "Design of AS"
> ;-)
> >>> While doing some performance testing for Seam I noticed that the
> >> default logging for AS 4.2.3 and AS 5.0 CR2 was set to debug, Note
> >> that console logging is limited to info so this only shows in the
> >> log.
> >>> This causes huge performance issues and exposes the user to way
> too
> >> much information. I have discussed this on the EAP side in
> >> JBPAPP-1187. They fixed it to some degree, but it still needs some
> >> work.
> >>> This is basically what I'm seeing
> >>>
> >>> Starting 4.2.3 - 1.2 mb - with app
> >>> Starting 5.0 CR2 - 1.3 mb - with no app
> >>>
> >>> A few requests with one user and seam app creates MBs of logs.
> >>>
> >>> >From my testing performance hit was huge. The average went from
> 14
> >> sec to 4 sec with 50 users and 25 requests each when I switched
> the
> >> threshold for the log file to info. The server.log file size (with
> a
> >> few requests) was only 97kb compared to the 1.2 above with just
> >> starting the server. That test was with 4.2.3 not 5.0.
> >>> Is there a reason that the logging is set this way? My opinion is
> >> that we should give the user the best initial performance, and
> concise
> >> information.
> >>
> >> IMO, it depends on what you're using it for. For
> >> production/staging/loadtesting yes, for development no.
> >>
> >> cc'ing jboss-dev
> >>
> >>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Jay Balunas
> >>>
> >> --
> >> Galder Zamarreño
> >> Sr. Software Maintenance Engineer
> >> JBoss, a division of Red Hat
> >
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberry(a)redhat.com
15 years, 5 months
JBAS-5535 - Modularisation of bootstrap and ServiceController's DeploymentException
by Adrian Brock
Dimitris's changes reminded me that I still
had to fix the classloading config for the bootstrap.
So this is now done (well almost ;-)
https://jira.jboss.org/jira/browse/JBAS-5535
I've now done this and checked a few of the configurations
(including the tests-profileservice).
There's one FIXME left which is that the ServiceController
and related classes depend on the DeploymentException
which kind of introduces a circular dependency
when it comes to exposing the deployers through JMX.
So I've put the deployer-core-spi in the jmx classloader
to resolve this.
Somebody already broke the backwards compatibility
of this api (despite me spending a lot of time making sure
this wasn't the case) by changing it to throw the new
DeploymentException instead of the old one.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=76829
I'm tempted to just change the api to throw Exception :-)
The reason it breaks backwards compatibility is that any user code
that does:
try
{
serviceController.install(...);
}
catch (old.DeploymentException e)
{
}
will now end up leaking an UndeclaredThrowableException
and also the code won't compile anymore.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 5 months
JBoss Cache uninformative noise
by Adrian Brock
It would be helpful if it actually told you the file name as well. ;-)
15:53:01,200 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,286 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,366 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,371 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,373 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,416 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,422 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,428 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,434 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,449 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,455 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,461 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
15:53:01,469 INFO [CacheConfigsXmlParser] Detected legacy configuration
file format when parsing configuration file. Migrating to the new (3.x)
file format is recommended. See FAQs for details.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 5 months
conf/bootstrap
by Dimitris Andreadis
To remove the clutter, I've tidied up the bootstrap files into conf/bootstrap
conf/
| bootstrap-minimal.xml
| bootstrap-norepo.xml
| bootstrap.xml
| java.policy
| jax-ws-catalog.xml
| jboss-log4j.xml
| jboss-minimal.xml
| jboss-service.xml
| jbossjta-properties.xml
| jndi.properties
| login-config.xml
| standardjboss.xml
| standardjbosscmp-jdbc.xml
|
+---bootstrap
| aop.xml
| bindings.xml
| classloader.xml
| deployers.xml
| jmx.xml
| profile-repository.xml
| profile.xml
| security.xml
| vfs.xml
15 years, 5 months
JBoss 5 CR2 - Serialization error
by jbossuser
I am using JBoss 5 CR2 version with OpenJPA v1.2 for my application. The
application has a custom JAAS login module that looks up user service
(stateless ejb3) and remotely invokes findUser(userId) method to retrieve
user information. JBoss runs into an infinite error loop while serializing
user information after completing findUser method in user service.
If I lookup user service ejb3 and remotely invoke findUser method from
standalone jdk client, the method runs successfully. Problem arises only
when the customlogin module tries to invoke the findUser method remotely.
Has anyone experienced similar error with JBoss CR2? Appreciate any help.
Following is the stack trace
------------------------------------------------------------------------------------------------------------------------
[org.jboss.serial.persister.RegularObjectPersister] (http-127.0.0.1-8080-4)
error
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithMethod(RegularObjectPersister.java:120)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:86)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:60)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
at java.util.ArrayList.writeObject(ArrayList.java:569)
at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithMethod(RegularObjectPersister.java:120)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:86)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:60)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
at java.util.ArrayList.writeObject(ArrayList.java:569)
at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithMethod(RegularObjectPersister.java:120)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:86)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at
org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at
org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
at
org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:188)
at
org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:390)
at
org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:60)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
at java.util.ArrayList.writeObject(ArrayList.java:569)
at sun.reflect.GeneratedMethodAccessor202.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
-----------------------------------------------------------------------------------------------------------------
--
View this message in context: http://www.nabble.com/JBoss-5-CR2---Serialization-error-tp20507824p205078...
Sent from the JBoss - Dev mailing list archive at Nabble.com.
15 years, 5 months
