java.sql.SQLException: ORA-01008: not all variables bound

One of the causes of this error can be found in the following snippet of code:

Cause:

query = "select * from AAA where condn = ?";

pstmt = con.prepareStatement(query);

pstmt.setString(1, firstValue);

// ResultSet rs = pstmt.executeQuery(query); // Wrong Usage - Do not provide query again

ResultSet rs = pstmt.executeQuery(); // Correct Usage

Another reason is that you have not mapped all '?' with corresponding values

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal

Problem:

package foo;

import java.math.BigDecimal;

public class BigDecimalTest {

   public static void main(String[] args) {

       BigDecimal foo = new BigDecimal("1");

       BigDecimal bar = new BigDecimal("125.4");

       

       BigDecimal result = foo.divide(bar);

       

       System.out.println(foo + " / " + bar + " = " + result);

   }

}

The above example will result in a  

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.. BigDecimal's divide() method uses a really effed up way to calculate the scale of the result: dividend.scale() - divisor.scale(). In order for this to work, you have to use one of the other divide() methods, where you can add another parameter specifying the scale or a predefined MathContext. Mh, I just noticed that the divide() method in question was added in 1.5, in 1.4 all divide() methods required a scale or RoundingMode.
As I see it, the new version of the method is pretty much useless,
since there's always the chance of breaking at runtime when you don't
have control over the values, e. g. if read from a database. Seems like
they tried to fix a class that's broken beyond all repair.

So a working version of the above example would look like this:

package foo;

import java.math.BigDecimal;

import java.math.RoundingMode;

public class BigDecimalTestScale {

   public static void main(String[] args) {

       BigDecimal foo = new BigDecimal("1");

       BigDecimal bar = new BigDecimal("125.4");

       

       BigDecimal result = foo.divide(bar, 3, BigDecimal.ROUND_HALF_UP);

       

       System.out.println(foo + " / " + bar + " = " + result);

   }

}

Reference:

Ref: http://www.jroller.com/nwinkler/entry/the_trouble_with_bigdecimal

java.net.SocketException: Connection reset by peer

The server is reporting "connection reset by peer" in the middle of a request. That means one of the following things:

• The browser started a request and the user pressed STOP.
  
  
• The browser started an request in one frame and JavaScript on another frame told it to go somewhere else (which has the same effect as a user pressing STOP).
  
  
• You have a meta refresh reload someplace that is firing so fast that the previous request hasn't had a chance to complete yet. The five second periodicity makes me pretty suspicious of this.
  
  
• You have some network component in between (a router or proxy) that is misbehaving.
  
  
• You have some completely separate connection attempts going on that are disobeying the HTTP protocol (such as doing a telnet connection to port 8080 and then disconnecting).
  
  

Error message in the HTTP Server error.log: File does not exist:

Problem Description:

I have deployed an webapplication on Websphere Application server 6.0.2.15. This runs on port 9080.

I have also deployed HTTP server and the plugin and are planning to use the HTTP Server as a proxy for the WAS server.

HTTP server is running on port 8080.

When trying to open following url: http://localhost:8080/myapp/signin.do I am supposed to be forwarded to the Application server where the myapp resources resides. This is not happening. Seems like the HTTP server is looking on its own document root instead of doing the actual forward.

Error message in the HTTP Server error.log:

File does not exist: D:/IBM HTTP Server/htdocs

Solution:

Solution in my case was to manually set the port 8080 in the WAS admin console:

Environment -> Virtual Hosts -> Default host -> Host Aliases

Servlet Custom error page not shown

The Servlet 2.2 specification allows you to specify an error page (a servlet or a JSP) for different kinds of HTTP errors or ServletExceptions. You can specify this in deployment descriptor of the web application as:

<error-page>
   <exception-type>FooException</exception-type>
   <location>/error.jsp</location>
 </error-page>

where FooException is a subclass of ServletException.

The web container invokes this servlet in case of errors, and you can access the following information from the request object of error servlet/JSP: error code, exception type, and a message. Refer to section 9.8 of Servlet 2.2 spec.

Here is the document:

 
<?xml version="1.0"?>

<!DOCTYPE web-app

   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

   "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<error-page>

   <error-code>404</error-code>

   <location>/error404.jsp</location>

</error-page>

</web-app>

Problem:

The problem I am experiencing is that Internet Explorer refuses to show my error page and shows his.

I tried with different browsers (Mozilla, Opera) and the output of the 404.jsp page is nicely shown.

Solution 1: (Client Side)

Explorer catches the HTTP message code 404 and replaces all the content with its own error page.

To switch this feature off go to:

Tools -> Internet Options... -> Advanced.

Then look for "Show friendly HTTP error messages" and uncheck it. Click OK.

Solution 2: (Working Solution)

The custom error pages are catched and replaced if they are "too small".

Looks like that Explorer thinks your "small" page is too ugly and so decides to show his.

If the page weights a few Kb then it is shown: so you can either create

a nice looking page or you can add some extra spaces to you page to

meet the Explorer's expectations.

Solution 3:

try setting the status to 200 in your error jsp.

 

<% response.setStatus(200); %>

This should tell the browser that the request was valid and it will show your page instead of the 'Friendly Error Page'.

