September 2007 - jboss-development

by Dimitris Andreadis

We have this base issue to track unification of transports in AS5 http://jira.jboss.com/jira/browse/JBAS-3925 My concern is without a clear strategy yet on remoting v3 (which I understand is currently under discussion) in terms of API changes and compatibility with v2, shouldn't we delay this set of tasks?

16 years, 7 months

4
6
0 / 0

Next bug fixing release - AS 4.2.2.GA

by Dimitris Andreadis

It is not our #1 priority but the clock is ticking for the next bug fixing release for AS 4.2, targeted for mid October. The cut-off date for work on Branch_4_2 is *Sep/21st*. After that, only testsuite fixes, until the release date. Please, take a look at the scheduled tasks: http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hid... - unschedule/reschedule tasks that won't be fixed now - make sure we haven't missed some important task for 4.2.2.GA - mark as critical the important ones - work on the tasks you are assigned For this release we are dependending on remoting 2.2.2.GA and JBossWeb 2.0.1.GA, so the respective owners, please follow up with delivery estimates. Related testsuites: http://hudson.jboss.org/hudson/job/JBoss-AS-4.2.x-TestSuite-sun15/ http://hudson.jboss.org/hudson/job/JBoss-AS-4.2.x-TestSuite-jrockit15/ http://hudson.jboss.org/hudson/job/JBoss-AS-4.2.x-CompatibilityMatrix/ Internal Hudson (http://dev45.qa.atl.jboss.com:8585/hudson/view/JBoss%20AS/) For any issue, let me know. Thanks /D -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Dimitris Andreadis JBoss AS, Project Lead JBoss, a Division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 7 months

3
5
0 / 0

Trunk upgrade to JGroups 2.5

by Brian Stansberry

I just move AS trunk to JGroups 2.5.0.GA. If your build complains about a version conflict with messaging, delete thirdparty/jboss/messaging and rebuild. -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

16 years, 7 months

1
0
0 / 0

JBoss Common

by Dimitris Andreadis

We have 2 branches from the old common that included logging: https://svn.jboss.org/repos/common/common-old/branches/ Branch_1_0 for AS 4.0.x (latest release, 1.0.4.GA) Branch_1_2 for AS 4.2.x (latest release, 1.2.0.GA) Those are tagged the old way and tracked in JIRA. For the new common (minus logging) we have again 2 branches: This was created recently, but is it actually used? https://svn.jboss.org/repos/common/common-core/branches/2_0/ We have different type of tags (is this a maven thing?): https://svn.jboss.org/repos/common/common-core/tags/2.0.5.GA/ https://svn.jboss.org/repos/common/common-core/tags/jboss-common-core-2.0... But 2.0.5.GA still looks unreleased in JIRA: http://jira.jboss.com/jira/secure/project/ViewProject.jspa?pid=12310265 2.0.2 and 2.0.3 were skipped in JIRA. The common-core trunk is now producing the 2.2.x versions: https://svn.jboss.org/repos/common/common-core/trunk/ Last ones were 2.2.0.GA, 2.2.1.GA. Only the second was registered in JIRA. Now that common-core has moved to 2.2.x, we have the problem that the logging modules are still in 2.0.x version so the COMMON JIRA cannot track now updates to both: common-logging-jdk common-logging-log4j common-logging-spi Commong-logging has tags that are not documented and don't know if/where are used 2.0.3.GA/ jboss-common-logging-spi-2.0.4.GA/ AS5 is no on 2.0.2.GA So 0) We need to do a better job tracking common-core/logging in JIRA, otherwise we won't know what a particular version contains. 1) Shouldn't we create a different project in jira for Common Logging? 2) Since the 3 logging modules move in tandem and not too often, does it make sense to move them in a single project, rather than having to maintain 3 different projects?

16 years, 7 months

2
3
0 / 0

jboss_5_0.xsd

by Alexey Loubyansky

Is it available anywhere else than at http://www.jboss.org/j2ee/schema/jboss_5_0.xsd? I can't find it in the trunk. It's referenced in trunk\testsuite\output\resources\naming\jar\META-INF\jboss.xml Alexey

