February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5474) @PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER

by Stefan Lindner (JIRA)

@PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER -------------------------------------------------------------------------------------------------------------------- Key: JBAS-5474 URL: http://jira.jboss.com/jira/browse/JBAS-5474 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.2.GA Environment: Win XP SP2, Java 1.5.0_15-b04 Reporter: Stefan Lindner Assigned To: Carlo de Wolf Fix For: JBossAS-4.2.3.GA I have a bean with a @OneToMany relation mapping like private List<TherapieeinheitBean> therapieeinheiten; @OneToMany( cascade = {CascadeType.REFRESH}, fetch = FetchType.EAGER, mappedBy="therapiekatalog" ) with FetchType.EAGER and a simnple @PostLoad like @PostLoad public void postLoad() { System.out.println("!!!!!!!!!! postLoad !!!!!!!!!!"); System.out.print("size: " + therapieeinheiten.size()); } When an entity of this bean is loaded JBoss trows org.hibernate.LazyInitializationException: illegal access to loading collection at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:341) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:249) at de.visiodesk.therapiekatalog.TherapiekatalogBean.postLoad(TherapiekatalogBean.java:170) . . . and prints the messages WARN [LoadContexts] fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@2c8ce9<rs=Ingres-ResultSet[18523]> WARN [CollectionLoadContext] On CollectionLoadContext#cleanup, localLoadingCollectionKeys contained [206] entries afterwards. The PostLoad method should be called after the data was completely loaded. Is there a workaround for this Problem? I found some other ressources on the net where peole had the same problem, but I saw no resolution, no hint, no 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

13 years, 3 months

9
15
0 / 0

[JBoss JIRA] Created: (JBREM-1182) Update testsuite to run under Hudson

by Richard Achmatowicz (JIRA)

Update testsuite to run under Hudson -------------------------------------- Key: JBREM-1182 URL: https://jira.jboss.org/jira/browse/JBREM-1182 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.3.SP1 Reporter: Richard Achmatowicz Fix For: 2.2.3.SP2 Update the JBoss Remoting testsuite to run under Hudson. Some current problems include: (i) on Linux, JRunit based tests are failing due to members not finding each other (ii) on Linux, under JDK6, JRunit based tests are not able to create a JGroups stack (iii) JRunit system properties specified by the user on the command line are not being passed the the JUnit targets correctly, and so have no effect on the tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
25
0 / 0

[JBoss JIRA] Created: (JBAS-8771) Async log handler doesn't work

by David Lloyd (JIRA)

Async log handler doesn't work ------------------------------ Key: JBAS-8771 URL: https://issues.jboss.org/browse/JBAS-8771 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Reporter: David Lloyd Assignee: David Lloyd Fix For: 6.0.0.Final Async log handler doesn't work. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-8389) Issue in using ThreadLocal

by Arunsakthi Kalyanasundharam (JIRA)

Issue in using ThreadLocal -------------------------- Key: JBAS-8389 URL: https://jira.jboss.org/browse/JBAS-8389 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Java EE APIs Affects Versions: JBossAS-4.2.2.GA Environment: Application Server - Garbage collection Reporter: Arunsakthi Kalyanasundharam Assignee: Shelly McGowan Fix For: JBossAS-4.2.3.GA I'm using Threadlocal in a web component. By definition, threadlocal variables should be cleared by end of execution of the thread. In case Application server, since its using a thread pool, the threadlocal variables are not cleared / garbage collected. This is leading to memory leakage (out of memory errors) and inconsistent behavior of the application since the variables are not getting cleared off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-5559) Example MC configuration for JBossCache instance with JDBCCacheLoader

by Galder Zamarreno (JIRA)

Example MC configuration for JBossCache instance with JDBCCacheLoader --------------------------------------------------------------------- Key: JBAS-5559 URL: http://jira.jboss.com/jira/browse/JBAS-5559 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, JBoss Cache Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Include an example on how to configure a JBossCache instance's JDBCCacheLoader via MC. -- 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

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1290) Windows 7 might throw SocketException instead of BindException

