The blog as a knowledge base

Microsoft has a term "knowledge base article" which solves a particular problem or at least describes it better.
It comes out, there's a term

Today was the second time I use the blog as a knowledge base. I know I have stumbled upon a problem, I think I wrote about it, I search the blog - there it is, and it solves my problem again.
Great, another usage of the seemingly useless blog.

Tomcat under attack, manager password exploited, trojan deployed

There's an Apache Tomcat I'm managing that's in the wild (internet).

Saturday evening it was under attack.

I use Tomcat's manager console to drop applications from time to time and I had it's password pretty simple. Within this console a new java web application may be installed.
What's even worse is that that Tomcat instance was running with pretty high privileges.

It was a test machine, only a few guys knew the address.

So using this console a trojan was inserted. The admin password was changed. This trojan might have succeeded if it weren't for the antivirus that got the trojan on time (yes, it was a windows machine).
The trojan is called TROJ_DELF.BDG and it was deployed in webapps/fexshell/init.exe

Now the tomcat is running with pretty low privileges, the port is not so obvious, and the manager password is changed.

Importing a class from the 'default package' (no package) - impossible

Did you know that classes in the 'default package' (classes that don't have a package) cannot be imported from classes that do have a package?

I did not know that.

Try it:

This is what javac says:


>javac package2\ -cp .

package2\ '.' expected
import Class1;
package2\ ';' expected
import Class1;
2 errors

How stupid is this?
Is this why omitting package is deprecated?

Javac bug, Eclipse innocent, bug in static imports

I had an issue compiling some java classes. Javac failed, Eclipse's compiler worked. The issue is described here.
I was blaming Eclipse, I was blaming java6's endorsing. I was thinking it was due to JAXB.

It comes out they all were innocent.

Here's my code:

package f;


import static f.ProblematicClass.E1.E2.VALUE;


import javax.annotation.Resource;


public class ProblematicClass {



    public static enum E1 {



        private E1( E2
requiredBankAccounts ) {



        public static enum E2 {





The result with javac is:

>javac f\

f\ cannot find symbol
symbol  : class Resource
location: class f.CorrectClass1
1 error

After some research I think I simplified the problem:
(If I continue to simplify it would still fail to compile but at some
point it would start to compile which yesterday drove me crazy.
This is the most simplistic case that consistently fails to compile)

package f;


import static f.ProblematicClass.E1.VALUE;



public class ProblematicClass {



      public static enum E1 {




All of these changes fix the compilation error (from javac):


// Reverse the order of imports


import static f.ProblematicClass.E1.VALUE;



      // Use the FQN of the annotation


      public static enum E1 {




This all makes me think that the static import fails the next one only if the next one is an annotation (I've tried with a java.util.Collection - it compiled).
I have tried this with jdk6u3 and jdk6u10.
I don't have jdk 1.5. Can someone test it on jdk 1.5?

Update: GRRRRRRRRRRRRRR, Somebody found it before me:
It was reported on 27th of June, 2006 :'(

Here's what they say:

1) switching the order of the import statements works (although they often get changed back by our development tools).
2) Commenting out the static import statements, then compiling, then putting the import statements back and
compiling again with the old classes still there also works. This means that the compiler errors happen at the strangest
of times
, and in large programs it can be very difficult to work out how to workaround the problems.

Weird javac case - Eclipse's compiler is wrong again.

I have some code.
I have two classes. They both have inner enums.
The two inner enums have an annotation.

But one of them does not compile. The other one compiles just fine.

In eclipse there's no error, but when I build the code from ant I get a compilation error - the annotation class is not found:

[javac] cannot find symbol
[javac] symbol  : class XmlType
[javac] location: class package.ProblematicClass
[javac]     @XmlType(name="fff")
[javac]      ^
[javac] 1 error

I spent some time looking for it - I thought that the classpath is wrong, I endorsed an updated version of the API (java 6). The issue persisted.

Then I decided to use javac directly:

javac -verbose -classpath lib\X.jar;lib\X2.jar -d bin -sourcepath src -encoding UTF-8 src\package\

Strangely enough I got the same error?! Then I did the same for the class that did compile successfully using ant - it worked.
So there was a difference between the two classes and I had to find it.

And I found it, can you find it?



//Does not compile

public class ProblematicClass


@XmlType( name = "fff1" )

public static enum InnerType {}


// Compiles

public class CompilableClass


@XmlType( name = "fff2" )

public enum InnerType {}


Yes, you're correct. The second enum is not static.
This only happens with inner static enums. The anomaly does not occur if it's an inner static class. I don't know why.

So I'm thinking that in the ProblematicClass the annotation is not visible because the import of XmlType is not visible.
I was correct - this one works:




//Does not compile

public class ProblematicClass


@javax.xml.bind.annotation.XmlType( name = "fff1" )

public static enum InnerType {}


I just supplied the FQN of @XmlType.

So eclipse is working, javac is not. Now is the time to say that Eclipse is not using javac. I thought it was using jikes (made by IBM), but that's not correct. Eclipse is using its own incremental compiler part of JDT Core. JDT stands for Eclipse Java Development Tools.

JDT Core is the Java infrastructure of the Java

IDE. It includes:

  • An incremental Java compiler. Implemented as an Eclipse

    builder, it is based on technology evolved from VisualAge for Java compiler.

    In particular, it allows to run and debug code which still contains unresolved


  • ...

So either javac or Eclipse's compiler is wrong. I would bet that javac is following the spec more strictly.

This is the second time I'm catching Eclipse's compiler of misconduct. The first time was something related to a very complex case with generics - one of the compilers said it was a warning, the other - error.

Update: I was wrong. I was trying to report the problem. I was making a pretty simple case. I used a different annotation: @javax.annotation.Resource. It worked both on Eclipse and on javac.
So the problem is somehow linked with JAXB.

JAXB is an API bundled with Java 6 (an 'endorsed standard' a 'standalone technology'). The version bundled was JAXB 2.0. If one wants to use a newer version, say JAXB 2.1, an 'Endorsed Standards Override Mechanism' had to be used.

Info on JAXB here.
Info on endorsed mechanism here.

I'm currently with JDK 6 update 10. Somewhere I saw that 'endorsed standard override mechanism' was no longer necessary.

It looks like the problem is more on javac side than on Eclipse's compiler.

I will investigate further.

Update2: It comes out that 'Endorsed Standards Override Mechanism' was existing prior to java 6. Only the standalone technologies were added in Java 6.

Update3: It comes out that 'Endorsed Standards Override Mechanism' is still used.

Update4: It comes out that this bug is very hard to reproduce. My simple examples at some point just started compiling 🙁

Update5: I just created some code that consistently reproduces the bug. I'll write it in a new entry to be cleaner.

Update6: I fixed coloring and finished the new article on the bug.

JAX-WS: Always clean-up generated stuff before regenerating.

I'm using JAX-WS.
When I'm generating stuff for a web service I generate the jaxws package in a 'gen' source folder.
I don't need the compiled stuff so I generate it to a temp folder that I don't care about.

It comes out that I do have to care about that folder because yesterday I got an obscure error: The serviceName cannot be retrieved from an interface.

This error has only 1 (one) hit on Google. Don't trust me?
Try this one out:

The use case in the forum has nothing to do with my environment so I cleaned up and everything worked like a charm.

I've always been unhappy with how production unready wsgen is (here).


Recently I had to move 200GB from one hard-drive to another.
It was imperative to make sure everything was copied successfully.

Using a binary comparison tool would take a really long time. So I only check the total file size of all files copied and the number of files.
I tried copying these 200GB files several times and never succeeded. I was too lazy or busy to investigate until today when I got really pissed off.

It comes out that the difference comes from thumbs.db files.

Thumbs.db is a thumbnail cache used by Windows XP and Windows 2k3 Server.

How to stop the creation of these files:

  1. Click Start
  2. Double-click Control Panel
  3. Double-click Folder Options
  4. Click on the View tab
  5. Check off the circle next to Do not cache thumbnails
  6. Click the Ok button

Quote of the day

Those who would sacrifice liberty for security deserve neither.

Benjamin Franklin

In Bulgarian:
Този, който е готов да пожертва свободата заради сигурността, не заслужава нито едно от двете.

Бенджамин Франклин

Google translating whole sites

I accentally went to
The weird part is that when one presses "English" (since it's in German) it goes to:|en&u=
I didn't know that Google can translate whole web sites.

The translation seems to be pretty good.
The site look&feel is exactly the same.

Very good thing.