com.sun.mail.smtp.SMTPSendFailedException: 530 authentication required (#5.7.1)

Errors:

DEBUG SMTP: use8bit false
MAIL FROM:<nitingautam@……com>
530 authentication required (#5.7.1)
com.sun.mail.smtp.SMTPSendFailedException: 530 authentication required (#5.7.1)

    at com.sun.mail.smtp.SMTPTransport.issueSendCommand(SMTPTransport.java:1333)
    at com.sun.mail.smtp.SMTPTransport.mailFrom(SMTPTransport.java:906)
    at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:535)
    at javax.mail.Transport.send0(Transport.java:151)
    at javax.mail.Transport.send(Transport.java:80)
    at practical.Mailer.main(Mailer.java:37)
QUIT
com.sun.mail.smtp.SMTPSendFailedException: 530 authentication required (#5.7.1)

    at com.sun.mail.smtp.SMTPTransport.issueSendCommand(SMTPTransport.java:1333)
    at com.sun.mail.smtp.SMTPTransport.mailFrom(SMTPTransport.java:906)
    at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:535)
    at javax.mail.Transport.send0(Transport.java:151)
    at javax.mail.Transport.send(Transport.java:80)
    at practical.Mailer.main(Mailer.java:37)
 

 It requires session authentication

Working Code 

package practical;

import java.security.Security;
import java.util.Properties;

import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.PasswordAuthentication;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

public class GoogleTest {

private static final String SMTP_HOST_NAME = "smtp.gmail.com";
private static final String SMTP_PORT = "465";
private static final String emailMsgTxt = "Test Message Contents";
private static final String emailSubjectTxt = "A test from gmail";
private static final String emailFromAddress = "something@gmail.com";
private static final String SSL_FACTORY = "javax.net.ssl.SSLSocketFactory";
private static final String[] sendTo = {"someone@gmail.com"};

public static void main(String args[]) throws Exception {

Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

new GoogleTest().sendSSLMessage(sendTo, emailSubjectTxt,
emailMsgTxt, emailFromAddress);
System.out.println("Sucessfully Sent mail to All Users");
}

public void sendSSLMessage(String recipients[], String subject,
String message, String from) throws MessagingException {
boolean debug = true;

Properties props = new Properties();
props.put("mail.smtp.host", SMTP_HOST_NAME);
props.put("mail.smtp.auth", "true");
props.put("mail.debug", "true");
props.put("mail.smtp.port", SMTP_PORT);
props.put("mail.smtp.socketFactory.port", SMTP_PORT);
props.put("mail.smtp.socketFactory.class", SSL_FACTORY);
props.put("mail.smtp.socketFactory.fallback", "false");

Session session = Session.getDefaultInstance(props,
new javax.mail.Authenticator() {

protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication("something@gmail.com", "pass");
}
});

session.setDebug(debug);

Message msg = new MimeMessage(session);
InternetAddress addressFrom = new InternetAddress(from);
msg.setFrom(addressFrom);

InternetAddress[] addressTo = new InternetAddress[recipients.length];
for (int i = 0; i < recipients.length; i++) {
addressTo[i] = new InternetAddress(recipients[i]);
}
msg.setRecipients(Message.RecipientType.TO, addressTo);

// Setting the Subject and Content Type
msg.setSubject(subject);
msg.setContent(message, "text/plain");
Transport.send(msg);
}
}

Google Toolbar – Field yellow background issue in mozilla

What is the Issue?

If you're a web developer you may have faced this problem at one time or another. If you haven't yet, you most likely will see it at some point. It's the mysterious yellow input fields. On a form, certain textfields inexplicably turn yellow when viewed in Internet Explorer. This is caused by having the Google Toolbar installed and the AutoFill option enabled. AutoFill allows Google to remember your personal information so that it can automatically populate form fields for you, if you desire. Fields such as name, address and phone will all turn yellow if AutoFill is turned on (which is the default setting). If you're anything like me, you probably like having a certain level of control over how things are displayed on your pages and don't like it when a program arbitrarily changes that.

 How does this affect me? I use Mozilla.

  Given that most people surfing the web use Internet Explorer and many of them use the Google Toolbar or a clone thereof, this affects almost anyone who designs a web page. The reality is that most users who have the toolbar installed do not actively use AutoFill, nor do they know how to disable it. When they come to your site and see that on some forms certain fields are yellow, it's not surprising that they can be confused. "Are those the only fields that are required?" "Why are some of these fields yellow when it obviously doesn't go with this color scheme?" In all likelihood it will never occur to them that the issue is their browser, not your site.

Can't I just use a stylesheet or inline styles? 

You can, but they will be overridden, whether you specify them inline or externally. Therein lies the problem. Here's how styles are applied in Internet Explorer as far as AutoFill is concerned:

  1. Styles may be set in the following places:
    • External stylesheets
    • Embedded stylesheets (via <style> tags)
    • Inline styles
  2. All of the styles above can be overridden by the Google Toolbar

Then what's the fix?

 While there is a purely CSS workaround, the recommended solution uses JavaScript. All styles outlined above are applied to the page while the document is loading. Once it has loaded completely, we can then undo whatever damage the toolbar has done. What we need, though, is a fix that will work the same regardless of what is or is not in the stylesheet. In other words, if we change our background color for text inputs in the stylesheet from light blue to light gray, our JavaScript fix should not need tweaking.

At the time of writing, the way the Google Toolbar changes the color of a form element is by explicitly adding background-color: #ffffa0 to its style property. All we need to do is remove it by adding the following code to our document head: 

 

 Code
<script type="text/javascript"><!--   if(window.attachEvent)     window.attachEvent("onload",setListeners);
function setListeners()
{ 
    inputList = document.getElementsByTagName("INPUT");
    for(i=0;i<inputList.length;i++)
{       
inputList[i].attachEvent("onpropertychange",restoreStyles);
inputList[i].style.backgroundColor = "";
}     
selectList = document.getElementsByTagName("SELECT");
for(i=0;i<selectList.length;i++){
selectList[i].attachEvent("onpropertychange",restoreStyles);
selectList[i].style.backgroundColor = "";     }   }
function restoreStyles(){
if(event.srcElement.style.backgroundColor != "")
event.srcElement.style.backgroundColor = "";   }//--> </script>

And that's it. Only Internet Explorer will execute the code, although we'd be fine even if all browsers did. The code places an event listener on every <input> and <select> in the document tree so that if its inline background color is modified, it will instantly reset itself. This means the browser will once again use whatever rules we have defined in our <style> declaration or external stylesheet. An added bonus is the fact that because we used the attachEvent method, this script will coexist with other scripts that are set to run using the window.onload event handler.

If you want to keep things simple, you can just include a JavaScript file containing the code above. Then all you need is <script type="text/javascript" xsrc="googlefix.js"></script> somewhere in your document head.

 Additional Notes

A compromise everyone can live with

For the people that actually use AutoFill, this can be a problem, because it will no longer be apparent that they can use the feature on your site. There are two easy workarounds that still make it apparent that they can use AutoFill without sacrificing your design. The first one is to assign a color of your choice to the AutoFill fields depending on your color scheme (simply modify the script above to assign a new color value in every instance where the toolbar has changed it). The other would be to style all inputs the same but provide an explanatory note visible only to those with AutoFill enabled.

The ideal solution would include both of the above approaches for maximum ease of use. A side benefit of this is that you help educate those people who have AutoFill enabled but don't know what it is and who wonder why so many sites have yellow input fields. The following code illustrates how:

 Code
<script type="text/javascript">
<!--   if(window.attachEvent)     window.attachEvent("onload",setListeners);
function setListeners(){
inputList = document.getElementsByTagName("INPUT");
for(i=0;i<inputList.length;i++){
 inputList[i].attachEvent("onpropertychange",restoreStyles);
inputList[i].style.backgroundColor = "";     }
selectList = document.getElementsByTagName("SELECT");
for(i=0;i<selectList.length;i++){
selectList[i].attachEvent("onpropertychange",restoreStyles);
selectList[i].style.backgroundColor = "";     }   }
function restoreStyles(){
if(event.srcElement.style.backgroundColor != ""  &&
event.srcElement.style.backgroundColor != "#a0d0ff"){
      event.srcElement.style.backgroundColor = "#a0d0ff";
/* color of choice for AutoFill */
 document.all['googleblurb'].style.display = "block";     }   }//--> </script>

 

 
 and include this directly above your form:
<div id="googleblurb" style="display:none;">
You can use the AutoFill function on the Google toolbar to fill out
the highlighted fields on this form.   <a xhref="http://toolbar.google.com/autofill_help.html"   title="AutoFill Help Page">Learn more</a>.
 </div>

 

 As long as you aren't setting any inline styles for your inputs, only people with the AutoFill  feature enabled on the toolbar will see the note and the re-styled inputs (and even then only if  the page actually has fields that AutoFill can complete).  Special thanks to Dean Owen for  additional insights on this subject.  
Pure CSS  
I should point out that making a declaration !important in your stylesheet will also override the AutoFill styles. However, it does not allow  to specifically target AutoFill fields (say, if you want them to be pale blue and other ones gray),  or to have content strictly for AutoFill users. If you do not plan on implementing the compromise above,  this may be a simpler solution for your needs.  

 
 

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver class ‘org.hsqldb.jdbcDriver’

Problem 

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver class 'org.hsqldb.jdbcDriver'
    at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:766)
    at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
    at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:81)
    at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
    at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
    at org.springframework.orm.hibernate3.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:805)
    at org.springframework.orm.hibernate3.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:745)
    at org.springframework.orm.hibernate3.AbstractSessionFactoryBean.afterPropertiesSet(AbstractSessionFactoryBean.java:134)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431)
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163)
    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:271)
    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:128)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1047)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:843)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:427)
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163)
    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:271)
    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:128)
