[JBoss-dev] [Lorg.hsqldb.persist.CachedObject;
I didn't have anything better to do in a Sunday night, I was then playing around improving the code of JBossProfiler. Then I realized a single object (org.hsqldb.persist.CachedObject[]) taking 196624 bytes on JBoss-4.0/default right after startup. Further investigation showed an array of 49152 items, and it looks this is referenced inside a method (thread). I don't think (or don't know if) we should do anything about it. I just wanted to point this out. --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] trove.jar
Both JBossSerialization and JBossAOP are using trove.jar, and on the case of if JBossSerialization is being used for communication on UnifiedInvokers, we need trove.jar on the client. I used that thing to keep register of references so I could control circular references without having to create intermediate objects. This forum here will explain why I decided to use trove: http://www.jboss.com/index.html?module=bbop=viewtopict=79587 Right now, trove.jar only exists on /jboss-aop.deployer, and in an installation without AOP, JBossSerialization won't work, and besides that anyone using UnifiedInvokers with JBossSerialization will have to manually add trove.jar on the client classpath. So... Can we move trove.jar to /lib and /client? --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] trove.jar
I agree we need to take care of this on the installer. But we are still distributing jboss as a ZIP bundle, and trove.jar is only under /jboss-aop.deployer while jboss-serialization is part of /client. It would be nice IMO if we could move it to a more generic place. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Thursday, May 25, 2006 6:08 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] trove.jar This gets to this installer discussion thread: http://www.jboss.com/index.html?module=bbop=viewtopict=83584 We need a common approach to defining how a component is integrated into a distribution so whether a jar is an embedded aspect or a dependency in the lib dir are handled consistently across all uses. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: Thursday, May 25, 2006 1:27 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] trove.jar Both JBossSerialization and JBossAOP are using trove.jar, and on the case of if JBossSerialization is being used for communication on UnifiedInvokers, we need trove.jar on the client. I used that thing to keep register of references so I could control circular references without having to create intermediate objects. This forum here will explain why I decided to use trove: http://www.jboss.com/index.html?module=bbop=viewtopict=79587 Right now, trove.jar only exists on /jboss-aop.deployer, and in an installation without AOP, JBossSerialization won't work, and besides that anyone using UnifiedInvokers with JBossSerialization will have to manually add trove.jar on the client classpath. So... Can we move trove.jar to /lib and /client? --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=kkid7521bid$8729dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBAS-2267 is the last task!!!
OptimizedOutputStream and OptimizedInputStream didn't send versioning information before. These were overriding metadata discovery by always rebuilding it from current class, what means if a field is added ObjectInputStream will think the streaming should have everything. Then my changes basically consisted of fixing writeClassDef and readClassDef by falling back to the defaults classes, if a System property is defined. From now on if a change in a class happens we will have much better chances of being compatible between versions. But now the problem is on ServerAddress. That class had a field added on 4.0.3, (and I thought the field was added on 4.0.4.rc1), and there is no way to make Pooled invokers compatible on 4.0.x - 4.0.2, unless we break 4.0.x - 4.0.3. I would like to keep PooledInvokers broken between 4.0.2-4.0.x, but I can't take that decision alone. There is no way to hack this to keep it always work. I almost got a way to write a hack (really a hack) using Serialization's protocol on a private writeObject and private readObject method, but on the end it wasn't possible at al because the presence of writeObject was telling serialization to send an extra byte. And even that way, the hack was so ugly that I didn't want to commit. So, can I proceed on breaking 4.0.2 -4.0.x on pooled invokers and having it working after 4.0.3? --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: JBAS-2267 is the last task!!!
The results we have on the matrix testsuite are what I expected: http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-compatibility-matr ix/20060512154233/results/index.html I will now find a way to remove PooledInvokers being tested under 4.0.2- BTW: There is another failure on JMS that I don't have anything to do with that: http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-compatibility-matr ix/20060512154233/results/org/jboss/test/compatibility/test/matrix/Matri xTestContainer(jms_3_2_x).html Clebert Suconic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: Friday, May 12, 2006 2:23 PM To: Scott M Stark; jboss-development@lists.sourceforge.net Subject: [JBoss-dev] RE: JBAS-2267 is the last task!!! It's already commited, I'm waiting next version compatibility testsuite build to see if this is working fine. -Original Message- From: Scott M Stark Sent: Friday, May 12, 2006 12:10 PM To: Clebert Suconic; 'jboss-development@lists.sourceforge.net' Subject: RE: JBAS-2267 is the last task!!! Ok, fine. -Original Message- From: Clebert Suconic Sent: Friday, May 12, 2006 10:03 AM To: Scott M Stark; jboss-development@lists.sourceforge.net Subject: JBAS-2267 is the last task!!! OptimizedOutputStream and OptimizedInputStream didn't send versioning information before. These were overriding metadata discovery by always rebuilding it from current class, what means if a field is added ObjectInputStream will think the streaming should have everything. Then my changes basically consisted of fixing writeClassDef and readClassDef by falling back to the defaults classes, if a System property is defined. From now on if a change in a class happens we will have much better chances of being compatible between versions. But now the problem is on ServerAddress. That class had a field added on 4.0.3, (and I thought the field was added on 4.0.4.rc1), and there is no way to make Pooled invokers compatible on 4.0.x - 4.0.2, unless we break 4.0.x - 4.0.3. I would like to keep PooledInvokers broken between 4.0.2-4.0.x, but I can't take that decision alone. There is no way to hack this to keep it always work. I almost got a way to write a hack (really a hack) using Serialization's protocol on a private writeObject and private readObject method, but on the end it wasn't possible at al because the presence of writeObject was telling serialization to send an extra byte. And even that way, the hack was so ugly that I didn't want to commit. So, can I proceed on breaking 4.0.2 -4.0.x on pooled invokers and having it working after 4.0.3? --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=kkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBAS-2267 is the last task!!!
It's already commited, I'm waiting next version compatibility testsuite build to see if this is working fine. -Original Message- From: Scott M Stark Sent: Friday, May 12, 2006 12:10 PM To: Clebert Suconic; 'jboss-development@lists.sourceforge.net' Subject: RE: JBAS-2267 is the last task!!! Ok, fine. -Original Message- From: Clebert Suconic Sent: Friday, May 12, 2006 10:03 AM To: Scott M Stark; jboss-development@lists.sourceforge.net Subject: JBAS-2267 is the last task!!! OptimizedOutputStream and OptimizedInputStream didn't send versioning information before. These were overriding metadata discovery by always rebuilding it from current class, what means if a field is added ObjectInputStream will think the streaming should have everything. Then my changes basically consisted of fixing writeClassDef and readClassDef by falling back to the defaults classes, if a System property is defined. From now on if a change in a class happens we will have much better chances of being compatible between versions. But now the problem is on ServerAddress. That class had a field added on 4.0.3, (and I thought the field was added on 4.0.4.rc1), and there is no way to make Pooled invokers compatible on 4.0.x - 4.0.2, unless we break 4.0.x - 4.0.3. I would like to keep PooledInvokers broken between 4.0.2-4.0.x, but I can't take that decision alone. There is no way to hack this to keep it always work. I almost got a way to write a hack (really a hack) using Serialization's protocol on a private writeObject and private readObject method, but on the end it wasn't possible at al because the presence of writeObject was telling serialization to send an extra byte. And even that way, the hack was so ugly that I didn't want to commit. So, can I proceed on breaking 4.0.2 -4.0.x on pooled invokers and having it working after 4.0.3? --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-4.0-jdk-matrix Build Failed
Its not my fault any more. I had fixed everything now. Bill, it looks like you updated remoting: services/cruisecontrol/checkout/jboss-4.0.x/server/src/main/org/jboss/invocation/InvokerInterceptor.java:39: cannot access org.jboss.remoting.serialization.IMarshalledValuebad class file: /services/cruisecontrol/checkout/jboss-4.0.x/thirdparty/jboss/remoting/lib/jboss-remoting.jar(org/jboss/remoting/serialization/IMarshalledValue.class)class file has wrong version 49.0, should be 48.0 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 11, 2006 4:26 PM To: Adrian Brock; Bill Burke; jboss-development@lists.sourceforge.net; QA; Scott M Stark Subject: jboss-4.0-jdk-matrix Build Failed Importance: High View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20060511171009 BUILD FAILED Ant Error Message:/services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details. Date of build:05/11/2006 17:10:09 Time to build:14 minutes 16 seconds Last changed:05/11/2006 17:00:50 Last log entry:remove erroneous subtest Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 5) 1.3.2.12 modified bill ejb3/src/test/org/jboss/ejb3/test/stateless/unit/StatelessTestCase.java remove erroneous subtest 1.1.2.134 modified bill build/build-thirdparty.xml update for remoting patch 1.5.2.33 modified bill ejb3/build-test.xml fix some failing tests. 1.10.6.6 modified adrian connector/.classpath Fix the eclipse build 1.5.2.32 modified starksm ejb3/build-test.xml Restore the jboss.dist settings on the start/stop macros
[JBoss-dev] RE: JBAS 4.0.4.GA project dependencies
Maybe Dimitris meant JBossRemoting should have a dependency on JBossSerialization 1.0.0.GA declared -Original Message- From: Tom Elrod Sent: Thursday, May 04, 2006 9:34 AM To: Dimitris Andreadis Cc: Scott M Stark; Adrian Brock; Kabir Khan; Alexey Loubyansky; Thomas Diesler; Tom Elrod; Clebert Suconic; jboss-development@lists.sourceforge.net; QA Subject: Re: JBAS 4.0.4.GA project dependencies - JBossRemoting, (a) the version number shouldn't be 1.4.2.GA ??. Second, I don't see any dependency in its component-info.xml on JBossRemoting ? Don't understand what you mean by the second point. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Updating jboss-remoting to 1.4.2
I'm updating jboss-remoting to 1.4.2 on build-thirdparty. There were some problems with WS, but I will be updating its dependency to 1.4.2 also. 1.4.2 is almost the same as 1.4.1_final. There was only a small change on MarshalledObject for JBossSerialization. Clebert --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Problem with minimal config in Branch_4_0
MarshalledInvocation is initializing
org.jboss.invocation.unified.interfaces.JavaSerializationManager on its
static block, to avoid the dependency on the streaming Tom mentioned.
public class MarshalledInvocation
extends Invocation
implements java.io.Externalizable
{
// Constants -
static
{
try
{
Class.forName(org.jboss.invocation.unified.interfaces.JavaSerialization
Manager);
}
catch (Exception e)
{
}
}
The instantiation of the streaming is being delegated to these
factories. And
org.jboss.invocation.unified.interfaces.JavaSerializationmanager creates
streams compatible with previous versions. (In case of MarshalledInvoker
being used with PooledInvoker for example).
-Original Message-
From: Scott M Stark
Sent: Monday, May 01, 2006 2:40 PM
To: Tom Elrod
Cc: Dimitris Andreadis; QA; jboss-development@lists.sourceforge.net;
Clebert Suconic
Subject: RE: Problem with minimal config in Branch_4_0
Why is that? We need to be doing a better job of minimizing cross
package dependencies to allow for cleaner reuse of functionality.
-Original Message-
From: Tom Elrod
Sent: Monday, May 01, 2006 12:33 PM
To: Scott M Stark
Cc: Tom Elrod; Dimitris Andreadis; QA;
jboss-development@lists.sourceforge.net; Clebert Suconic
Subject: Re: Problem with minimal config in Branch_4_0
They are not broken out in terms of jar currently (all in one jar).
However, the org.jboss.remoting.serialization package can be
broken out, but will need to include
org.jboss.remoting.loading.ObjectInputStreamWithClassLoader as well.
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Problem with minimal config in Branch_4_0
Eh eh... sorry, I should have been clearer.
There is an implementation under org.jboss.invocation.unified package.
If that package is available under the minimal configuration, we don't
need to add the streaming Tom mentioned.
-Original Message-
From: Scott M Stark
Sent: Monday, May 01, 2006 11:16 PM
To: Clebert Suconic; Tom Elrod
Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net'
Subject: RE: Problem with minimal config in Branch_4_0
So what does this mean, that the custom object input stream is not
needed?
-Original Message-
From: Clebert Suconic
Sent: Monday, May 01, 2006 12:49 PM
To: Scott M Stark; Tom Elrod
Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net'
Subject: RE: Problem with minimal config in Branch_4_0
MarshalledInvocation is initializing
org.jboss.invocation.unified.interfaces.JavaSerializationManager on its
static block, to avoid the dependency on the streaming Tom mentioned.
public class MarshalledInvocation
extends Invocation
implements java.io.Externalizable
{
// Constants -
static
{
try
{
Class.forName(org.jboss.invocation.unified.interfaces.JavaSerialization
Manager);
}
catch (Exception e)
{
}
}
The instantiation of the streaming is being delegated to these
factories. And
org.jboss.invocation.unified.interfaces.JavaSerializationmanager creates
streams compatible with previous versions. (In case of MarshalledInvoker
being used with PooledInvoker for example).
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-serialization dependent on trove.jar
Jboss-serialization is now dependent on trove.jar. I used that to solve circular dependencies, and it was way better to use TIntObjectHashMap and TObjectIntHashMap. And jboss-serialization is included into /client/jboss-all.jar. So, what should I do before GA? Basically I have three options: I Remove jboss-serialization.jar from /jboss-all. Since JMS is using it, I dont know if this is a good idea, but Im considering this option. II add trove.jar into jboss-all. Sincie its a third-party, I dont know if we want to do that. III Keep as is now
RE: [JBoss-dev] jboss-serialization dependent on trove.jar
Sorry about the crappy HTML post. My bad. Same post again, sorry about the duplication. Jboss-serialization is now dependent on trove.jar. I used that to solve circular dependencies, and it was way better to use TIntObjectHashMap and TObjectIntHashMap. And jboss-serialization is included into /client/jboss-all.jar. So, what should I do before GA? Basically I have three options: I - Remove jboss-serialization.jar from /jboss-all. Since JMS is using it, I don't know if this is a good idea, but I'm considering this option. II - add trove.jar into jboss-all. Sincie it's a third-party, I don't know if we want to do that. III - Keep as is now --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss-head-jdk-matrix Build Failed
Geez... still broken: http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-jdk-matrix/200604 03061941/compile.log -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Fox Sent: Friday, March 31, 2006 10:14 PM Cc: jboss-development@lists.sourceforge.net; Jason T. Greene; Thomas Diesler Subject: Re: [JBoss-dev] jboss-head-jdk-matrix Build Failed ok, hacked it to make it build. lucky we're not using web services Tim Fox wrote: It's 5am, we're going through the release procedure for JBossMessaging 1.0, updated from CVS to build the release bundle, and HEAD is broken! If any one from web services is listening please *fix this* we are NOT very happy bunnies right now [EMAIL PROTECTED] wrote: View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log =log20060331153535 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details. Date of build: 03/31/2006 15:35:35 Time to build: 19 minutes 25 seconds Last changed: 03/31/2006 15:28:35 Last log entry: convert jbws383 to wstools Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 77) 1.3deletedjgreene testsuite/src/resources/webservice/jbws383/config.xmlconvert jbws383 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws383/wstools-config.xml convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws383/WEB-INF/jaxrpc-mapping.xml convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws383/WEB-INF/webservices.xml convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws383/WEB-INF/wsdl/TestService.wsdl convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/main/org/jboss/test/webservice/jbws381/WeatherForecastSoap Impl.java Convert jbws381 to wstools 1.3modifiedjgreene testsuite/src/main/org/jboss/test/webservice/jbws381/WeatherForecasts.ja va Convert jbws381 to wstools 1.3deletedjgreene testsuite/src/resources/webservice/jbws381/config.xmlConvert jbws381 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws381/wstools-config.xml Convert jbws381 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws381/WEB-INF/jaxrpc-mapping.xml Convert jbws381 to wstools 1.3deletedjgreene testsuite/src/resources/webservice/jbws377/config.xmlconvert jbws377 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws377/wstools-config.xml convert jbws377 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws377/WEB-INF/jaxrpc-mapping.xml convert jbws377 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws377/WEB-INF/webservices.xml convert jbws377 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws377/WEB-INF/wsdl/HelloService.wsd l convert jbws377 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws358/wstools-config.xml convert jbws358 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws358/META-INF/jaxrpc-mapping.xml convert jbws358 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws358/META-INF/webservices.xml convert jbws358 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws358/META-INF/wsdl/HelloService.ws dl convert jbws358 to wstools 1.4deletedjgreene testsuite/src/resources/webservice/jbws349/config.xmlconvert jbws349 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws349/wstools-config.xml convert jbws349 to wstools 1.4modifiedjgreene testsuite/src/resources/webservice/jbws349/WEB-INF/jaxrpc-mapping.xml convert jbws349 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws331/WS-META-INF/wsdl/HelloService .wsdl convert jbws331 to wstools 1.3deletedjgreene testsuite/src/resources/webservice/jbws331/config.xmlconvert jbws331 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws331/wstools-config.xml convert jbws331 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws331/WS-META-INF/jaxrpc-mapping.xm l convert jbws331 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws331/WS-META-INF/webservices.xml convert jbws331 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws316/wstools-config.xml convert jbws316 to wstools 1.3modifiedjgreene
RE: [JBoss-dev] jboss-head-jdk-matrix Build Failed
Yes... it worked for me as well.. I had a compilation problem after I have updated my CVS. That's why I thought it was still broken. It worked fine after I removed thirdparty. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kabir Khan Sent: Monday, April 03, 2006 11:46 AM To: jboss-development@lists.sourceforge.net Cc: Jason T. Greene; Thomas Diesler Subject: RE: [JBoss-dev] jboss-head-jdk-matrix Build Failed It worked for me here, the cruisecontrol message last time I checked was an error unzipping some file? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: 03 April 2006 18:39 To: jboss-development@lists.sourceforge.net Cc: Jason T. Greene; Thomas Diesler Subject: RE: [JBoss-dev] jboss-head-jdk-matrix Build Failed Geez... still broken: http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-jdk-mat rix/200604 03061941/compile.log -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Fox Sent: Friday, March 31, 2006 10:14 PM Cc: jboss-development@lists.sourceforge.net; Jason T. Greene; Thomas Diesler Subject: Re: [JBoss-dev] jboss-head-jdk-matrix Build Failed ok, hacked it to make it build. lucky we're not using web services Tim Fox wrote: It's 5am, we're going through the release procedure for JBossMessaging 1.0, updated from CVS to build the release bundle, and HEAD is broken! If any one from web services is listening please *fix this* we are NOT very happy bunnies right now [EMAIL PROTECTED] wrote: View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk- matrix?log =log20060331153535 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details. Date of build: 03/31/2006 15:35:35 Time to build: 19 minutes 25 seconds Last changed: 03/31/2006 15:28:35 Last log entry: convert jbws383 to wstools Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 77) 1.3deletedjgreene testsuite/src/resources/webservice/jbws383/config.xmlconvert jbws383 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws383/wstools-config.xml convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws383/WEB-INF/jaxrpc-mapping.xml convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws383/WEB-INF/webservices.xml convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws383/WEB-INF/wsdl/TestSe rvice.wsdl convert jbws383 to wstools 1.3modifiedjgreene testsuite/src/main/org/jboss/test/webservice/jbws381/WeatherFo recastSoap Impl.java Convert jbws381 to wstools 1.3modifiedjgreene testsuite/src/main/org/jboss/test/webservice/jbws381/WeatherFo recasts.ja va Convert jbws381 to wstools 1.3deletedjgreene testsuite/src/resources/webservice/jbws381/config.xmlConvert jbws381 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws381/wstools-config.xml Convert jbws381 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws381/WEB-INF/jaxrpc-mapping.xml Convert jbws381 to wstools 1.3deletedjgreene testsuite/src/resources/webservice/jbws377/config.xmlconvert jbws377 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws377/wstools-config.xml convert jbws377 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws377/WEB-INF/jaxrpc-mapping.xml convert jbws377 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws377/WEB-INF/webservices.xml convert jbws377 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws377/WEB-INF/wsdl/HelloS ervice.wsd l convert jbws377 to wstools 1.1addedjgreene testsuite/src/resources/webservice/jbws358/wstools-config.xml convert jbws358 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws358/META-INF/jaxrpc-map ping.xml convert jbws358 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws358/META-INF/webservices.xml convert jbws358 to wstools 1.3modifiedjgreene testsuite/src/resources/webservice/jbws358/META-INF/wsdl/Hello Service.ws dl convert jbws358 to wstools 1.4deletedjgreene testsuite/src/resources/webservice/jbws349/config.xmlconvert jbws349 to wstools 1.1addedjgreene testsuite/src
RE: [JBoss-dev] Why isn't server building?
Title: Re: [JBoss-dev] Why isn't server building? I didn't commit my changes. I was waiting the newer version of Remoting. I will be looking into that now. From: [EMAIL PROTECTED] on behalf of Tom ElrodSent: Tue 3/28/2006 8:51 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] Why isn't server building? I think this has to do with moving the IMarshalledValue out of commonand into remoting (which would be in the remoting 1.4.1 release). Iknow Clebert was waiting on the upgrade to 1.4.1 to commit his changesto 4.0 branch that reflected this change (am guess he made that commit?)Scott M Stark wrote: My common, server, and remoting thirdparty are in synch with the 4.0 branch but there is a conflict: [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:285: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = new LocalMarshalledValue(invocation.getArguments(),n ew SafeCloningRepository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:289: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = SerializationStreamFactory.getManagerInstance().crea tedMarshalledValue((Object)invocation.getArguments()); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:304: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalle dValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = new LocalMarshalledValue(rtnValue,new SafeCloningR epository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:308: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = SerializationStreamFactory.getManagerInstance().cr eatedMarshalledValue(rtnValue); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:315: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] IMarshalledValue mv = SerializationStreamFactory.getManager Instance().createdMarshalledValue(t); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\uni fied\interfaces\JavaSerializationManager.java:97: createdMarshalledValue(java.la ng.Object) in org.jboss.invocation.unified.interfaces.JavaSerializationManager c annot override createdMarshalledValue(java.lang.Object) in org.jboss.remoting.se rialization.SerializationManager; attempting to use incompatible return type [javac] found : org.jboss.util.stream.IMarshalledValue [javac] required: org.jboss.remoting.serialization.IMarshalledValue [javac] public IMarshalledValue createdMarshalledValue(Object source) [javac] ^ [javac] 6 errors [javac] 1 warning Scott Stark VP Architecture Technology JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642___JBoss-Development mailing listJBoss-Development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why isn't server building?
It should be fixed now. BTW I've removed org.jboss.util.stream.IMarshalledValue It was confusing to have IMarshalledValue in both versions. Since org.jboss.util.stream.IMarshalledValue wasn't introduced in a final version, I thought it should be okay removing it. Clebert From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: Tuesday, March 28, 2006 9:28 PM To: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Why isn't server building? I didn't commit my changes. I was waiting the newer version of Remoting. I will be looking into that now. From: [EMAIL PROTECTED] on behalf of Tom Elrod Sent: Tue 3/28/2006 8:51 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] Why isn't server building? I think this has to do with moving the IMarshalledValue out of common and into remoting (which would be in the remoting 1.4.1 release). I know Clebert was waiting on the upgrade to 1.4.1 to commit his changes to 4.0 branch that reflected this change (am guess he made that commit?) Scott M Stark wrote: My common, server, and remoting thirdparty are in synch with the 4.0 branch but there is a conflict: [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:285: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = new LocalMarshalledValue(invocation.getArguments(),n ew SafeCloningRepository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:289: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = SerializationStreamFactory.getManagerInstance().crea tedMarshalledValue((Object)invocation.getArguments()); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:304: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalle dValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = new LocalMarshalledValue(rtnValue,new SafeCloningR epository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:308: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = SerializationStreamFactory.getManagerInstance().cr eatedMarshalledValue(rtnValue); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:315: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] IMarshalledValue mv = SerializationStreamFactory.getManager Instance().createdMarshalledValue(t); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\uni fied\interfaces\JavaSerializationManager.java:97: createdMarshalledValue(java.la ng.Object) in org.jboss.invocation.unified.interfaces.JavaSerializationManager c annot override createdMarshalledValue(java.lang.Object) in org.jboss.remoting.se rialization.SerializationManager; attempting to use incompatible return type [javac] found : org.jboss.util.stream.IMarshalledValue [javac] required: org.jboss.remoting.serialization.IMarshalledValue [javac] public IMarshalledValue createdMarshalledValue(Object source) [javac] ^ [javac] 6 errors [javac] 1 warning Scott Stark VP Architecture Technology JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications
[JBoss-dev] AOP ClassLeakages
Today, I've made more improvements on the ClassLeakage tool we used to discover some of our leakages on redeployments. Today, I decided to evaluate AOP, and I found this leak: In a first window, I saw this (field dcl on JBossClassPool): !--- FieldReference protected java.lang.ClassLoader [EMAIL PROTECTED] Detail Detailing then JbossClassPool I found this: [EMAIL PROTECTED] !--- [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] !---!--- FieldReference javassist.ClassPool [EMAIL PROTECTED] I'm willing to create a small testcase within AOP testing redeployments. I would need to work close to someone at AOP project. Clebert Suconic --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages
You're right... I will implement the Field feature. And I thought about an algorithm that would make exploreClasses faster. Actually, if I had a way to create viewers on JMX-Console, I would create links on the view in such way you could call another methods on JMX, doing a real tree navigation. Like: a href=./jmx-callMethod(MBean=some sort of context, method=show-sub-methods parameter1= parameter2==) References to Class org.user.SomeUserClass /href -Original Message- From: Adrian Brock Sent: Thursday, March 23, 2006 10:18 AM To: Clebert Suconic Cc: Scott M Stark; QA; jboss-development@lists.sourceforge.net Subject: RE: JBAS-2972 - OOME / Redeployment leakages On Thu, 2006-03-23 at 09:52 -0600, Clebert Suconic wrote: 1) It is slow - It's the best I can do now, since there is no way on the API to get such thing. I can verify later if there is a way to associate two tags with a class on JVMTI, that would help me doing a faster navigation. I'm not familiar with JVMTI and the doco is not very good, at least for newbies trying to understands the semantics of the call. I need to expermient. ;-) 2) The formatting is not good - Any ideas on how to improve it? I have just made a quick fix, improved a little bit, but not much I'd like to see something like reference - referer1.field - referer2.field - referer3.field And although using object.toString() is useful, it can be obscure when it doesn't include [EMAIL PROTECTED] like some of the jsr77 classes and it is totally uninformative for arrays. Similarly, some collections like linked lists or HashMaps don't show up well with the algorithm you are using. 3) Showing the field name - I don't have a way on the event chain to determine what's the field keeping a reference. It would be nice though. http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#jvmtiObjectRe ferenceCallback http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#JVMTI_REFEREN CE_FIELD -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: FW: JBAS-2972 - OOME / Redeployment leakages
I don't even know what ThreadPool changes you are referring to, are they real or proposed? I thought we had some changes on the ThreadPools. My bad. I meant that because of references through ThreadWithAttributes (they will be always appear for some reason on JVMTI). Anyway, I need to know if a Thread is cleared (Thread.setContextClassLoader(somethingElse) before the Thread goes to sleep. If the Thread keeps the ClassLoader reference until next request, that will make my life harder creating a TestCase structure for testing redeployment/classLeakages. http://jira.jboss.org/jira/browse/JBAS-2909 -Original Message- From: Adrian Brock Sent: Thursday, March 23, 2006 3:41 AM To: Clebert Suconic Cc: Scott M Stark; jboss-development@lists.sourceforge.net Subject: Re: FW: JBAS-2972 - OOME / Redeployment leakages On Wed, 2006-03-22 at 21:03 -0600, Clebert Suconic wrote: Sorry... pressed Ctrl-enter instead of Enter. (Damn Outlook) Do you think that our changes on ThreadPool would eventually leak redeployments on the testsuite? (for instance, by keeping Thread.currentThread().contextClassLoader() still alive) ? Clebert, can you please include some hard facts. I am not going to comment on speculation. If you want me to get the facts - (and I don't mean MSFacts ;-) then tell me. I don't even know what ThreadPool changes you are referring to, are they real or proposed? -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages
I can imagine a visitor pattern that understands what is permenantly deployed and what is hotdeployed and determines the root cause. I have that already. I can create a heapSnapshot, and analyze it later. But at this point the method I have to sort the will takes a lot of time to process now. I need a faster way to index file (without using a database). The new features uses getRerenceHolders Method, which does an inverted walkthrough everyObject looking for references on the object passed by parameter, what can be done on a life JVM (I can discover holders without create a snapshot) The method takes probably one second to run every time you call it, since it walks through the whole heap. I have to do that, since there isn't a way to fire reference events by its referenced objects. I have to calculate the equivalent backward operation. For a 10 levels analysis on a classLoader will probably take 1 minute or two. BTW: If someone is using JVMTIInterface, I will create a xmdesc to the MBean today/tomorrow. Right now you will have to look at parameter names on source code (JVMTIInterfaceMBean) -Original Message- From: Adrian Brock Sent: Thursday, March 23, 2006 4:27 AM To: Clebert Suconic Cc: Scott M Stark; QA Subject: RE: JBAS-2972 - OOME / Redeployment leakages On Thu, 2006-03-23 at 01:37 -0600, Clebert Suconic wrote: I created another method on JVMTIInterface, called exploreClassRefernces. With that method you can use JMXConsole to explore class and classLoader references to a class (given by name). - First let me explain how the data is organized: ReferencesToClassLoader.html shows every reference to [EMAIL PROTECTED] url=null ,addedOrder=50}, on this case the ClassLoader responsible for deploying testbyvalue.ear. I have limited this analysis up to 10 levels. A better approach would be dump all objects and their references out to a file. Then write something that runs a full gc() over that information. Once that is done, you need something that lets you walk the tree. I can imagine a visitor pattern that understands what is permenantly deployed and what is hotdeployed and determines the root cause. Otherwise, a simple GUI would do the trick. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages
1) It is slow - It's the best I can do now, since there is no way on the API to get such thing. I can verify later if there is a way to associate two tags with a class on JVMTI, that would help me doing a faster navigation. 2) The formatting is not good - Any ideas on how to improve it? I have just made a quick fix, improved a little bit, but not much 3) Showing the field name - I don't have a way on the event chain to determine what's the field keeping a reference. It would be nice though. -Original Message- From: Adrian Brock Sent: Thursday, March 23, 2006 9:46 AM To: Clebert Suconic Cc: Scott M Stark; QA; jboss-development@lists.sourceforge.net Subject: RE: JBAS-2972 - OOME / Redeployment leakages On Thu, 2006-03-23 at 09:23 -0600, Clebert Suconic wrote: The new features uses getRerenceHolders Method, which does an inverted walkthrough everyObject looking for references on the object passed by parameter, what can be done on a life JVM (I can discover holders without create a snapshot) The method takes probably one second to run every time you call it, since it walks through the whole heap. I have to do that, since there isn't a way to fire reference events by its referenced objects. I have to calculate the equivalent backward operation. For a 10 levels analysis on a classLoader will probably take 1 minute or two. I've been look at that this morning. 1) It is slow 2) The formatting is not good 3) Showing the field name There must be a better way to implement it, since that is what the api was designed for. BTW: If someone is using JVMTIInterface, I will create a xmdesc to the MBean today/tomorrow. Right now you will have to look at parameter names on source code (JVMTIInterfaceMBean) -Original Message- From: Adrian Brock Sent: Thursday, March 23, 2006 4:27 AM To: Clebert Suconic Cc: Scott M Stark; QA Subject: RE: JBAS-2972 - OOME / Redeployment leakages On Thu, 2006-03-23 at 01:37 -0600, Clebert Suconic wrote: I created another method on JVMTIInterface, called exploreClassRefernces. With that method you can use JMXConsole to explore class and classLoader references to a class (given by name). - First let me explain how the data is organized: ReferencesToClassLoader.html shows every reference to [EMAIL PROTECTED] url=null ,addedOrder=50}, on this case the ClassLoader responsible for deploying testbyvalue.ear. I have limited this analysis up to 10 levels. A better approach would be dump all objects and their references out to a file. Then write something that runs a full gc() over that information. Once that is done, you need something that lets you walk the tree. I can imagine a visitor pattern that understands what is permenantly deployed and what is hotdeployed and determines the root cause. Otherwise, a simple GUI would do the trick. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages
- My first implementation was an InMemory model. It was fast and beautiful, but I couldn't process large snapshots. - My second implementation was then HSQLDB. But when I was navigating, if I needed for instance to lookup on references for Strings, I had to look for reference holders on more than a thousand objects. The query was fast, but since I needed to execute it several times, took me a lot of time to process. Then I tried to use dynamic queries (if ID=1 or id=2 or id=3. it=100) and couldn't find a way to process - My third implementation (current) now is to use what I called FileCollections with a dummy quick sort. Since I was using just quickSort/binarySearch that was way faster than using HSQLDB. -Original Message- From: Adrian Brock Sent: Thursday, March 23, 2006 9:44 AM To: Clebert Suconic Cc: Scott M Stark; QA; jboss-development@lists.sourceforge.net Subject: RE: JBAS-2972 - OOME / Redeployment leakages On Thu, 2006-03-23 at 09:23 -0600, Clebert Suconic wrote: I can imagine a visitor pattern that understands what is permenantly deployed and what is hotdeployed and determines the root cause. I have that already. I can create a heapSnapshot, and analyze it later. But at this point the method I have to sort the will takes a lot of time to process now. I need a faster way to index file (without using a database). Can't you just use hsqldb in memory? That is what it was designed for ;-) -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages
Do you think that our changes on ThreadPool would eventually leak redeployments on the testsuite? (for instance, by keeping Thread.currentThread().contextClassLoader() still alive) ? I have run some tests, and if I keep running them, eventually I will get unloaded classes. (CMP for example). It's really hard to find references on this huge testsuite without having a clue on what might be the cause. I guess that thread pool will keep references until the same thread gets another classLoader on contextClassLoader()), and because of that every redeployment will keep refeferences for a while. For example, if I run: ant -Dtest=org.jboss.test.cts.test.BmpUnitTestCase one-test -Original Message- From: Scott M Stark Sent: Wednesday, March 22, 2006 7:02 PM To: Clebert Suconic; QA Cc: Bill Burke Subject: RE: JBAS-2972 - OOME / Redeployment leakages Something has pushed us over the memory edge and I doubt its aop since its usage has not expanded to my knowledge. If there is nothing obvious showing up we can consider upping the memory, but I don't want to do this without first looking into what is consuming memory. -Original Message- From: Clebert Suconic Sent: Wednesday, March 22, 2006 11:54 AM To: Scott M Stark; QA Cc: Bill Burke Subject: RE: JBAS-2972 - OOME / Redeployment leakages Can't we increase the memory (Permsize for instance) for the short term, so we would have the testsuite running, while we chase redeployment issues (hopefully fixed before GA). I haven't seen a single regression junit test testing for classLeakage (unless I'm missing something), so I guess this is a big problem for us. http://jira.jboss.org/jira/browse/JBAS-2909 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: JBAS-2972 - OOME / Redeployment leakages
Sorry... pressed Ctrl-enter instead of Enter. (Damn Outlook) Do you think that our changes on ThreadPool would eventually leak redeployments on the testsuite? (for instance, by keeping Thread.currentThread().contextClassLoader() still alive) ? I have run some tests, and if I keep running them, eventually I will get unloaded classes. (CMP for example). It's really hard to find references on this huge testsuite without having a clue on what might be the cause. I guess that thread pool will keep references until the same thread gets another classLoader on contextClassLoader()), and because of that every redeployment will keep refeferences for a while. For example, if I run this about 5 times: ant -Dtest=org.jboss.test.cts.test.BmpUnitTestCase one-test I would get every class loaded 5 times. But after forcing releases on SoftReferences (by forcing an outOfMemoryException (dummy loop allocation memory), and if I do another deployment, I would have maybe a same class loaded in maybe three distinct classLoaders (instead of 5). If you want to replicate this test, you will need to download jboss-profiler from CVS, and use the method listClassesHTMLReport from JVMTIClassMBean. (use jboss-profiler-jvmti.sar for that), and don't forget to add -agentlib:jbossAgent into your run.bat/run.sh Clebert -Original Message- From: Scott M Stark Sent: Wednesday, March 22, 2006 7:02 PM To: Clebert Suconic; QA Cc: Bill Burke Subject: RE: JBAS-2972 - OOME / Redeployment leakages Something has pushed us over the memory edge and I doubt its aop since its usage has not expanded to my knowledge. If there is nothing obvious showing up we can consider upping the memory, but I don't want to do this without first looking into what is consuming memory. -Original Message- From: Clebert Suconic Sent: Wednesday, March 22, 2006 11:54 AM To: Scott M Stark; QA Cc: Bill Burke Subject: RE: JBAS-2972 - OOME / Redeployment leakages Can't we increase the memory (Permsize for instance) for the short term, so we would have the testsuite running, while we chase redeployment issues (hopefully fixed before GA). I haven't seen a single regression junit test testing for classLeakage (unless I'm missing something), so I guess this is a big problem for us. http://jira.jboss.org/jira/browse/JBAS-2909 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] FW: Viewer for JMX/MBeans
Yes, viewer for JMXConsole would be a nice feature to be added IMO... For example, a method returning an array of objects could have a viewer formatting the result properly. On JbossProfiler I have a method called Class[] getLoadedClasses() on JVMTIInterface If I had a way to add a viewer metadata on xmdesc I would be able to create a nice tool only using JMX-Console. Clebert -Original Message- From: Scott M Stark Sent: Tuesday, March 21, 2006 11:44 AM To: Clebert Suconic Subject: RE: Viewer for JMX/MBeans WAS: [JBoss JIRA] Created: (JBAS-2972) Find cause of current testsuite OOMEs We don't have such a notion currently. The way it should be done for the jmx-console is via an mbean descriptor with a special name (viewer) for example as descriptors are the only way to add metadata to an mbean. -Original Message- From: Clebert Suconic Sent: Tuesday, March 21, 2006 9:41 AM To: Scott M Stark Subject: Viewer for JMX/MBeans WAS: [JBoss JIRA] Created: (JBAS-2972) Find cause of current testsuite OOMEs Hey Scott... Quick question.. I have a method within JVMTIInterface, Class[] getAllClasses() Do you know if it's possible to associate a method return with some sort of special viewer on the JMXConsole. If you have such feature available, it would be a cool thing. I would be able to create a nice ClassLeak tool using only JMX-Console (since I have a method getReferenceHolders now, it would be possible even to find who is holding the reference) Doing like: attribute access=read-write getMethod=getClasses setMethod=setHANamingService descriptionThe HANamingService service name/description nameHANamingService/name typejava.lang.String/type viewerorg.jboss.profiler.ResultViewer/viewer !-- by having this, I would format the result the way I want -- /attribute For now I'm asking this as a simple question, because I though we have such feature. If we don't, I will feed this in some forum. Clebert -Original Message- From: Scott M Stark (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 11:07 AM To: Clebert Suconic Subject: [JBoss JIRA] Created: (JBAS-2972) Find cause of current testsuite OOMEs Find cause of current testsuite OOMEs - Key: JBAS-2972 URL: http://jira.jboss.com/jira/browse/JBAS-2972 Project: JBoss Application Server Type: Task Environment: http://cruisecontrol.jboss.com:80/cc/artifacts/jboss-4.0-tests uite/20060320121502/results/index.html Reporter: Scott M Stark Assigned to: Clebert Suconic Priority: Critical Fix For: JBossAS-4.0.4.CR2 Looking at the the txtimer errors, these are due to previous deployments not getting cleaned up due to OOMEs: 2006-03-20 13:20:21,455 WARN [org.jboss.system.ServiceController] Problem start ing service jboss.j2ee:jndiName=test/txtimer/TimerTest,service=EJB java.lang.OutOfMemoryError ... 2006-03-20 13:20:25,895 INFO [org.jboss.ejb.plugins.StatelessSessionInstancePool] Registration is not done - stop 2006-03-20 13:20:25,896 DEBUG [org.jboss.ejb.StatelessSessionContainer] Failed to register pool as mbean javax.management.InstanceAlreadyExistsException: jboss.j2ee:jndiName=test/txtimer/TimerTest,plugin=pool,service =EJB already registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBean Registry.java:757) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean( BasicMBeanRegistry.java:225) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedD ispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIn terceptor.java:133) We need to find out why there OOMEs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Struts error with current Tomcat version
Im seeing this error when starting JBossProfiler with JBoss-4.0 fresh install. It works with any other previous version. Any idea on what changed? (did we change any classLoader op here?) 18:01:48,986 ERROR [MainDeployer] Could not create deployment: file:/home/csuconic/jboss-4.0.x/build/output/jboss-4.0.4.CR2/server/all/deploy/jboss-profiler.war/ org.jboss.ws.WSException: java.lang.ClassNotFoundException: org.apache.struts.action.ActionServlet at org.jboss.ws.server.WebServiceDeployerJSE.isWebserviceDeployment(WebServiceDeployerJSE.java:159) at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:99) at org.jboss.ws.server.WebServiceDeployerJSE.create(WebServiceDeployerJSE.java:65) at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180) at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:190) at $Proxy39.create(Unknown Source) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:190) at $Proxy8.deploy(Unknown Source)
RE: [JBoss-dev] possible builder error during 3 minute window
I have a fresh checkou of Branch_4_0, and I have a build failure, but not on WebServices BUILD FAILED /home/csuconic/jboss-4.0.x/server/build.xml:274: Failed to copy /home/csuconic/jboss-4.0.x/server/src/resources/org/jboss/verifier/EJB21 Messages.properties to /home/csuconic/jboss-4.0.x/server/output/resources/org/jboss/verifier/EJ B21Messages.properties due to null -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason T. Greene Sent: Thursday, March 09, 2006 12:06 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] possible builder error during 3 minute window Due to differing library dependencies on my system versus current thridparty, I accidentally committed code that would break the build. It was only broken for about a 3 minute window. So if you see a compile error in webservices just cvs update the module. -Jason Jason T. Greene Developer - Web Services JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] possible builder error during 3 minute window
Sorry about this... I was using IBM JDK by accident: [EMAIL PROTECTED] csuconic]$ java -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20060124) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223ifx-20060124 (JIT enabled) J9VM - 20051027_03723_lHdSMR JIT - 20051027_1437_r8 GC - 20051020_AA) JCL - 20060120a [ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: Thursday, March 09, 2006 12:55 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] possible builder error during 3 minute window I have a fresh checkou of Branch_4_0, and I have a build failure, but not on WebServices BUILD FAILED /home/csuconic/jboss-4.0.x/server/build.xml:274: Failed to copy /home/csuconic/jboss-4.0.x/server/src/resources/org/jboss/verifier/EJB21 Messages.properties to /home/csuconic/jboss-4.0.x/server/output/resources/org/jboss/verifier/EJ B21Messages.properties due to null -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason T. Greene Sent: Thursday, March 09, 2006 12:06 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] possible builder error during 3 minute window Due to differing library dependencies on my system versus current thridparty, I accidentally committed code that would break the build. It was only broken for about a 3 minute window. So if you see a compile error in webservices just cvs update the module. -Jason Jason T. Greene Developer - Web Services JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Dependency on IMarshalledValue
Scott, Im removing MarshalledValues dependency on IMarshalledValue. IMarshalledValue will be moved to jboss-remoting.jar next RC release. (later this week, or early next week). So, can I remove IMarshalledValue from commons then? Or should I just make it deprecated? Clebert
RE: [JBoss-dev] [Fwd: Reflection using Javassist]
Just one addendum...
When you asked me long ago to consider using the micro-container's
reflection metadata to serialization, I didn't do it because
serialization is something totally different in terms of reflection's
metadatas.
Hibernate and MicroContainer deals with Properties collections, while
Reflection deals with properties (private and final private), and some
other weird definitions like object replacement, private readObject,
private writeObject, and other things like that.
But if you provide an alternative way to access fields (I was actually
looking for one :-)), I can definitely extend the metadata to support
this.
That is the reason a serializable class must have a noargs
constructor.
Actually an externalizable needs a noarg constructor. A regular
serializable class don't.
Serialization needs hooks to change final fields, as a ghost constructor
is created, calling the non-serializable's super class constructor.
(Object() in the worse case), and after its creationg the fields are
changed (final and regular fields).
Sun's implementation uses sun.misc.Unsafe to do this job.
I do the same job through FieldsManager, and I delegate to regular
reflection (on JVM 1.5 you can change a final field if you set
accessible to true, and if the SecurityManger allows you to do that) or
falling back into Unsafe if available and regular reflection doesn't
work. (in other words, I will use sun.misc.Unsafe if JVM 1.4) I have
tested this mechanism using Sun, BEA and IBM's JVM.
If you look at this following example, you don't have a default
constructor, and the final field is changed on the serialization. The
constructor(int) here is not used to change finalValue, as any exception
was generated.
import java.util.Random;
import java.io.*;
public class TestSer implements java.io.Serializable
{
public static boolean PRINT_MESSAGE=false;
private final int finalValue;
private String strValue;
public TestSer(int value)
{
if (PRINT_MESSAGE)
{
throw new RuntimeException(This constructor
shouldn't be called now);
}
this.finalValue=value;
this.strValue = Some value= + finalValue;
}
public String toString()
{
return finalValue = + finalValue + and strValue=
+ strValue;
}
public static void main(String arg[])
{
try
{
TestSer ser = new TestSer(1000);
TestSer.PRINT_MESSAGE=true;
ByteArrayOutputStream byteOut = new
ByteArrayOutputStream();
ObjectOutputStream out = new
ObjectOutputStream(byteOut);
out.writeObject(ser);
out.flush();
ByteArrayInputStream byteInp = new
ByteArrayInputStream(byteOut.toByteArray());
ObjectInputStream inp = new
ObjectInputStream(byteInp);
TestSer ser2=(TestSer) inp.readObject();
System.out.println(ser1=[ + ser + ] and
ser=[ + ser2 + ]);
}
catch (Throwable e)
{
e.printStackTrace();
}
}
}
The only output I got was:
ser1=[finalValue = 1000 and strValue=Some value=1000] and
ser=[finalValue = 1000 and strValue=Some value=1000]
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [Fwd: Reflection using Javassist]
Sorry about this double... I guess it could generate some confusion.
I meant Serialization instead of Reflection in one of my words here:
When you asked me long ago to consider using the micro-container's
reflection metadata to serialization, I didn't do it because
serialization is something totally different in terms of reflection's
metadatas.
Hibernate and MicroContainer deals with Properties collections, while
*Serialization* deals with properties (private and final private), and
some
other weird definitions like object replacement, private readObject,
private writeObject, and other things like that.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Clebert Suconic
Sent: Monday, February 20, 2006 10:36 AM
To: jboss-development@lists.sourceforge.net
Subject: RE: [JBoss-dev] [Fwd: Reflection using Javassist]
Just one addendum...
When you asked me long ago to consider using the micro-container's
reflection metadata to serialization, I didn't do it because
serialization is something totally different in terms of reflection's
metadatas.
Hibernate and MicroContainer deals with Properties collections, while
Reflection deals with properties (private and final private), and some
other weird definitions like object replacement, private readObject,
private writeObject, and other things like that.
But if you provide an alternative way to access fields (I was actually
looking for one :-)), I can definitely extend the metadata to support
this.
That is the reason a serializable class must have a noargs
constructor.
Actually an externalizable needs a noarg constructor. A regular
serializable class don't.
Serialization needs hooks to change final fields, as a ghost constructor
is created, calling the non-serializable's super class constructor.
(Object() in the worse case), and after its creationg the fields are
changed (final and regular fields).
Sun's implementation uses sun.misc.Unsafe to do this job.
I do the same job through FieldsManager, and I delegate to regular
reflection (on JVM 1.5 you can change a final field if you set
accessible to true, and if the SecurityManger allows you to do that) or
falling back into Unsafe if available and regular reflection doesn't
work. (in other words, I will use sun.misc.Unsafe if JVM 1.4) I have
tested this mechanism using Sun, BEA and IBM's JVM.
If you look at this following example, you don't have a default
constructor, and the final field is changed on the serialization. The
constructor(int) here is not used to change finalValue, as any exception
was generated.
import java.util.Random;
import java.io.*;
public class TestSer implements java.io.Serializable
{
public static boolean PRINT_MESSAGE=false;
private final int finalValue;
private String strValue;
public TestSer(int value)
{
if (PRINT_MESSAGE)
{
throw new RuntimeException(This constructor
shouldn't be called now);
}
this.finalValue=value;
this.strValue = Some value= + finalValue;
}
public String toString()
{
return finalValue = + finalValue + and strValue=
+ strValue;
}
public static void main(String arg[])
{
try
{
TestSer ser = new TestSer(1000);
TestSer.PRINT_MESSAGE=true;
ByteArrayOutputStream byteOut = new
ByteArrayOutputStream();
ObjectOutputStream out = new
ObjectOutputStream(byteOut);
out.writeObject(ser);
out.flush();
ByteArrayInputStream byteInp = new
ByteArrayInputStream(byteOut.toByteArray());
ObjectInputStream inp = new
ObjectInputStream(byteInp);
TestSer ser2=(TestSer) inp.readObject();
System.out.println(ser1=[ + ser + ] and
ser=[ + ser2 + ]);
}
catch (Throwable e)
{
e.printStackTrace();
}
}
}
The only output I got was:
ser1=[finalValue = 1000 and strValue=Some value=1000] and
ser=[finalValue = 1000 and strValue=Some value=1000]
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
RE: [JBoss-dev] [Fwd: Reflection using Javassist]
If it doesn't do what you want then fix it, don't fork it.
I guess I was dead scared about breaking your code! Lol
Seriously now... I will have to revise metadata anyway next couple
weeks. I will take a look on that.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Monday, February 20, 2006 10:46 AM
To: jboss-development@lists.sourceforge.net
Subject: RE: [JBoss-dev] [Fwd: Reflection using Javassist]
It is no different.
The Microcontainer has two abstractions.
ClassInfo - a plain view of the classes (fields and methods, private or
otherwise)
BeanInfo - a javabean view
If you want to waste user's memory by keeping duplicate copies
of this information for yourself (like everybody else does :-)
then go ahead.
This is my main complaint about people continually
rolling their own.
If it doesn't do what you want then fix it, don't fork it.
I'm hoping we can return JBoss5 to being able to boot
within less than a week on machines with something
less than 4G of memory. :-)
On Mon, 2006-02-20 at 11:36, Clebert Suconic wrote:
Just one addendum...
When you asked me long ago to consider using the micro-container's
reflection metadata to serialization, I didn't do it because
serialization is something totally different in terms of reflection's
metadatas.
Hibernate and MicroContainer deals with Properties collections, while
Reflection deals with properties (private and final private), and some
other weird definitions like object replacement, private readObject,
private writeObject, and other things like that.
But if you provide an alternative way to access fields (I was actually
looking for one :-)), I can definitely extend the metadata to support
this.
That is the reason a serializable class must have a noargs
constructor.
Actually an externalizable needs a noarg constructor. A regular
serializable class don't.
Serialization needs hooks to change final fields, as a ghost
constructor
is created, calling the non-serializable's super class constructor.
(Object() in the worse case), and after its creationg the fields are
changed (final and regular fields).
Sun's implementation uses sun.misc.Unsafe to do this job.
I do the same job through FieldsManager, and I delegate to regular
reflection (on JVM 1.5 you can change a final field if you set
accessible to true, and if the SecurityManger allows you to do that)
or
falling back into Unsafe if available and regular reflection doesn't
work. (in other words, I will use sun.misc.Unsafe if JVM 1.4) I have
tested this mechanism using Sun, BEA and IBM's JVM.
If you look at this following example, you don't have a default
constructor, and the final field is changed on the serialization. The
constructor(int) here is not used to change finalValue, as any
exception
was generated.
import java.util.Random;
import java.io.*;
public class TestSer implements java.io.Serializable
{
public static boolean PRINT_MESSAGE=false;
private final int finalValue;
private String strValue;
public TestSer(int value)
{
if (PRINT_MESSAGE)
{
throw new RuntimeException(This constructor
shouldn't be called now);
}
this.finalValue=value;
this.strValue = Some value= + finalValue;
}
public String toString()
{
return finalValue = + finalValue + and strValue=
+ strValue;
}
public static void main(String arg[])
{
try
{
TestSer ser = new TestSer(1000);
TestSer.PRINT_MESSAGE=true;
ByteArrayOutputStream byteOut = new
ByteArrayOutputStream();
ObjectOutputStream out = new
ObjectOutputStream(byteOut);
out.writeObject(ser);
out.flush();
ByteArrayInputStream byteInp = new
ByteArrayInputStream(byteOut.toByteArray());
ObjectInputStream inp = new
ObjectInputStream(byteInp);
TestSer ser2=(TestSer) inp.readObject();
System.out.println(ser1=[ + ser + ] and
ser=[ + ser2 + ]);
}
catch (Throwable e)
{
e.printStackTrace();
}
}
}
The only output I got was:
ser1=[finalValue = 1000 and strValue=Some value=1000] and
ser=[finalValue = 1000 and strValue=Some value=1000]
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine
RE: [JBoss-dev] [Fwd: Reflection using Javassist]
:-) Can I use this to access/modify private attributes? Also, is it possible to modify final private attributes? Clebert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Sunday, February 19, 2006 7:27 AM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] [Fwd: Reflection using Javassist] -Forwarded Message- From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Reflection using Javassist Date: Sun, 19 Feb 2006 08:21:05 -0500 For those that don't read the dev forums: http://www.jboss.com/index.html?module=bbop=viewtopict=77714 Clebert might be interested in this to optimize his reflection usage in serialization? I told you, you should have used the ClassInfo API! But you will go reinventing. :-) -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: 3.2.8 Client - 4.0.x Compatibility
If changing RMIAdaptor and RMIAdaptorImpl on 3.2.8 like attached we solve the
compatibility.
3.2.8.sp1 (with that change) should be compatible with previous versions of
3.2.8 as useFullHashMode is always false on 3.2.8, and therefore wouldn't be
using the interface name on the hashMethod calculation.
And 3.2.8.sp1 with that change will be compatible with 4.0.x as the interface
will now match.
But I had to add a few methods on RMIAdaptorImpl. I don't know if this is the
expected semantic, so if someone could take a look on that please.
Clebert
From: Scott M Stark
Sent: Saturday, February 18, 2006 1:04 AM
To: Clebert Suconic; Ryan Campbell; Dimitris Andreadis
Cc: 'jboss-development@lists.sourceforge.net'; QA
Subject: RE: 3.2.8 Client - 4.0.x Compatibility
Ok, so we would have:
4.0.x:
MBeanServerConnection:*
RMIAdaptor:add/removeNotificationListener(...)
3.2.8-:
RMIAdaptor:*
3.2.8.SP1:
RMIAdaptor:*
MBeanServerConnection:*
The real problem is not having the hash codes, its choosing the right hash
codes for the target server. You really need to be able to build the hash map
based on the connection.
From: Clebert Suconic
Sent: Friday, February 17, 2006 10:51 PM
To: Scott M Stark; Ryan Campbell; Dimitris Andreadis
Cc: 'jboss-development@lists.sourceforge.net'; QA
Subject: RE: 3.2.8 Client - 4.0.x Compatibility
For doing that, you would need to implement that on [EMAIL PROTECTED], what
would make only possible a communication between 3.2.8.sp1 and 4.0.4.
If we had a way to inject other hashCodes on 3.2.8.sp1, we would be able to
have 3.2.8.sp1 communicating with previous versions of 4.0.4. But I don't know
if that is required.
Clebert
From: Scott M Stark
Sent: Fri 2/17/2006 7:00 PM
To: Clebert Suconic; Ryan Campbell; Dimitris Andreadis
Cc: 'jboss-development@lists.sourceforge.net'; QA
Subject: RE: 3.2.8 Client - 4.0.x Compatibility
My suggestion is that the useFullHashMode be updated to include the hash of all
methods in there interface inheritence tree hashed to the subinterfaces as well
as the interface. So, an interface B like:
interface A
{
void m1(String);
}
interface B extends A
{
void m2(String);
}
would have a hash map of:
H(A:m1(String))
H(B:m1(String))
H(B:m2(String))
This solves the existing RMIAdaptor problem where some methods were pushed into
a superinterface. The extra method hashes don't hurt anything.
-Original Message-
From: Clebert Suconic
Sent: Friday, February 17, 2006 3:08 PM
To: Scott M Stark; Ryan Campbell; Dimitris Andreadis
Cc: jboss-development@lists.sourceforge.net; QA
Subject: RE: 3.2.8 Client - 4.0.x Compatibility
I spent some time today with this issue. I just want to throw
some ideas to fix this.
First option:
If you have 4.0:MarshalledInvocation.useFullHashMode=false,
and 3.2:MarshalledInvocation.useFullHashMode=false, the
testsuite should pass.
So, we could change FullHashMode to false if some parameter
is avaible, and 3.2.8.sp1 would be compatible with 4.0.4, but
not 3.2.8. The easiest way would be have a parameter to
change the FullHashMode on 4.0
Second option:
We could also have an interface on RMIAdaptorImpl and change
MarshalledInvocation to do something like:
public static Map getInterfaceHashes(Class intf)
{
If (intf implements ThatInterface)
{
ThatINterface that = (ThatInterface)intf.newInstance();
... delegate the hashCalculation to that, somehow.
}
}
I don't like this idea, but I just wanted to throw something
on the discussion, as a brain storm.
Third options:
An option also, would be to back port RMIAdaptor from 4.0.x
to 3.2.8, but that would break compatibility between 3.2.8
and previous versions, and I don't know if there is a way to
have a selective classLoading between a newer and an older version.
Any other idea/option?
Thoughts?
Clebert Suconic
RMIAdaptor.java
Description: RMIAdaptor.java
RMIAdaptorImpl.java
Description: RMIAdaptorImpl.java
[JBoss-dev] RE: 3.2.8 Client - 4.0.x Compatibility
I spent some time today with this issue. I just want to throw some ideas
to fix this.
First option:
If you have 4.0:MarshalledInvocation.useFullHashMode=false, and
3.2:MarshalledInvocation.useFullHashMode=false, the testsuite should
pass.
So, we could change FullHashMode to false if some parameter is avaible,
and 3.2.8.sp1 would be compatible with 4.0.4, but not 3.2.8. The easiest
way would be have a parameter to change the FullHashMode on 4.0
Second option:
We could also have an interface on RMIAdaptorImpl and change
MarshalledInvocation to do something like:
public static Map getInterfaceHashes(Class intf)
{
If (intf implements ThatInterface)
{
ThatINterface that = (ThatInterface)intf.newInstance();
... delegate the hashCalculation to that, somehow.
}
}
I don't like this idea, but I just wanted to throw something on the
discussion, as a brain storm.
Third options:
An option also, would be to back port RMIAdaptor from 4.0.x to 3.2.8,
but that would break compatibility between 3.2.8 and previous versions,
and I don't know if there is a way to have a selective classLoading
between a newer and an older version.
Any other idea/option?
Thoughts?
Clebert Suconic
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: 3.2.8 Client - 4.0.x Compatibility
Title: RE: 3.2.8 Client - 4.0.x Compatibility
For doing that, you would need to implement
that on [EMAIL PROTECTED],
what would make only possible a communication between 3.2.8.sp1 and
4.0.4.
If we had a way to inject other hashCodes
on 3.2.8.sp1, we would be able to have 3.2.8.sp1 communicating with previous
versions of 4.0.4. But I don't know if that is required.
Clebert
From: Scott M StarkSent: Fri
2/17/2006 7:00 PMTo: Clebert Suconic; Ryan Campbell; Dimitris
AndreadisCc: 'jboss-development@lists.sourceforge.net';
QASubject: RE: 3.2.8 Client - 4.0.x
Compatibility
My suggestion is that the useFullHashMode be updated to include
the hash of all methods in there interface inheritence tree hashed to the
subinterfaces as well as the interface. So, an interface B
like:interface A{ void m1(String);}interface
B extends A{ void m2(String);}would have a hash
map of:H(A:m1(String))H(B:m1(String))H(B:m2(String))This
solves the existing RMIAdaptor problem where some methods were pushed into a
superinterface. The extra method hashes don't hurt anything.
-Original Message- From: Clebert Suconic Sent: Friday,
February 17, 2006 3:08 PM To: Scott M Stark; Ryan Campbell; Dimitris
Andreadis Cc: jboss-development@lists.sourceforge.net; QA
Subject: RE: 3.2.8 Client - 4.0.x Compatibility I spent some
time today with this issue. I just want to throw some ideas to fix
this. First option: If you have
4.0:MarshalledInvocation.useFullHashMode=false, and
3.2:MarshalledInvocation.useFullHashMode=false, the testsuite should
pass. So, we could change FullHashMode to false if some
parameter is avaible, and 3.2.8.sp1 would be compatible with 4.0.4,
but not 3.2.8. The easiest way would be have a parameter to
change the FullHashMode on 4.0 Second
option: We could also have an interface on RMIAdaptorImpl and
change MarshalledInvocation to do something
like: public static Map getInterfaceHashes(Class
intf) { If (intf
implements ThatInterface)
{ ThatINterface
that =
(ThatInterface)intf.newInstance();
delegate the hashCalculation to that,
somehow. }
} I don't like this idea, but I just wanted to throw
something on the discussion, as a brain
storm. Third options: An option
also, would be to back port RMIAdaptor from 4.0.x to 3.2.8, but that
would break compatibility between 3.2.8 and previous versions, and I
don't know if there is a way to have a selective classLoading between a
newer and an older version. Any other
idea/option? Thoughts? Clebert Suconic
RE: [JBoss-dev] client libraries on EJB3
IMO we need to add the whole asm, cglib and hibernate.proxy into hibernate3-client. These packages are required on any lazy relationship. Clebert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Heiko W. Rupp Sent: Wednesday, February 15, 2006 2:36 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] client libraries on EJB3 On Tue, Feb 14, 2006 at 12:09:59PM -0600, Clebert Suconic wrote: If you write an EJB3 remote application application, it's very likely you will have to add cglib, asm and hibernate3 to the classpath of your application. This sounds extremely fat. Can this be reduced to the absolutely needed clases please? -- Heiko W.Rupp http://www.pilhuhn.de/hwr/ http://mcntp.sf.net/ JBoss Buch: http://www.dpunkt.de/buch/3-89864-318-2.html --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Title: Re: [JBoss-dev] client libraries on EJB3 we are not propagating relationships across JVM boundaries. But if you have a lazy relationship, you need CGLIB and ASM on the client side. So, if you don't have CGLib, ASM and Hibernate and using a lazy relationship you will get a ClassNotFoundException when deserializing the POJO on the client side. My point was should we add these libraries to /client, or should we add the classes to hibernate-client.jar? From: [EMAIL PROTECTED] on behalf of Bill BurkeSent: Wed 2/15/2006 5:34 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] client libraries on EJB3 Unloaded relationships throw a lazy-loaded exception if accessed afterthe entity is detached.Scott M Stark wrote: Huh? We are propagating relationships across jvm boundaries? That does not make sense.-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] OnBehalf Of Clebert SuconicSent: Wednesday, February 15, 2006 1:22 PMTo: jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3IMO we need to add the whole asm, cglib and hibernate.proxyinto hibernate3-client.These packages are required on any lazy relationship.Clebert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development--Bill BurkeChief ArchitectJBoss Inc.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems? Stop! Download the new AJAX search engine that makessearching your log files as easy as surfing the web. DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___JBoss-Development mailing listJBoss-Development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Title: Re: [JBoss-dev] client libraries on EJB3 Well... I'm not sure what would happen if the lazy relationship is filled. I guess you would get the ClassNotFoundException on any Lazy Relationship if hibernate.proxy is not availble. Bill? Kabir? I only tested without activating a Lazy Relationships. From: [EMAIL PROTECTED] on behalf of Scott M StarkSent: Wed 2/15/2006 7:12 PMTo: jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 Can this enhanced proxy be replacedduring serialization to avoid this? If these classes cannot be used in a functional manner by a client, they should not be exposed to the client. Just replace the proxy with a wrapper around the lazy load exception. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert SuconicSent: Wednesday, February 15, 2006 4:31 PMTo: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 we are not propagating relationships across JVM boundaries. But if you have a lazy relationship, you need CGLIB and ASM on the client side. So, if you don't have CGLib, ASM and Hibernate and using a lazy relationship you will get a ClassNotFoundException when deserializing the POJO on the client side. My point was should we add these libraries to /client, or should we add the classes to hibernate-client.jar? From: [EMAIL PROTECTED] on behalf of Bill BurkeSent: Wed 2/15/2006 5:34 PMTo: jboss-development@lists.sourceforge.netSubject: Re: [JBoss-dev] client libraries on EJB3 Unloaded relationships throw a lazy-loaded exception if accessed afterthe entity is detached.Scott M Stark wrote: Huh? We are propagating relationships across jvm boundaries? That does not make sense.-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] OnBehalf Of Clebert SuconicSent: Wednesday, February 15, 2006 1:22 PMTo: jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3IMO we need to add the whole asm, cglib and hibernate.proxyinto hibernate3-client.These packages are required on any lazy relationship.Clebert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development--Bill BurkeChief ArchitectJBoss Inc.---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems? Stop! Download the new AJAX search engine that makessearching your log files as easy as surfing the web. DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___JBoss-Development mailing listJBoss-Development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Title: Re: [JBoss-dev] client libraries on EJB3 we will need a proxy framework anyways, right? if we replace cglib by something else (aop, javassist maybe) I guess it would be the same on that point, and besides it would require some work. From: [EMAIL PROTECTED] on behalf of Scott M StarkSent: Wed 2/15/2006 7:22 PMTo: jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 I'm asking if we can replace the proxy with one that throws the lazy loading exception on any method access without leaking dependencies on the proxy related classes. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert SuconicSent: Wednesday, February 15, 2006 5:16 PMTo: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.netSubject: RE: [JBoss-dev] client libraries on EJB3 Well... I'm not sure what would happen if the lazy relationship is filled. I guess you would get the ClassNotFoundException on any Lazy Relationship if hibernate.proxy is not availble. Bill? Kabir? I only tested without activating a Lazy Relationships.
[JBoss-dev] client libraries on EJB3
If you write an EJB3 remote application application, it's very likely you will have to add cglib, asm and hibernate3 to the classpath of your application. I don't know if we already had a discussion about this, but shouldn't these jars be under /client in our distribution. I know we have hibernate-client.jar, but in case an application uses lazy attributes it will be required cg-lib, asm and hibernate.proxy, and these classes are not available at hibernate-client.jar. I guess I realized this because I just wrote an ejb3 testcase for lazy attributes and had to add these jars in order to have it working. Clebert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] client libraries on EJB3
Look at this issue, on CVS history: http://jira.jboss.com/jira/browse/EJBTHREE-440?page=vcs I had to change build.xml to add the libraries on the client-path for ejb3 testsuite. I have added the test on Branch-4.0. Meanshile, take a look at this user's thread. It's quite interesting. http://www.jboss.com/index.html?module=bbop=viewtopict=76737postdays= 0postorder=ascstart=20 When you have a Lazy attribute over inheritance you can get a proxy serialization problem over CGLib. The testcase I created is the testcase created by the user but removing everything was not causing the issue. Only left the inheritance and Lazy ManyToOne attribute. EJBTHREE-440 also has a comment in how to replicate it. Clebert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kabir Khan Sent: Tuesday, February 14, 2006 12:22 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] client libraries on EJB3 The hibernate-client.jar is being created by the ejb3 build, but should really be done by hibernate. Can you send me or let me know where the testcase is, so I can update the files that go in there? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: 14 February 2006 19:10 To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] client libraries on EJB3 If you write an EJB3 remote application application, it's very likely you will have to add cglib, asm and hibernate3 to the classpath of your application. I don't know if we already had a discussion about this, but shouldn't these jars be under /client in our distribution. I know we have hibernate-client.jar, but in case an application uses lazy attributes it will be required cg-lib, asm and hibernate.proxy, and these classes are not available at hibernate-client.jar. I guess I realized this because I just wrote an ejb3 testcase for lazy attributes and had to add these jars in order to have it working. Clebert --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Pluggable Serialization into JBAS Invocation Layer
I just committed JBAS-2436 into JBAS 4.0 since JBoss Remoting is already out (I had some changes on JBoss Remoting holding me to commit this). I still have some questions about how to improve its configuration at http://www.jboss.com/index.html?module=bbop=viewtopict=73693 I will create a wiki page on how to use and configure it. Clebert Suconic --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: WebServices in the 3.2.8 compatibility testsuite
Okay... At this point my understanding is it's not needed to perform compatibility tests with WebServices. I would say if you QA to test WebService between different versions at any time, you will need to provide a compatible testsuite. Clebert -Original Message- From: Thomas Diesler Sent: Monday, February 06, 2006 2:41 PM To: Clebert Suconic Cc: Scott M Stark; [EMAIL PROTECTED] Subject: RE: WebServices in the 3.2.8 compatibility testsuite Hi Clebert, see attached my earlier response. With web service, the endpoint and the client are fundamentally detached (i.e. the server side endpoint does not care what technology put the message on the wire) All of our WS tests currently deploy the endpoint and the client to the same box - this is not very sensible. Similar to a J2EE-1.4 application client, the client should be deployed to a separate box (that may run a different jboss version) If you look at testsuite/output/lib you see jars like ws4ee-sometest.jar + ws4ee-sometest-client.jar Form JBossTest, both jars should be deployable to different jboss versions. This is currently not possible. Please create a JIRA issue for this requirement that equally applies to all tests where the client does a jndi lookup - it should not use the jndi tree from the server if you want to test compatibility. Cheers -thomas -Original Message- From: Clebert Suconic Sent: 06 February 2006 16:29 To: Thomas Diesler Subject: FW: WebServices in the 3.2.8 compatibility testsuite Hey Thomas... I don't know if you saw that e-mail. We still need to know if there are client libraries that need to be validated. Or if we don't need to validate client libraries, if it's required to validate any sort of protocol in between versions. (3.2.x vs previous, 4.0.x vs previous). It seems that you said that 3.2.x it's not needed even within previous version of 3.2.x, but what about 4.0.x withing previous prevsions. Please, copy QA in your answer. Thanks Clebert -Original Message- From: Clebert Suconic Sent: Friday, February 03, 2006 11:20 AM To: Thomas Diesler Cc: QA; Dimitris Andreadis; Scott M Stark; Ryan Campbell Subject: RE: WebServices in the 3.2.8 compatibility testsuite For QA: Generally web service client deployments should be disconnected from web service endpoint deployments. Currently an application client is deployed on the same host as the webservice endpoint - this is strictly speaking incorrect. We know what a webservice is (that is a disconnected service endpoint), but we need to know if there are client libraries that might need to be required on WebService clients. You already answered our question about if we need interoperability between 3.2.x and 4.0.x, but you didn't answer what tests we need (or even if we have to) to execute to guarantee interoperability between 4.0.x and previous versions of 4. -Original Message- From: Thomas Diesler Sent: Friday, February 03, 2006 7:20 AM To: Dimitris Andreadis; Scott M Stark; Ryan Campbell; Clebert Suconic Cc: QA Subject: RE: WebServices in the 3.2.8 compatibility testsuite Hi Dimitris, There is no need to test interoperability between 3.2.x and 4.0.x web services . With jboss 4.0.x we have J2EE-1.4 compliant web services that did not exist prior to jboss-4.0.0. The Jboss.Net implementation is shipped with jboss-4.0.x as an optional module in docs/examples. If customers really choose to install Jboss.NET on jboss-4.0.x (what we discourage them from doing so) and they really run into interop issues with jboss-3.2.x, we will be dealing with those on a case by case basis. For QA: Generally web service client deployments should be disconnected from web service endpoint deployments. Currently an application client is deployed on the same host as the webservice endpoint - this is strictly speaking incorrect. Cheers -thomas -Original Message- From: Dimitris Andreadis Sent: 03 February 2006 09:50 To: Thomas Diesler Subject: WebServices in the 3.2.8 compatibility testsuite Importance: High Hi Thomas, Is there any chance of interoperability between 3.2.x / 4.0.x webservices? If yes, is there someone from WS team, to work on this now? We are at the last stages of finalizing 3.2.8 (we are supposed to release on Monday 6th) so a quick response is appreciated :) -Original Message- From: Scott M Stark Sent: 03 February, 2006 00:38 To: Clebert Suconic; Ryan Campbell; Dimitris Andreadis; QA Cc: Thomas Diesler Subject: RE: Inclusion of jbossmx in the 3.2.8 compatibility testsuite A server side library should not be required for the recent jboss webservice tests/stacks. The 3.2 branch may not have a descent webservice stack and might need to be excluded, but the 4.0.x interop tests should work. I would expect at least some basic webservice tests should work between 3.2.8 and 4.0.x. Thomas would
[JBoss-dev] New Javadocs
Sometime ago I modified a javadoc implementation to generate links to sourcecodes + integrating with Java2HTML converter. I just noticed that Norman deployed these javadocs with sourcecode and Im feeling it pretty useful: http://www.jboss.org/docs/index and http://docs.jboss.org/jbossas/javadoc/4.0.2/ I feel like is easier to look at the WebInterface than open my IDE when just reading/analyzing/studying sourcecode. Thanks a lot Norman. Clebert
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316877 ] Clebert Suconic commented on JBAS-1319: --- Scott wrote: Ok, then no. Is there an example other than the spec ear which demonstrates the issue? -Original Message- From: Clebert Suconic Sent: Tuesday, April 12, 2005 6:43 AM To: Scott M Stark Subject: FW: [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError Do you really think we should close it? For simple JARs the tomcat patch is working, but for more complex jars ThreadWithAttributes still holding references. Clebert redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: ServletExample.zip, analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1676) Exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise when using invalidation/reusing session too often
[ http://jira.jboss.com/jira/browse/JBAS-1676?page=history ] Clebert Suconic updated JBAS-1676: -- Summary: Exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise when using invalidation/reusing session too often (was: Exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise when using invalidation/reusing session too oftenly) Exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise when using invalidation/reusing session too often -- Key: JBAS-1676 URL: http://jira.jboss.com/jira/browse/JBAS-1676 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2 Final Reporter: Clebert Suconic Assignee: Ben Wang Fix For: JBossAS-4.0.3 Final If you invalidate/reuse the session too shortly, this can generate an en exception (Stack trace at the end of this description). The workaround for this is if you need this behavior in cluster is to remove all properties from the session, or only invalidate the session when the user is really leaving the page. Although I think It's unlikely this bug being reproduced in a production environment as in general a programmer will call session.invalidate when the user is really leaving the page, I think we should fix it as this will be an improvement in the HttpSession data repplication. Follow the stack-trace: :14:45,211 ERROR [[HttpStressTest]] Servlet.service() for servlet HttpStressTest threw exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise at org.jboss.web.tomcat.tc5.session.ClusteredSession.getAttribute(ClusteredSession.java:154) at org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:109) at org.apache.jsp.sessionIntro_jsp._jspService(org.apache.jsp.sessionIntro_jsp:73) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.jboss.test.weblayer.HttpStressTest.doGet(HttpStressTest.java:33) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1676) Exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise when using invalidation/reusing session too oftenly
Exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise when using invalidation/reusing session too oftenly Key: JBAS-1676 URL: http://jira.jboss.com/jira/browse/JBAS-1676 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2 Final Reporter: Clebert Suconic Assigned to: Ben Wang Fix For: JBossAS-4.0.3 Final If you invalidate/reuse the session too shortly, this can generate an en exception (Stack trace at the end of this description). The workaround for this is if you need this behavior in cluster is to remove all properties from the session, or only invalidate the session when the user is really leaving the page. Although I think It's unlikely this bug being reproduced in a production environment as in general a programmer will call session.invalidate when the user is really leaving the page, I think we should fix it as this will be an improvement in the HttpSession data repplication. Follow the stack-trace: :14:45,211 ERROR [[HttpStressTest]] Servlet.service() for servlet HttpStressTest threw exception java.lang.IllegalStateException: clusteredSession.getAttribute.ise at org.jboss.web.tomcat.tc5.session.ClusteredSession.getAttribute(ClusteredSession.java:154) at org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:109) at org.apache.jsp.sessionIntro_jsp._jspService(org.apache.jsp.sessionIntro_jsp:73) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.jboss.test.weblayer.HttpStressTest.doGet(HttpStressTest.java:33) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) 13:14:45,330 ERROR [[HttpStressTest]] Servlet.service() for servlet
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316849 ] Clebert Suconic commented on JBAS-1319: --- Adrian wrote: What we really need is to identify the classloader classloader.toString() and then provide backtraces to what is holding references: There is a new method on the JVMTI MBean I created that can expose all objects of a given class. I have a small JSP that is writting details about these class in a simple table, but it's still under work. If you think this might help, let me know! redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: ServletExample.zip, analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316855 ] Clebert Suconic commented on JBAS-1319: --- This should be done in what version? Should we mark the fix to? (At least a trying?) -clebert redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: ServletExample.zip, analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=history ] Clebert Suconic updated JBAS-1319: -- Attachment: analysis.zip redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: JMX Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Clebert Suconic Attachments: analysis.zip Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316790 ] Clebert Suconic commented on JBAS-1319: --- Basically I have created a profiler for analyzing this bug. I had to do that because I had to cross information on the classloader to find where we could have references to any specific classloader. By definition (at least I read that somewhere on Sun's website, I think this was JVM spec) a class is only unloaded if there isn't any reference in the memory, plus you don't have any references to the classloader. So, I'm not sure if this will release classes at GC operations, but this is the only way it could work. So, first the analysis I've made: (open the file analysis.zip) I - step1-classes.htm You will see all the classes I have loaded. In particular I deployed a WAR application twice (in particular JBoss-profiler.war). You will see Lorg/jboss/profiler/util/SPYConsts without any instances. I also navigated to references in both ways. Nothing holding. II - step2-classesAtClassLoader. I detailed the classLoader that loaded Lorg/jboss/profiler/util/SPYConsts;. It's kind of weird but that same ClassLoader also loaded FastHashMap and PropertyMessageResourcesFactory. Well... maybe this was because of Struts as I use it in the profiler. (not sure, but maybe this is not even related) III - step3-references-toClassLoader.htm I think (or at least I hope) this is the root cause: You have some references to the classLoader to its classes (what is expected), but you have also 34 thread references through Lorg/apache/tomcat/util/threads/ThreadWithAttribute. These are 34 references to that classloader through a single instance of ThreadWithAttribute. A Thread reference means a reference that sits in the stack-trace on the VM. (In another words, the thread, what could be even a ThreadLocalData or a property in a Thread). I read its source code and there is an array on that thread. Well... I don't have resources to go beyond that right now, but at least I wanted to leave this analysis registered and maybe someone could have some light on this. redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: JMX Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Clebert Suconic Attachments: analysis.zip Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316804 ] Clebert Suconic commented on JBAS-1319: --- I'm using a downloaded version from cvs, Branch_4_0, jboss-4.0, updated I think 2 weeks ago. Isn't the patch supposed to be already in our CVS? Can you please confirm if we have this patch already in our CVS? I can't check this as I'm out of site with limited internet connectivity today. Depending on what you tell me I will captur the snapshot again. redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Clebert Suconic Attachments: analysis.zip Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316815 ] Clebert Suconic commented on JBAS-1319: --- I think for a small application like JMX-console you would have to re-deploy it a lot until you get into any memory boundaries. I'm creating a docummentation for the JVMTI version I created, so I think you will be able to use the profiler yourself and look for leaks in any other application. What I would do is to order by signature. (The name is kind of hidden due to my lacking of UI skills). Please, take a look at the jboss-profiler forum as I'm going to post locations there. redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: analysis.zip Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316820 ] Clebert Suconic commented on JBAS-1319: --- HUH? Well... I don't have access to Java methods through JVMTI, and plus I'm already showing the references throught the jboss-profiler memory module. Have you tried it? redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=history ] Clebert Suconic updated JBAS-1319: -- Attachment: ServletExample.zip redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: ServletExample.zip, analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316821 ] Clebert Suconic commented on JBAS-1319: --- I uploaded a ServletExample.zip that I was using to test. That file was releasing Classes without any problem. I would assume the problem is something on the jakarta's connection/struts. The application (ServletExample) i uploaded I can even see by -verbose:gc that the classes are being unloaded. I don't know what action we should take, as it's pretty strange an struts application holding a reference into a Tomcat classloader. Maybe this is because of Servlet's properties holded by Struts (during the struts-xml parsing), and a simple application doesn't have that class loaded. If you remember in my analysis, I have two instances of jakarta's collections. I realized later on from my post that these collections are referred by the thread, and this is not done by a static variable in the thread. It's done by a class-variable in the thread. I will try to improve ServletExample.zip in a way to use the same behavior as a Struts-servlet. redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: ServletExample.zip, analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[
http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316822 ]
Clebert Suconic commented on JBAS-1319:
---
I added these three lines to HttpStressTest.java, and the VM still releasing
the class:
public void init() throws ServletException {
System.out.println(INIT Test);
getServletContext().setAttribute(Test-class, this);
}
So... I guess that patch created at 02-05-2005 fixed the classloading issue,
but there still issues when using Jakarta collections and struts.
So Adrian, should we try a patch into struts or should we just close this issue
and set the resolution as done?
If we found an application that reproduces this bug again we could reopen this
issue.
redeploy causes OutOfMemoryError
Key: JBAS-1319
URL: http://jira.jboss.com/jira/browse/JBAS-1319
Project: JBoss Application Server
Type: Bug
Components: Web (Tomcat) service
Versions: JBossAS-4.0.1 Final
Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0
Reporter: Matthew Todd
Assignee: Adrian Brock
Attachments: ServletExample.zip, analysis.zip
Time Spent: 1 week
Constant redployment, even of a simple web application eventually causes an
OutOfMemoryError in JBoss.
To duplicate, keep on copying a .war package into a servers hot deploy
directory. Eventually an OutOfMemoryError occurs.
This is especially dangerous when running as a cluster, as when the node is
restarted, it is unable to join the cluster again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316823 ] Clebert Suconic commented on JBAS-1319: --- Forget what I said about jakarta's collections. I did the deployment test with Specj that doesn't use any jakarta's collection. The only think it uses is the XML reader. (but I don't think it was loaded by the deployment/init time). So... it looks like the produced patch in Tomcat works for simple loading scenarios but still produces leaks for more complex usage scenarios. I could or upload the profiler snapshot for you somewhere then you could navigate through the heap yourself or I could provide you access to the Specj deployment as we have license for this. So.. I regreat on what I said about closing this issue! ;-) redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Adrian Brock Attachments: ServletExample.zip, analysis.zip Time Spent: 1 week Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316523 ] Clebert Suconic commented on JBCACHE-98: BTW: 1.2.1 or 1.2.2? Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases -- Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Bela Ban Fix For: 1.2.2 Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=history ] Clebert Suconic updated JBAS-1632: -- Attachment: 2005-03-30.17-34.tgz clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2RC1, JBossAS-3.2.7 Final, JBossAS-5.0 Alpha Reporter: Ben Wang Assignee: Clebert Suconic Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.7 Final Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1584) Create a unit test for tracking the serialVersionUID across versions using ObjectStreamClass
[ http://jira.jboss.com/jira/browse/JBAS-1584?page=comments#action_12316539 ] Clebert Suconic commented on JBAS-1584: --- I can add checking of serialUUID against older versions also. Say... load the defined serialUUID (not the calculated through java.io.ObjectClass) and verify if it's the same in older versions. Create a unit test for tracking the serialVersionUID across versions using ObjectStreamClass Key: JBAS-1584 URL: http://jira.jboss.com/jira/browse/JBAS-1584 Project: JBoss Application Server Type: Sub-task Components: Test Suite Reporter: Scott M Stark Assignee: Scott M Stark Priority: Critical Fix For: JBossAS-4.0.2 Final We need a unit test that compares the serialVersionUID of classes in the dist against those from previous versions using ObjectStreamClass.getSerialVersionUID() and a database of previous version/class/serialVersionUID. As of 4.0.2 forward this test should fail there is a change in any serialVersionUID. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=history ] Clebert Suconic updated JBAS-1632: -- Attachment: jboss-cache.jar clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2RC1, JBossAS-3.2.7 Final, JBossAS-5.0 Alpha Reporter: Ben Wang Assignee: Clebert Suconic Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.7 Final Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar, jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316534 ] Clebert Suconic commented on JBCACHE-98: I'm assuming the file attached at JBAS-1632 is 1.2.2 based in what Ben told me. Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases -- Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Bela Ban Fix For: 1.2.2 Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1584) Create a unit test for tracking the serialVersionUID across versions using ObjectStreamClass
[ http://jira.jboss.com/jira/browse/JBAS-1584?page=comments#action_12316537 ] Clebert Suconic commented on JBAS-1584: --- As I worked already on this, I commited three new tests that are verifying if Serializable/Externalizable classes are implementing serialUUID by reflection. If needed it's possible to implement exception list for Serializable classes that we don't want to have serialUUID implemented. It's easy also to add more JARs in the verification I created and the test itself run pretty fast. Create a unit test for tracking the serialVersionUID across versions using ObjectStreamClass Key: JBAS-1584 URL: http://jira.jboss.com/jira/browse/JBAS-1584 Project: JBoss Application Server Type: Sub-task Components: Test Suite Reporter: Scott M Stark Assignee: Scott M Stark Priority: Critical Fix For: JBossAS-4.0.2 Final We need a unit test that compares the serialVersionUID of classes in the dist against those from previous versions using ObjectStreamClass.getSerialVersionUID() and a database of previous version/class/serialVersionUID. As of 4.0.2 forward this test should fail there is a change in any serialVersionUID. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1632) clustering unit test failure
[
http://jira.jboss.com/jira/browse/JBAS-1632?page=comments#action_12316570 ]
Clebert Suconic commented on JBAS-1632:
---
I've executed the testsuite after applied the patch for jboss-cache.jar 1.2.2
beta (different from the attached version at this case), and I got two failures.
__
JBoss daily test results
SUMMARY
Number of tests run: 82
Successful tests: 80
Errors:0
Failures: 2
[time of test: 2005-03-31.20-08 GMT]
[java.version: 1.4.2_06]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.4.2_06-b03]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.21-27.0.1.ELsmp]
Useful resources:
- http://jboss.sourceforge.net/junit-results/32/2005-03-31.20-08 for
the junit report of this test.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
It is assumed that whoever makes change(s) to jboss that
break the test will be fixing the test or jboss, as appropriate!
DETAILS OF ERRORS
Suite:
org.jboss.test.cluster.test.SimpleTestCase(Default-${jboss-junit-configuration})
Test:testSessionTimeout
Type:failure
Exception: junit.framework.AssertionFailedError
Message: Http session get
-
Suite:
org.jboss.test.cluster.test.SimpleTestCase(SyncModeNUseJvm-${jboss-junit-configuration})
Test:testSessionTimeout
Type:failure
Exception: junit.framework.AssertionFailedError
Message: Http session get
-
clustering unit test failure
Key: JBAS-1632
URL: http://jira.jboss.com/jira/browse/JBAS-1632
Project: JBoss Application Server
Type: Bug
Components: Clustering
Versions: JBossAS-3.2.7 Final, JBossAS-5.0 Alpha, JBossAS-4.0.2RC1
Reporter: Ben Wang
Assignee: Clebert Suconic
Fix For: JBossAS-3.2.7 Final, JBossAS-5.0 Alpha, JBossAS-4.0.2 Final
Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar, jboss-cache.jar
Original Estimate: 4 hours
Remaining: 4 hours
Currently, tests-clustering target has numerous failure. It was because that
the jboss-cache.jar is not the latest. In order for the test to success, we
will need it.
Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine
to all/lib directory.
This issue is therefore depends on backporting JBossCache release 1.2.2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=history ] Clebert Suconic reassigned JBAS-1632: - Assign To: Ben Wang (was: Clebert Suconic) clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-3.2.7 Final, JBossAS-5.0 Alpha, JBossAS-4.0.2RC1 Reporter: Ben Wang Assignee: Ben Wang Fix For: JBossAS-3.2.7 Final, JBossAS-5.0 Alpha, JBossAS-4.0.2 Final Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar, jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316575 ] Clebert Suconic commented on JBCACHE-98: Just executed the backport test into jboss-4.0, executing the testsuite for tests-clustering. I got the same results in both runnings. With and without the patch. These results are exactly the same even before the patch, so I assume the patch is OK for 4.0.0: I'm testing into 4.0.1.sp1 now. DETAILS OF ERRORS Suite: org.jboss.test.cluster.test.DistributedStateTestCase Test:testStateReplication Type:error Exception: java.lang.NullPointerException Message: - Suite: org.jboss.test.cluster.test.WebSessionTestCase Test:testServletSessionFailover Type:failure Exception: junit.framework.AssertionFailedError Message: X-AccessCount == 3 - Suite: org.jboss.test.cluster.test.WebSessionTestCase Test:testServletSessionLoadBalancing Type:error Exception: java.lang.NullPointerException Message: - Suite: org.jboss.test.testbeancluster.test.BeanUnitTestCase Test:testStatelessBeanLoadBalancing Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: org.jboss.test.testbeancluster.test.BeanUnitTestCase Test:testStatefulBeanFailover Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Components: Clustering Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Ben Wang Fix For: 1.2.2 Attachments: jboss-cache.jar Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. In addition, there is 3.2.x release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=history ] Clebert Suconic reassigned JBCACHE-98: -- Assign To: Clebert Suconic (was: Ben Wang) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Components: Clustering Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Clebert Suconic Fix For: 1.2.2 Attachments: jboss-cache.jar Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. In addition, there is 3.2.x release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316577 ] Clebert Suconic commented on JBCACHE-98: Well... the patch is validated for 4.0.0 and 4.0.1. (4.0.3 is a consequence of the release process, as we are applying the patch right now). Just one thing... IMHO... whoever is using cluster should upgrade version instead of patching. Ben did a really good job improving cluster. I can see a larger number of testcases now. . Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Components: Clustering Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Clebert Suconic Fix For: 1.2.2 Attachments: jboss-cache.jar Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. In addition, there is 3.2.x release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=history ] Clebert Suconic reassigned JBCACHE-98: -- Assign To: Ben Wang (was: Clebert Suconic) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Components: Clustering Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Ben Wang Fix For: 1.2.2 Attachments: jboss-cache.jar Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. In addition, there is 3.2.x release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316576 ] Clebert Suconic commented on JBCACHE-98: Into 4.0.1-sp1 I had two failures before the patch, two after the patch DETAILS OF ERRORS Suite: org.jboss.test.cluster.test.DRMTestCase Test:testStateReplication Type:failure Exception: junit.framework.AssertionFailedError Message: replicants0 contains:172.16.129.170 - Suite: org.jboss.test.cluster.test.WebSessionTestCase Test:testServletSessionFailover Type:failure Exception: junit.framework.AssertionFailedError Message: X-AccessCount == 3 - Backporting JBossCache 1.2.2 in JBossAS 4.0.x and 3.2.x releases Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Components: Clustering Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Clebert Suconic Fix For: 1.2.2 Attachments: jboss-cache.jar Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. In addition, there is 3.2.x release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316522 ] Clebert Suconic commented on JBCACHE-98: It looks like it's mandatory to backport JBossCache to AS 4.0 due to the dependency on this JIRA task: JBAS-1632. Ben, can you confirm that please? Clebert Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases -- Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Bela Ban Fix For: 1.2.2 Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=history ] Clebert Suconic updated JBAS-1632: -- Attachment: jboss-cache.jar I attached the mentioned file. clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2RC1, JBossAS-3.2.7 Final, JBossAS-5.0 Alpha Reporter: Ben Wang Assignee: Clebert Suconic Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.7 Final Attachments: jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=comments#action_12316528 ] Clebert Suconic commented on JBAS-1632: --- Even by changing the library we still have few errors. I've attached the results (2005-03-30.17-34.tgz) and I executed this test by: ant -Dnojars=true tests-clustering-all-stacks clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2RC1, JBossAS-3.2.7 Final, JBossAS-5.0 Alpha Reporter: Ben Wang Assignee: Clebert Suconic Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.7 Final Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=history ] Clebert Suconic reassigned JBAS-1632: - Assign To: Ben Wang (was: Clebert Suconic) I executed the tests... see comments at this task. clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2RC1, JBossAS-3.2.7 Final, JBossAS-5.0 Alpha Reporter: Ben Wang Assignee: Ben Wang Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.7 Final Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316532 ] Clebert Suconic commented on JBCACHE-98: I've already done this as part of JBAS-1632. Ben asked me to run it again (just in case), and it would be already done if our sourceforge-cvs wasn't so slw. :-) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases -- Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Bela Ban Fix For: 1.2.2 Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1632) clustering unit test failure
[ http://jira.jboss.com/jira/browse/JBAS-1632?page=history ] Clebert Suconic reassigned JBAS-1632: - Assign To: Clebert Suconic (was: Ben Wang) clustering unit test failure Key: JBAS-1632 URL: http://jira.jboss.com/jira/browse/JBAS-1632 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.2RC1, JBossAS-3.2.7 Final, JBossAS-5.0 Alpha Reporter: Ben Wang Assignee: Clebert Suconic Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.7 Final Attachments: 2005-03-30.17-34.tgz, jboss-cache.jar Original Estimate: 4 hours Remaining: 4 hours Currently, tests-clustering target has numerous failure. It was because that the jboss-cache.jar is not the latest. In order for the test to success, we will need it. Clebert, you can verify this by copying /tmp/jboss-cache.jar in Atl machine to all/lib directory. This issue is therefore depends on backporting JBossCache release 1.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316546 ] Clebert Suconic commented on JBAS-1319: --- My understanding is that unused classes will be unloaded by the GC. I mean... no instances, on references through garbage collectors, next full GC=class release. So, why do we need additional features in the JVM unloading the class? (Sorry about my ignorance) I was trying to use JProfiler for this, but my JVM is crashing everytime I try to take a big snapshot of the memory. If it's not possible to use an already existent profiler for this, I was able to navigate in the HEAP using JVMTI (JVM 5), and I need to do the dirty job of analyze log files and show the heap through some simple front-end. Also... can this task be deferred to the next version? redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: JMX Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Clebert Suconic Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1319) redeploy causes OutOfMemoryError
[ http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316547 ] Clebert Suconic commented on JBAS-1319: --- Sorry... i meant no references through class loaders, not garbage collectors. redeploy causes OutOfMemoryError Key: JBAS-1319 URL: http://jira.jboss.com/jira/browse/JBAS-1319 Project: JBoss Application Server Type: Bug Components: JMX Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0 Reporter: Matthew Todd Assignee: Clebert Suconic Constant redployment, even of a simple web application eventually causes an OutOfMemoryError in JBoss. To duplicate, keep on copying a .war package into a servers hot deploy directory. Eventually an OutOfMemoryError occurs. This is especially dangerous when running as a cluster, as when the node is restarted, it is unable to join the cluster again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-98) Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases
[ http://jira.jboss.com/jira/browse/JBCACHE-98?page=comments#action_12316540 ] Clebert Suconic commented on JBCACHE-98: Ok... It's 1.2.2 alpha. I guess this is the version that Ben has worked with. Can you upload the JAR at this JIRA task or send-me by e-mail, or instruction in how to get the file please? Backporting JBossCache 1.2.1 in JBossAS 4.0.x releases -- Key: JBCACHE-98 URL: http://jira.jboss.com/jira/browse/JBCACHE-98 Project: JBoss Cache Type: Support Patch Versions: 1.2 Environment: should work in any environment Reporter: Luc Texier Assignee: Bela Ban Fix For: 1.2.2 Some customers have expressed the wish to take avantages of the optimizations/bug fixes/enhancements being implemented in the latest releases of JBossCache (i.e. 1.2.1 and the upcoming 1.2.2). Therefore, it has been decided to backport JBossCache 1.2.2 to JBossAS 4.0.0 and JBossAS 4.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBAS-1580) Problem when Submitting Massive Load into HttpSession
[ http://jira.jboss.com/jira/browse/JBAS-1580?page=history ]
Clebert Suconic reopened JBAS-1580:
---
Remy,
I think you have answered Clebert's question saying that when a session is
invalidated, we are supposed to re-use the session id to create a new session
object, right?
In this case, I still have a bug in my replication code that doesn't handle
this correctly all the time then.
Thanks,
-Ben
-Original Message-
From: Remy Maucherat
Sent: Tuesday, March 29, 2005 3:49 PM
To: Clebert Suconic
Cc: Ben Wang; Scott M Stark; Ryan Campbell
Subject: RE: Session Invalidation
Remy,
Can solve a question for me and Ben please...
We have a TestCase that behaves like this:
Int i=0;
HttpClient client = new HttpClient(); /// this HttpClient can hold
cookies without any problem, like the way a browser does.
Invfinite Loop {
I++
If (i3)
{
Client.invoke(WhateverURL);
} else
{
I=0;
Client.invoke(An URL that Will Invalidate the Session);
}
}
This client will call a Servlet that will have an invalidation on
every 3 callings.
The clustered session is failing, throwing some exceptions as the
HttpClient is using the same session cookie even after its invalidation.
You will see more descriptions about this error on this JIRA-Task:
http://jira.jboss.com/jira/browse/JBCACHE-102
If we recreate the Client at the third iteration, we don't have an
error any more.
So... a question:
How do you implement Session Invalidation at Tomcat. Do you reassign
the session cookie by removing the cookie, or do you keep the cookie?
My point is, isn't the server's responsibility to delete the session
cookie or assign a new one when the server invalidates the Session.
Just pretend a client that pressed log-off but will keep using another
account login. The HttpClient would be the same and unless the server
resend/delete the cookies the Session would be the same.
If this is true, we will have to reopen
http://jira.jboss.com/jira/browse/JBCACHE-102, even if we have to
defer it to the next version, as in 90% of the cases the client closes
the browser after its invalidation.
By creating a new HttpClient you are assuming that the client is
closing the browser and a new client is arriving in.
Clebert
PS: I started this thread as an e-mail just to make it easier, but
this will be copied into http://jira.jboss.com/jira/browse/JBCACHE-102
and http://jira.jboss.com/jira/browse/JBAS-1580 eventually.
As far as I can understand, you are confusing session object, session cookie,
and session id. Any cookie will not be removed (of course). With the current
default setup, session ids from submitted cookies will actually also be reused.
The only thing for which state matters is the session object, and so your case
is not supposed to fail.
Rmy
Problem when Submitting Massive Load into HttpSession
-
Key: JBAS-1580
URL: http://jira.jboss.com/jira/browse/JBAS-1580
Project: JBoss Application Server
Type: Bug
Components: JBoss Cache service
Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-5.0 Alpha,
JBossAS-3.2.5 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1
Reporter: Clebert Suconic
Assignee: Ben Wang
Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-3.2.8 Final
Description available at:
http://jira.jboss.com/jira/browse/JBCACHE-102
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBCACHE-102) Exception when Submitting Load into HttpSession
[ http://jira.jboss.com/jira/browse/JBCACHE-102?page=history ] Clebert Suconic reopened JBCACHE-102: - Comments available for its reopening at http://jira.jboss.com/jira/browse/JBAS-1580 Exception when Submitting Load into HttpSession --- Key: JBCACHE-102 URL: http://jira.jboss.com/jira/browse/JBCACHE-102 Project: JBoss Cache Type: Bug Environment: jboss-4.0 Branch_4_0 Reporter: Clebert Suconic Assignee: Ben Wang When submitting load using ou HttpStressTest application, using 10 threads in the client and 1 session hold per thread, we have thrown these exceptions: java.lang.IllegalStateException: standardSession.setAttribute.ise at org.jboss.web.tomcat.tc5.session.ClusteredSession.setAttribute(ClusteredSession.java:185) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:129) at org.jboss.test.weblayer.HttpStressTest.doGet(HttpStressTest.java:24) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:147) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) And: java.lang.IllegalArgumentException: You can only add ClusteredSessions to this Manager at org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:228) at org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:38) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-102) Exception when Submitting Load into HttpSession
[ http://jira.jboss.com/jira/browse/JBCACHE-102?page=comments#action_12316502 ] Clebert Suconic commented on JBCACHE-102: - Scott wrote: It will try to keep the session cookie. -Original Message- From: Clebert Suconic Sent: Tuesday, March 29, 2005 8:54 PM To: Scott M Stark; Remy Maucherat; Ben Wang Cc: Ryan Campbell Subject: RE: Session Invalidation But what's the behavior of a Web-browser? Isn't to keep the HttpState if the client keeps navigating after its invalidation? Well... even if that's true, we could change the behavior, like keeping the HttpState in 1 of each 10 invalidations. (or some other number). But that would only decrease the probability of the failure we have seen. Clebert Exception when Submitting Load into HttpSession --- Key: JBCACHE-102 URL: http://jira.jboss.com/jira/browse/JBCACHE-102 Project: JBoss Cache Type: Bug Environment: jboss-4.0 Branch_4_0 Reporter: Clebert Suconic Assignee: Ben Wang When submitting load using ou HttpStressTest application, using 10 threads in the client and 1 session hold per thread, we have thrown these exceptions: java.lang.IllegalStateException: standardSession.setAttribute.ise at org.jboss.web.tomcat.tc5.session.ClusteredSession.setAttribute(ClusteredSession.java:185) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:129) at org.jboss.test.weblayer.HttpStressTest.doGet(HttpStressTest.java:24) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:147) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) And: java.lang.IllegalArgumentException: You can only add ClusteredSessions to this Manager at org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:228) at org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:38) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=comments#action_12316433 ] Clebert Suconic commented on JBAS-1579: --- I thought the requirement for this would be to have serialUID defined in every single class. By using that method SerialUID will be calculated and I understood that we want to have them all defined. So...what's the requirement? - To have serialUID declared in every class? or - To have serialUID always compatible with previous versions? (in such a way that doesn't matter if it came defined or calculated) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Clebert Suconic Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip, compatibilityCheckProposedSourceCde.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=history ] Clebert Suconic reassigned JBAS-1579: - Assign To: Clebert Suconic (was: Scott M Stark) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Clebert Suconic Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=comments#action_12316392 ] Clebert Suconic commented on JBAS-1579: --- I didn't know there is another testcase doing something to serialUIDs. When I saw JBAS-1598 I understood I needed to verify serialUIDs. Well... let's talk about the differences. First difference: I'm checking if every class into a given JAR has implemented serialUID. I'm doing that by getField/introspection. As it's a private field, I'm changing the property in the same way ObjectOutputStream does: Field field = parameterClass.getDeclaredField(serialVersionUID); field.setAccessible(true); Second difference: If you add older versions in a configured directory (through a property in the system... good option for cruisecontrol), I will check if all the older versions also have serialUID defined. Them I'm checking if both are the same. Third difference: If I have a default constructor, I'm serializing the Object using the older versions in the configured directory. I deserialize in the current version using ObjectInputStreamWithClassLoader. Forth difference: You will see every class tested as a TestResult. Fancy feature only I'm attaching the sourcecode, as I will commit it after validated. Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Clebert Suconic Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=history ] Clebert Suconic updated JBAS-1579: -- Attachment: compatibilityCheckProposedSourceCde.zip Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Clebert Suconic Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip, compatibilityCheckProposedSourceCde.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=comments#action_12316393 ] Clebert Suconic commented on JBAS-1579: --- If this test is relevant/aprooved I will put it under org.jboss.test.compatibility.test Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Clebert Suconic Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip, compatibilityCheckProposedSourceCde.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1580) Problem when Submitting Massive Load into HttpSession
[ http://jira.jboss.com/jira/browse/JBAS-1580?page=history ] Clebert Suconic updated JBAS-1580: -- Security Level: Public (was: JBoss Internal) Problem when Submitting Massive Load into HttpSession - Key: JBAS-1580 URL: http://jira.jboss.com/jira/browse/JBAS-1580 Project: JBoss Application Server Type: Bug Components: JBoss Cache service Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-5.0 Alpha, JBossAS-3.2.5 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Clebert Suconic Assignee: Ben Wang Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-3.2.8 Final Description available at: http://jira.jboss.com/jira/browse/JBCACHE-102 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBCACHE-102) Exception when Submitting Load into HttpSession
[ http://jira.jboss.com/jira/browse/JBCACHE-102?page=history ] Clebert Suconic updated JBCACHE-102: Security Level: Public (was: JBoss Internal) Exception when Submitting Load into HttpSession --- Key: JBCACHE-102 URL: http://jira.jboss.com/jira/browse/JBCACHE-102 Project: JBoss Cache Type: Bug Environment: jboss-4.0 Branch_4_0 Reporter: Clebert Suconic Assignee: Ben Wang When submitting load using ou HttpStressTest application, using 10 threads in the client and 1 session hold per thread, we have thrown these exceptions: java.lang.IllegalStateException: standardSession.setAttribute.ise at org.jboss.web.tomcat.tc5.session.ClusteredSession.setAttribute(ClusteredSession.java:185) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:129) at org.jboss.test.weblayer.HttpStressTest.doGet(HttpStressTest.java:24) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:147) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) And: java.lang.IllegalArgumentException: You can only add ClusteredSessions to this Manager at org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:228) at org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:38) at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=history ] Clebert Suconic updated JBAS-1579: -- Attachment: TestResultSample.zip Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Clebert Suconic Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1579) Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes
[ http://jira.jboss.com/jira/browse/JBAS-1579?page=history ] Clebert Suconic reassigned JBAS-1579: - Assign To: Scott M Stark (was: Clebert Suconic) I've created a TestCase that: - tests if all classes in a given JAR have the SerialUID - tests if all classes in all equivalent JARs at the same version have the SerialUID - If the default constructor is available, serialize the class and verify if it can be deserialized in the new version. I've ran the testcase against jboss-all.jar Questions: Do you think this testcase is enough for the test-compatibility? I'm going to add this into jboss-head, and test the backward compatibility through jboss-4 and jboss-3 what will cover all versions. I didn't add the test into CVS yet (at the time of this comment). Please, after you have read and evaluated this comment, assign me the activity back. Need to cleanup the serialVersionUIDs for Serializable/Externalizable classes - Key: JBAS-1579 URL: http://jira.jboss.com/jira/browse/JBAS-1579 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Reporter: Scott M Stark Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-4.0.2 Final Attachments: SerializableHasSerialVersionUIDField.zip, TestResultSample.zip I'm seeing incomptibilities between versions that are simply due to the fact that Serializable/Externalizable classes are letting their serialVersionUIDs float instead of explicitly defining them. We need to get this cleaned up. There should not be a single Serializable/Externalizable class that does not fix its serialVersionUID and then take responsibility for maintaining compatibility with the indicated version. The attached SerializableHasSerialVersionUIDField.zip unzips to create a SerializableHasSerialVersionUIDField-index.html and SerializableHasSerialVersionUIDField directory which is a report of all classes in the 4.0 codebase that are not defining a serialVersionUID as they should. The JDK object serialization spec defines all you need to know about the apis and contracts for object serialization: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/serialTOC.html In particular, Versioning of Serializable Objects: http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419 talks about binary compatibility and what is available to manage this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1580) Problem when Submitting Massive Load into HttpSession
Problem when Submitting Massive Load into HttpSession - Key: JBAS-1580 URL: http://jira.jboss.com/jira/browse/JBAS-1580 Project: JBoss Application Server Type: Bug Components: JBoss Cache service Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final, JBossAS-5.0 Alpha Reporter: Clebert Suconic Assigned to: Ben Wang Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha Description available at: http://jira.jboss.com/jira/browse/JBCACHE-102 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1580) Problem when Submitting Massive Load into HttpSession
[ http://jira.jboss.com/jira/browse/JBAS-1580?page=history ] Clebert Suconic updated JBAS-1580: -- Fix Version: JBossAS-3.2.8 Final Problem when Submitting Massive Load into HttpSession - Key: JBAS-1580 URL: http://jira.jboss.com/jira/browse/JBAS-1580 Project: JBoss Application Server Type: Bug Components: JBoss Cache service Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final, JBossAS-5.0 Alpha Reporter: Clebert Suconic Assignee: Ben Wang Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-3.2.8 Final Description available at: http://jira.jboss.com/jira/browse/JBCACHE-102 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1588) Collection synchronization into cmp2
[ http://jira.jboss.com/jira/browse/JBAS-1588?page=history ] Clebert Suconic resolved JBAS-1588: --- Resolution: Done Collection synchronization into cmp2 Key: JBAS-1588 URL: http://jira.jboss.com/jira/browse/JBAS-1588 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.7 Final Reporter: Clebert Suconic Assignee: Alexey Loubyansky Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-3.2.8 Final More details at this Jira Issue: http://jira.jboss.com/jira/browse/JBBENCH-44 Also, this issue was created just to reference the issue into JBossAS. It was already solved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1588) Collection synchronization into cmp2
Collection synchronization into cmp2 Key: JBAS-1588 URL: http://jira.jboss.com/jira/browse/JBAS-1588 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.7 Final Reporter: Clebert Suconic Assigned to: Alexey Loubyansky Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-3.2.8 Final More details at this Jira Issue: http://jira.jboss.com/jira/browse/JBBENCH-44 Also, this issue was created just to reference the issue into JBossAS. It was already solved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-45) JVM Crashes when starting three groups at the same time
JVM Crashes when starting three groups at the same time --- Key: JGRP-45 URL: http://jira.jboss.com/jira/browse/JGRP-45 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Linux RedHat 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST 2004 i686 i686 i386 GNU/Linux (our dev02 box) Reporter: Clebert Suconic Assigned to: Bela Ban Priority: Minor Fix For: 2.2.8 When starting three clusters at the same time, a JVM crashed inside the socket JNI function. I've added the log file for the crashed instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-45) JVM Crashes when starting three groups at the same time
[ http://jira.jboss.com/jira/browse/JGRP-45?page=history ] Clebert Suconic updated JGRP-45: Attachment: console3.out.gz JVM Crashes when starting three groups at the same time --- Key: JGRP-45 URL: http://jira.jboss.com/jira/browse/JGRP-45 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Linux RedHat 2.4.21-27.0.1.ELsmp #1 SMP Mon Dec 20 18:47:45 EST 2004 i686 i686 i386 GNU/Linux (our dev02 box) Reporter: Clebert Suconic Assignee: Bela Ban Priority: Minor Fix For: 2.2.8 Attachments: console3.out.gz When starting three clusters at the same time, a JVM crashed inside the socket JNI function. I've added the log file for the crashed instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
