February 2007 - jboss-development

jboss-remoting-testsuite-1.6 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

jbossretro-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

microcontainer-head-testsuite-14 Build Failed

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

microcontainer-head-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

Branch_4_2 build clean does not remove any custom server configs

by Anil Saldhana

Doing "ant clean" in build, removes the "default", "minimal" and "all" server configs. It does not remove any custom server configs that may have been creared. Shouldn't it just nuke the output directory? Here is an example of a clean build on my windows ------------ asaldhana~/jboss-4.2/build>ls output/jboss-4.2.0.CR1/server/ cts custom-securitymgr jacc ------------- What changed in the build scripts?

17 years, 2 months

1
0
0 / 0

jbpm.3 Build Failed

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

jboss-head-testsuite-1.6 Build Failed

by jboss-qa-internal＠redhat.com

17 years, 2 months

1
0
0 / 0

Branch_4_2 Naming not working correctly if -b is used

by Brian Stansberry

Recent changes (probably related to running bound to localhost by default??) cause a problem if the -b switch is used. The RMI stub for the naming service seems to be bound to localhost. Note the endpoint in this log message: 2007-02-27 12:10:14,515 DEBUG [org.jboss.naming.Naming] NamingServer stub: NamingServer_Stub[UnicastRef2 [liveRef: [endpoint:[127.0.0.1:1098,org.jboss.net.sockets.DefaultSocketFactory@aa7d433a[bindAddress=/192.168.1.164]](local),objID:[0]]]] The naming service is useless, e.g. shutdown doesn't work: c:\dev\jboss\jboss-4.2\build\output\jboss-4.2.0.CR1\bin>shutdown -s 192.168.1.16 4 -S Exception in thread "main" javax.naming.CommunicationException [Root exception i s java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: connect] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:722) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.jboss.Shutdown.main(Shutdown.java:214) Caused by: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185 ) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:94) at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625) ... 3 more Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at java.net.Socket.<init>(Socket.java:366) at java.net.Socket.<init>(Socket.java:179) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirect SocketFactory.java:22) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMaster SocketFactory.java:128) at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:569) ... 8 more I'll poke around a bit to see if I can find the cause/solution. -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

17 years, 2 months

3
3
0 / 0

brew version inconsistency

by Scott M Stark

A current problem with brew version is that the source attachments in the repository are not usable by eclipse: [starksm@succubus repository.jboss.com]$ ls javassist/3.5.0.CR1-brew/src/ CVS/ javassist-3.5.CR1-src.tar.gz eclipse can only deal with source directories and jar/zip archives of source. This breaks the jbossas eclipse project sourcepaths that point to the thirdparty location for javassist-src.jar as it existed in the non-brew version: [starksm@succubus repository.jboss.com]$ ls javassist/3.5.0.CR1/lib/ CVS/ javassist.jar* javassist-src.jar [starksm@succubus repository.jboss.com]$ Inclusion of the version in the artifact also means the source attachment has to be updated every time there is a version change to the jbossas project.

17 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-development February 2007