February 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBREM-302) remote dynamic marshall loading not working on linux

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-302?page=all ] Ron Sigal updated JBREM-302: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) > remote dynamic marshall loading not working on linux > ---------------------------------------------------- > > Key: JBREM-302 > URL: http://jira.jboss.com/jira/browse/JBREM-302 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 1.4.0 beta > Environment: Linux, JDK 1.4 > Reporter: Tom Elrod > Priority: Minor > Fix For: 2.4.0.GA > > Attachments: SocketMarshallerLoadingTestCase-out.txt > > > The following test cases fail on Linux (and not on Windows): > org.jboss.test.remoting.marshall.dynamic.remote.http.HTTPMarshallerLoadingTestCase > org.jboss.test.remoting.marshall.dynamic.remote.socket.SocketMarshallerLoadingTestCase > Test output for SocketMarshallerLoadingTestCase attached, but says that server can not find the class: > org.jboss.test.remoting.marshall.dynamic.remote.socket.TestObject > However, confirmed that this class is within the jboss-remoting-loading-tests.jar, which is being set on the classpath (as shown in the output log). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-221) remove physical inclusion of docbook support directories

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-221?page=all ] Ron Sigal updated JBREM-221: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) Assignee: (was: Tom Elrod) > remove physical inclusion of docbook support directories > -------------------------------------------------------- > > Key: JBREM-221 > URL: http://jira.jboss.com/jira/browse/JBREM-221 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.4.0 beta > Reporter: Tom Elrod > Priority: Optional > Fix For: 2.4.0.GA > > > Included style and support directory under root docs directory. These are large in size and should either require checkoout of docbook-support project (as suggested on wiki) and point to that or find another solution that does not require getting these upon standard JBossRemoting checkout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-238) JBossRemoting testsuite needs to generate artificats in the output folder

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-238?page=all ] Ron Sigal updated JBREM-238: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) > JBossRemoting testsuite needs to generate artificats in the output folder > ------------------------------------------------------------------------- > > Key: JBREM-238 > URL: http://jira.jboss.com/jira/browse/JBREM-238 > Project: JBoss Remoting > Issue Type: Task > Components: general > Reporter: Adrian Brock > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.GA > > > The JBossRemoting testsuite is dumping its artifacts in the root of the project rather than output. > e.g. cvs diff: > ? MultiThreadPerformanceTestCase_benchmark.txt > ? MultiThreadedRMIPerformanceTestCase_benchmark.txt > ? PerformanceClientSideTestCase_benchmark.txt > ? PerformanceServerSideTestCase_benchmark.txt > ? PerformanceTestCase_benchmark.txt > ? RMIPerformanceTestCase_benchmark.txt > ? data > ? debug_output.log > ? start_1132237128739.txt > ? start_1132237129627.txt > etc. > Eventually somebody is going to commit these to cvs by mistake. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-139) need automated test for servlet server invoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-139?page=all ] Ron Sigal updated JBREM-139: ---------------------------- Fix Version/s: 2.4.0.GA (was: 2.4.0.CR1 (Pinto)) Assignee: (was: Tom Elrod) > need automated test for servlet server invoker > ---------------------------------------------- > > Key: JBREM-139 > URL: http://jira.jboss.com/jira/browse/JBREM-139 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Priority: Minor > Fix For: 2.4.0.GA > > > Tests for servlet invoker is manual since have to deploy servlet-invoker.war to jboss in order for it to work. Need to figure out if there > is an easy automated way to do this (since would currently require JBossAS, don't think realistic to run as unit test for JBossRemoting > test run). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-521) Organize configuration of client side socket/server socket factories and server side socket/server socket factories.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-521?page=all ] Ron Sigal closed JBREM-521. --------------------------- Resolution: Done Upon further consideration, it seems that socket factory and server socket factory configuration on the client side is already sufficiently flexible. The following options are available: For SocketFactory's, there are seven means of configuration: 1) Call Client.setSocketFactory(). 2) Get the ClientInvoker from the Client and call ClientInvoker.setSocketFactory(). 3) Put a constructed SocketFactory in a configuration Map, using key Remoting.CUSTOM_SOCKET_FACTORY (actual value "customSocketFactory", and pass the Map to one of the Client constructors. 4) Put the class name of a SocketFactory in a configuration Map, using key Remoting.SOCKET_FACTORY_NAME (actual value "socketFactory", and pass the Map to one of the Client constructors. In this case, an instance of the class will be created using the default constructor. 5) Put a set of SSL parameters, using the keys in org.jboss.remoting.security.SSLSocketBuilder, in a configuration Map and pass the Map to one of the Client constructors. These will be used by SSLSocketBuilder to create a CustomSSLSocketFactory. 6) Configure an appropriate set of SSL system properties and use one of the SSL transports (https, sslbisocket, sslrmi, or sslsocket). The properties will be used to create a default SSLSocketFactory. 7) Use one of the non-SSL transports and do nothing. A default SocketFactory will be constructed. These methods are essentially in descending order of precedence. Methods 1) and 2) have equal precedence, and the last one to be used prior to calling Client.connect() will determine the SocketFactory that gets used. Otherwise, if methods 3) and 6), for example, are both used, the factory passed in method 3) will prevail. For ServerSocketFactory's used by callback Connectors, there are also seven means of configuration, though the list is somewhat different in this case: 1) Put a constructed ServerSocketFactory in a configuration Map, using key Remoting.CUSTOM_SERVER_SOCKET_FACTORY (actual value "customServerSocketFactory", and pass the Map to one of the Client constructors. 2) Pur the classname of a ServerSocketFactory in a metadata map, using key ServerInvoker.SERVER_SOCKET_FACTORY (actual value "serverSocketFactory") and pass the map to Client.addListener(). In this case, an instance of the class will be created using the default constructor. 3) Pur the classname of a ServerSocketFactory in a configuration map, using key ServerInvoker.SERVER_SOCKET_FACTORY (actual value "serverSocketFactory") and pass the map to one of the Client constructors. In this case, an instance of the class will be created using the default constructor. 4) Put a set of SSL parameters, using the keys in org.jboss.remoting.security.SSLSocketBuilder, in a metadata Map and pass the Map to Client.addListener(). These will be used by SSLSocketBuilder to create a CustomSSLServerSocketFactory. 5) Put a set of SSL parameters, using the keys in org.jboss.remoting.security.SSLSocketBuilder, in a configuration Map and pass the Map to one of the Client constructors. These will be used by SSLSocketBuilder to create a CustomSSLSocketFactory. 6) Configure an appropriate set of SSL system properties and use one of the SSL transports (https, sslbisocket, sslrmi, or sslsocket). The properties will be used to create a default SSLServerSocketFactory. 7) Use one of the non-SSL transports and do nothing. A default ServerSocketFactory will be constructed.. Again, these are in descending order of precedence. > Organize configuration of client side socket/server socket factories and server side socket/server socket factories. > -------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-521 > URL: http://jira.jboss.com/jira/browse/JBREM-521 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.CR1 (Pinto) > > > JBREM-520 concerns organizing configuration of socket factories and sever socket factories in the context of a Connector. This issue concerns the more general problem of organizing the configuration of factories in the contexts of both Clients and Connectors. There are two aspects of configuration through the Client: > 1) configuration of socket factories used by client invokers, and > 2) configuration of server socket factories used by server invokers in callback Connectors created by calls to Client.addListener(). > and these need to be aligned with the two aspects of configuration through the Connector: > 1) configuration of server socket factories used by server invokers, and > 2) configuration of socket factories used by callback client invokers created on the server side in response to calls to Client.addListener(). > For example, there should be a Client.setServerInvoker() method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1926) Event loop detection

