Getting Error while sending mail from Localhost using JSP - java

After hours of googling I got the code for sending email from JSP page from tutorialpoints web site, I tried this entire code as mentioned in the tutorial also added recommended jar files. But after every setting with actual email id like this -
// Recipient's email ID needs to be mentioned.
String to = "vishaldb28#gmail.com";
// Sender's email ID needs to be mentioned
String from = "info#cbsecsnip.in";
// Assuming you are sending email from localhost
String host = "localhost";
// Get system properties object
Properties properties = System.getProperties();
// Setup mail server
properties.setProperty("mail.cbsecsnip.in", host);
properties.setProperty("mail.user", "info#cbsecsnip.in");
properties.setProperty("mail.password", "password");
// Get the default Session object.
Session mailSession = Session.getDefaultInstance(properties);
I am getting exception -
javax.mail.SendFailedException: Sending failed; nested exception is:
class javax.mail.SendFailedException: Invalid Addresses; nested
exception is: class javax.mail.SendFailedException: 553 We do not
relay non-local mail, sorry.
at javax.mail.Transport.send0(Transport.java:218) at
javax.mail.Transport.send(Transport.java:80) at
org.apache.jsp.addstudent_jsp._jspService(addstudent_jsp.java:168) at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:185)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:151)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:269)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1773)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Please if anybody can help me to come out from this exception.

javax.mail.SendFailedException: 553 We do not relay non-local mail, sorry.
You need to use an SMTP-server which you are allowed to forward mail through. If you have root access to the system you are running on, you just need to reconfigure the SMTP-server to allow relaying (in a safe manner, not for all the internet). If not, talk to those who do.

Related

java.sql.SQLException: ORA-00942: table or view does not exist, getting in every third hit to database

i am working in a java project, where we are using oracle as a database and we have two schema, for every schema we are creating saprate connections in connection pool.
its working fine if we hit max 2 request at a time from the client for the data from a table but at every third time its getting java.sql.SQLException: ORA-00942: table or view does not exist exception.
i want to understand why its happening and what would be the possible the reason? Please help me.
Full Stacktrace:
java.sql.SQLException: ORA-00942: table or view does not exist
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:111)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:330)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:287)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:742)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:212)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:795)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1030)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:835)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1123)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3284)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3328)
at DLRecordSetSQL.DLRecordSetSQL.setRecordCount(DLRecordSetSQL.java:3622)
at DLRecordSetSQL.DLRecordSetSQL.open(DLRecordSetSQL.java:3124)
at DLRecordSetSQL.DLRecordSetSQL.open(DLRecordSetSQL.java:3207)
at com.utility.queryManager.util.MetadataManager.init(MetadataManager.java:79)
at com.utility.queryManager.util.MetadataManager.<init>(MetadataManager.java:65)
at com.utility.queryManager.processor.UtilityManagerRequestProcessor.selectCommandRequestProcessor(UtilityManagerRequestProcessor.java:187)
at com.utility.queryManager.processor.UtilityManagerRequestProcessor.UtilityRequestProcessor(UtilityManagerRequestProcessor.java:77)
at com.utility.queryManager.servlet.UtilityManagerServlet.doPost(UtilityManagerServlet.java:36)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
I think your db is being run out of available connections.
You can set initial pool size 5. as it is default to 0.
For more, you can go through this tutorial: Setting Connection Pool Properties in Oracle
As Avi stated the issue as below
Oracle database connections are not multi-threaded. If two or more
threads simultaneously try to access the same connection, one of them
will block until the other one finishes interacting with the
connection.
So I guess you should try to verify whether your code exhibits this
behaviour trying to access the same database connection from multiple
threads at the same time.

Why is Tomcat complaining about attempting to write too much to a response header?