Caused by: java.lang.ClassNotFoundException: org.hsqldb.jdbcDriver
    at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:141)
    at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:760)

Solution 

 Tomcat is unable to find the hsqldb.jar please put this inside "tomcat\common\lib" directory.

& your problem is solved my friend 🙂  . 

Ant within Eclipse: switching JDKs and finding tools.jar – com.sun.tools.javac.Main is not on the classpath.

I've been doing quite a lot of work creating new Ant build processes and grokking Eclipse (installing and reinstalling on different machines), and this is a problem that keeps recurring. This morning I cleaned up vast amounts of garbage on my main Windows machine, garbage left over from old J2SDK installs (I had FOUR–when will Sun fix the install problem?) and I reinstalled JDK 1.4.2_03 and then tried running everything again within Eclipse (v3.0 M7). Needless to say, Ant was running fine before, after I had pointed to tools.jar but now that I had changed JDKs it wasn't guaranteed that it would run–and it didn't. While it is possible that this is so well known that people do it without thinking, it certainly isn't clearly documented, and it's a situation that people will probably find regularly doing a clean install of Eclipse and the JDK on a machine, or when upgrading JDKs after the settings have been done long ago–and forgotten. 🙂

First, the situation. On restart, Eclipse correctly detected the new JRE (clearly from the registry entries created by the JDK/JRE install) to the one the JSDK installs in C:\Program Files\Java\… but it's better to change the pointer to the JRE within the JDK IMO. Even then, Ant doesn't work. The error message you get is for Ant:

