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.
> > -Origin
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 f
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 version
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, whil
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 :-
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/
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 tota
In the discussion thread for this issue
(http://www.jboss.com/index.html?module=bb&op=viewtopic&t=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
>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 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.
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
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 s
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.apa
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.
xxx
> 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 loade
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 mention
> 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 cl
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
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.jc
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/concurrent-testsuite?log=log20060220165625
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-concurrent-testsuite.xml:73: The following error occurred while executing this line: /services/cruisecontrol/work
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/s
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 be
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
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
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.sourcef
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, causi
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/script
> 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:
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 fin
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, r
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/wo
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060221013225
BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details.Date of build: 02/21
32 matches
Mail list logo
