[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
18 years
[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
18 years
[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
18 years
[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
18 years