I am trying to send an error message from back bean class to view but it shows for a second and then went away. I don't know the reason please let me know what I am doing wrong.
For scope, I am using ManagedBean and RequestScoped
String msg = "Without 'Sample Id/Experiment Id' Keys file cannot proceed";
FacesContext.getCurrentInstance().addMessage(null,new FacesMessage(FacesMessage.SEVERITY_ERROR, msg, ""));
In my view, I am trying to get these error and these containers
<rich:messages globalOnly="true" />
<rich:messages for="gv" />
It shows these messages but doesn't stay there and vanish. Thank you in advance
JSF messages have basically a lifetime of a single request (but you can extend this via Flash Scope in JSF2) and thus disappear after a request finished.
rich:message components get auto-updated (i.e. ajaxRendered) by default. So it's very likely, that you have some AJAX-request, that triggers right after the message was shown on your page. Because of the request-scope of messages, no more messages are available in the new request and the rich:messages get updated again with empty content.
You can verify this by using your browsers developer tools or Firebug to watch network your traffic.
Related
Context:
I am working on a piece of Java code where I am reading mails from an array (which works fine). I was wondering if someone can help me with the callback in order to show a fancy message like Your email was sent.
Questions:
How do I implement this?
Is there any way to get any Boolean type return value from javax.mail to check if the message was sent or not?
Maybe I should create a pool? If yes, how do I do that? Is there any signal to kill the pool?
Code:
// addressTo is the array.
Transport t = sesion.getTransport(this.beanMail.getProtocolo());
t.connect(this.beanMail.getUsuario(), this.beanMail.getPassword());
t.sendMessage(mensaje, addressTo);
t.close();
Quoting from the JavaMail API FAQ (in the context of tracking bounced messages):
While there is an Internet standard for reporting such errors (the multipart/report MIME type, see RFC1892), it is not widely implemented yet. RFC1211 discusses this problem in depth, including numerous examples.In Internet email, the existence of a particular mailbox or user name can only be determined by the ultimate server that would deliver the message. The message may pass through several relay servers (that are not able to detect the error) before reaching the end server. Typically, when the end server detects such an error, it will return a message indicating the reason for the failure to the sender of the original message. There are many Internet standards covering such Delivery Status Notifications but a large number of servers don't support these new standards, instead using ad hoc techniques for returning such failure messages. This makes it very difficult to correlate a "bounced" message with the original message that caused the problem. (Note that this problem is completely independent of JavaMail.)
Source
I'm using Weblogic 10.3.5. I work on a large legacy enterprise application with Struts (1.x) mapped as the default servlet.
Background
A bit of legacy convolution to start: each enterprise customer has a "subscriber ID" which their users must provide at login in addition to their username and password. Subscriber IDs are numeric and always at least four digits, usually five. If you go to mysite.com/, you are presented with a three-field login page: subscriber ID, username, and password.
Our largest enterprise customers didn't like that, so many years ago we introduced skinned login pages: go to mysite.com/12345, where 12345 is your subscriber ID. We'll prepopulate and hide the subscriber ID field, and skin the login page with the enterprise customer's logo and color scheme.
Years later, we had 100+ servlet mappings, one for each subscriber. Every new customer required a software deployment to add the servlet mapping, so our implementations team was hamstrung by the dev team's deployment schedule, which in turn was limited by our large enterprise customers' need to budget time for user acceptance testing.
To address that, we changed the URL: mysite.com/login/12345, where /login/* is mapped to a single servlet that accepts any subscriber ID. We kept the old servlet mappings around so that existing customers didn't have to change the URL, but that left two annoyances:
A few hundred lines of cruft in web.xml
As a developer or QA, it's annoying to have to know whether this is an old subscriber or a new one before you know what URL to use to log in. Try to use the old method for a new subscriber? You get a 404 page.
Here's what I did
We had a pre-existing custom 404 page, correctly defined in web.xml and behaving exactly as expected. I updated it with the following code, right at the top:
<%
if (request.getRequestURI().matches("^/[\\d]{4,}$")) {
// probably someone trying to log in with the old-style URL
response.sendRedirect(String.format("/login%s", request.getRequestURI()));
return;
}
%>
This worked like a charm, until I noticed one oddity:
Here's what's wrong
The very first time I try to visit a URL that should result in a 404 but will be redirected because it matches the regex, it doesn't redirect. With my debugger, I've determined that the reason is that request.getRequestURI() returns "/errors/404error.jsp" rather than "/12345" like I would expect, resulting in the regex not matching and our normal 404 page being served to the user.
My first thought was that something was telling the browser to redirect to the 404 page, but Chrome Dev Tools "Network" tab indicates that is not the case.
After it fails that first time, my change works every subsequent time until the application server restarts.
If I hit /login/12345 first it loads fine. Any subsequent attempt to hit /12345 will work fine, so it seems like it might have something to do with the login servlet not being fully initialized until after the first request. Weblogic is closed source, so I'm not able to dig into what's happening.
Here's my question
I know it's a pretty weird thing I'm doing; I'm open to other approaches. But the question is this: what's causing the different request URI on the first attempt, and how do I fix it? I've scoured the HttpServletRequest object in the debugger and I don't see any indication of the real request URI.
Here is what I am trying to do:
Add a special button to attach files to Notes "New message" window. If files were attached using this button, when email sent, they should be uploaded to the server and link to them added to the email.
My question - is it possible (and how) to capture "send mail" event in the plugin for Lotus Notus?
I don't know how an Eclipse plugin would do this. Furthermore, since Notes can be used off-line -- when it would be impossible to upload files to a server -- it would be better to have code running on the Domino server intercept the mail messages and perform the upload.
Most products that hook mail operations on the server use the Lotus Notes C API's Extension Manager functions to hook the EM_BEFORE notification for the EM_NSFNOTEUPDATE event and check whether the NSFNoteUpdate operation occurred within the server's mail.box files, and then check whether the the message requires special processing (i.e., in your case that would be by looking for a special NotesItem that your button code has inserted into the message). The usual coding method for this is to immediately change the status of the message to put it on hold, preventing the Domino router from attempting to send the message while your code is still working on it. Many products actually have two components - the EM hook DLL and a separate server task that receives a signal from the hook DLL, processes the message, and then releases it from on hold status. This approach keeps your code from tying up router threads while processing large files.
(Note: Newer versions of the Domino server have the ability to use OSGI plugins written in Java instead of using the Notes C API for operations like this. I've not looked into the details of how this might work for operations that process mail messages. )
I sort of figured it out. There is a very nice extension point provided in 8.5 - "com.ibm.notes.mailsend.MailSendAttachmentsDialog", that is specifically exists for custom handling of attachments. You can see it in plugin.xml, in IBM\Lotus\Notes\framework\shared\eclipse\plugins\com.ibm.notes.mailsend_8.5.*.jar.
The only problem is - it handles just attachments and does not have access to anything else. So if somebody figured how to get subject line and the message text from there, please reply.
Update: got it.
NotesUIElement elem = (new NotesUIWorkspace()).getCurrentElement();
if (elem instanceof NotesUIDocument) {
NotesUIDocument doc = ((NotesUIDocument) elem);
String to = doc.getField("EnterSendTo").getText();
String cc = doc.getField("EnterCopyTo").getText();
String bcc = doc.getField("EnterBlindCopyTo").getText();
String subject = doc.getField("Subject").getText();
String body = doc.getField("Body").getText();
....
}
is there any way to display messages on the JMS Queue to the client JSP ?
so if any message inserted into the Queue (MessageDrivenBean) , it will shows to the client (browser) ,,
thank you ..
u cannot sent the message to a jsp directly. means u will have no idea when the message will come right so it is async way of communication. In a jsp u can have a ajax component wherein we can poll to the backend system and get populate the messages recieved in a given point of time in intervals.
You Could create a servlet or JSP that responds to some user action like a button click or page refresh and calls the bean to see if there are any in the Queue. You could also call a method in the bean from the servlet that returns the number in queue, etc.
How I can track an email?
I' m using java on the server side for sending emails. I want to track whether it is delivered , opened, etc... How I can do that ?
This is not a Java specific issue.
You can create an HTML email, and embed an invisible gif which will report back to your server. Some software like Outlook and some web mail programs will block this for untrusted emails.
You can request a return receipt. Many mail programs ignore this entirely, and the ones which don't usually ask the user if they want to send it.
Example:
email.AddHeaderField("Disposition-Notification-To","<g.revolution#stackoverflow.com>")
There is no way to ensure that you always get the delivery or open-message notification.
Mailservers may accept the mail and drop it afterwards.
users may read the mail but dismiss the notification.
"Webbugs" (aka images in the html source of the mail that include a special token that allows the mail to be recognized) don't work in most email programs.
As a matter of fact it's very unlikely that you can see that someone got the message.
What you could do is to keep the message on your server and only send a link. If the user clicks that you can be pretty sure that he got the message. But thankfully many users would not click on such links because it's used in fraud and spam.
I suppose you're sending it through SMTP. Whenever your mail is sent to your SMTP server, your java program has no control of it:
1) If you want to know if your mail has been delivered, you should contact your SMTP server somehow (if the SMTP server is outside your control then forget that) and see if your mail has been sent.
2) You can't know if a mail has been opened by its receiver. The maximum you can do is set a flag that the mail requires acknowledgement, but that depends if the user explicitly wants to send that acknowledgment. Other possibility is set some link to your site within the mail that should be clicked to see the content. You will be able to track if the user clicked that link.
what you can do is -
you have to embed an invisible image in the body in which the src will call the page in server and log that event, you can only do it in HTML encoding.
example -
<img src="ImageServer.aspx?imageID=track.jpg& custID=134ghxx34343ai& campID=32434"/>
and then in ImageServer.aspx there will a handling code which will log that event or save it to database.
example -
private void Page_Load(object sender, System.EventArgs e)
{
// content type should be resolved programmatically
Response.ContentType = "image/jpeg";
if (!IsPostBack) Track();
Response.WriteFile(GetImageFileByID());
}
In case you send HTML email, you could add a 1x1 pixel image with some tracking parameters, that calls back to your webserver. It's not 100% reliable since some email clients (and users) block images in emails.
You can add something like
<span style="display:none">Tracking no: ${TRACK_NO}</span>
to the body of the email. This should always be in the response unless the email client strips it out.