December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-436) Port [JBBUILD-428 - Add support for ThreadLocal.remove()] to JBossRetro1.0.0.GA

by Magesh Kumar B (JIRA)

Port [JBBUILD-428 - Add support for ThreadLocal.remove()] to JBossRetro1.0.0.GA ------------------------------------------------------------------------------- Key: JBBUILD-436 URL: http://jira.jboss.com/jira/browse/JBBUILD-436 Project: JBoss Build System Issue Type: Support Patch Components: JBossRetro Environment: JBoss4.0.4 + JBossWS1.2.1.GA + JBWS-1860 + JDK1.4 Reporter: Magesh Kumar B Assigned To: Magesh Kumar B If we use the combination above it throws exception: java.lang.NoClassDefFoundError: org/jboss/lang/ThreadLocalRedirects at org.jboss.ws.core.utils.ThreadLocalAssociation.clear(ThreadLocalAssociation.java:74) at org.jboss.ws.core.server.ServiceEndpointManager.processRequest(ServiceEndpointManager.java:493) at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(AbstractServiceEndpointServlet.java:114) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(AbstractServiceEndpointServlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:534) -- 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

1
4
0 / 0

[JBoss JIRA] Updated: (JBAS-1435) JCA Interceptors

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1435?page=all ] Dimitris Andreadis updated JBAS-1435: ------------------------------------- Comment: was deleted > JCA Interceptors > ---------------- > > Key: JBAS-1435 > URL: http://jira.jboss.com/jira/browse/JBAS-1435 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Priority: Minor > Fix For: JBossAS-5.0.1.CR1 > > > Forums discussion thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48683 > This is really a major rewrite of the JCA implementation to be less monolithic > so this will need some careful design and consideration and > breaking up into more fine grained tasks. > The idea is to provide containers/interceptors for the components within the JCA module > such that these components can be more easily customised and developed according to > the needs of each user. > There are three main interceptor stacks that I can think of: > 1) ConnectionManager (connection allocation) > This provides an interceptor stack behind the ConnectionFactory/DataSource proxy > to process the allocateConnection invocation. > It will look something like: > ConnectionFactory proxy -> ConnectionManager interceptor -> Pooling interceptor > 2) ManagedConnection/ConnectionEventListener (connection management) > This stack provides most of the features that are currently performed by the > BaseManagerConnection2$ConnectionListener and their supporting methods, > but as an interceptor stack. > As now they will largely be driven by the events from the resource adapter, > and it this object that is actually pooled. > 3) Resource Adaptors > The JDBC and JMS adaptors should be implemented as interceptor stacks > to allow optional interceptors like statistics collection, custom behaviour > and also to perform vendor specific processing/workarounds. > Where AOP can be used, we could actually instrument the vendor classes so > we can also expose vendor specific methods, not just the JDBC interfaces. > This would remove the requirement to do things like getUnderlyingConection() by user code. -- 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

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-1435) JCA Interceptors

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1435?page=all ] Dimitris Andreadis reassigned JBAS-1435: ---------------------------------------- Assignee: (was: Shelly McGowan) Unassign from Shelly. > JCA Interceptors > ---------------- > > Key: JBAS-1435 > URL: http://jira.jboss.com/jira/browse/JBAS-1435 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Priority: Minor > Fix For: JBossAS-5.0.1.CR1 > > > Forums discussion thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48683 > This is really a major rewrite of the JCA implementation to be less monolithic > so this will need some careful design and consideration and > breaking up into more fine grained tasks. > The idea is to provide containers/interceptors for the components within the JCA module > such that these components can be more easily customised and developed according to > the needs of each user. > There are three main interceptor stacks that I can think of: > 1) ConnectionManager (connection allocation) > This provides an interceptor stack behind the ConnectionFactory/DataSource proxy > to process the allocateConnection invocation. > It will look something like: > ConnectionFactory proxy -> ConnectionManager interceptor -> Pooling interceptor > 2) ManagedConnection/ConnectionEventListener (connection management) > This stack provides most of the features that are currently performed by the > BaseManagerConnection2$ConnectionListener and their supporting methods, > but as an interceptor stack. > As now they will largely be driven by the events from the resource adapter, > and it this object that is actually pooled. > 3) Resource Adaptors > The JDBC and JMS adaptors should be implemented as interceptor stacks > to allow optional interceptors like statistics collection, custom behaviour > and also to perform vendor specific processing/workarounds. > Where AOP can be used, we could actually instrument the vendor classes so > we can also expose vendor specific methods, not just the JDBC interfaces. > This would remove the requirement to do things like getUnderlyingConection() by user code. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5032) Create a Release for new EJB3 Artifact: ejb3-impl

