admin – Page 3 – techbuddha.in

January 20, 2009June 12, 2011

Client does not support authentication protocol requested by server; consider upgrading MySQL client

I have installed MySql 5.1 version on my lappy and when I try to connect with the DB it was giving me following error:

“Client does not support authentication protocol requested by server; consider upgrading MySQL client”

MySQL 5.1 uses an authentication protocol based on a password hashing algorithm that is incompatible with that used by older (pre-4.1) clients. If you upgrade the server from 4.0, attempts to connect to it with an older client may fail with the above message.

To solve this problem, you should use one of the following approaches:

Upgrade all client programs to use a 4.1.1 or newer client library.
When connecting to the server with a pre-4.1 client program, use an account that still has a pre-4.1-style password.
Reset the password to pre-4.1 style for each user that needs to use a pre-4.1 client program. This can be done using the SET PASSWORD statement and the OLD_PASSWORD() function:

mysql> SET PASSWORD FOR -> ‘some_user‘@’some_host‘ = OLD_PASSWORD(‘newpwd‘);

Alternatively, use UPDATE and FLUSH PRIVILEGES:

mysql> UPDATE mysql.user SET Password = OLD_PASSWORD(‘newpwd‘) -> WHERE Host = ‘some_host‘ AND User = ‘some_user‘; mysql> FLUSH PRIVILEGES;

Earlier to this command password look like this

After the command it changed it to this.

This works for me. Hope this will help

Reference:http://dev.mysql.com/doc/refman/5.1/en/old-client.html

March 26, 2008July 8, 2011

How to change Eclipse SVN Plugin Password

Subclipse does not collect or store username and password credentials when defining a repository. This is because the JavaHL and SVNKit client adapters are intelligent enough to prompt you for this information when they need to — including when your password has changed.

You can also allow the adapter to cache this information and a common question is how do you delete this cached information so that you can be prompted again? We have an open request to have an API added to JavaHL so that we could provide a UI to do this. Currently, you have to manually delete the cache. The location of the cache varies based on the client adapter used.

JavaHL caches the information in the same location as the command line client — in the Subversion runtime configuration area. On Windows this is located in %APPDATA%\Subversion\auth. On Linux and OSX it is located in ~/.subversion/auth. Just find and delete the file with the cached information.

SVNKit caches information in the Eclipse keyring. By default this is a file named .keyring that is stored in the root of the Eclipse configuration folder. Both of these values can be overriden with command line options. To clear the cache, you have to delete the file. Eclipse will create a new empty keyring when you restart.

Note: If using tortoise SVN, can reset the same by going to settings > Saved Data and clear Authentication Data.

March 24, 2008March 24, 2008

A simple class for converting any Java object to XML string

In need to save XML representation of your Java object Here is a simple 200-line class that will do this using reflection. But don`t worry, there is some very powerful caching going on, so that the performance will be very good.

// OptimizedReflectionMarshaller.java

package my;

import java.io.IOException;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.Collection;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;

import org.jdom.Document;
import org.jdom.Element;
import org.jdom.output.XMLOutputter;

/*
* This is a utility class that marshals a Java Object into an XML
* String. Originally, this used StringBuffer to build the XML
* String. However, it has been modified from it's original
* version to build the XML with JDOM instead.
*
* @author Kirill at http://www.topxml.com/rbnews/XML/re-2909_A-simple-class-for-converting-any-Java-object-to-XML-string.aspx
*
* @date January 21, 2008 – modified
* @author Jimmy Honeycutt – modified to use JDOM to create XML instead of StringBuffer.

*/
public class OptimizedReflectionMarshaller {
// cache for getters
private static HashMap gettersMap = new HashMap();

// cache for storing info on whether certain class implements Collection
private static HashMap collectionsMap = new HashMap();

   private static final String JAVA = "java.";
   private static final String JAVAX = "javax.";

   private static final Class[] EMPTYPARAMS = new Class[0];
Continue reading “A simple class for converting any Java object to XML string”

February 18, 2008February 18, 2008

Java.io.IOException: Invalid header signature; read

Hi,

Today I was creating a Java Program to read a Excel files (created by importing text log files) using POI HSSF and faced the following errors:

java.io.IOException: Invalid header signature; read 8751655596022002505, expected -2226271756974174256 .

After a analysis i found that the excel file I am using is not an Excel binary file. It's a text file with a .xls extension s.t. Excel can quietly convert it and display as a spreadsheet. HSSF deals with files written in Excel format only.

I used the Save As… command to save that file as Excel . And now the problem is Solved :).

February 12, 2008July 21, 2008

document.forms[0].submit is not a function

Firstly check do you have any fields or buttons etc... on the form that have the name or id "submit".

If so these will shadow (hide) the submit function of the form object and thus attempting to call form.submit()

will give you an error as you are now attempting to call an object that is not of the function type (functions injavascript

are objects to and exist as properties of their parent object in the same way as other objects).

February 5, 2008May 26, 2009

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)

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);
}
}

December 30, 2007June 6, 2008

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:

Styles may be set in the following places:
- External stylesheets
- Embedded stylesheets (via <style> tags)
- Inline styles
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.

December 9, 2007

Author: admin