[javac] BUILD FAILED: [build file location here]
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

Of course, JAVA_HOME is pointing to the right location, in both the OS environment and within Eclipse (This variable can be set within Eclipse through Window > Preferences > Java > Classpath Variables).

So how to fix the Ant build problem?

I found various solutions searching, for example running Eclipse with "eclipse -vm [JDKPATH]\bin" but that didn't quite satisfy me (I wanted something that could be configured within the environment). Other solutions to the problem where even more esoteric.

The best solution I've found (after a little bit of digging through Eclipse's options) is to edit Ant's runtime properties. Go to Window > Preferences > Ant > Runtime. Choose the Classpath tab. Select the Global Properties node in the tree and click Add External JARs. Select tools.jar from your JDK directory (e.g., j2sdk1.4.2_03\lib\tools.jar). Click Apply and OK, and you should be on your way. Not too hard when you know what to do. Now if this could only be done automatically by Eclipse on install…

SEVERE: Error reading tld listeners java.lang.NullPointerException

SEVERE: Error reading tld listeners java.lang.NullPointerException, the error appears to come from log4j.

I came across this error when reloading a context in Tomcat 5.5.23.

The solution appeared to be to remove commons-logging from WEB-INF/lib of my web app. I’d only added it because Jakarta’s HttpClient insisted on it.

Once again, when in doubt, blame commons-logging.