by Andrew Lee Rubinger (JIRA)

Create a Release for new EJB3 Artifact: ejb3-impl ------------------------------------------------- Key: JBAS-5032 URL: http://jira.jboss.com/jira/browse/JBAS-5032 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Priority: Blocker Fix For: JBossAS-5.0.0.Beta3 -- 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: (JBAS-4990) Use a tagged release for the new jboss-ejb3-ext-api module

by Dimitris Andreadis (JIRA)

Use a tagged release for the new jboss-ejb3-ext-api module ---------------------------------------------------------- Key: JBAS-4990 URL: http://jira.jboss.com/jira/browse/JBAS-4990 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB3 Reporter: Dimitris Andreadis Assigned To: Carlo de Wolf Priority: Critical Fix For: JBossAS-5.0.0.Beta3 Please use a proper version suffix this time (BetaN). -- 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
6
0 / 0

[JBoss JIRA] Updated: (JBAS-3151) Convert HA-JNDI stubs to Remoting

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3151?page=all ] Dimitris Andreadis updated JBAS-3151: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta3) Pushing to CR1 > Convert HA-JNDI stubs to Remoting > --------------------------------- > > Key: JBAS-3151 > URL: http://jira.jboss.com/jira/browse/JBAS-3151 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering, Naming, Remoting > Reporter: Brian Stansberry > Assigned To: Ron Sigal > Fix For: JBossAS-5.0.0.CR1 > > > The HA-JNDI naming service proxy is based on the old HARMIClient and HARMIServer code. We should convert this to use Remoting. -- 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

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-471) Handle JGroups MERGE

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-471?page=comments#action_12390431 ] Manik Surtani commented on JBCACHE-471: --------------------------------------- Decided to provide a policy based approach here. When we get a JGroups notification of a merge, provide plugins that allow for: 1) Evict entire cluster state (useful with Hibernate) 2) Evict cache state of the losing sub-cluster 3) Throw exception, stop cache (useful if we need to force some manual cleanup) 4) Perform merging of disjointed subtrees. (Maybe later - this "plugin" could be released in future) > Handle JGroups MERGE > -------------------- > > Key: JBCACHE-471 > URL: http://jira.jboss.com/jira/browse/JBCACHE-471 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Fix For: 2.2.0.GA > > > When JGroups needs to do a merge due to a temporary break in the group structure, JGroups does not handle the merging of data. This is usually left up to the application to handle. > JBossCache should support pluggable merge policies, we could provide some simple merge policies and allow users to write their own. > 1. Evict on merge policy - when a merge occurs, evict the entire in-memory state. Useful for Hibernate or when used with a shared cache loader. > 2. Other merge algos ... ? -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4980) Calling a message endpoint twice from different transactions makes MessageInflowLocalProxy confuse the two transactions

by Marcus Nilsson (JIRA)

Calling a message endpoint twice from different transactions makes MessageInflowLocalProxy confuse the two transactions ----------------------------------------------------------------------------------------------------------------------- Key: JBAS-4980 URL: http://jira.jboss.com/jira/browse/JBAS-4980 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.0.GA Reporter: Marcus Nilsson Assigned To: Carlo de Wolf We have a resource adapter where we call an endpoint (a MessageInflowLocalProxy) twice from two different transactions. This caused the endpoint to fail in endTransaction with Current transaction TransactionImple < ac, BasicAction: -3f57fcde:b392:473d5904:ab status: ActionStatus.RUNNING > is not the expected transaction We tracked this problem down to the member variable "transaction" in MessageInflowLocalProxy.java, which is not set to null in endTransaction. When the endpoint is called again during a transaction, startTransaction will leave it alone, making transaction point to the old one. http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_2_0_GA/ejb3/src/main/... Suggested fix: Set transaction=null at end of transaction -- 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

[JBoss JIRA] Created: (JBPORTAL-1834) Entering registration information is confusing

by Chris Laprun (JIRA)

Entering registration information is confusing ---------------------------------------------- Key: JBPORTAL-1834 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1834 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Chris Laprun Assigned To: Chris Laprun -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5021) org.jboss.test.jca.test.XADSUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.jca.test.XADSUnitTestCase ---------------------------------------- Key: JBAS-5021 URL: http://jira.jboss.com/jira/browse/JBAS-5021 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Shelly McGowan Assigned To: Shelly McGowan -- 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

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007