My service functions as a proxy server that will send GET requests using a proxy, add some info into the header, and return this to the client. But sometimes I get this error when I'm writing the extra headers:
org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write more data to the response headers than there was room available in the buffer. Increase maxHttpHeaderSize on the connector or write less data into the response headers.
at org.apache.coyote.http11.AbstractOutputBuffer.checkLengthBeforeWrite(AbstractOutputBuffer.java:546)
at org.apache.coyote.http11.AbstractOutputBuffer.write(AbstractOutputBuffer.java:510)
at org.apache.coyote.http11.AbstractOutputBuffer.write(AbstractOutputBuffer.java:427)
at org.apache.coyote.http11.AbstractOutputBuffer.sendHeader(AbstractOutputBuffer.java:393)
at org.apache.coyote.http11.AbstractHttp11Processor.prepareResponse(AbstractHttp11Processor.java:1468)
at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:764)
at org.apache.coyote.Response.action(Response.java:172)
at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:185)
at org.apache.coyote.Response.doWrite(Response.java:504)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:342)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:413)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:401)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:91)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:135)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
at java.io.Writer.write(Writer.java:157)
at org.springframework.util.StreamUtils.copy(StreamUtils.java:106)
at org.springframework.http.converter.StringHttpMessageConverter.writeInternal(StringHttpMessageConverter.java:106)
at org.springframework.http.converter.StringHttpMessageConverter.writeInternal(StringHttpMessageConverter.java:40)
at org.springframework.http.converter.AbstractHttpMessageConverter.write(AbstractHttpMessageConverter.java:179)
at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:148)
at org.springframework.web.servlet.mvc.method.annotation.HttpEntityMethodProcessor.handleReturnValue(HttpEntityMethodProcessor.java:124)
at org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:69)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:122)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:745)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:686)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:80)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:936)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:827)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:812)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
I find this strange because the only thing I add into the header is {"proxy_error":"false"}. Did I just happen to send a GET to a website that returned so many headers that I couldn't write another one in? Or am I somehow causing the buffer to get too big by never clearing it (I'm sending thousands of GET requests to random urls, each time I am copying over their headers).
#RequestMapping(value = {"/hi"}, method = RequestMethod.GET)
#ResponseBody
public String test(final String url, HttpServletResponse response) {
CloseableHttpResponse httpResponse = sendGetRequest(url);
response.setHeader(PROXY_ERROR_KEY, "false");
// Copy the fetched headers
for (Header header : httpResponse.getAllHeaders()) {
response.addHeader(header.getName(), header.getValue());
}
response.setStatus(httpResponse.getStatusLine().getStatusCode());
return "hello";
}
Happened to me as well, in Jersey. I set a breakpoint on Exception, waited for Eclipse to break on it, walked through the stack and parameters and found:
I had enabled Jersey tracing which outputs debugging info into the headers. It can be quite a lot of data, no surprise I got this error.

"Stream Closed" Error caused apparently by multiple submits

I am accessing an Oracle 9 database using Java, in a Tomcat 7 environment.
In context.xml I have
<Resource type="javax.sql.DataSource" auth="Container"
name="jdbc/myDB"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:#localhost:1521:db" maxwait="10000"
username="temp" password="temp" maxActive="20" maxIdle="10"/>
My java code works most of the time, but sometimes randomly I get the Stream Closed exception. I suspect this may be if the user presses the buttons in the application too fast, thus starting one query before finishing another query.
This exception is caused by the doEndTag function in the following code.
public class SQLIteratorTag extends BodyTagSupport
{
public SQLIteratorTag()
{
query = "";
rs = null;
stmt = null;
rsmd = null;
dbConn = null;
con = null;
}
public int doStartTag()
throws JspTagException
{
String fieldName = "";
try
{
DBConnection d=DBConnection.getInstance();
con = d.getConnection();
...
public int doAfterBody()
throws JspException
{
try
{
....
public int doEndTag()
throws JspException
{
try
{
if(bodyContent != null)
{
bodyContent.writeOut(bodyContent.getEnclosingWriter());
}
}
catch(IOException ex)
{
Log.getIns
I do not want to post too much code, but I may have posted too little. I have no idea where the problem may lie, but I will update the question if necessary.
The exception itself is:
SEVERE: Servlet.service() for servlet [jsp] in context with path [/charm] threw exception [javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Stream closed] with root cause
javax.servlet.jsp.JspTagException: Stream closed
at c.tags.sql.SQLIteratorTag.doEndTag(SQLIteratorTag.java:218)
at org.apache.jsp.comp_005fpara_jsp._jspService(comp_005fpara_jsp.java:708)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.jspbook.GZIPFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
From the stack trace, this doesn't appear to be anything to do with the database connection, but does look related to the user submitting two requests from the back end. I've changed the tags, but you might want to rephrase the question a bit and change the title to get more attention.
Essentially your application receives two requests, and processes them both. It's a while since I've seen this but as far as I can remember the first one gets this error because the browser has closed the TCP/IP connection in order to open a new one for the second request. (That's probably a bit simplistic with HTTP/1.1 as it reuses connections).
I think we worked around this by hiding a unique identifier on the page as it was generated, and then detecting if we got a second POST request on the same session with that UID - indicating they'd submitted twice. It was a while ago though so I'm rather hazy on exactly what we did, and how we stopped it being visible to the user; I do recall that we wrapped the HttpServletRequest for the second request in a HttpServletRequestWrapper that appeared to change the request from a POST to a GET, but I'd have to do some digging to figure what was going on.
Edit: This link is quite old but seems to have a better way to deal with it than anything ancient I can drag up (which seems to be essentially option 2 in that post). There are probably several common ways to deal with this.

Tomcat connection pooling,idle connections,and connection creation

I have the following problem in a web application.When i leave the server on for some period for example 24 hours my app stops working.
I am using tomcat 7 and Connection pooling.My Database is MySQL.
I am getting the following exception:
Communication link failure: java.io.EOFException, underlying cause: null ** BEGIN NESTED EXCEPTION ** java.io.EOFException STACKTRACE: java.io.EOFException at
com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1394) at
com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1538) at
com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1929) at
com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1167) at
com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1278) at
com.mysql.jdbc.Connection.execSQL(Connection.java:2251) at
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1586) at
org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStat
ement.java:96) at
org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStat
ement.java:96) at configuration.Login.doPost(Login.java:104) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.jav
a:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403) at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:301) at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java
:162) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java
:140) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at
java.lang.Thread.run(Thread.java:662) ** END NESTED EXCEPTION **
I find out that this error occurred when the pooled connections for some reason after some period of time have been closed maybe due to time limit or something.
My question is that connection pool shouldn't have created new connections when there are no connections into the pool ?The error is not caused by traffic because no one uses the application at the moment.How can I fix this error ?When the app is deployed I start using the app,pooled connections are being created.These connections are idle?Is there a way these connections wont be closed?But if i can do that don't I waste connections from other applications on the server?
Also if I keep trying to use the application after some time new connections are created and the app starts working.But this isn't normal.......
//Edit if i manualy close all active connections from MYSQL Admin this error appears again.
There are background connections.
How do you define your pool?
Here are some useful options.
minEvictableIdleTimeMillis="60000"maxActive="100" minIdle="10" maxIdle="50" maxWait="10000"
removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true"
And add in the url the autoReconnect=true
url="jdbc:mysql://localhost:3306/db?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8" />

