February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4050) Restore the org.jboss.web.tomcat.tc5.session FIELD granularity marker interfaces

by Brian Stansberry (JIRA)

Restore the org.jboss.web.tomcat.tc5.session FIELD granularity marker interfaces -------------------------------------------------------------------------------- Key: JBAS-4050 URL: http://jira.jboss.com/jira/browse/JBAS-4050 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-4.2.0.CR1 With the move the Tomcat 6, the o.j.w.t.tc5 packages were removed. Need to restore AopMarker and InstanceOfAopMarker so 4.0.x FIELD granularity apps that use them will still work. Mark them as deprecated, for removal in the next minor version. They won't be in AS 5. -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-966) Include the JDK 1.4 PojoCache marker interfaces in the jboss-cache-jdk50.jar

by Brian Stansberry (JIRA)

Include the JDK 1.4 PojoCache marker interfaces in the jboss-cache-jdk50.jar ---------------------------------------------------------------------------- Key: JBCACHE-966 URL: http://jira.jboss.com/jira/browse/JBCACHE-966 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.1.GA, 1.4.0.SP1, 1.4.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 1.4.1.SP1 The build.xml excludes the org.jboss.cache.aop.(InstanceOf)AopMarker interfaces from the jboss-cache-jdk50.jar. This means there is no jar that the AS (or others) can integrate and provide support for both the JDK 1.4 and JDK 5 methods of marking classes for PojoCache use. I see no reason for the exclusion, so I've removed it. -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4013) Add ability to use multiplexer to ClusterPartition

by Brian Stansberry (JIRA)

Add ability to use multiplexer to ClusterPartition -------------------------------------------------- Key: JBAS-4013 URL: http://jira.jboss.com/jira/browse/JBAS-4013 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.2.0.CR1 Inject the JChannelFactoryMBean and a stack name; if present use them to construct the channel. Even if we do not deploy the multiplexer in 4.2.0, we want these hooks to leave a path for upgrading. -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JBAS-2731) JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2731?page=all ] Scott M Stark resolved JBAS-2731. --------------------------------- Resolution: Done The base class has been updated. > JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory > ------------------------------------------------------------------------------------ > > Key: JBAS-2731 > URL: http://jira.jboss.com/jira/browse/JBAS-2731 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Arto Huusko > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > org.jboss.security.jndi.JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory. This leads to problems with, for example, UserTransaction lookups (see JBAS-1270). > Changing the class to extend org.jboss.naming.NamingContextFactory makes it work properly. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-2865) Move org.jboss.naming package from server module to naming module

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2865?page=all ] Scott M Stark resolved JBAS-2865. --------------------------------- Resolution: Done The core jndi classes have been moved to the naming project. > Move org.jboss.naming package from server module to naming module > ----------------------------------------------------------------- > > Key: JBAS-2865 > URL: http://jira.jboss.com/jira/browse/JBAS-2865 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.1.CR1 > > > The existence of the org.jboss.naming classes in the server module are another point for broken module dependencies. There are InitialContextFactory implementations in the security module that should subclass org.jboss.naming implementations (JBAS-2731 for example) but cannot due to server depending on security. Only naming integration services should exist in the server module. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-631) Fix org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase and SocketConnectionTestCase failures.

by Ron Sigal (JIRA)

Fix org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase and SocketConnectionTestCase failures. ----------------------------------------------------------------------------------------------------------------------------- Key: JBREM-631 URL: http://jira.jboss.com/jira/browse/JBREM-631 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) These tests have been getting about 75% done and then failing. Looks like the System.out.println() in the loop might be causing junit to run out of heap space. -- 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

19 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-623) need reset() call added back to JavaSerializationManager.sendObject() method

by Tom Elrod (JIRA)

need reset() call added back to JavaSerializationManager.sendObject() method ---------------------------------------------------------------------------- Key: JBREM-623 URL: http://jira.jboss.com/jira/browse/JBREM-623 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.0.Alpha3 (Bluto) Reporter: Tom Elrod Assigned To: Ron Sigal Priority: Critical Fix For: 2.2.0.Beta1 (Bluto) Per JBREM-597, code was changed within JavaSerializationManager.sendObject() to not call reset() on the ObjectOutputStream as would cause an error (see below). Although this solution works, it is not optimal as need the reset() to be called to release the references kept internally to the object stream (otherwise could potentially run out of memory if are sending a lot of different object types). Error when reset() method is called: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.io.IOException: Can not read data for version 121. Supported versions: 1, 2 at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:408) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125) at org.jboss.remoting.Client.invoke(Client.java:605) at org.jboss.remoting.Client.invoke(Client.java:597) at org.jboss.remoting.Client.invoke(Client.java:582) at org.jboss.test.remoting.transport.socket.connection.SocketTestClient.testInvocations(SocketTestClient.java:74) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: java.io.IOException: Can not read data for version 121. Supported versions: 1, 2 at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:503) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:370) ... 28 more Test case: org.jboss.test.remoting.transport.socket.connection.SocketConnectionTestCase & org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-287) RemotingTest.testConnectionListener() invalid

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ] Ovidiu Feodorov updated JBMESSAGING-287: ---------------------------------------- Assignee: (was: Juha Lindfors) > RemotingTest.testConnectionListener() invalid > --------------------------------------------- > > Key: JBMESSAGING-287 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287 > Project: JBoss Messaging > Issue Type: Bug > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Priority: Minor > Fix For: 1.0.3.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. > After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ] Ovidiu Feodorov reassigned JBMESSAGING-407: ------------------------------------------- Assignee: Ovidiu Feodorov (was: Juha Lindfors) > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Assigned To: Ovidiu Feodorov > Priority: Blocker > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Time Spent: 1 week, 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ] Ovidiu Feodorov reassigned JBMESSAGING-407: ------------------------------------------- Assignee: (was: Ovidiu Feodorov) > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Priority: Blocker > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Time Spent: 1 week, 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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

19 years, 3 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 February 2007