November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1113) Confusion over queues deployed in ejb3 testsuite

by Adrian Brock (JIRA)

Confusion over queues deployed in ejb3 testsuite ------------------------------------------------ Key: EJBTHREE-1113 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1113 Project: EJB 3.0 Issue Type: Bug Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: AS 5.0.0.Beta3 The queues getting deployed in ejb3 testsuite are indeterminate because both the invalidtxmdb test and the plain mdb test define an mdbtest-service.xml Which gets deployed is random. -- 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

17 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1112) Strange behaviour in Bank test

by Adrian Brock (JIRA)

Strange behaviour in Bank test ------------------------------ Key: EJBTHREE-1112 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1112 Project: EJB 3.0 Issue Type: Sub-task Affects Versions: AS 5.0.0.Beta3 Reporter: Adrian Brock Related to parent task, if you rebuild bank.jar such that BankBean doesn't implement its remote interface and restart the server, the interceptors bank test passes anyway. It shouldn't since it is not using a business method. Subsequent re-runs of the test fail as expected. -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (HIBERNATE-74) Add support for ON DELETE RESTRICT | CASCADE | SET TO NULL for Java entity generation

by sstrenn (JIRA)

Add support for ON DELETE RESTRICT | CASCADE | SET TO NULL for Java entity generation ------------------------------------------------------------------------------------- Key: HIBERNATE-74 URL: http://jira.jboss.com/jira/browse/HIBERNATE-74 Project: Hibernate Issue Type: Feature Request Reporter: sstrenn Assigned To: Steve Ebersole It appears that the Java entities that correspond to tables with foreign keys in them always result in a @OneToMany annotation with a cascade type of ALL, even when the foreign key has a constraint of ON DELETE RESTRICT. This can cause confusion for developers, since, in most other aspects, the Java entities mirror the database behavior. So this request is to add support for ON DELETE RESTRICT | CASCADE | SET TO NULL for Java entity generation. As an example of the cascade type for a foreign key that has a ON DELETE RESTRICT constraint, perhaps the annotation would be: @OneToMany(cascade = {CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH}, ...) -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails

by Martin Vecera (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2235?page=all ] Martin Vecera updated JBAS-2235: -------------------------------- JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104862 Added forum reference. Unfortunatelly the forum limits the length of the thread title :-( > Server Controller Tasks: Throw error if normal shutdown fails > ------------------------------------------------------------- > > Key: JBAS-2235 > URL: http://jira.jboss.com/jira/browse/JBAS-2235 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Environment: jboss-4.0 tip > Reporter: Ryan Campbell > Assigned To: Martin Vecera > Fix For: JBossAS-5.0.0.Beta3 > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue. > There should be an error thrown if the server fails to shutdown within the timeout period. -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4269) NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK

by Darran Lofthouse (JIRA)

NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK ---------------------------------------------------------------------------- Key: JBAS-4269 URL: http://jira.jboss.com/jira/browse/JBAS-4269 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.0.4.GA, JBossAS-5.0.0.Beta1 Environment: IBM JDK 1.5 32bit and 64bit IBM JDK 1.4 64bit Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.0.GA, JBossAS-4.0.5.SP1 Using the IBM JDKs listed in the environment, performing a remote lookup of a dynamic proxy from within JBoss cases a NoClassDefFoundError. java.lang.NoClassDefFoundError: $Proxy59 at sun.reflect.GeneratedSerializationConstructorAccessor49.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Constructor.java:521) at java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:951) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:354) at java.rmi.MarshalledObject.get(MarshalledObject.java:163) at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) at javax.naming.InitialContext.lookup(InitialContext.java:363) -- 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

17 years, 1 month

3
6
0 / 0

[JBoss JIRA] Updated: (JBAS-2563) Cleanup the build for jboss5

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2563?page=all ] Dimitris Andreadis updated JBAS-2563: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta3) > Cleanup the build for jboss5 > ---------------------------- > > Key: JBAS-2563 > URL: http://jira.jboss.com/jira/browse/JBAS-2563 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-5.0.0.CR1 > > > The current jboss-head build seems rather crusty with outdated modules (media which I removed) and weird modules like jbossas. From the dev list: > This is the remoting/jbossas integration code. > i.e. the UnifiedInvoker > It shouldn't really be in jbossas which was meant to be the top level build folder replacement for "build" > e.g. in the new build > cvs .. co jbossas > cd jbossas > ant rebuild > would pull down all modules and thirdparty and build the release. > Instead jbossas has turned into another "varia" ;-) > On Tue, 2005-12-13 at 03:00, Scott M Stark wrote: > > Why is there this jbossas module in jboss-head when there is also > > remoting being pulled via the thirdparty? > > > We need a plan on cleaning up the jboss-head build using the jbossbuild before creating a jboss5 branch. -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1184) Get rid of repeated DEBUG logging by eviction layer