16 years, 7 months

2
1
0 / 0

Using the EJBTestCase to run tests in the appserver

by Adrian

I made a small modification to the EJBTestCase so you can use it more generically to run tests inside the appserver. Before, it always started a UserTransaction which makes it difficult to run tests where you want to start a transaction yourself. To workaround this issue, you can now say you don't want the UserTransaction with an env-entry, e.g. <session> <description>JUnit Session Bean Test Runner</description> <ejb-name>EJBTestRunnerEJB</ejb-name> <home>org.jboss.test.util.ejb.EJBTestRunnerHome</home> <remote>org.jboss.test.util.ejb.EJBTestRunner</remote> <ejb-class>org.jboss.test.util.ejb.EJBTestRunnerBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> <env-entry> <env-entry-name>NO_USER_TRANSACTION</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>true</env-entry-value> </env-entry> </session> -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 7 months

1
0
0 / 0

org.jboss.util.threadpool.BasicThreadPool issue

by Anil Saldhana

Adrian, with some progressive changes in my AS5 trunk workspace, while running one of the tests in the test suite, the server log is filling up with the following exception (it is reaching something like 800MB in log size) ================= 2007-09-11 09:40:10,843 DEBUG [org.jboss.util.threadpool.BasicThreadPool] Timeou t monitor saw unexpected error java.util.NoSuchElementException at java.util.AbstractQueue.remove(AbstractQueue.java:80) at org.jboss.util.threadpool.BasicThreadPool.getNextTimeout(BasicThreadPool.java:475) at org.jboss.util.threadpool.BasicThreadPool$TimeoutMonitor.run(BasicThreadPool.java:593) at java.lang.Thread.run(Thread.java:595) ===================== I am still checking why this issue is happening. But I see that you are making use of a PriorityQueue and whose remove is supposed to be safe from any exception. Regards, Anil

16 years, 7 months

3
3
0 / 0

Status of oswego-concurrent in the repository

by Adrian

For this issue: http://jira.jboss.com/jira/browse/JBAS-4697 and the related missing fixes http://jira.jboss.com/jira/browse/JBAS-4698 I'm confused by the oswego-concurrent package in our repository. 1) It says it is 1.3.4-brew, but when I diff with the latest release from the oswego website which is 1.3.4, it looks more 1.3.3 judging by the release notes. 2) If I'm going to fix this what do I call it 1.3.4-brew2 or 1.3.4-jboss-brew or what? 3) The actual fix hasn't been released, it is one of two fixes after the 1.3.4 release, see the bottom of this page: http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html What I propose to do is to apply the two fixes to the raw 1.3.4 source as a patch and upload the raw source + patch file to our repository. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 7 months

2
2
0 / 0

Strange thing in Jbossas with jboss-web.xml

by jean-frederic clere

Hi, I have the following jboss-web.xml: +++ <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Service Reference 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd"> <jboss-web>  </jboss-web> +++ It causes the following error: +++ Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: vfsfile:/home/jfclere/jbossas_head/build/output/jboss-5.0.0.Beta3/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml@3,12 at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:184) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:186) at org.jboss.deployers.vfs.spi.deployer.ObjectModelFactoryDeployer.parse(ObjectModelFactoryDeployer.java:120) ... 22 more Caused by: org.xml.sax.SAXException: Element type "jboss-web" must be declared. @ vfsfile:/home/jfclere/jbossas_head/build/output/jboss-5.0.0.Beta3/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml[3,12] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler.error(SaxJBossXBParser.java:427) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) +++ Is that normal? Cheers Jean-Frederic

16 years, 7 months

4
6
0 / 0

javax.net.ServerSocketFactory not found?!?!

by Kabir Khan

I've just imported an updated jboss-head into Eclipse, and I get the following error in naming/src/main/org/jnp/server/Main.java: The type javax.net.ServerSocketFactory cannot be resolved. It is indirectly referenced from required .class files Main.java imports that file, but should this not be part of the JRE System library?

16 years, 7 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-development September 2007