January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1275) Better logging in case of rollback

by Sebastien Pennec (JIRA)

Better logging in case of rollback ---------------------------------- Key: JBCACHE-1275 URL: http://jira.jboss.com/jira/browse/JBCACHE-1275 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 2.0.0.GA Environment: Weblogic 9, Clustered application, JBossCache 2.0.0 Reporter: Sebastien Pennec Assigned To: Manik Surtani If JBosse Cache tries to rollback a transaction but cannot do it, the error that would have triggered the rollback is not logged. See forum thread for more information. -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-5138) Upgrade to a non-snapshot Microcontainer release (2.0.0.Beta10)

by Dimitris Andreadis (JIRA)

Upgrade to a non-snapshot Microcontainer release (2.0.0.Beta10) --------------------------------------------------------------- Key: JBAS-5138 URL: http://jira.jboss.com/jira/browse/JBAS-5138 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: MicroContainer bus Reporter: Dimitris Andreadis Assigned To: Ales Justin Fix For: JBossAS-5.0.0.Beta4 Upgrade to a non-snaphost release for AS5 Beta4. It would be good to update the Microcontainer JIRA with Beta10 tasks, as MC Beta8 and Beta9 went out undocumented. -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5141) Move out of jbossws-native50 snapshot

by Dimitris Andreadis (JIRA)

Move out of jbossws-native50 snapshot ------------------------------------- Key: JBAS-5141 URL: http://jira.jboss.com/jira/browse/JBAS-5141 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Web Services Reporter: Dimitris Andreadis Assigned To: Heiko Braun Fix For: JBossAS-5.0.0.Beta4 We need all snapshots resolved by Jan/18th. -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-232) VFSUtils.addManifestLocations does not work for nested archives

by Scott M Stark (JIRA)

VFSUtils.addManifestLocations does not work for nested archives --------------------------------------------------------------- Key: JBMICROCONT-232 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-232 Project: JBoss MicroContainer Issue Type: Bug Components: VFS Affects Versions: JBossMC-2.0.0.Beta10 Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC-2.0.0.CR1 The logic for VFSUtils.addManifestLocations is not working for wars in ears, probably all nested archives with class path manifest entries. One example in the jbossas testsuite is: org.jboss.test.web.test.ClasspathUnitTestCase 2008-01-24 16:09:03,284 DEBUG [org.jboss.virtual.VFSUtils] Manifest Class-Path entry jbosstest-web-util.jar ignored for manifest-web.war reason=java.io.IOException: Child not found il.jar for JarHandler@1842226989[path= context=file:/home/svn/JBossHead/jboss-head/testsuite/output/lib/manifest-web.ear real=file:/home/svn/JBossHead/jboss-head/testsuite/output/lib/manifest-web.ear] -- 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, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-5180) Make ClusterPartition mbean queryable

by Brian Stansberry (JIRA)

Make ClusterPartition mbean queryable ------------------------------------- Key: JBAS-5180 URL: http://jira.jboss.com/jira/browse/JBAS-5180 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta4 >From Greg Hinkle: "One thing i will suggest for the future (i've been telling everyone this) is to make the mbeans queryable. "jboss:service={PartitionName}" is not queryable since i need to know what the partition name is to find the bean... and i'll probably be looking for the bean to determine the name. Also, what happens if I name my partition "Mail"? A better idea would be "jboss:type=ClusterPartition,name={PartitionName}" or something similar." I'll register the mbean as "jboss:service=HAPartition,partition=${jboss.partition.name:DefaultPartition}" -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5181) Inject MBeanServer into JChannelFactory

by Brian Stansberry (JIRA)

Inject MBeanServer into JChannelFactory --------------------------------------- Key: JBAS-5181 URL: http://jira.jboss.com/jira/browse/JBAS-5181 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta4 JChannelFactory needs a ref to the MBeanServer so it can register channels and protocols in JMX. It used to havesemi-hacky code to try and find the server; that's been removed in favor of dependency injection. So, we need to inject the mbean server. -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ] Ron Sigal closed JBREM-480. --------------------------- Resolution: Out of Date Assignee: Ron Sigal This issue is out of date. 1. The "open connection checking" facility introduced for JBREM-690 gives a connection checking facility that does not depend on Socket.isConnected(). 2. There are now explicit tests in place, on both the client and server side, that treat a version of -1 as an end of file condition. > Insure reliable tests in socket invoker for unusable socket connections. > ------------------------------------------------------------------------ > > Key: JBREM-480 > URL: http://jira.jboss.com/jira/browse/JBREM-480 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto) > > > The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set. > The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1. > On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1. > In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4762) Make distributable webapps depend on the clustering cache

by Brian Stansberry (JIRA)

Make distributable webapps depend on the clustering cache --------------------------------------------------------- Key: JBAS-4762 URL: http://jira.jboss.com/jira/browse/JBAS-4762 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 In 4.x, in the all config the JBossWeb service itself depends on the jboss.cache:service=TomcatClusteringCache mbean. In AS 5 this is not viable, as the relevant bean is the TomcatDeployer, which can't/shouldn't depend on a deploy folder service like the cache. In any case, it's really the <distributable/> webapps that depend on the cache, not the deployer. The TomcatDeployer should be adding a dependency on the cache to deployments where WebMetaData.getDistributable() is true (probably in superclass AbstractWarDeployer.deployWebModule()). A problem with this dependency-based approach is it breaks the current "feature" whereby apps marked <distributable/> can be deployed in the default config. When this is done, the 4.x deployment code detects the absence of the cache and falls back on using the standard non-distributable session manager. That won't work if we introduce a deployment dependency. -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-798) Implement quick Client.removeListener() for polled callbacks, part 2

by Ron Sigal (JIRA)

Implement quick Client.removeListener() for polled callbacks, part 2 -------------------------------------------------------------------- Key: JBREM-798 URL: http://jira.jboss.com/jira/browse/JBREM-798 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) This issue is a continuation of JBREM-757. There are two additions: 1. The unit tests org.jboss.test.remoting.transport.http.timeout.HttpQuickDisconnectTestCase and org.jboss.test.remoting.transport.socket.timeout.SocketQuickDisconnectTestCase did not properly test the the quick version of org.jboss.remoting.Client.removeListener() in the case of polled callbacks. 2. The facility should be tested for the RMI transport when per invocation timeouts are implemented for that transport. (See JBREM-701.) -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] Closed: (JBREM-364) refactor client invoker config for common configurations

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-364?page=all ] Ron Sigal closed JBREM-364. --------------------------- Resolution: Won't Fix Assignee: (was: Tom Elrod) > refactor client invoker config for common configurations > -------------------------------------------------------- > > Key: JBREM-364 > URL: http://jira.jboss.com/jira/browse/JBREM-364 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Fix For: 2.4.0.Beta1 (Pinto) > > > Currently client invoker implementations all do their own configuration processing. Since many share the same configuration properties, need to standardize these and handle them in the RemoteClientInvoker instead of individual implementations (i.e. SocketClientInvoker, HTTPClientInvoker, etc.). Should follow same model that has been done for ServerInvoker. -- 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, 5 months

1
0
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 January 2008