October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBWEB-84) Class Cast Exception - when using CometProcessor - Jboss 4.2.0

by Vali Dumitru (JIRA)

Class Cast Exception - when using CometProcessor - Jboss 4.2.0 -------------------------------------------------------------- Key: JBWEB-84 URL: http://jira.jboss.com/jira/browse/JBWEB-84 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows Reporter: Vali Dumitru Assigned To: Mladen Turk I have a servlet that implements CometProcessor interface. Whenever I try to access it I get : java.lang.ClassCastException: org.jboss.web.tomcat.filters.ReplyHeaderFilter at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:398) at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:701) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2031) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) What is this? Is there a workaround? -- 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

16 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4773) Move the JBossWS integration tests to the AS test module

by Heiko Braun (JIRA)

Move the JBossWS integration tests to the AS test module -------------------------------------------------------- Key: JBAS-4773 URL: http://jira.jboss.com/jira/browse/JBAS-4773 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Heiko Braun Assigned To: Heiko Braun Fix For: JBossAS-4.2.3.GA The JBossWS integration test need to reside with the AS. -- 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

16 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-4508) Add a way to defined dependencies for a JCA adapter

by Georges Berscheid (JIRA)

Add a way to defined dependencies for a JCA adapter --------------------------------------------------- Key: JBAS-4508 URL: http://jira.jboss.com/jira/browse/JBAS-4508 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.0.GA Environment: Any Reporter: Georges Berscheid Currently there is no way to define that a resource adapter has a dependency on different component. Adrian has suggested to add support for a jboss-ra.xml file that let you define those dependencies (see forum entry). -- 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

16 years, 5 months

3
8
0 / 0

[JBoss JIRA] Created: (BPEL-268) provide a people task management example

by Alejandro Guizar (JIRA)

provide a people task management example ---------------------------------------- Key: BPEL-268 URL: http://jira.jboss.com/jira/browse/BPEL-268 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Documents Affects Versions: jBPM BPEL 1.1 beta 3 Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 1.1 GA Put together a simple example demonstrating how the task management facilities found in jPDL can be leveraged in BPEL. -- 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

16 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1191) Work with contributor to translate JBoss Cache documentation into Spanish

by Manik Surtani (JIRA)

Work with contributor to translate JBoss Cache documentation into Spanish ------------------------------------------------------------------------- Key: JBCACHE-1191 URL: http://jira.jboss.com/jira/browse/JBCACHE-1191 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Michael Smith Fix For: 2.2.0.GA See email sent in to the jbosscache-dev list: http://lists.jboss.org/pipermail/jbosscache-dev/2007-September/002031.html -- 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

16 years, 5 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-4382) EnterpriseContext lock counting is not synchronized

by Adrian Brock (JIRA)

EnterpriseContext lock counting is not synchronized --------------------------------------------------- Key: JBAS-4382 URL: http://jira.jboss.com/jira/browse/JBAS-4382 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Reporter: Adrian Brock Assigned To: Scott M Stark Fix For: JBossAS-4.2.0.GA The lock counting in org.jboss.ejb.EnterpriseContext is not synchronized. The lock ivar is not even volatile. This variable needs replacing with synchronized method blocks or an oswego concurrent SynchronizedInt. This bug could either cause passivation to be invoked when it shouldn't or vice versa. Additionally, even with this fix, the usage in StatefulSessionInstanceInterceptor needs replacing with something more atomic! if (!ctx.isLocked()) { //take it! ctx.lock(); } -- 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

16 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1108) Move CacheListeners to their own thread pool

by Jason T. Greene (JIRA)

Move CacheListeners to their own thread pool -------------------------------------------- Key: JBCACHE-1108 URL: http://jira.jboss.com/jira/browse/JBCACHE-1108 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assigned To: Manik Surtani Fix For: 2.0.0.CR3 User CacheListeners should be dispatched in their own thread pool to prevent reentrancy problems and delays on cache operations. Evection listeners should still be executed in the app thread. -Jason -- 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

16 years, 5 months

2
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-991) Non-JTA based mechanism for batching invocations

by Brian Stansberry (JIRA)

Non-JTA based mechanism for batching invocations ------------------------------------------------ Key: JBCACHE-991 URL: http://jira.jboss.com/jira/browse/JBCACHE-991 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Currently JBC uses the lifecycle of a JTA Transaction to scope a series of cache invocations doing things like lock release, replication and cache loader storage as part of the transaction commit. Need a mechanism to do this kind of invocation batching that doesn't depend on JTA. Needed to allow callers that don't wish their work to be associated with an active JTA transaction to still get the batching behavior JBC provides. AS web session replication is an example use case. It uses BatchModeTransactionManger to ensure its activity doesn't impact any ongoing transaction. But BatchModeTransactionManager isn't a good JTA transaction manager even though it implements the JTA interfaces. So using it is problematic; it can easily be misused by those who don't understand it's limitations (e.g. hooking it up to a JTA Datasource.) A couple of possible approaches have been discussed: 1) A new API added to Cache. Methods like startBatch(), commitBatch(), rollbackBatch(), along with some internal mechanism to timeout a batch that's been started but never committed/rolled-back. 2) Abstract away the JTA API such that JBC doesn't use JTA directly, but rather its own interfaces that largely parallel TransactionManager and Transaction. Provide an impl that simply wraps a real JTA TransactionManager. BatchModeTransactionManger would be another impl. API includes a method like 'boolean isJTACompliant()' that things like CacheLoader impls can check at startup to confirm they are working with a compatible impl (e.g. if JBDCCacheLoader is configured to use a JTA Datasource but isJTACompliant() returns false, throw an exception at startup.) Apologies if this is a duplicate issue. Thought there was something like this but couldn't find 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

16 years, 5 months

3
12
0 / 0

[JBoss JIRA] Created: (JBCACHE-841) Be able to set the internal ordering of child nodes and data keys

by Elias Ross (JIRA)

Be able to set the internal ordering of child nodes and data keys ----------------------------------------------------------------- Key: JBCACHE-841 URL: http://jira.jboss.com/jira/browse/JBCACHE-841 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani I believe that this issue is required to resolve JBCACHE-166 satisfactorily. But it would also be a useful (and easily added) feature for JBossCache 2.0. The attached .java file explains two additional methods to add. The internal implementation would likely need to rely on the JDK1.6 java.util.concurrent.ConcurrentSkipListSet and Map implementations to work without change to other code that rely on iteration to work on concurrently modified sets. As JDK 1.6 is new, this might require use of http://dcl.mathcs.emory.edu/util/backport-util-concurrent/doc/api/ for now, or support from the jbossretro to change these JDK1.6 classes to use the backport for 1.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

16 years, 5 months

3
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1060) getInvokedBusinessInterface doesn't return correct interface

by Carlo de Wolf (JIRA)

getInvokedBusinessInterface doesn't return correct interface ------------------------------------------------------------ Key: EJBTHREE-1060 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1060 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Andrew Rubinger When there is a common super interface, getInvokedBusinessInterface doesn't return the correct interface. @Stateless @Remote({Remote1.class, Remote2.class}) interface Remote1 extends CommonRemote interface Remote2 extends CommonRemote -- 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

16 years, 5 months

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007