I'm using Apache James version 3.0-beta1 and I would like to know if there is a way to save separately the body of the e-mails from the attachments. Right now both of them are saved inside the DB, that leads to a noticeable increase in the table size due to the fact that all the attachments are saved inside the MAIL_BYTES column in the shape of a byte stream.
Is there a way to move outside the DB the attachments and leave inside the DB only the body of the emails? On the long run this default behaviour will make my DB collapse.
You may simply write a mailet to get the attachments of the mail and then save them to a specific folder in your filesystem. To be more specific, in mailet, get the MimeMessage from org.apache.mailet.Mail, then use it to check if there are any attachments by using getFileName() method. This method returns file names if Disposition and ContentType headers are not null . If the result is not null, then that means in than bodyPart you have a file attached.Then using getInputStream() you can save it to anywhere you want.
Related
I am trying to read the HTML contents of a Document object(mail) as a part of my plug in development in Lotus Notes 9.
With this HTML content, we would like to create a file and send it as an attachment file in our query, so we can preserve the formatting, images, etc.
Even after session.setConvertMIME(false); I still do not get the Mime entity when I call doc.getMIMEEntity().
I have made preferences setting in Preferences>Mail>Internet
Internet mail format to "HTML and plain text".
I have tried doc.createMIMEEntity and then tried to retrieve it
mimePart = doc.getMIMEEntity("Body");
When i right clicked on Incoming mails from outlook I was able to see multiple Body items, one of which contained the HTML part.However I was still not able to access it via getMIMEEntity.
The mails I created from lotus notes, do not have multiple Body items. When I receive the mails from Lotus Notes > Outlook and I inspect source in Outlook, I see it as HTML. So I assume there is a place where this conversion takes place.
ShelfSession.getInstance().localSession.setConvertMime(false);
MIMEEntity nMime = (MIMEEntity) doc.getMIMEEntity("Body");
I want the Mime part to be set to this variable so I can retrieve the content to form the HTML file.
Please help with any code suggestions or is there some Lotus notes setting that I have missed out on that is making the Mime variable always null?
You said, "The mails I created from lotus notes, do not have multiple Body items." This almost certainly means the Body item is stored as rich text instead of MIME. You can confirm this by looking at the document properties in Notes.
You can use document.convertToMIME() to convert a Body item from Notes rich text to MIME. Here's an example:
MIMEEntity mimeEntity = null;
Item item = document.getFirstItem("Body");
if (item != null) {
if (item.getType() == Item.RICHTEXT) {
// Convert Notes rich text to MIME
document.convertToMIME(Document.CVT_RT_TO_PLAINTEXT_AND_HTML, 0);
}
mimeEntity = document.getMIMEEntity();
}
I've adapted this example from some code in MimeEntityHelper from the XPages Extension Library. I'd encourage you to take a look at that code for more context. For example, you still need to call session.setConvertMIME(false) to avoid converting a document that is already MIME to rich text. The MimeEntityHelper class uses both session.setConvertMIME() and document.convertToMIME() to control document conversions.
I am using jax-ws cxf to load documents from a SOAP interface. I can get the correct document via SoapUI (xop/multipart). Unfortunately, when I try to load the attachment via code, the CachedOutputStream is empty for files greater than ~210kb.
What I tried:
Activate MTOMFeature for my WebServiceClient
Play with JVM arguments CachedOutputStream.Threshold and CachedOutputStream.MaxSize
Use different versions of apache-cxf (3.2.1 or 3.1.14)
When debugging:
PhaseInterceptorChain#doIntercept uses the AttachmentInInterceptor (at currentInterceptor.handleMessage(message);) which loads the attachments with LazyAttachmentCollection and adds it to the message.
happy case: document is loaded into CachedOutputStream and available after the for-loop.
error case (file too big?): document is available directly after currentInterceptor.handleMessage is called, but disappears when the loop has finished
In both of the above cases however, a correct tmp file is saved to my disk (with exactly my document's content). Furthermore, I can load that file in both cases even when the loop has finished with: ((org.apache.cxf.attachment.LazyAttachmentCollection)(message.getAttachments())).loadAll();
I had similar problem with apache-cxf 3.1.6. The issue was that files above 102kB were empty. After some digging it turned turned out to be "attachment-memory-threshold" which u can set in requestContext, for some reason file cache doesnt seem to work.
Using JQuery and Spring's #ModelAndView annotation for the controller.
I'm trying to code a process in which the user clicks an icon and if a certain criteria on the DB is met, a zip file will be produced on the server containing a bunch of files, then this zip file should be sent to the browser for saving.
If the criteria isn't met, then an error message should be sent to the browser telling there isn't any file to be created and produced.
However if I use JQuery' .post method, I can receive the error message (if that is the case) but never the zip binary file.
If I use a regular Href Link I can receive the file (if that is the case) but don't know how to receive the message when the file cannot be produced.
Is there an alternative or a standard way to do this?
Thanks for your support!
-Gabriel.
You should probably split your server-side method in two:
the first one validates the criteria. If unsuccessful, it notifies of an exception, otherwise it returns a URL to the method in next point
the second one actually returns the zip file
In your frontend, the code will look something like this:
$.post(urlToPoint1, data, function(response) {
if (response.success) {
// download the file using the url provided
// (pointing to method described in point 2)
window.location.href = response.url;
}
else {
alert('whatever');
}
});
I would like to "create" an email using Java.
Here's what I mean:
Based on information I already have, I would like to make an email message open in Microsoft Outlook with the fields To, CC, Subject, Message Body, and attachments already populated (all now stored as strings, the directories for attachments are stored as strings as well).
The message needs to open in Outlook for the user to verify the contents and give the opportunity for adding more CC, slight adjustments to subject and message body.
From what I gather, it seems that the "best" way of achieving this is first creating a file on disk that Outlook can read, which contains my message, then opening it with outlook using something similar to the code below.
Runtime rt = Runtime.getRuntime();
Process pr = rt.exec("OUTLOOK Directory + CMD switches for opening files");
Ideally, I would like to use a simple framework for simply creating such a file using the strings I already have for the different fields (or achieving the same thing through a a non-simple framework).
If there's no "good" way of achieving the above, I'd settle for a method of just attaching my attachment file to a given Outlook template (.oft) file.
(3. I'll resort to my current solution of simply having the template open in Outlook, the attachment in Explorer, and prompt the user to drag the file into Outlook.)
I've looked at HSMF in Apache POI (I'm Apache POI for other parts of my program), but it appears to be rather experimental at this point, and I've been unable to find much documentation for it.
Does anyone have any suggestions on where to look?
Use the Desktop API with the URI constructor that will quote legal characters. This example code will open your default mail client with the headers populated.
public static void main(String[] args) throws Exception {
URI msg = new URI("mailto", "you#foo.com&cc=team#bar.com&subject=How to create email in Java?body=Use JavaMail.", (String) null);
Desktop.getDesktop().mail(msg);
}
The only limitation is that there is an upper limit to the length of the URI that the O/S can handle. On windows, the 'start' command also understands the syntax which is explained in RFC 2368.
I have never saved and retrieved an image to and from the database before. I wrote down what I guessed would be the process. I would just like to know if this is correct though:
Save image:
Select & Upload image file from jsp (Struts 2) which will save it as a .tmp file.
Convert the .tmp file to a byte[] array (Java Server-Side)
Store the byte[] array as a blob in the database (Java Server-Side)
Get image:
Get the byte[] array from the database (Java Server-Side)
Convert the byte[] array to an image file (Java Server-Side)
Create the file in a location (Java Server-Side)
Use an img tag to display the file (JSP Client-Side)
Delete the file after it's finished being used? (Java Server-Side)
I'm aware of the fact that it is highly recommended to not save & retrieve images to and from the database. I would like to know how to do it anyway.
Thanks
Almost correct.
It's expensive and not so great to create the file on the fly and then delete it.
Yes, you store it as the raw bytes in the database, but the way to retrieve it and display it to a client machine is to implement a web handler that sets the content-type of the response to the appropriate MIME type and then dumps the bytes out to the response stream.
Yes, You get it right.
Save Image :
The decision to save image is very much dependent on further usage. You have one option to save the file on the file system. The location for saved file should be saved into the metadata in the database table.
Get Image:
You do not have to right file data on any temp location. It can be easily rendered from the database only. Just send a request from client and intercept that request in a spacial designed Servlet. This Servlet will read the file metadata and corresponding file, if successful, write the file back on the response stream.