ReportSDKException: Unexpected error determining relative path---- Error code:-2147217395 Error code

com.crystaldecisions.sdk.occa.report.lib.ReportSDKException: Unexpected error determining relative path---- Error code:-2147217395 Error code name:serverProgrammingError

at com.businessobjects.reports.sdk.d.byte(Unknown Source)

at com.businessobjects.reports.sdk.JRCCommunicationAdapter.a(Unknown Source)

at com.businessobjects.reports.sdk.JRCCommunicationAdapter.void(Unknown Source)

at com.businessobjects.reports.sdk.JRCCommunicationAdapter.connect(Unknown Source)

at com.crystaldecisions.proxy.remoteagent.y.a(Unknown Source)

Cause:

For the JRC XI Release 1 and higher, the reportLocation tag value you'd place in CRConfig.xml is relative to the location of CrystalReportEngine.jar file. You'd get that error if the app can't walk up the path from the jar file location to where it expects to find the rpt files.

Solution:

Make sure you've placed CrystalReportEngine.jar & all aother supporting jars in applications WEB-INF/lib.

List of jar files in my lib folder:

commons-discovery.jar
commons-logging.jar
Concurrent.jar
corbaidl.jar
CRDB_JavaServer.ini
CRDBJavabeansServer.jar
CRDBJavaServer.jar
CRDBJavaServerCommon.jar
CRDBJDBCServer.jar
CRDBXMLExternal.jar
CRDBXMLServer.jar
crlov.jar
crlovexternal.jar
crlovmanifest.jar
CrystalCharting.jar
CrystalCommon.jar
CrystalContentModels.jar
CrystalDatabaseConnectors.jar
CrystalExporters.jar
CrystalExportingBase.jar
CrystalFormulas.jar
CrystalQueryEngine.jar
CrystalReportEngine.jar
CrystalReportingCommon.jar
ebus405.jar
freessl201.jar
icu4j.jar
jaxrpc.jar
jrcerom.jar
jsafe.jar
keycodeDecoder.jar
log4j.jar
mergeboar.jar
MetafileRenderer.jar
pullparser.jar
rasapp.jar
rascore.jar
rpoifs.jar
saaj.jar
serialization.jar
sslj.jar
u211java.jar
URIUtil.jar
webreporting.jar
webreporting-jsf.jar
wsdl4j.jar
xbean.jar
xercesImpl.jar
xml-apis.jar
asn1.jar
axis.jar
axis-ant.jar
cecore.jar
celib.jar
ceplugins.jar
cereports.jar
certj.jar
cesession.jar
ceutils.jar
cexsd.jar
clientSDKOptions.xml

J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource

The error "J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource jdbc/DEMO." can be caused by many problems.

        They are showing a time-out condition where a resource or a managed connection is not available to fulfill a connection request.

        Probably you might have many connections or long running transactions to process.

        Action Plan:

        1. Increase the "Maximum connections" from 10 to 30. This is likely to help fix this issue.

        To ask your question:

        You can check the current active connection when the ConnectionWaitTimeoutException happened by dumping java threads or javacores.

        The following document will guide you to collect requested information. Please use manual collection steps.

        [Please follow through the section "Manual collection of troubleshooting data (optional)"]

        MustGather: Performance, Hang, or High CPU Issues on Windows

        - http://www-01.ibm.com/support/docview.wss?uid=swg21111364

       

        Recommendation:

        1. It is recommended to test the scripts which is attached the above document first or before the problem occurred to ensure it does work in your environment.

        2. Could you please check the database side? Has database provided enough cursors or connections to serve requests?

            Is (Are) there any lock in database table?

        3. Please check with your program coding side. Does it close connection(s) to database when it finished the task or transaction?

More Info:

http://www-01.ibm.com/support/docview.wss?uid=swg21217062

Similar Prob:

http://forums.sun.com/thread.jspa?threadID=5387319

IE8 RTM cann't print preview checked checkbox

IE8 has a new bug with printing. When you change a checkbox or radio button on a page either by clicking it or calling some JavaScript function to toggle it - it looks like it changed but if you try to print it, it won't print in the new state.

In fact it won't even show up correctly in the print preview window!

The best part is that this ONLY occurs in Standards Mode. If you render your pages in the Legacy IE7 Mode the checkboxes and radio buttons print (and preview) properly.

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=431489

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=434706

Parsing error processing resource path /WEB-INF/struts-config.xml

ERROR [http8080-Processor1] action.ActionServlet (ActionServlet.java:768) - Parsing error processing resource path /WEB-INF/struts-config.xml

java.lang.reflect.InvocationTargetException

at org.apache.commons.digester.Digester.createSAXException(Digester.java:2792)

at org.apache.commons.digester.Digester.createSAXException(Digester.java:2818)

at org.apache.commons.digester.Digester.startElement(Digester.java:1289)

at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)

at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)

at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(Unknown Source)

at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)

at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)

at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)

at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)

at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)

at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)

Possible causes:

1. version problem of the JDKs. Check the version of xerces.jar.

2. different Java (JRE) versions on the two machines (the developer-machine had 1.6 and the target-machine only 1.5)

Solution:

1.make sure the very first line in config or web.xml should not be blank. The contents should start with the very first line.

2. Compile project with JRE version equals to target-machine.