testsuite run again hosed with localDB.lck problem
by Scott M Stark
The testsuite run is broken again
https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-TestSu...
with the same hsql lock problem:
2007-12-15 00:49:40,873 DEBUG [org.jboss.jdbc.HypersonicDatabase]
Starting failed jboss:service=Hypersonic,database=localDB
java.sql.SQLException: The database is already in use by another
process: org.hsqldb.persist.NIOLockFile@f654de53[file
=/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.Beta3/server/all/data/hypersonic/localDB.lck,
exists=true, locked=false, valid=false, fl =null]:
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
at org.hsqldb.jdbcDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:171)
at
org.jboss.jdbc.HypersonicDatabase.getConnection(HypersonicDatabase.java:777)
16 years, 4 months
Re: [jboss-dev] testsuite run again hosed with localDB.lck problem
by Ryan Campbell
Aleksandar Kostadinov wrote:
> Ryan Campbell wrote, On 12/17/2007 05:55 PM (EEST):
>> One way this could theoretically happen is that a rogue job is using
>> this job's JBoss home, instead of copying it over in to it's own job
>> directory. IE, another job besides "JBoss-AS-5.0.x-TestSuite-sun15"
>> running simultaneously on a different node in the test grid.
>
> That doesn't seem to be the case at least looking at job configuration.
> Can you point me to the log file where I can see the error?
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
(grep for it ;-)
The whole thing seems very unlikely to me as well, but I can't otherwise
explain the lockfile issue.
16 years, 4 months
Re: JBossAS 4.2.2.GA status
by Dimitris Andreadis
Then we should defer the resolution of JBAS-4852, JBWS-1813 for a future release.
Unless I hear differently I will be tagging the release on Wed morning.
Rajesh, we just want to verify that the TCK runs clean.
William DeCoste wrote:
> Both of the EJB3/WS (JBAS-4852,JBWS-1813) issues are related to
> processing metadata from xml - it's VERY broken. Thomas is making fixes
> in jbossws2.0.3. I doubt it will be complete in time for 4.2.2.
>
> -Bill
>
> Dimitris Andreadis wrote:
>> We are very close to tagging the AS 4.2.2.GA release.
>>
>> From the JIRA
>> http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hid...
>>
>>
>> We performed a jbossxb upgrade from 1.0.0.GA to 1.0.0.SP1 for
>> http://jira.jboss.com/jira/browse/JBAS-4853
>>
>> This includes:
>> JBXB-97 org.w3c.dom.Element is being mapped incorrectly
>> JBXB-105 switch from oswego to java.util concurrent
>> JBXB-103 JBossXB ignores non-ignorable white space
>> JBXB-96 JAXB error when using different derived types in the same
>> container/array type
>>
>> I don't see any regressions in the testsuites.
>>
>> The only thing that is holding us is this:
>> http://jira.jboss.com/jira/browse/JBAS-4852
>> http://jira.jboss.com/jira/browse/JBWS-1813
>>
>> It needs to be either resolved ASAP, or deferred. Carlo and Thomas
>> cooperate on this task.
>>
>> TCK 1.4 should be fully passing now, but it is probably wise to do
>> another run just after JBAS-4852 is resolved/deferred and before
>> releasing.
>> http://jira.jboss.com/jira/browse/JBAS-4754
>>
>> There is also a task for including the jbossws testsuite in the AS
>> release process
>> http://jira.jboss.com/jira/browse/JBAS-4811
>>
>> For both QA tasks, Rajesh is our man.
>>
>> Let's finish with this release!
>>
>> Thanks
>> /Dimitris
>>
>>
>
16 years, 4 months
AS trunk freeze
by Dimitris Andreadis
We are freezing the trunk for Beta3. Please don't commit stuff unless is related to fixing a
testsuite failure, or a critical/blocker AS issue.
If you have doubts if you can commit or not, please email me.
/Dimitris
PS
We saw recently some spikes in the testsuite/tck results but that seemed to be fixed now.
16 years, 4 months
Re: [Fwd: Re: [JBoss JIRA] Commented: (JBAS-5072) Fix null pointer exception when getting keys, values, or entry's in the ConcurrentHashmap]
by Adrian Brock
Copying to the main dev-list.
Yes, you can change it. But ideally you should test it first.
i.e. checkout the jbossxb 1.0.0SP1 tag
and modfiy the build to use update1
That's what compatiblity means. ;-)
This clearly wasn't done for the brew release
since there's no maven release for that.
Which is another reason why brew is bad.
http://repository.jboss.com/maven2/oswego-concurrent/concurrent/
On Wed, 2007-12-12 at 16:41 -0500, Jay Howell wrote:
> Hey Adrian,
> I've made a new version of the concurren
> lib(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1....
> , and I've changed my build-thirdparty.xml file, but I also need to add
> an entry in the jbossxb(component-info.xml) to establish compatibility.
> The current version that is current in branch 4.2 for jbossxb is
> 1.0.0.SP1. My question is, Do I need to make a new version of jbossxb,
> or can I check the compatibility changes in for 1.3.4-jboss-update1into
> jbossxb 1.0.0SP1? I see that the entry that put the compatibility entry
> in for 1.3.4-jboss(1.0.0.GA_CP01-brew) was just added to that version
> and a new version(directory) was not added. I can easily either make a
> new version(called ???) or I can just change the version that's there.
>
> Thanks, Jay:)
> email message attachment (Re: [JBoss JIRA] Commented: (JBAS-5072) Fix
> null pointer exception when getting keys, values, or entry's in the
> ConcurrentHashmap)
> > -------- Forwarded Message --------
> > From: Jay Howell <jhowell(a)redhat.com>
> > To: Adrian <abrock(a)redhat.com>
> > Subject: Re: [JBoss JIRA] Commented: (JBAS-5072) Fix null pointer
> > exception when getting keys, values, or entry's in the
> > ConcurrentHashmap
> > Date: Wed, 12 Dec 2007 15:04:59 -0500
> >
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 4 months
My logging ultimatum
by David M. Lloyd
Developing Remoting 3 I discovered that, thanks to depending on MINA
and JBoss Serialization, I now have an indirect dependency on both
log4j and slf4j. This sucks. I'm tired of dealing with issues with
logging when this problem should have been solved years ago.
I've asked Clebert to change JBoss Serialization to use JDK logging.
His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
(except for the wedge that Stan Silvert wrote for JSF).
My feelings are as follows:
* The JBossAS logging system must be changed such that BY DEFAULT log
messages are all handled properly (in terms of category and level),
regardless of the logging framework used (java.util.logging or log4j).
No, relying on the System.out/System.err capture mechanism is NOT
sufficient for this task. This means that, as far as I can tell, we
should always be installing a JUL LogManger on appserver startup.
Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
do this out of the box.
* ALL framework devlopers should switch to java.util.logging. This is
the ONLY way you can have logging without introducing a JAR
dependency. Yeah the API kind of sucks, but it's easily worked around
(here's one way: http://tinyurl.com/3848rr - notice the lack of
external JAR dependencies). It's far better for the framework
developer to embrace suckage, so that the end-user doesn't have to.
* The end application developer should be able to use whatever
logging API they like the best without surprises.
A while back Scott indicated that there would be the option of a JDK
logger in AS 5, and maybe it would even be the default one. The
discussion thread is at:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
though unfortunately, the whole theme of the discussion is "which
logging framework to use, log4j or jdk" and the issue was confused by
the faulty assumption that by using one, we would no longer be able to
support the other. So I'm actually sort of confused as to the outcome
of that.
In any case, Remoting 3 will use JDK logging, at least until someone
stops me. And I will continue my efforts to get JBSER and MINA changed
over to JDK logging as well.
- DML
16 years, 4 months
JBAS-4548 - Breaks the testsuite
by Adrian Brock
Brian,
You created this test:
http://jira.jboss.com/jira/browse/JBAS-4548
org.jboss.test.deployers.ear.test.EmbeddedDatasourceUnitTestCase
The test actually passes for me, I'm assuming it should
fail with whatever problem you were seeing?
Or the problem has been fixed.
BUT....
It breaks the remaining tests, since it appears to be
shutting down hypersonic when it is undeployed:
2007-12-12 17:23:07,057 DEBUG [org.jboss.system.ServiceController]
stopping service: jboss:service=Hypersonic,database=localDB2
2007-12-12 17:23:07,057 DEBUG [org.jboss.jdbc.HypersonicDatabase]
Stopping jboss:service=Hypersonic,database=localDB2
2007-12-12 17:23:07,253 INFO [org.jboss.jdbc.HypersonicDatabase]
Database standalone closed clean
You then get lots of errors like:
org.jboss.deployment.DeploymentException: Error while checking if table
aleady exists CTS_CMP_V1
at
org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1082)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.java:100)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:499)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:396)
at
org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
...
Caused by: java.sql.SQLException: Access is denied: Session is closed
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.jdbcStatement.executeQuery(Unknown Source)
at org.hsqldb.jdbc.jdbcDatabaseMetaData.execute(Unknown Source)
at org.hsqldb.jdbc.jdbcDatabaseMetaData.getTables(Unknown
Source)
at
org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.tableExists(SQLUtil.java:1075)
... 98 more
I guess it is either using a singleton internally or getting confused
about which server should be shutdown?
I'm going to exclude the test from the testsuite run.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 4 months
