[JBoss JIRA] Created: (JBAS-5303) JBoss doesn't recognize closing ResultSet by PreparedStatement close() method
by Evanildo Batista (JIRA)
JBoss doesn't recognize closing ResultSet by PreparedStatement close() method
-----------------------------------------------------------------------------
Key: JBAS-5303
URL: http://jira.jboss.com/jira/browse/JBAS-5303
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: JBossAS-4.0.5.SP1
Environment: Linux; jre 1.5.012
Reporter: Evanildo Batista
Assigned To: Scott M Stark
In a database query, after ps.executeQuery(), when the PreparedStatement close() is declared before ResultSet close() the ps.close() close de ResultSet.
( "... A ResultSet object is automatically closed when the Statement object that generated it is closed" - ResultSet API doc )
But, when this occur Jboss AS doesn't recognize the close in the ResultSet and shows this log:
# WARN[20 Feb 2008 08:01:00,107] - Closing a result set you left open! Please close it yourself.
# java.lang.Throwable: STACKTRACE
# at java.lang.Throwable.<init>(Throwable.java:56)
# at java.lang.Throwable.<init>(Throwable.java:67)
# at org.jboss.resource.adapter.jdbc.WrappedStatement.registerResultSet(WrappedStatement.java:617)
# at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:237)
# at dao.ProdDAO.getIdProd(ProdDAO.java:1504)
# at dao.ProdDAO.getListaProd(ProdDAO.java:73)
# at dao.ProdDAO.getListaProd(ProdDAO.java:1015)
# at action.ProdAction.buscarProd(ProdAction.java:1032)
# at action.ProdAction.buscarProdutos(ProdAction.java:1082)
# at sun.reflect.GeneratedMethodAccessor291.invoke(Unknown Source)
# at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
# at java.lang.reflect.Method.invoke(Method.java:615)
# at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:280)
# at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:216)
# at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
# at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
# at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
# at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
# at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
# 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.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
# at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
# at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
# at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
# at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
# at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
--
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, 2 months
[JBoss JIRA] Created: (JBMESSAGING-1121) Allow command line configuration of ServerPeerID
by Brian Stansberry (JIRA)
Allow command line configuration of ServerPeerID
------------------------------------------------
Key: JBMESSAGING-1121
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1121
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Clustering
Affects Versions: 1.4.0.GA
Reporter: Brian Stansberry
Assigned To: Tim Fox
Fix For: AS 5.0 Integration, EAP 4.3 Integration
The ServerPeer ServerPeerID is currently hard coded at 0 in messaging-service.xml. If you want to set up a cluster, the only way to get it to work is to manually change the value in that file in each node. This needs to be configurable from the command line; i.e via system property substitution.
Need to be sure any changes made in the messaging-service.xml are also reflected in docs/examples/binding-manager/sample-bindings.xml.
--
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, 2 months
[JBoss JIRA] Created: (JBSER-98) Write slot with fields only if both readObject and writeObject are missing
by Galder Zamarreno (JIRA)
Write slot with fields only if both readObject and writeObject are missing
--------------------------------------------------------------------------
Key: JBSER-98
URL: http://jira.jboss.com/jira/browse/JBSER-98
Project: JBoss Serialization
Issue Type: Feature Request
Affects Versions: 1.0.3 GA
Reporter: Galder Zamarreno
Assigned To: Clebert Suconic
Over the last few weeks, I've been dealing with a funky support case which showed the following
stacktrace:
...
Caused by: org.jboss.serial.exception.SerializationException: Excepted to be String
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1120)
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:71)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
... 28 more
Caused by: java.lang.ClassCastException: org.jboss.serial.finalcontainers.IntegerContainer
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1116)
... 42 more
The cause of the issue was that the customer had a class where it had re-implemented
readObject(java.io.ObjectInputStream stream) but had not re-implemented
writeObject(java.io.ObjectOutputStream stream). This is obviously a programming error on their side,
but it took a while to detect such stupid mistake.
The problem within JBoss Serialization was that because this class didn't have a writeObject()
reimplementation, it was a writing the class as a slot with fields, but when it came to reading it, it
was reading the class as a slot with method because readObject had been reimplemented. The
next time a slot with fields was read, the fields were mixed up.
To avoid these type of situations, I'd suggest that:
- JBS only writes as fields if *both* writeObject and readObject are missing. Right now, can't see a
situation where you'd implement one and not the other, thoughts?
--
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, 2 months