I was seeing this issue since loong time but never really got to the crux of it. After getting extremely annoyed with this message after every time I tried printing something from a GTK app, I finally decided to solve this problem. Interestingly this problem does not come for Qt (KDE) apps. Only GTK (Gnome) applications are affected.
I found a solution in this post http://ubuntuforums.org/archive/index.php/t-829706.html
Simple solution for this problem is to copy your printer. That will create a new copy of the existing configured printer. Now just print using the newly created printer. Everything works now!!
Don't ask me how!!!
Printer in Ubuntu "Cannot prompt for Authorization"
on
Tuesday, May 04, 2010
Labels:
gnome
,
ubuntu
0
comments
Myth about InputStream.read(byte [], int, int) method
on
Saturday, April 24, 2010
Labels:
Java
,
java.io
0
comments
I know it may sound stupid but only yesterday I discovered that
What that means is if you are doing something like,
There is good explanation in javadocs about this method. The default implementation of this method at the level of InputStream class does this,
So out of my curiosity, I wrote a sample where I had a ServerSocket as a produces producing 2 bytes and waiting for 1 second. And a consumer using Socket which would attempt to read 4 bytes at a time without waiting. The problem was easily reproduced and I could see my every read call in consumer only reading 2 bytes at a time.
BufferedInputStream provides a more convinient implementation of the read method. It repeatedly invkoes the multibyte read method on the underlying stream until
In my case our SocketInputStream was wrapped in the BufferedInputStream, which relatively shielded us from this problem but it aggrevated the problem as we saw this problem very rarely. Only after some code review is what we identified this issue.
Now a few questions in your mind maybe why call the multibyte read? why not just keep calling single byte read and track how many bytes we read? One of the grey hair in my company answered this question saying,
So when does the multibyte read call wait then? Since it is capable of returing lesser bytes than requested, it can always just return with lesser data. My guess is that it will only block when there are 0 bytes avaialble to read. In a way multibyte read call will never return 0, as it will make an attempt to read at least one byte.
InputStream.read(byte [] data, int offset, int length)method can end up reading lesser number of bytes than length.
What that means is if you are doing something like,
InputStream in = getInputStream(); // getting it from somewhere..The you cannot gurantee that in.read() call will read 10 bytes even when the stream is connected / not broken (applicable particularly in sockets). My understanding was that if it ever returns lesser bytes than lenght, then the channel us broken and we should assume that connection is dropped from counter-party.
byte data = new byte[10];
int read = in.read(data, 0, data.length);
System.out.println("Bytes read: " + read);
There is good explanation in javadocs about this method. The default implementation of this method at the level of InputStream class does this,
- It tries to read the first byte from the stream. If the read fails due to any other reason other than end of stream, then IOException is thrown. If end of stream is detected, -1 is returned.
- After the first read, if any of the subsequent read throws and IOException, It is swallowed and end of stream is assumed and the number of bytes read until this point are returned. If any of the subsequent reads detects end of stream, again whaterver bytes are read are returned.
So out of my curiosity, I wrote a sample where I had a ServerSocket as a produces producing 2 bytes and waiting for 1 second. And a consumer using Socket which would attempt to read 4 bytes at a time without waiting. The problem was easily reproduced and I could see my every read call in consumer only reading 2 bytes at a time.
BufferedInputStream provides a more convinient implementation of the read method. It repeatedly invkoes the multibyte read method on the underlying stream until
- Length number of bytes are read
- End of stream is reached
- Subsequent call to read will block. This is identified by calling available method on the stream.
In my case our SocketInputStream was wrapped in the BufferedInputStream, which relatively shielded us from this problem but it aggrevated the problem as we saw this problem very rarely. Only after some code review is what we identified this issue.
Now a few questions in your mind maybe why call the multibyte read? why not just keep calling single byte read and track how many bytes we read? One of the grey hair in my company answered this question saying,
Whe we use to do it in C, the multibyte read made sure that there were fewer stack pushes and pops as we would end up doing fewer read calls.I havent personally measured the performance gain by using multibyte read but Ithink it never hurts using it if you understand how it works.
So when does the multibyte read call wait then? Since it is capable of returing lesser bytes than requested, it can always just return with lesser data. My guess is that it will only block when there are 0 bytes avaialble to read. In a way multibyte read call will never return 0, as it will make an attempt to read at least one byte.
Good comparison of OpenESB and ServiceMix
on
Friday, April 09, 2010
Labels:
ESB
,
GlassfishESB
,
ServiceMix
0
comments
Quick way to untar and bunzip files in java
on
Tuesday, April 06, 2010
Labels:
ant
,
bzip
,
Java
,
tar
0
comments
Have you ever felt a need to deal with bzip2 compressed tarballs in Java? Recently I compressed a lot of test resources in our source tree using bzip2 compression. The resources were static and were meant to change very rarely. bzip2 was the best choice in terms of amount of compression. What it also meant was my SVN download of the source tree would take much lower time. I planned to extract the resources and make them available at runtime while running tests.
If you already know, there is no way to handle bzip compression in Java core API. But at the back of my mind I knew that you can create bzipped tarballs using Ant. So I looked at the Ant tasks and figured that there was untar task which can be instructed to also process it through bzip2 uncompression.
Here is the code snippet that can untar and bunzip the file using Java code.
Also make sure that you put ant jar on the classpath.
Maven users can simply add following dependency,
If you already know, there is no way to handle bzip compression in Java core API. But at the back of my mind I knew that you can create bzipped tarballs using Ant. So I looked at the Ant tasks and figured that there was untar task which can be instructed to also process it through bzip2 uncompression.
Here is the code snippet that can untar and bunzip the file using Java code.
Untar untar = new Untar();
untar.setSrc(new File("./src/test/resources/files.tar.bz2"));
untar.setDest(new File("./target"));
UntarCompressionMethod compression = new UntarCompressionMethod();
compression.setValue("bzip2");
untar.setCompression(compression);
untar.setOverwrite(true);
untar.execute();
Also make sure that you put ant jar on the classpath.
Maven users can simply add following dependency,
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.0</version>
<scope>test</scope>
</dependency>
Disabling test under JUnit 4.4
on
Sunday, April 04, 2010
Labels:
Java
,
junit
,
maven
0
comments
Recently I had to disable a unit test in our test system. We use Maven as our build tool and JUnit 4.4 for unit testing. I had a few options,
After looking at the JUnit javadocs, I stumbled upon an annotation @Ignore it is indeed an annotation to be used if you want to skip the test.
So if you want to disable your test case in JUnit 4.4 just annotate your test methond with @Ignore @Test annotations.
What it also did was that Maven started reposting one test as being "Skipped" which is nicer as it keeps reminding you that you need to look after the test that you have disabled.
- Exclude that particular class from tests under surefire plugins configuration in my pom.xml
- Remove @Test annotation from test method in the test class. Which fails as it finds a Test class but does not find any test methods
- Rename the class from say MyTest to something that does not end with "Test" say "Tezt"
After looking at the JUnit javadocs, I stumbled upon an annotation @Ignore it is indeed an annotation to be used if you want to skip the test.
So if you want to disable your test case in JUnit 4.4 just annotate your test methond with @Ignore @Test annotations.
What it also did was that Maven started reposting one test as being "Skipped" which is nicer as it keeps reminding you that you need to look after the test that you have disabled.
Wow! Thunderbird now reminds me to attach the file
on
Monday, March 29, 2010
Labels:
thunderbird
0
comments
Thunderbird 3.0.3 introduces a great feature that reminds you to attach a document in case you type words like "attaching" in your email. It scans through the matter of the composed email finds relevant word that may indicate that you may want to attach some file. Here is a screenshot.
Thunderbird 3.0.3 migration
on
Wednesday, March 24, 2010
Labels:
Linux
,
thunderbird
,
ubuntu
0
comments
I recently migrated to Thunderbird 3.0.3 There is a specific problem with Thunderbird that I have seen at times. Ever faced a problem of loosing your mail data and accounts after migrating to new Thunderbird? Thunderbird stores data under directory named .thunderbird in your home. But maybe just in Ubuntu or some versions of Thunderbird store it under directory named .mozilla-thunderbird. So if after installing a new Thunnderbird and restarting it, if you are not able to see your e-mails, it might well be the problem of directory names.
To resolve, try renaming the directory (Whatever applies to you),
> mv .mozilla-thunderbird .thunderbird
or
> mv .thunderbird .mozilla-thunderbird
Restart your Thunderbird and now you should be able to see your e-mails.
I have mostly seen this problem when I install Thunderbird externally i.e. not through package manager. By installing I mean simply extracting it to /opt and not doing "./configure make install"
To resolve, try renaming the directory (Whatever applies to you),
> mv .mozilla-thunderbird .thunderbird
or
> mv .thunderbird .mozilla-thunderbird
Restart your Thunderbird and now you should be able to see your e-mails.
I have mostly seen this problem when I install Thunderbird externally i.e. not through package manager. By installing I mean simply extracting it to /opt and not doing "./configure make install"
RIA frameworks and HTML 5
on
Saturday, February 27, 2010
Labels:
flex
,
html 5
,
pivot
,
ria
0
comments
Recently when Steve Jobs wrote off Adobe Flash support in iPad, I went ahead and read more about HTML 5.0 and I am convinced that once HTML 5.0 is out, there will be no need of the fancy RIA frameworks like Apache Pivot and Adobe Flex.
HTML 5.0 introduces everything from videos, audio as well as shapes as part of the specification (introduces tags
But indeed HTML 5.0 is the future. If you are planning to develop your products based on Adobe Flex or Apache Pivot then think twice.
HTML 5.0 introduces everything from videos, audio as well as shapes as part of the specification (introduces tags
But indeed HTML 5.0 is the future. If you are planning to develop your products based on Adobe Flex or Apache Pivot then think twice.
Why I like Twitter!
on
Thursday, February 11, 2010
Labels:
blogger
,
twitter
0
comments
With only about 30 odd posts in last 4 years over here, and already about a 35 tweets in a couple of months, I really have started liking twitter. I ask myself why did I not blog so much? Answer is simple, everytime I tried to write a blog entry, I never had a restriction of number of words. I always felt as if I needed to fill the space (for no reason) With Twitter its just soo much more easy.
Animal Sniffer Maven Plugin
on
Friday, February 05, 2010
Labels:
api
,
Java
,
maven
,
maven plugins
0
comments
While looking at the Maven plugins at Codehaus, I just stumbled upon a maven plugin named Animal Sniffer. This plugin could be a great tool for people working on frameworks where API's are published to the user. There is always a problem of API loosing the compatibility across versions (for eg. making some method final looses backward compatibility). These kind of problems are very very difficult to trap.
I wanted to evaluate this plugin for instrumenting our internal API against which following versions can check compatibility. Firstly I am not sure if Animal Sniffer can be used in this way but I believe it could be.
I tried to play with the plugin a little where I figured out that vresion 1.5-SNAPSHOT cannot be downloaded from the Codehaus snapshot repository and older versions 1.4, 1.3 encounter an NPE when I run animal-sniffer:build goal.
Does anyone have experience with Animal Sniffer?
I wanted to evaluate this plugin for instrumenting our internal API against which following versions can check compatibility. Firstly I am not sure if Animal Sniffer can be used in this way but I believe it could be.
I tried to play with the plugin a little where I figured out that vresion 1.5-SNAPSHOT cannot be downloaded from the Codehaus snapshot repository and older versions 1.4, 1.3 encounter an NPE when I run animal-sniffer:build goal.
Does anyone have experience with Animal Sniffer?
