[JBoss JIRA] Created: (JBJCA-484) make *.sh execute permission on in release package
by Jeff Zhang (JIRA)
make *.sh execute permission on in release package
--------------------------------------------------
Key: JBJCA-484
URL: https://issues.jboss.org/browse/JBJCA-484
Project: IronJacamar
Issue Type: Task
Components: Build
Affects Versions: 1.0.0.Beta3
Reporter: Jeff Zhang
Assignee: Jeff Zhang
svn/jbossas/projects/jboss-jca/trunk/build/ironjacamar-1.0.0.Beta4$ find . -name *sh | xargs ls -l
-rw-r--r-- 1 jizhang jizhang 1562 2010-12-29 11:23 ./bin/run.sh
-rw-r--r-- 1 jizhang jizhang 52 2010-12-29 11:23 ./doc/codegenerator/codegenerator.sh
-rw-r--r-- 1 jizhang jizhang 462 2010-12-29 11:23 ./doc/validator/validator.sh
go to
-rwxr-xr-x
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBSER-123) StackOverflowError is suppressed
by Karl Brodowsky (JIRA)
StackOverflowError is suppressed
--------------------------------
Key: JBSER-123
URL: https://issues.jboss.org/browse/JBSER-123
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.3 GA
Environment: win32 (Microsoft Windows [Version 6.0.6002]), JBoss 5.1.GA, Hibernate 3.3.1.GA
Reporter: Karl Brodowsky
Assignee: Clebert Suconic
I am running JBoss with Hibernate and I am persisting objects that reference each other in a way that allows infinite recursion when following all references without keeping track of which instances have already been visited.
I am getting a gigabyte of log-output and the app-server becomes unusable.
Debugging reveals that this situation occurs during passivation (I can neither confirm nor exclude that it occurs in other situations as well).
Debugging reveals that in method writeSlotWithMethod of RegularObjectPersister (line 127) an exception e is caught and wrapped in an IOException. In the case that I observed this was an InvocationTargetException that itself wraps an StackOverflowError. Without breakpoint a deep structure wrapping of a large number of exceptions with InvocationTargetException containing IOException containing InvocationTargetException occurs.
The primary bug is that the stackOverflow occurs anyway, but I am assuming that that issue is already addressed by other bug reports.
In this piece of code it is important that the InvocationTargetException is handled separately, unpacked and in case the target of the InvocationTargetException is already IOException, RunTimeException or Error it is rethrown as is without (ultimately endless) wrapping in IOException.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months