by Julien Viet (JIRA)

Event loop detection -------------------- Key: JBPORTAL-1926 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1926 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Portlet Reporter: Julien Viet Assigned To: Julien Viet Fix For: Portlet-2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1297) NPE in InvalidationInterceptor.getNodeVersion()

by Brian Stansberry (JIRA)

NPE in InvalidationInterceptor.getNodeVersion() ----------------------------------------------- Key: JBCACHE-1297 URL: http://jira.jboss.com/jira/browse/JBCACHE-1297 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.1.0.CR4 InvalidationInterceptor throws an NPE in getNodeVersion() if there is no node for a particular Fqn in the workspace. See forum thread for details. This breaks the Hibernate/JBC integration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4389) nestedjarXXXX.temp files remain in the User's Temp directory on Windows after AS shutdown.

by Mark Spritzler (JIRA)

nestedjarXXXX.temp files remain in the User's Temp directory on Windows after AS shutdown. ------------------------------------------------------------------------------------------ Key: JBAS-4389 URL: http://jira.jboss.com/jira/browse/JBAS-4389 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Mark Spritzler When you startup the App Server some temp jar files are created in "C:\Documents and Settings\Username\Local Settings\Temp" directory. After you shutdown the App Server, a lot of them are deleted, but not all of them. After restarting the server many times those files that remain are all still there, causing your hard drive to run out of space. I had had 15 gigs used up by these remaining files. Here are the statistics of restarting the server about 4 times after cleaning everything out of the Temp folder before the first startup. Start 386 Files 73.5 MB Shutdown 224 Files 33.7 Megabytes Second start 546 Files 97.6 MB Second Shutdown 576 Files 86.9 MB Third start // This tells me I didn't refresh(F5) Windows Explorer to get all the new files. 576 Files 86.9 MB Third Shutdown 1024 Files 154 MB Fourth start 1410 Files 228 MB Fourth Shutdown 1280 Files 193 MB Format of files remaining in temp nestedjarNNNN.temp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAS-5248) Multiple components are seen for DefaultDS, type=("DataSource", "LocalTx")

by Scott M Stark (JIRA)

Multiple components are seen for DefaultDS, type=("DataSource", "LocalTx") -------------------------------------------------------------------------- Key: JBAS-5248 URL: http://jira.jboss.com/jira/browse/JBAS-5248 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JCA service, Management services, ProfileService Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.CR1 If one queries for the ManagedComponents of type ("DataSource", "LocalTx") with name DefaultDS, multiple ManagedComponent are returned. These correspond to the runtime ManagedObjects associated with the DefaultDS management view. These should be combined into a single ManagedComponent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5247) testDefaultDSStats fails to see non-null values

by Scott M Stark (JIRA)

testDefaultDSStats fails to see non-null values ----------------------------------------------- Key: JBAS-5247 URL: http://jira.jboss.com/jira/browse/JBAS-5247 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Management services, ProfileService Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Scott M Stark Assigned To: Scott M Stark The ProfileServiceUnitTestCase.testDefaultDSStats has been updated to validate that the stats seen from the DefaultDS are in fact non-null. Currently this is failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2008