by Manuel Dominguez Sarmiento (JIRA)

Windows 7 might throw SocketException instead of BindException -------------------------------------------------------------- Key: JGRP-1290 URL: https://issues.jboss.org/browse/JGRP-1290 Project: JGroups Issue Type: Enhancement Affects Versions: 2.12 Environment: Windows 7 Reporter: Manuel Dominguez Sarmiento Assignee: Bela Ban Priority: Minor This is not actually a JGroups bug, it's more of a Sun JVM bug. See the following: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939037 In short, when a port is in use in Windows 7, SocketException is thrown instead of the more specific BindException. JGroups has code in several places that probes for available ports. Perhaps Windows 7 should be detected, and SocketException be caught instead of BindException in these circumstances. Before anyone cries out "get a real OS", we use RHEL on our production servers, but some of our developers use Windows 7 on their development boxes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
11
0 / 0

[JBoss JIRA] Created: (JBAS-8837) Clean up the max-threads attribute in managment socket config

by Brian Stansberry (JIRA)

Clean up the max-threads attribute in managment socket config ------------------------------------------------------------- Key: JBAS-8837 URL: https://issues.jboss.org/browse/JBAS-8837 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Priority: Minor Fix For: 7.0.0.Beta1 There is a max-threads field in the dc/host/server management socket config. It's not in the schema and AFAICT it's not used. Either use it and add to the schema, or remove it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8825) Default interface for a socket binding should come via SocketBindingManagerService

by Brian Stansberry (JIRA)

Default interface for a socket binding should come via SocketBindingManagerService ---------------------------------------------------------------------------------- Key: JBAS-8825 URL: https://issues.jboss.org/browse/JBAS-8825 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Assignee: Emanuel Muckenhuber Fix For: 7.0.0.Beta1 The default interface used for socket bindings comes from an attribute on the socket-binding-group element. The XML parser tracks the value and then adds it to the operation to create a socket-binding if the <socket-binding> element doesn't declare an interface. This parser-based approach isn't sufficient as it only works for the parsing use case. Applying it elsewhere forces operations on child model resources (socket-bindings) to find out information stored in parent resources, which we want to avoid. Better IMO is to make the "interface" field on the model representation of a socket binding nullable; the parser should just pass through what the XML says. The SocketBindingManagerService should store the default interface, like it currently stores the port offset. SocketBinding.getAddress() can then ask for the default address from SocketBindingManagerService if its own networkInterface field is null. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8826) No way to apply a socket binding port offset to a standalone server

by Brian Stansberry (JIRA)

No way to apply a socket binding port offset to a standalone server ------------------------------------------------------------------- Key: JBAS-8826 URL: https://issues.jboss.org/browse/JBAS-8826 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Assignee: Emanuel Muckenhuber Fix For: 7.0.0.Beta1 There is no place to store the SocketBindingManagerService's port-offset in standalone.xml. Currently it gets passed in as a special value by the HostController, which only works in the domain mode use case. I think the most intuitive thing to do is to add a port-offset attribute to standalone-socket-binding-groupType. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8801) Undeployment leaks root deployment service

by Thomas Diesler (JIRA)

Undeployment leaks root deployment service ------------------------------------------ Key: JBAS-8801 URL: https://issues.jboss.org/browse/JBAS-8801 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler To reproduce #1 do a hot-deploy #2 do a hot-undeploy #3 use jconsole to check the installed services. you should see jboss.deployment.yourdeployment As a result redeploy fails with Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:69) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:85) ... 4 more Caused by: java.io.IOException: Filsystem already mounted at mount point ""/content/example-simple.jar"" at org.jboss.vfs.VFS.mount(VFS.java:159) at org.jboss.vfs.VFS.doMount(VFS.java:379) at org.jboss.vfs.VFS.mountZip(VFS.java:405) at org.jboss.as.server.deployment.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:78) at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:65) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2011