RE: Dynamic Email (Workaround)

[Timothy Shadel <sh...@mtc.byu.edu>]

I found a workaround.  Apparently the content wasn't ready as soon as my thread continued, so I just added a try to Thread.sleep( 100 ) a few times and then the InputStream had data ready to go.  One drawback is that the input stream never returns -1 indicating the end of the input (because the socket's still open??), so I have to fake it by allowing 3 waits of 1/10 of a second each to see if there's more data before moving on.  Strange, but it seems to work reliably now...  From here I'll try to tack the session information onto the request to get access to at least that in my JSP page.

>>> shadeltd@mtc.byu.edu 11/15/01 08:26AM >>>
I actually tried that earlier (my last of 3 attempts before sending this e-mail), but the InputStream associated with the HttpURLConnection has run past all the content by the time I get it.  I have no idea why it does that.  Here's a snipet of the code:

	String strURL;
	if( request.getServerPort() == 443 ) {
		strURL = "https://" + request.getServerName() + request.getContextPath() + "/mailContent.jsp?from=" + from + "&to=" + to;
	} else if (request.getServerPort() == 80 ) {
		strURL = "http://" + request.getServerName() + request.getContextPath() + "/mailContent.jsp?from=" + from + "&to=" + to;
	} else {
		strURL = "http://" + request.getServerName() + ":" + request.getServerPort() + request.getContextPath() + "/mailContent.jsp?from=" + from + "&to=" + to;
	}
	java.net.URL url = new java.net.URL( strURL );
	java.net.HttpURLConnection conn = (java.net.HttpURLConnection)url.openConnection();
	java.io.InputStream in = (InputStream)conn.getInputStream();
	StringBuffer strMailContent = new StringBuffer();
	while ( in.available() > 0 ) {
		strMailContent.append( (char)in.read() );
	}
	in.close();
	conn.disconnect();
	message.setText( strMailContent.toString() + "\r\n--------\r\n" + text );

But for some reason in.available() almost always returns 0 bytes.  I can use my debugger to see the protected byte array used by the PushbackInputStream, but can't get at any of the data since the position variable is already pointing to the end of the array and the mark() and reset() messages aren't supported.  I'm guessing that it may have to do with something that either the container does or the JVM does to pool or optimize connection requests, but I don't know.  If the connection DOES return the content of the URL, then on the next invocation it ALWAYS returns nothing.

One more thing, using this method ALWAYS causes Tomcat to log the request, so it appears to be processing the JSP every time this code calls for it.  I can also pull the JSP up multiple times in a browser without any problems.  This seemed to be a fairly simple, fail-safe way to approach it, but I don't understand why it's giving me trouble...

Any ideas?

Thanks,

Tim


>>> randy.layman@aswethink.com 11/15/01 04:48AM >>>

	Here's an idea.  Its sketched out in Java, but most technologies
would work.

	Use HttpURLConnection to open the page you want (i.e. request the
page through the Tomcat server).  Copy the result text into the body of the
email message.  Send the email message.

	Randy


> -----Original Message-----
> From: Timothy Shadel [mailto:shadeltd@mtc.byu.edu] 
> Sent: Wednesday, November 14, 2001 5:59 PM
> To: tomcat-user@jakarta.apache.org 
> Subject: RE: Dynamic Email
> 
> 
> Thanks for the tip.  It looks like the developer's guide at 
> http://jakarta.apache.org/velocity/developer-guide.html#Using% 
> 20Velocity%20In%20Servlets is going to give me the most options there.
> 
> I'd REALLY like to avoid training my group on ANOTHER view 
> mechanism, and I'd like to take custom JSP tags that we write 
> for initial use in HTML and reuse them in the dynamic e-mail. 
>  I'm not satisfied that Velocity will be the best solution, 
> though it seems to be a viable one.
> 
> Any other ideas of how to use JSP to generate dynamic e-mail content?
> 
> - Tim
> 
> >>> kevin@atg.ca 11/14/01 03:05PM >>>
> Check out Velocity at apache.org
> 
> Kevin McBrearty
> ATG Automation Technologies Group Ltd.
> ______________________________________
> 
> "A computer lets you make mistakes faster than any other 
> invention in human
> history, with the possible exception of handguns and tequila." - D.W.
> McArthur
> 
> > -----Original Message-----
> > From: Timothy Shadel [mailto:shadeltd@mtc.byu.edu] 
> > Sent: Wednesday, November 14, 2001 4:42 PM
> > To: tomcat-user@jakarta.apache.org 
> > Subject: Dynamic Email
> >
> >
> > Hi,
> >
> > I'd like to generate dynamic e-mail content, typically based on
> > some parameters stored in the current HttpSession.  JSP seems
> > like a great tool for this.  I can easily edit the "static"
> > portion of the e-mail, and have non-technical personnel work with
> > it.  I'd get all the advantages JSP gives to dynamic HTML
> > generation.  I can't seem to figure out a good way to do it,
> > though.  I've tried to use the RequestDispactcher.include(), but
> > there's no way to change the OutputStream to recover the content
> > that was inadvertently streamed to the browser.  I can't wrap the
> > request/response objects in the Servlet 2.2 spec (tomcat 3.x),
> > and I'm not sure I'd know the details of how to even if I was
> > running tomcat 4.0.  I tried creating a URL and calling
> > getContent(), which returns a PushbackInputStream, but this works
> > only sporadically.  Most of the time the buffer has been read
> > completely, and I have no data with which to push it back.  All I
> > want to do is load a JSP page, ensure that it's processed within
> > the current Session and Request (so it has access to the needed
> > variables), and then push that content into an e-mail message
> > that I send using the JavaMail API.
> >
> > I assume that somebody else has wanted this type of thing before.
> >  If there's another solution to let end-users easily edit the
> > static surroundings of dynamic e-mail content, where I can use
> > templates, internationalization, and other great tools as easily
> > as Struts, please let me know.
> >
> > Thanks,
> >
> > Tim
> >
> >
> > --
> > To unsubscribe:   
> <ma...@jakarta.apache.org>
> > For additional commands: 
> <ma...@jakarta.apache.org>
> > Troubles with the list: 
> <ma...@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe:   <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe:   <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>d.apache.org/velocity/developer-guid
> 

--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>