Re: [JBoss-dev] FW: [JBoss-user] [Installation, Configuration Deployment] - Getting 'no such file or directory
On Sun, 2006-02-19 at 12:12, Scott M Stark wrote: Should we drop this warning message? Its actually irrelevant since the default compilation mode for jsps is to use the eclipse version. What is javassist using for compilation? Itself. But it is not complete, see the docs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of faisalaslam Sent: Saturday, February 18, 2006 8:06 AM To: jboss-user@lists.sourceforge.net Subject: [JBoss-user] [Installation, Configuration Deployment] - Getting 'no such file or directory Hi All, I am new to linux based JBOSS. I am using Redhat9.0 with, JDK1.5.0_06, MYSQL 4.1.18.0 and have installed JBOSS-4.0.3SP1. JBOSS installation path is /usr/local/jboss-4.0.3SP1/ I am getting this error when I run run.sh here is the output i got: | run.sh: Missing file: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/ usr/X11R6/bin:/root/bin:/usr/java/jdk1.5.0_06/lib/tools.jar | run.sh: Unexpected results may occur. Make sure JAVA_HOME points to a JDK and not a JRE. | | | JBoss Bootstrap Environment | | JBOSS_HOME: /usr/local/jboss-4.0.3SP1 | | JAVA: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/ usr/X11R6/bin:/root/bin:/usr/java/jdk1.5.0_06/bin/java | | JAVA_OPTS: -server -Xms128m -Xmx128m -Dprogram.name=run.sh | | CLASSPATH: /usr/local/jboss-4.0.3SP1/bin/run.jar:/usr/local/sbin:/usr/loc al/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin: /usr/java/jdk1.5.0_06/lib/tools.jar | | Any idea? plz i need urgent help. Regards, -A NewJBOSSUser View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=39247 84#3924784 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=repl yp=3924784 --- 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=230486; dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user --- 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 -- 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
RE: [JBoss-dev] [Fwd: Reflection using Javassist]
On Sun, 2006-02-19 at 13:15, Clebert Suconic wrote: :-) Can I use this to access/modify private attributes? See the forums thread. Also, is it possible to modify final private attributes? Probably, but that doesn't mean the JIT will necessarily pickup the change if you modify a final after construction. Under what circumstances would you do this? That is the reason a serializable class must have a noargs constructor. 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
[JBoss-dev] RE: 3.2.8 Client - 4.0.x Compatibility
The methods added to the RMIAdaptorImpl are not correct.
getDomains should be:
public String[] getDomains() throws IOException
{
return mbeanServer.getDomains();
}
The NotificationListener base add/removeNotificationListener cannot
delegate to the RMINotificationListener versions by casting the listener
to a RMINotificationListener. These are MBeanServerConnection methods
and should be delegated to the mbeanServer.
-Original Message-
From: Clebert Suconic
Sent: Sunday, February 19, 2006 3:03 PM
To: Scott M Stark; Dimitris Andreadis
Cc: 'jboss-development@lists.sourceforge.net'; QA
Subject: 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
---
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]
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]
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 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
--
Adrian Brock
Chief Scientist
JBoss Inc.
[JBoss-dev] jboss-cache-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060220111317 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-JBossCache.xml:82: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/20/2006 11:13:17Time to build:34 minutes 49 secondsLast changed:12/28/2005 10:48:11Last log entry:Add the 1.2.4SP1 changelog notes. Unit Tests: (1361) Total Errors and Failures: (15)testRelationshipWithSharedSet1org.jboss.cache.aop.collection.ReplicatedObjectGraphAopTesttestSimplifiedorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestSimplifiedorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestCheckReplInstanceorg.jboss.cache.aop.ReplicatedObjectGraphAopTesttestCollectionWithCacheLoaderorg.jboss.cache.aop.loader.FileCacheLoaderAopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer1241AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer124AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer130AopTesttestUpdateEvictionorg.jboss.cache.eviction.AopLRUPolicyTesttest2ReadersAnd1Writerorg.jboss.cache.lock.ReentrantWriterPreferenceReadWriteLockTesttestConcurrentUseAsyncorg.jboss.cache.statetransfer.StateTransfer130TesttestConcurrentAccessWithRWLockorg.jboss.cache.transaction.ConcurrentTransactionalTesttestNodeCreationRollbackorg.jboss.cache.transaction.IsolationLevelReadCommittedTest Modifications since last build:(first 50 of 1675)1.3modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaFixes rating to JBCACHE-118 - optimising cache loader functionality.1.2modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.1addedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.2modifieddhuangtests/stress/org/jboss/cache/EvictionLocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Eviction Policies for MRU and LFU.Allow configuration of EvictionPolicies at runtime.References JIRA tasks:JBCACHE-314JBCACHE-313JBCACHE-312JBCACHE-286JBCACHE-225JBCACHE-2131.2modifieddhuangtests/stress/org/jboss/cache/LocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Eviction Policies for MRU and LFU.Allow configuration of EvictionPolicies at runtime.References JIRA tasks:JBCACHE-314JBCACHE-313JBCACHE-312JBCACHE-286JBCACHE-225JBCACHE-2131.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead50JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead75JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead90JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplSyncPessRead50JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplSyncPessRead75JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplSyncPessRead90JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/LocalPessIsoRRRead90JRunitTest.javaAdded more tests1.1addedbwangtests/scripts/profile.shnew1.1addedhmeshatests/perf/org/jboss/cache/loader/JDBCCacheLoaderPerfTest.javaJBCACHE-330 first draft JDBCCacheLoader performance test case1.2modifiedbwangtests-50/functional/org/jboss/cache/aop/test/TestNode.javaMissed the annotation.1.1addedbwangtests-50/functional/org/jboss/cache/aop/test/Address.javaJBCACHE-175 JDK50 annotation support1.1addedbwangtests-50/functional/org/jboss/cache/aop/test/CacheObject.javaJBCACHE-175 JDK50 annotation support1.1addedbwangtests-50/functional/org/jboss/cache/aop/test/IdObject.javaJBCACHE-175 JDK50 annotation support1.1addedbwangtests-50/functional/org/jboss/cache/aop/test/Link.javaJBCACHE-175 JDK50 annotation support1.1addedbwangtests-50/functional/org/jboss/cache/aop/test/NetworkAdmin.javaJBCACHE-175 JDK50 annotation support1.1addedbwangtests-50/functional/org/jboss/cache/aop/test/NetworkDomain.javaJBCACHE-175 JDK50 annotation
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] JBAS-1476 (was: Long standing JMS Message Inflow testing)
In the discussion thread for this issue (http://www.jboss.com/index.html?module=bbop=viewtopict=73652), I'd said that for 4.0.4 I would: 1) Adapt RetryInterceptor so it can make use of o.jboss.naming.NamingContextFactory's ability to cache the naming env properties in a ThreadLocal. 2) Create a SingleRetryInterceptor that would make only a single attempt to re-lookup the invoker. This would be useful in the JBAS-1476 situation where an out-of-date EJB proxy invalidates the FamilyClusterInfo, or in any situation where a cached EJB proxy is held throughout a cluster restart and then reused. It wouldn't help if the cached proxy is used before the cluster has restarted; the regular RetryInterceptor would be needed for this. 3) Add the new SingleRetryInterceptor to the default clustered bean configs in standardjboss.xml. Items 1 and 2 were done for 4.0.4.RC1. #3 should have been, but wasn't, which is my fault. It will be in the GA. I'll be adding a wiki entry for the above late this week after JBossCache 1.3.0.Alpha1 is out. RetryInterceptor can now also easily be subclassed to add an arbitrary number of retries that is appropriate for the client application (e.g. retry once a second for 30 seconds, then fail.) - Brian [EMAIL PROTECTED] wrote: On Sat, 2006-02-18 at 04:58, Adrian Brock wrote: On Fri, 2006-02-17 at 15:34, Scott M Stark wrote: These two issues currently assigned to Tim: http://jira.jboss.com/jira/browse/JBAS-1434 http://jira.jboss.com/jira/browse/JBMESSAGING-170 I hope so. The purpose of giving them to someone else was that I didn't have time to do it, and they are something that could be done by anybody. They have been progressively pushed back since 4.0.0 I'd prefer to find the time to write these tests myself then we can move the JMSContainerInvoker with its practically unoverridable implementation to legacy. This would also be one less thing to worry about for EJB3 integration. Which I see you also moved to 4.0.5. In my opionion this is a mistake. If you keep pushing these things back, people just learn to ignore it knowing that if they leave it long it enough it will be keep getting deferred to the next release. e.g. The critical clustering issue that has been hanging around for months: http://jira.jboss.com/jira/browse/JBAS-1476 I hope this isn't going to get pushed back as well. These critical issues should really be done in the next availble release candidate, not done at the last minute for the GA release. [EMAIL PROTECTED] wrote: Regarding to JBAS-1476, it is critical althoguh it is a corner case, IMHO. You are right, we can't push it back forever. I am meeting with Bela this week. We will discuss it then. Thanks, -Ben --- 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]
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 that
RE: [JBoss-dev] [Fwd: Reflection using Javassist]
On Mon, 2006-02-20 at 12:25, Clebert Suconic wrote: 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 I have tests to catch that! :-) -- 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
[JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
Dimitris, remind me why removing xalan is a problem. I'm not getting it from the discussion thread associated with this JBAS-2073 issue. From the TransformerFactory javadoc: public static TransformerFactory newInstance() throws TransformerFactoryConfigurationError Obtain a new instance of a TransformerFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the TransformerFactory implementation class to load: * Use the javax.xml.transform.TransformerFactory system property. * Use the properties file lib/jaxp.properties in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above. * Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime. * Platform default TransformerFactory instance. Neither the javax.xml.transform.TransformerFactory system property nor jre lib/jaxp.properties exists by default: [EMAIL PROTECTED] bin]$ find /usr/java/jdk1.5.0_05 -name jaxp.properties [EMAIL PROTECTED] bin]$ find /usr/java/j2sdk1.4.2_09 -name jaxp.properties -print [EMAIL PROTECTED] bin]$ so the Services API (class loader scoped resources) should dictate how the jaxp factories are found. Having the xalan.jar in lib/endorsed overrides the javax.xml.transform namespace with classes loaded from the bootstrap class loader. I don't see why we need to do this? -Original Message- From: Dimitris Andreadis (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 4:00 AM To: Jira Notifications Subject: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed [ http://jira.jboss.com/jira/browse/JBAS-2073?page=all ] Dimitris Andreadis updated JBAS-2073: - Fix Version: (was: JBossAS-4.0.4.GA) I don't see how the lib/endorsed mechanism can be avoided, when running under jdk1.4, in which case, we can't fix this for Branch 4.x --- 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] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
What I'm saying is under jdk1.4 the only way to override the jdk embedded xalan with a different version is to drop it in lib/endorsed or use a scoped deployment. Putting it in server/xxx/lib or server/xxx/deploy won't work, even if specifying the javax.xml.transform.TransformerFactory property since setting it to org.apache.xalan.processor.TransformFactoryImpl makes no difference, it will just load the jdk provided xalan version because the class names collide. Now, I had the feeling that we *needed* a xalan.jar version newer than the one provided with jdk1.4, in which case, what other way we would have to override the jdk version? The rules you mention would work, if the overriding xalan version used different class names! I just removed lib/endorsed/xalan.jar and the server seems to boot happily. If we *do not need* a newer version, I guess we can just remove it, and let the user drop its own lib/endorsed/xalan.jar version, if necessary. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 20 February, 2006 21:33 To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed Dimitris, remind me why removing xalan is a problem. I'm not getting it from the discussion thread associated with this JBAS-2073 issue. From the TransformerFactory javadoc: public static TransformerFactory newInstance() throws TransformerFactoryConfigurationError Obtain a new instance of a TransformerFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the TransformerFactory implementation class to load: * Use the javax.xml.transform.TransformerFactory system property. * Use the properties file lib/jaxp.properties in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above. * Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime. * Platform default TransformerFactory instance. Neither the javax.xml.transform.TransformerFactory system property nor jre lib/jaxp.properties exists by default: [EMAIL PROTECTED] bin]$ find /usr/java/jdk1.5.0_05 -name jaxp.properties [EMAIL PROTECTED] bin]$ find /usr/java/j2sdk1.4.2_09 -name jaxp.properties -print [EMAIL PROTECTED] bin]$ so the Services API (class loader scoped resources) should dictate how the jaxp factories are found. Having the xalan.jar in lib/endorsed overrides the javax.xml.transform namespace with classes loaded from the bootstrap class loader. I don't see why we need to do this? -Original Message- From: Dimitris Andreadis (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 4:00 AM To: Jira Notifications Subject: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed [ http://jira.jboss.com/jira/browse/JBAS-2073?page=all ] Dimitris Andreadis updated JBAS-2073: - Fix Version: (was: JBossAS-4.0.4.GA) I don't see how the lib/endorsed mechanism can be avoided, when running under jdk1.4, in which case, we can't fix this for Branch 4.x --- 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
RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
So the problem is lack of encapsulation of the essentially global org.apache.xalan.processor.TransformFactoryImpl name due to the proliferation of the xalan distribution. One should be able to work around this by introducing a org.apache.xalan.processor.TransformFactoryImpl2 that loaded the org.apache.xalan.processor.TransformFactoryImpl visible via the thread context class loader. We don't need xsl during bootstrap, and as far as I know we don't have any requirements for a specific xsl version. The jira issue is a user request to update the xalan version since we do bundle it. So maybe just dropping it and defaulting to the jdk version is the best approach. We really should avoid introducing library dependencies unless they are needed. The xalan.jar dates from jboss-3.2 and the fact that jdk1.3 had no bundled xsl implementation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Monday, February 20, 2006 12:39 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed What I'm saying is under jdk1.4 the only way to override the jdk embedded xalan with a different version is to drop it in lib/endorsed or use a scoped deployment. Putting it in server/xxx/lib or server/xxx/deploy won't work, even if specifying the javax.xml.transform.TransformerFactory property since setting it to org.apache.xalan.processor.TransformFactoryImpl makes no difference, it will just load the jdk provided xalan version because the class names collide. Now, I had the feeling that we *needed* a xalan.jar version newer than the one provided with jdk1.4, in which case, what other way we would have to override the jdk version? The rules you mention would work, if the overriding xalan version used different class names! I just removed lib/endorsed/xalan.jar and the server seems to boot happily. If we *do not need* a newer version, I guess we can just remove it, and let the user drop its own lib/endorsed/xalan.jar version, if necessary. --- 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] This is the type of dependency info every project on labs.jboss.org
This type if info on dependecies (the license needs to be added as well and the project url cannot be empty) is what every project in labs.jboss.org should have: http://groovy.codehaus.org/dependencies.html This should be generated from the project thirdparty dependency declarations. Scott Stark VP Architecture Technology 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
So the problem is lack of encapsulation of the essentially global org.apache.xalan.processor.TransformFactoryImpl name due to the proliferation of the xalan distribution. One should be able to work around this by introducing a org.apache.xalan.processor.TransformFactoryImpl2 that loaded the org.apache.xalan.processor.TransformFactoryImpl visible via the thread context class loader. The org.apache.xalan.processor.TransformFactoryImpl visible through the TCL, for a non-scoped deployment, wouldn't be again the JDK bundled xalan, since this is loaded with the Bootstrap CL? (testing my CL knowledge here :) We don't need xsl during bootstrap, and as far as I know we don't have any requirements for a specific xsl version. The jira issue is a user request to update the xalan version since we do bundle it. So maybe just dropping it and defaulting to the jdk version is the best approach. We really should avoid introducing library dependencies unless they are needed. The xalan.jar dates from jboss-3.2 and the fact that jdk1.3 had no bundled xsl implementation. Fine, I'll remove it and see if anyone complaints :) Maybe we should go for an 4.0.4.RC2, too. --- 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: This is the type of dependency info every project on labs.jboss.org
As a sidenote to this discussion, I have been investigating the validation of these fields as well as license information retrieval/generation for thirdparty dependencies within the Maven2 confines. All of these tasks are possible using the same functionality which generates the previously mentioned website. I will be committing this into the prototype this afternoon and will post instructions in the build forum regarding how to use it. Ruel Loehr JBoss QA -Original Message- From: Scott M Stark Sent: Monday, February 20, 2006 3:27 PM To: jboss-development@lists.sourceforge.net Cc: '[EMAIL PROTECTED]' Subject: This is the type of dependency info every project on labs.jboss.org This type if info on dependecies (the license needs to be added as well and the project url cannot be empty) is what every project in labs.jboss.org should have: http://groovy.codehaus.org/dependencies.html This should be generated from the project thirdparty dependency declarations. Scott Stark VP Architecture Technology 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
The org.apache.xalan.processor.TransformFactoryImpl visible through the TCL, for a non-scoped deployment, wouldn't be again the JDK bundled xalan, since this is loaded with the Bootstrap CL? (testing my CL knowledge here :) Not necessarily because the org.apache.* is not a jdk core classes. Neither are the javax.* nor bundled org.* classes. All of those can be created in a scoped context by a class loader that does not delegate to its parent. Only classes in the java.* namespace cannot be passed to the ClassLoader.defineClass method. When this does not work is when you have mixing of classes with static references to jdk bootstrap classes in a class that is being used across different class loaders. There is no notion of redefine class on inconsistent type system usage although there should be in server environments. Fine, I'll remove it and see if anyone complaints :) Maybe we should go for an 4.0.4.RC2, too. That is probably a good idea. Two weeks for CR2(RC2 is now bad, I'll update the jboss version usage today), and the GA in 3-4 weeks after that. --- 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] jbossretro-testsuite Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jbossretro-testsuite?log=log20060220165559 BUILD FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jbossretro-testsuite.xml:53: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:81: Exit code: 1 Core tests failed. See tests.log in Build Artifacts for details.Date of build:02/20/2006 16:55:59Time to build:21 secondsLast changed:02/20/2006 13:00:08Last log entry:Don't exclude the concurrent tests. Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 108)1.3modifiedadriansrc/test/org/jboss/test/concurrent/ExecutorCompletionServiceTest.javaRemove "probably broken" tests because they are! :-)1.2modifiedadriansrc/test/org/jboss/test/concurrent/DelayQueueTest.javaRemove test for known issue:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6327342Not fixed until Mustang1.2modifiedadriansrc/test/org/jboss/test/concurrent/ThreadPoolExecutorTest.javaComment out tests that use non-existant api1.2modifiedadriansrc/test/org/jboss/test/concurrent/ThreadPoolExecutorSubclassTest.javaComment out tests that use non-existant api1.2modifiedadriansrc/test/org/jboss/test/concurrent/TreeSetTest.javaComment out tests that use non-existant apiSimulate pollFirst/Last used by this test.1.2modifiedadriansrc/test/org/jboss/test/concurrent/TreeMapTest.javaComment out tests that use non-existant api1.2modifiedadriansrc/test/org/jboss/test/concurrent/TimeUnitTest.javaComment out tests that use non-existant api1.1addedadriansrc/test/org/jboss/test/concurrent/RunnableScheduledFuture.javaInclude non-existant api in org.jboss.test.concurrent1.1addedadriansrc/test/org/jboss/test/concurrent/RunnableFuture.javaInclude non-existant api in org.jboss.test.concurrent1.3modifiedadriansrc/test/org/jboss/test/concurrent/JSR166TestCase.javaComment out non-existant test1.2modifiedrcampbellsrc/test/org/jboss/test/concurrent/ReentrantReadWriteLockTest.javaJBAS-2814 - remove tests of non java 5 methods1.2modifiedrcampbellsrc/test/org/jboss/test/concurrent/LinkedListTest.javaJBAS-2814 - remove tests of non java 5 methods1.2modifiedrcampbellsrc/test/org/jboss/test/concurrent/ExecutorCompletionServiceTest.javaJBAS-2814 - remove usage of RunnableTask which isn't present in java51.2deletedrcampbellsrc/test/org/jboss/test/concurrent/EntryTest.javaJBAS-2814 - java.util.AbstractMap won't be retroweaved, so this test is useless as well as broken1.2modifiedrcampbellsrc/test/org/jboss/test/concurrent/JSR166TestCase.javaJBAS-2814 - removed tests for classes not present in jdk51.2deletedrcampbellsrc/test/org/jboss/test/concurrent/LinkedBlockingDequeTest.javaJBAS-2814 - removed tests for classes not present in jdk51.2deletedrcampbellsrc/test/org/jboss/test/concurrent/TreeSubMapTest.javaJBAS-2814 - removed tests for classes not present in jdk51.2deletedrcampbellsrc/test/org/jboss/test/concurrent/TreeSubSetTest.javaJBAS-2814 - removed tests for classes not present in jdk51.1addedrcampbellsrc/test/org/jboss/test/concurrent/DelayQueueTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/EntryTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/ExchangerTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/ExecutorCompletionServiceTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/ExecutorsTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/FutureTaskTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/JSR166TestCase.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/LinkedBlockingDequeTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in jdk5.1.1addedrcampbellsrc/test/org/jboss/test/concurrent/LinkedBlockingQueueTest.javaJBAS-2814: Initial import of jsr166 tck. Currently excluded from build since it has dependencies not available in
[JBoss-dev] Status of groovy in jdk6
Gavin made me look at groovy for things like closures, and the groovy site shows a pervasive set of changes in the core jdk classes to support things like groovy.lang.Range, groovy.lang.Closure: http://groovy.codehaus.org/groovy-jdk.html but the associated jsrs don't seem far along: http://www.jcp.org/en/jsr/detail?id=241 http://www.jcp.org/en/jsr/detail?id=223 I should probably know this but I don't see anything on the jdk6 eg, and the jdk6 beta has nothing in the apis for groovy as yet. Anyone know more about its status? The related question I have is whether closures are something that make sense in javassist/aop as a more abstract representation of the behavior of an aspect. This could be used to cleanup code reuse in boilerplate aspects like security. Today they only differ in the interceptor/aspect invoke signature. Scott Stark VP Architecture Technology 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=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.4-testsuite?log=log20060220170427 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:199: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/20/2006 17:04:27Time to build:1 minute 58 secondsLast changed:02/20/2006 09:17:02Last log entry:JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication Unit Tests: (84) Total Errors and Failures: (0)All Tests Passed Modifications since last build:(first 50 of 26)1.4modifiedjulienserver/src/main/org/jboss/portal/server/output/cache/SoftTimedContent.javaJBPORTAL-608 : Timed content is not serializable and raise issues in http session replication1.3modifiedjulienserver/src/main/org/jboss/portal/server/output/cache/StrongTimedContent.javaJBPORTAL-608 : Timed content is not serializable and raise issues in http session replication1.3modifiedjulienserver/src/main/org/jboss/portal/server/output/cache/TimedContent.javaJBPORTAL-608 : Timed content is not serializable and raise issues in http session replication1.2modifiedbdawportlet/src/resources/test/test-portletinterface-war/WEB-INF/portlet.xml- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.9modifiedbdawportlet/src/main/org/jboss/portal/test/portlet/junit/PortletTestCase.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.2modifiedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/PortletInterfaceTestCase.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/ExceptionsDuringRequestHandlingControllerPortlet.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/PortletExceptionDuringRequestHandlingPortlet.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/RuntimeExceptionDuringRequestHandlingPortlet.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/UnavailableExceptionDuringProcessActionPortlet.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/UnavailableExceptionDuringRenderPortlet.java- JBPORTAL-672 "PLT.5.2.4.4 Exceptions During Request Handling" test cases1.4modifiedjuliencommon/src/main/org/jboss/portal/common/net/file/FileURLNavigationProvider.javasort files when we list a sub dir to have the behavior independant of the platform1.1addedbdawportlet/src/resources/test/test-portletinterface-war/WEB-INF/portlet.xml- JBPORTAL-638 - "portletinterface" test portlet deployment descriptors1.1addedbdawportlet/src/resources/test/test-portletinterface-war/WEB-INF/web.xml- JBPORTAL-638 - "portletinterface" test portlet deployment descriptors1.49modifiedbdawportlet/build.xml- JBPORTAL-638 - added "portletinterface" package and SPEC:4 testcase- JBPORTAL-671 - PLT.5.2.2.1 - 'Error Conditions on Initialization' test cases (SPEC:5,6 and 8)1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/PortletInterfaceTestCase.java- JBPORTAL-638 - added "portletinterface" package and SPEC:4 testcase- JBPORTAL-671 - PLT.5.2.2.1 - 'Error Conditions on Initialization' test cases (SPEC:5,6 and 8)1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/ExceptionsOnInitControllerPortlet.java- JBPORTAL-638 - added "portletinterface" package and SPEC:4 testcase- JBPORTAL-671 - PLT.5.2.2.1 - 'Error Conditions on Initialization' test cases (SPEC:5,6 and 8)1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/InitializeBeforeHandlePortlet.java- JBPORTAL-638 - added "portletinterface" package and SPEC:4 testcase- JBPORTAL-671 - PLT.5.2.2.1 - 'Error Conditions on Initialization' test cases (SPEC:5,6 and 8)1.1addedbdawportlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/PortletExceptionDuringInitPortlet.java- JBPORTAL-638 - added "portletinterface" package and SPEC:4 testcase- JBPORTAL-671 - PLT.5.2.2.1 - 'Error Conditions on Initialization' test cases (SPEC:5,6
[JBoss-dev] Re: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
how can we do to improve that (i.e fix the wellformedness) ? Rajesh Rajasekaran wrote: The junit reports (xml) for the portlet tests are not well formed. Hence the portlet test results are not accounted in the HTML reports shown. The common and format tests pass 100%. Please refer the link below for the portlet test reports. http://cruisecontrol.jboss.com/cc/artifacts/jboss-portal-2.4-testsuite/20060220170427/jboss-4.0.3SP1-logs/results/testfailures Please let me know if you have the same problem. Thanks Rajesh *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, February 20, 2006 4:07 PM *To:* [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet; QA *Subject:* jboss-portal-2.4-testsuite Build Completed With Testsuite Errors *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.4-testsuite?log=log20060220170427 *TESTS FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:199: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures. *Date of build: *02/20/2006 17:04:27 *Time to build: *1 minute 58 seconds *Last changed: *02/20/2006 09:17:02 *Last log entry: *JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication Unit Tests: (84) Total Errors and Failures: (0) All Tests Passed Modifications since last build: (first 50 of 26) 1.4 modified julien server/src/main/org/jboss/portal/server/output/cache/SoftTimedContent.java JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication 1.3 modified julien server/src/main/org/jboss/portal/server/output/cache/StrongTimedContent.java JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication 1.3 modified julien server/src/main/org/jboss/portal/server/output/cache/TimedContent.java JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication 1.2 modified bdaw portlet/src/resources/test/test-portletinterface-war/WEB-INF/portlet.xml - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.9 modified bdaw portlet/src/main/org/jboss/portal/test/portlet/junit/PortletTestCase.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.2 modified bdaw portlet/src/main/org/jboss/portal/test/portlet/portletinterface/PortletInterfaceTestCase.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.1 added bdaw portlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/ExceptionsDuringRequestHandlingControllerPortlet.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.1 added bdaw portlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/PortletExceptionDuringRequestHandlingPortlet.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.1 added bdaw portlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/RuntimeExceptionDuringRequestHandlingPortlet.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.1 added bdaw portlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/UnavailableExceptionDuringProcessActionPortlet.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.1 added bdaw portlet/src/main/org/jboss/portal/test/portlet/portletinterface/spec/UnavailableExceptionDuringRenderPortlet.java - JBPORTAL-672 PLT.5.2.4.4 Exceptions During Request Handling test cases 1.4 modified julien common/src/main/org/jboss/portal/common/net/file/FileURLNavigationProvider.java sort files when we list a sub dir to have the behavior independant of the platform 1.1 added bdaw
[JBoss-dev] RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
I guess portal uses an old version of junit(from 2001). The newer version might solve the problem. Anyways these are the errors I get. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.dispatcher.spec.DispatcherTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletconfig.PortletConfigTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletinterface.PortletInterfaceTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletmode.PortletModeTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletrequest.PortletRequestTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletsession.PortletSessionTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.preferences.PreferencesTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.renderresponse.RenderResponseTestCase.xml is not a valid XML document. It is possibly corrupted. -Original Message- From: Julien Viet Sent: Monday, February 20, 2006 4:41 PM To: Rajesh Rajasekaran Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet Subject: Re: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors how can we do to improve that (i.e fix the wellformedness) ? Rajesh Rajasekaran wrote: The junit reports (xml) for the portlet tests are not well formed. Hence the portlet test results are not accounted in the HTML reports shown. The common and format tests pass 100%. Please refer the link below for the portlet test reports. http://cruisecontrol.jboss.com/cc/artifacts/jboss-portal-2.4-testsuite/2 0060220170427/jboss-4.0.3SP1-logs/results/testfailures Please let me know if you have the same problem. Thanks Rajesh *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, February 20, 2006 4:07 PM *To:* [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet; QA *Subject:* jboss-portal-2.4-testsuite Build Completed With Testsuite Errors *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.4-testsuit e?log=log20060220170427 *TESTS FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:199: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures. *Date of build: *02/20/2006 17:04:27 *Time to build: *1 minute 58 seconds *Last changed: *02/20/2006 09:17:02 *Last log entry: *JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication Unit Tests: (84) Total Errors and Failures: (0) All Tests Passed Modifications since last build: (first 50 of 26) 1.4 modified julien server/src/main/org/jboss/portal/server/output/cache/SoftTimedContent.ja va JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication 1.3 modified julien
[JBoss-dev] RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
I see two things here: 1. The xml reports are empty, causing the XML validation errors. I guess no one has even looked at these yet?! 2. The Portlet test cases don't extend org.junit.TestCase, they extend java.lang.Object. That might work in your IDE, but I doubt we should expect AntRunner to put it up with it. -Original Message- From: Rajesh Rajasekaran Sent: Monday, February 20, 2006 5:22 PM To: Julien Viet Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA Subject: RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors I guess portal uses an old version of junit(from 2001). The newer version might solve the problem. Anyways these are the errors I get. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.dispatcher.spec.DispatcherTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletconfig.PortletConfigTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletinterface.PortletInterfaceTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletmode.PortletModeTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletrequest.PortletRequestTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletsession.PortletSessionTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.preferences.PreferencesTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.renderresponse.RenderResponseTestCase.xml is not a valid XML document. It is possibly corrupted. -Original Message- From: Julien Viet Sent: Monday, February 20, 2006 4:41 PM To: Rajesh Rajasekaran Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet Subject: Re: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors how can we do to improve that (i.e fix the wellformedness) ? Rajesh Rajasekaran wrote: The junit reports (xml) for the portlet tests are not well formed. Hence the portlet test results are not accounted in the HTML reports shown. The common and format tests pass 100%. Please refer the link below for the portlet test reports. http://cruisecontrol.jboss.com/cc/artifacts/jboss-portal-2.4-testsuite/2 0060220170427/jboss-4.0.3SP1-logs/results/testfailures Please let me know if you have the same problem. Thanks Rajesh *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, February 20, 2006 4:07 PM *To:* [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet; QA *Subject:* jboss-portal-2.4-testsuite Build Completed With Testsuite Errors *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.4-testsuit e?log=log20060220170427 *TESTS FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:199: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures. *Date of build: *02/20/2006 17:04:27 *Time to build: *1 minute 58 seconds *Last changed: *02/20/2006 09:17:02 *Last log entry: *JBPORTAL-608 : Timed content is not serializable and raise issues in http session replication Unit Tests: (84) Total Errors and
[JBoss-dev] RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
The xml reports are generated. The error from the junitreport task deletes the contents of the malformed xml's. -Original Message- From: Ryan Campbell Sent: Monday, February 20, 2006 5:37 PM To: Rajesh Rajasekaran; Julien Viet Cc: QA; '[EMAIL PROTECTED]'; 'jboss-development@lists.sourceforge.net' Subject: RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors I see two things here: 1. The xml reports are empty, causing the XML validation errors. I guess no one has even looked at these yet?! 2. The Portlet test cases don't extend org.junit.TestCase, they extend java.lang.Object. That might work in your IDE, but I doubt we should expect AntRunner to put it up with it. -Original Message- From: Rajesh Rajasekaran Sent: Monday, February 20, 2006 5:22 PM To: Julien Viet Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA Subject: RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors I guess portal uses an old version of junit(from 2001). The newer version might solve the problem. Anyways these are the errors I get. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.dispatcher.spec.DispatcherTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletconfig.PortletConfigTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletinterface.PortletInterfaceTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletmode.PortletModeTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletrequest.PortletRequestTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.portletsession.PortletSessionTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.preferences.PreferencesTestCase.xml is not a valid XML document. It is possibly corrupted. [junitreport] [Fatal Error] :-1:-1: Premature end of file. [junitreport] The file /home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port al.test.portlet.renderresponse.RenderResponseTestCase.xml is not a valid XML document. It is possibly corrupted. -Original Message- From: Julien Viet Sent: Monday, February 20, 2006 4:41 PM To: Rajesh Rajasekaran Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet Subject: Re: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors how can we do to improve that (i.e fix the wellformedness) ? Rajesh Rajasekaran wrote: The junit reports (xml) for the portlet tests are not well formed. Hence the portlet test results are not accounted in the HTML reports shown. The common and format tests pass 100%. Please refer the link below for the portlet test reports. http://cruisecontrol.jboss.com/cc/artifacts/jboss-portal-2.4-testsuite/2 0060220170427/jboss-4.0.3SP1-logs/results/testfailures Please let me know if you have the same problem. Thanks Rajesh *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, February 20, 2006 4:07 PM *To:* [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien Viet; QA *Subject:* jboss-portal-2.4-testsuite Build Completed With Testsuite Errors *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.4-testsuit e?log=log20060220170427 *TESTS FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:199: The following error occurred while executing this line:
[JBoss-dev] Re: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
yes they don't extend TestCase because we only use the
public static Test suite() { }
method as the class itself is not really a test but rather a suite provider.
should we make the portlet test case extends it ?
Ryan Campbell wrote:
I see two things here:
1. The xml reports are empty, causing the XML validation errors. I
guess no one has even looked at these yet?!
2. The Portlet test cases don't extend org.junit.TestCase, they extend
java.lang.Object. That might work in your IDE, but I doubt we should
expect AntRunner to put it up with it.
-Original Message-
From: Rajesh Rajasekaran
Sent: Monday, February 20, 2006 5:22 PM
To: Julien Viet
Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA
Subject: RE: jboss-portal-2.4-testsuite Build Completed With Testsuite
Errors
I guess portal uses an old version of junit(from 2001). The newer
version might solve the problem.
Anyways these are the errors I get.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.dispatcher.spec.DispatcherTestCase.xml is not a valid
XML document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.portletconfig.PortletConfigTestCase.xml is not a valid
XML document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.portletinterface.PortletInterfaceTestCase.xml is not a
valid XML document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.portletmode.PortletModeTestCase.xml is not a valid XML
document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.portletrequest.PortletRequestTestCase.xml is not a valid
XML document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.portletsession.PortletSessionTestCase.xml is not a valid
XML document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.preferences.PreferencesTestCase.xml is not a valid XML
document. It is possibly corrupted.
[junitreport] [Fatal Error] :-1:-1: Premature end of file.
[junitreport] The file
/home/test_cc/work/checkout/jboss-portal-2.4/portlet/TEST-org.jboss.port
al.test.portlet.renderresponse.RenderResponseTestCase.xml is not a valid
XML document. It is possibly corrupted.
-Original Message-
From: Julien Viet
Sent: Monday, February 20, 2006 4:41 PM
To: Rajesh Rajasekaran
Cc: QA; [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien
Viet
Subject: Re: jboss-portal-2.4-testsuite Build Completed With Testsuite
Errors
how can we do to improve that (i.e fix the wellformedness) ?
Rajesh Rajasekaran wrote:
The junit reports (xml) for the portlet tests are not well formed.
Hence the portlet test results are not accounted in the HTML reports
shown.
The common and format tests pass 100%.
Please refer the link below for the portlet test reports.
http://cruisecontrol.jboss.com/cc/artifacts/jboss-portal-2.4-testsuite/2
0060220170427/jboss-4.0.3SP1-logs/results/testfailures
Please let me know if you have the same problem.
Thanks
Rajesh
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
*Sent:* Monday, February 20, 2006 4:07 PM
*To:* [EMAIL PROTECTED]; jboss-development@lists.sourceforge.net; QA; Julien
Viet; QA
*Subject:* jboss-portal-2.4-testsuite Build Completed With Testsuite
Errors
*Importance:* High
View results here -
http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.4-testsuit
e?log=log20060220170427
*TESTS FAILED*
*Ant Error
Message:
*/services/cruisecontrol/work/scripts/build-jboss-portal.xml:67:
The following error occurred while executing this line:
/services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The
following error occurred while executing this line:
/services/cruisecontrol/work/scripts/build-jboss-portal.xml:199: The
following error occurred while executing this line:
/services/cruisecontrol/work/scripts/build-common-targets.xml:11:
Build
Successful - Tests completed with errors or failures.
*Date of build: *02/20/2006 17:04:27
*Time to build: *1 minute 58 seconds
[JBoss-dev] jboss-4.0-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20060220184656 BUILD FAILEDAnt 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:02/20/2006 18:46:56Time to build:13 minutes 35 secondsLast changed:02/20/2006 18:19:50Last log entry:JBAS-2073, remove xalan.jar Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 5)1.51.2.4modifieddimitrismessaging/build.xmlJBAS-2073, remove xalan.jar1.13.2.17modifieddimitrisaspects/build.xmlJBAS-2073, remove xalan.jar1.87.6.5modifieddimitrisjmx/build.xmlJBAS-2073, remove xalan.jar1.1.4.29modifieddimitrisbuild/build-distr.xmlJBAS-2073, remove xalan.jar1.1.2.72modifieddimitrisbuild/build-thirdparty.xmlJBAS-2073, remove xalan.jar
[JBoss-dev] RE: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
should we make the portlet test case extends it ?
Well, as Rajesh pointed out it is the junitreport task which blanks the
XML reports, so I was wrong on my point #2. Rajesh is trying to narrow
this down and will followup with what he finds.
-Original Message-
From: Julien Viet
Sent: Monday, February 20, 2006 5:53 PM
To: Ryan Campbell
Cc: Rajesh Rajasekaran; Julien Viet; QA; [EMAIL PROTECTED];
jboss-development@lists.sourceforge.net
Subject: Re: jboss-portal-2.4-testsuite Build Completed With Testsuite
Errors
yes they don't extend TestCase because we only use the
public static Test suite() { }
method as the class itself is not really a test but rather a suite
provider.
should we make the portlet test case extends it ?
---
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: jboss-portal-2.4-testsuite Build Completed With Testsuite Errors
thanks,
Junit is so lame :-)
Ryan Campbell wrote:
should we make the portlet test case extends it ?
Well, as Rajesh pointed out it is the junitreport task which blanks the
XML reports, so I was wrong on my point #2. Rajesh is trying to narrow
this down and will followup with what he finds.
-Original Message-
From: Julien Viet
Sent: Monday, February 20, 2006 5:53 PM
To: Ryan Campbell
Cc: Rajesh Rajasekaran; Julien Viet; QA; [EMAIL PROTECTED];
jboss-development@lists.sourceforge.net
Subject: Re: jboss-portal-2.4-testsuite Build Completed With Testsuite
Errors
yes they don't extend TestCase because we only use the
public static Test suite() { }
method as the class itself is not really a test but rather a suite
provider.
should we make the portlet test case extends it ?
--
Julien Viet
JBoss Portal Project Lead
---
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
[JBoss-dev] jboss-4.0-jdk-matrix build.835 Build Fixed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20060220213845Lbuild.835 BUILD COMPLETE-build.835Date of build:02/20/2006 21:38:45Time to build:20 minutes 12 secondsLast changed:02/20/2006 19:08:51Last log entry:JBAS-2073, remove xalan.jar Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(first 50 of 6)1.2.2.14modifieddimitrishibernate-int/build.xmlJBAS-2073, remove xalan.jar1.51.2.4modifieddimitrismessaging/build.xmlJBAS-2073, remove xalan.jar1.13.2.17modifieddimitrisaspects/build.xmlJBAS-2073, remove xalan.jar1.87.6.5modifieddimitrisjmx/build.xmlJBAS-2073, remove xalan.jar1.1.4.29modifieddimitrisbuild/build-distr.xmlJBAS-2073, remove xalan.jar1.1.2.72modifieddimitrisbuild/build-thirdparty.xmlJBAS-2073, remove xalan.jar
[JBoss-dev] jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060220220020 TESTS FAILEDAnt Error Message:/services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build:02/20/2006 22:00:20Time to build:73 minutes 31 secondsLast changed:12/31/2005 20:37:24Last log entry:JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup. Unit Tests: (285) Total Errors and Failures: (2)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(java_serialization)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(jboss_serialization) Modifications since last build:(first 50 of 2053)1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutTestCase.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/ComplexObject.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvocationHandler.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServer.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServerImpl.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TransporterTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/SSLInvokerConstants.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.8modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleClient.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleServer.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.7modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-270:Replaced "," with ""1.6modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-270:Replaced "," with ""1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-253 - changed to use coyote connector by default instead of http server invoker. Also adding many fixes so now only ssl related http tests are failing within the tests suite.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/.truststoreJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many
