May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-960) CascadeType REMOVE in relationships doesn't appear to cascade anymore.

by Fritz Feuerbacher (JIRA)

CascadeType REMOVE in relationships doesn't appear to cascade anymore. ---------------------------------------------------------------------- Key: EJBTHREE-960 URL: http://jira.jboss.com/jira/browse/EJBTHREE-960 Project: EJB 3.0 Issue Type: Bug Environment: Windows XP, JBoss AS 4.0.5.GA Reporter: Fritz Feuerbacher Since I upgraded from JBoss 4.0.4.GA to 4.0.5.GA I have encountered this problem. Whenever I have an entity bean that has a relation in it I get strange behavior that I didn't have in 4.0.4.GA. Examples: Say I have an entity bean with a relation in it like: @OneToMany (mappedBy="user", cascade={cascadeType.ALL}), fetch=fetchType.EAGER) public List<UserAndRole> getUserAndRoles() { return userAndRoles; } This works fine, and will cascade in all instances except if I take an existing bean and set the list to an empty list like: userAndRoles = new ArrayList<UserAndRole>(); and then call merge on the entity bean. It appears to remove the relationship in the the bean, however, the old entries in the table are still there. In JBoss 4.0.4.GA, doing this would also remove the entries in the UserAndRoles table that corresponded to the items that were in the original userAndRoles list. Definately something has changed between the versions. I just can't figure out what. -- 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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4429) Classloader leak to JBossTS ReaperThread

by Brian Stansberry (JIRA)

Classloader leak to JBossTS ReaperThread ---------------------------------------- Key: JBAS-4429 URL: http://jira.jboss.com/jira/browse/JBAS-4429 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.2.0.GA Reporter: Brian Stansberry Assigned To: Scott M Stark ClassloaderLeakUnitTestCase is showing a classloader leak when the test does remote calls to EJB2 SLSBs. See http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-1.5?lo... JBoss Profiler analysis (see attached) shows the leak is to the JBossTS ReaperThread -- the DelegatingClassLoader for the ejb jar deployment is set as the TCCL on that thread. Oddities I observed while trying to track this down: 1) The leak doesn't occur if JMS is deployed. By mistake I changed the AS config for the test such that JBossMQ no longer gets deployed; that's when the leak appeared. The test doesn't use JMS in any way. Can only speculate that if MQ is running the TCCL on the ReaperThread gets cleared or changed somehow or never gets set to the ejb's DelegatingClassLoader. 2) The test class includes 3 different tests that basically make the same calls. The differences between the tests is just how the ejbs are packaged -- one in a plan jar, one with an ear and the plain jar, one with the ear but a loader-repository configured. Only the first of these that gets executed fails; the other two pass. I changed the order in which the tests execute, and whichever was first failed. Hence the success/failure doesn't appear to be a function of the packaging. -- 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, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1347) URLNavigator test improvements

by Julien Viet (JIRA)

URLNavigator test improvements ------------------------------ Key: JBPORTAL-1347 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1347 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet Assigned To: Matt Wringe Fix For: 2.6.CR2 -- 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, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-964) Enable all security tests

by Tim Fox (JIRA)

Enable all security tests ------------------------- Key: JBMESSAGING-964 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-964 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.2.1.CR1 Some tests in jms/SecurityTest are commented out (pre configured client ids) - they should be re-enabled. -- 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, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1355) PortletSecurityException throws ClassCastException

by Prabhat Jha (JIRA)

PortletSecurityException throws ClassCastException -------------------------------------------------- Key: JBPORTAL-1355 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1355 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.CR1 Reporter: Prabhat Jha Assigned To: Julien Viet Fix For: 2.6.CR2 PortletSecurityException test in test page throws ClassCastException. avax.servlet.ServletException org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java:406) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) root cause java.lang.ClassCastException org.jboss.portal.core.model.portal.PortalObjectResponseHandler.processCommandResponse(PortalObjectResponseHandler.java:63) org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:96) org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:70) sun.reflect.GeneratedMethodAccessor311.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) org.jboss.mx.server.Invocation.invoke(Invocation.java:88) org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) org.jboss.mx.server.Invocation.invoke(Invocation.java:88) org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) $Proxy118.processCommandResponse(Unknown Source) org.jboss.portal.core.controller.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:69) sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) org.jboss.mx.server.Invocation.invoke(Invocation.java:88) org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) org.jboss.mx.server.Invocation.invoke(Invocation.java:88) org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) $Proxy129.processCommandResponse(Unknown Source) org.jboss.portal.core.controller.Controller.processCommandResponse(Controller.java:263) org.jboss.portal.core.controller.Controller.processCommand(Controller.java:251) org.jboss.portal.core.controller.Controller.processHandlerResponse(Controller.java:286) -- 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, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-783) isPropagated calculation for event is not correct