by Brian Stansberry (JIRA)

Get rid of repeated DEBUG logging by eviction layer --------------------------------------------------- Key: JBCACHE-1184 URL: http://jira.jboss.com/jira/browse/JBCACHE-1184 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Eviction Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.1.0.GA 2007-09-14 15:17:16,454 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] process(): region: / 2007-09-14 15:17:16,454 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] processed 0 node events in region: / 2007-09-14 15:17:16,454 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Recycle queue is empty 2007-09-14 15:17:19,798 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] process(): region: / 2007-09-14 15:17:19,798 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] processed 0 node events in region: / 2007-09-14 15:17:19,798 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Recycle queue is empty 2007-09-14 15:17:21,454 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] process(): region: / 2007-09-14 15:17:21,454 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] processed 0 node events in region: / 2007-09-14 15:17:21,454 DEBUG [org.jboss.cache.eviction.BaseEvictionAlgorithm] Recycle queue is empty Drives me insane when I'm trying to monitor AS logs to debug issues. Needs to be TRACE. -- 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

17 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1185) Reduce logging level when a lifecycle operation is performed twice

by Brian Stansberry (JIRA)

Reduce logging level when a lifecycle operation is performed twice ------------------------------------------------------------------ Key: JBCACHE-1185 URL: http://jira.jboss.com/jira/browse/JBCACHE-1185 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.1.0.GA We log a WARN when, for example, stop() is invoked when the cache is already stopped. But this can happen easily (and validly) when the JMX wrappers are used with the microcontainer. MC stops the Cache and then the wrapper is stopped, which calls through to the Cache. This kind of thing is normal and we handle it properly, so we shouldn't log a warn. Perhaps having the wrappers test the cache status before invoking on it would be better; that way we can still warn in other situations. -- 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

17 years, 1 month

1
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-486) Optimize activations

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-486?page=all ] Manik Surtani updated JBCACHE-486: ---------------------------------- Fix Version/s: 2.2.0.GA (was: 2.1.0.GA) > Optimize activations > -------------------- > > Key: JBCACHE-486 > URL: http://jira.jboss.com/jira/browse/JBCACHE-486 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Jerry Gauthier > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.2.0.GA > > > JBCACHE-420 notes that activation processing is performed excessively. The resolution of JBCACHE-420 eliminates the excessive activations but it doesn't resolve the following optimization issue. > The ActivationInterceptor can't readily determine whether a node has been passivated because the cache loading operation occurs in the CacheLoaderInterceptor. Consequently the activation interceptor invokes loader.exists(node) to ascertain whether the node has been passivated. This works properly but is an unnecessary operation as the CacheLoader interceptor executes immediately prior to the Activation interceptor and it makes a similar determination. This determination can be expensive as itmay involve performing database operations (e.g., for a JDBC cache loader). > It's desirable to eliminate the loader.exists(node) invocation in the Activation interceptor to optimize performance. One possible way to accomplish this would be to add a pesudo attribute __PASSIVATED__ > to the node's hashmap (similar to __INITIALIZED__) whenever a node has been passivated, and remove it again when > activated. -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (GPD-185) CLONE -Exception in New Page Flow wizard

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-185?page=all ] Koen Aers updated GPD-185: -------------------------- Component/s: jpdl > CLONE -Exception in New Page Flow wizard > ---------------------------------------- > > Key: GPD-185 > URL: http://jira.jboss.com/jira/browse/GPD-185 > Project: JBoss jBPM GPD > Issue Type: Bug > Components: jpdl > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.1.0.SP1 > > > EXECUTE: Invoke 'New Page Flow' wizard. > EXECUTE: Click 'Browse...' button. > EXECUTE: Click 'Cancel' in 'Folder Selection' dialog. > FAILURE: Log contains exception java.lang.IllegalArgumentException: Argument cannot be null. -- 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

17 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007