OpenSAML bootstrap() nets me "InputStream cannot be null"

Deployment environment: Windows Server 2008, Tomcat 7.0.5, Oracle JRE 1.6. Development environment same plus Eclipse Helios.
When I try to deploy my Java application which uses OpenSAML 2.3.1 and test it live, it doesn't want to run. Looking through the source code and stack trace, it seems that DefaultBootstrap.bootstrap() ends up causing java.lang.IllegalArgumentException: InputStream cannot be null. I'm including the full stack trace below.
The software versions on the target deployment system are, or at least are supposed to be, exactly the same as on my development box, where everything runs just fine, but of course there I don't deploy using the .war. I am getting the distinct feeling that I'm missing some XML or DTD file in the deployment archive, but that feeling alone doesn't help me much in fixing it. Googling for parts of the stacktrace also didn't really help me much.
Where do I start tracking down the actual root cause of this error, so I can fix it?
2011-feb-10 10:56:08 org.apache.catalina.core.StandardWrapperValve invoke
ALLVARLIG: Servlet.service() for servlet [se.novasoftware.gabriel.SAMLParser] in context with path [/ServiceTier] threw exception [java.lang.IllegalArgumentException: InputStream cannot be null] with root cause
java.lang.IllegalArgumentException: InputStream cannot be null
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:120)
at org.opensaml.xml.parse.BasicParserPool$DocumentBuilderProxy.parse(BasicParserPool.java:643)
at org.opensaml.xml.parse.BasicParserPool.parse(BasicParserPool.java:216)
at org.opensaml.xml.XMLConfigurator.load(XMLConfigurator.java:141)
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:148)
at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:88)
at _mynamespace_.saml.ParsedResponse.<init>(ParsedResponse.java:56)
at _mynamespace_.saml.ParsedResponse.<init>(ParsedResponse.java:104)
at _mynamespace_.SAMLParser.doPost(SAMLParser.java:29) // servlet entry point
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:259)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:281)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ParsedResponse.java line 56 is the bootstrap() call in its constructor:
private PersedResponse() throws ConfigurationException {
DefaultBootstrap.bootstrap(); // line 56
...
whereas line 104 in that same file is the constructor that gets called from the outside calling this private default constructor:
public ParsedResponse(final String samlXML)
throws UnmarshallingException, ConfigurationException {
this(); // line 104
...
Adding openws-1.3.0.jar to the deployment assembly did the trick.

Categories