[
https://issues.apache.org/jira/browse/OFBIZ-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-9714:
---------------------------------
Attachment:
OFBIZ-9714_org.apache.ofbiz.service.rmi.socket.ssl_bugfixes.patch
class SSLClientSocketFactory:
- Line 38: it’s not necessary for the class to implement serialVerisonUID
class SSLServerSocketFactory:
- Line 43: it’s not necessary for the class to implement serialVerisonUID
- Line 74 and following: changed the declaration of the FileInputStream
- Line 117: changed the code to reduce the possibility of errors
> [FB] Package org.apache.ofbiz.service.rmi.socket.ssl
> ----------------------------------------------------
>
> Key: OFBIZ-9714
> URL: https://issues.apache.org/jira/browse/OFBIZ-9714
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework
> Affects Versions: Trunk
> Reporter: Dennis Balkir
> Priority: Minor
> Attachments:
> OFBIZ-9714_org.apache.ofbiz.service.rmi.socket.ssl_bugfixes.patch
>
>
> - SSLClientSocketFactory.java:37, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLClientSocketFactory is
> Serializable; consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different naming
> conventions for synthetic variables generated for references to class objects
> or inner classes. To ensure interoperability of Serializable across versions,
> consider adding an explicit serialVersionUID.
> - SSLServerSocketFactory.java:43, SE_NO_SERIALVERSIONID
> SnVI: org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory is
> Serializable; consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different naming
> conventions for synthetic variables generated for references to class objects
> or inner classes. To ensure interoperability of Serializable across versions,
> consider adding an explicit serialVersionUID.
> - SSLServerSocketFactory.java:76, OS_OPEN_STREAM
> OS:
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
> may fail to close stream
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak. It is generally a good idea to use a finally
> block to ensure that streams are closed.
> - SSLServerSocketFactory.java:76, OBL_UNSATISFIED_OBLIGATION
> OBL:
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
> may fail to clean up java.io.InputStream
> This method may fail to clean up (close, dispose of) a stream, database
> object, or other resource requiring an explicit cleanup operation.
> In general, if a method opens a stream or other resource, the method should
> use a try/finally block to ensure that the stream or resource is cleaned up
> before the method returns.
> This bug pattern is essentially the same as the OS_OPEN_STREAM and
> ODR_OPEN_DATABASE_RESOURCE bug patterns, but is based on a different (and
> hopefully better) static analysis technique. We are interested is getting
> feedback about the usefulness of this bug pattern. To send feedback, either:
> send email to findb...@cs.umd.edu
> file a bug report: http://findbugs.sourceforge.net/reportingBugs.html
> In particular, the false-positive suppression heuristics for this bug pattern
> have not been extensively tuned, so reports about false positives are helpful
> to us.
> See Weimer and Necula, Finding and Preventing Run-Time Error Handling
> Mistakes, for a description of the analysis technique.
> - SSLServerSocketFactory.java:111, BC_UNCONFIRMED_CAST_OF_RETURN_VALUE
> BC: Unchecked/unconfirmed cast from java.net.ServerSocket to
> javax.net.ssl.SSLServerSocket of return value in
> org.apache.ofbiz.service.rmi.socket.ssl.SSLServerSocketFactory.createServerSocket(int)
> This code performs an unchecked cast of the return value of a method. The
> code might be calling the method in such a way that the cast is guaranteed to
> be safe, but FindBugs is unable to verify that the cast is safe. Check that
> your program logic ensures that this cast will not fail.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