by Olga Ivanova (JIRA)

isPropagated calculation for event is not correct ------------------------------------------------- Key: JBPM-783 URL: http://jira.jboss.com/jira/browse/JBPM-783 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.2 alpha 1 Reporter: Olga Ivanova Assigned To: Tom Baeyens As it is stated in comment inside org.jbpm.graph.def.GraphElement.fireAndPropagateEvent method // calculate if the event was fired on this element or if it was a propagated event boolean isPropagated = (this.equals(executionContext.getEventSource())); I believe code does not correspond to the intent and should look following: boolean isPropagated = !(this.equals(executionContext.getEventSource())); i.e if event source is same element that this, event is not propagated, if they are different - event is propagated. -- 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, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-713) PojoCache when it has been detached remotely, accessing it again will throw PojoCacheAlreadyDetachedException

by Ben Wang (JIRA)

PojoCache when it has been detached remotely, accessing it again will throw PojoCacheAlreadyDetachedException ------------------------------------------------------------------------------------------------------------- Key: JBCACHE-713 URL: http://jira.jboss.com/jira/browse/JBCACHE-713 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 This is the use case here: cacheA.attach(id, pojo); p = cacheB.find(id); cacheA.detach(id); p.getName(); // this will throw PojoCacheAlreadyDetachedException -- 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, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3992) Race condition in JBossManagedConnectionFactory

by Derek Lewis (JIRA)

Race condition in JBossManagedConnectionFactory ----------------------------------------------- Key: JBAS-3992 URL: http://jira.jboss.com/jira/browse/JBAS-3992 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.4.GA Environment: I'm running JBoss 4.0.4.GA on jaba 1.5.0_07-b03. I haven't tried a newer JBoss, however the code I've determined is causing the problem looks the same on 5.0.0.Beta1. Reporter: Derek Lewis Assigned To: Weston Price The problem happens when calling flush() on JBossManagedConnectionPool via the jmx-console. If a call to getConnection() is made by the application at the same time, there is a potential for getConnection() to throw a ResourceException saying "The pool has been shutdown". Thread 1: calls flush() Thread 2: calls getConnection() In Thread 1, in JBossManagedConnectionPool.flush(), after the pools are iterated through and shut down (this is synchronized on subPools). Assume that a context switch happens here, and Thread 2 runs now, with Thread 1 paused, before calling subPools.clear(). When thread 2 gets to where it calls getSubPool(...), this is not synchronized, so subPools.get(key) returns a pool which is not null though it has been shutdown), and returns it. getConnection() is then called on this pool, causing the exception to be thrown. Thread 1 then proceeds to clear the pool, so that the shutdown subpools are not returned. (But it's too late for this one case) -- 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, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-345) Mavenize JBoss Retro

by Paul Gier (JIRA)

Mavenize JBoss Retro -------------------- Key: JBBUILD-345 URL: http://jira.jboss.com/jira/browse/JBBUILD-345 Project: JBoss Build System Issue Type: Feature Request Affects Versions: MavenBuild 1.2 Reporter: Paul Gier The builds of JBoss Retro should be converted to maven. -- 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, 1 month

1
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-333) Implement translation of generic types

by Kabir Khan (JIRA)

Implement translation of generic types -------------------------------------- Key: JBBUILD-333 URL: http://jira.jboss.com/jira/browse/JBBUILD-333 Project: JBoss Build System Issue Type: Task Components: JBossRetro Affects Versions: JBossRetro-1.0.4.GA Reporter: Kabir Khan This causes jdk14 test failures in the retroed container project (and so in retroed aop which depends on container) Things like Class.getGenericInterfaces() Class.getGenericSuperClass() Field.getGenericType() Method/Constructor.getGenericExceptionTypes() Method/Constructor.getGenericParameterTypes() Method/Constructor.getTypeParameters() need to be moved into a GenericTypeRedirects or something. -- 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, 1 month

4
5
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 May 2007