Windows update KB2735855

Hello, 21.9.2012

Do you have Windows?
Is your stream freezing, timeouting, or you are getting samething like this:

missing CR

Caused by: org.jvnet.mimepull.MIMEParsingException: java.io.IOException: missing CR
 at org.jvnet.mimepull.MIMEParser.fillBuf(MIMEParser.java:436)
 at org.jvnet.mimepull.MIMEParser.readBody(MIMEParser.java:204)
 at org.jvnet.mimepull.MIMEParser.access$600(MIMEParser.java:62)
 at org.jvnet.mimepull.MIMEParser$MIMEEventIterator.next(MIMEParser.java:154)
 at org.jvnet.mimepull.MIMEParser$MIMEEventIterator.next(MIMEParser.java:123)
 at org.jvnet.mimepull.MIMEMessage.makeProgress(MIMEMessage.java:193)
 at org.jvnet.mimepull.MIMEMessage.parseAll(MIMEMessage.java:176)
 at org.jvnet.mimepull.MIMEMessage.(MIMEMessage.java:89)
 at com.sun.xml.ws.encoding.MimeMultipartParser.(MimeMultipartParser.java:88)
 at com.sun.xml.ws.encoding.MimeCodec.decode(MimeCodec.java:180)
 at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:352)
 ... 101 more
Caused by: java.io.IOException: missing CR
 at sun.net.www.http.ChunkedInputStream.processRaw(ChunkedInputStream.java:378)
 at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:545)
 at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582)
 at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669)
 at java.io.FilterInputStream.read(FilterInputStream.java:116)
 at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2668)
 at java.io.FilterInputStream.read(FilterInputStream.java:116)
 at org.jvnet.mimepull.MIMEParser.fillBuf(MIMEParser.java:434)
 ... 111 more

or

XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '<' (code 60)excepted either space or "?>" after PI target

Uninstall Windows Update KB2735855

Boys totally destroyed TCP. I hate them! It took us a lot of time to find out what is going on.

Spring Security - How to prolong resonse times on login failed?

Spring Security - How to prolong resonse times on login failed?
It seems that there is nice and simple way to achive it, if you create own UsernamePasswordAuthenticationFilter.

An article on this topic can be found here http://mrather.blogspot.cz/2010/02/extending-usernamepasswordauthenticatio.html

import org.springframework.security.core.AuthenticationException;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class CustomUsernamePasswordAuthenticationFilter extends
        UsernamePasswordAuthenticationFilter {

    @Override
    protected void unsuccessfulAuthentication(HttpServletRequest request,
                                              HttpServletResponse response,
                                              AuthenticationException failed)
            throws IOException, ServletException {
        super.unsuccessfulAuthentication(request, response, failed);

        //Well login failed - we are going to prolong server response

        String username = request.getParameter(getUsernameParameter());
        String password = request.getParameter(getPasswordParameter());
        String ip = request.getRemoteAddr();

        //And here must be some code,
        // that prolong response based on previous login failed attempts
        ownResponseTimeProlonger.prolong(username, password, ip);
    }
}

OK - now you just need, or find something like ownResponseTimeProlonger.prolong(username, password, ip);

Mercurial hg vs. Git

Ten článek je ještě rozepsaný a ještě by potřeboval dost upravit, ale stejně už ho publikuju... :)

Už nějakou dobu se zabývám otázkou, jestli je lepší používat Mercurial (hg), nebo Git. A ať počítám, jak počítám vcelku jasným vítězem je Mercurial. Zkusím tu uvést pár věcí, proč si myslím, že je to tak.

-

Proč Mercurial:

• Mercurial je jednodušší
  

  To je dle mého velmi důležité. Pokud něco programujete, chcete se zaobírat tím, jak to udělat, a učit se věci, které potřebujete k psaní kódu, a ne trávit hodiny nad Gitem a řešit, co a jak kam commitnout.

  Další věc je, že klasicky neprogramujeme sami. A rozhodně je mnohem jednodušší naučit nováčka Mercurial než Git. Navíc se s Mercuriálem o dost snižuje riziko, že tam nováček něco vymňoukne, protože je to střelec. Nebudete pak pracně zachraňovat jeho kód, nebo nedej bože Váš vlastní.

  Git je mocný a umožní Vám udělat skoro všechno, o co mu řeknete (což beru jako velkou nevýhodu). Může se stát, že Vám někdo nezkušený zavolá "git-push --force" a to může vést k přepsání a ztrátě historie na serveru. Takže nováček Vám zruší váš kód a to tak, že ho už nikdy neuvidíte. To v Mercuriálu naštěstí nejde. A věřte mi, hlavní, co chci po verzovacím systému, je abych nepřišel o to, co tam dávám, a cokoli mohl výtáhnout z historie (proto ho mám). Ne že mi to Vonásek zlikviduje.
  Git se dá nějak nastavit, aby to zakazoval, ale vy si vždycky vzpomenete to nastavit? Já teda ne!
  To je věc, u které takřka ztrácím důvěru k verzovacímu systému...

  Pak Vám také lidi budou více mluvit o programování a nebudou tolik řešit, jakou skvělou fintu mohou udělat s verzovacím nástrojem (což je, přiznejme si, lákavé, ale kontraproduktivní).

  Git má více commandů s více způsoby použití, což je pro učení náročnější.

  
  

  Popravdě nad Gitem i Hg vede v jednoduchosti Subversion, kterou jsou po školení schopni úspěšně používat i lidé na úřadě. Pro verzovaní a sdílení svých dokumentů. Ale Subversion zase není distribuovaná, což se při vývoji může vskutku hodit.

• Git má špatnou podporu pro Windows
  

  Mercuriál je od začátku psaný, aby byl multiplatformní, zatímco Git byl napsán pro správu zdrojáků Linuxového jádra. Jeho podpora pro Windows je spíš dílem "bandy nadšenců" a je rozhodně na druhé koleji. Z toho pramení dost problémů s Gitem na Windows, které vskutku nejsou dílem náhody.

  Lidé zkrátka používají různé Operační systémy. A verzovací systém je musí plně podporovat. Zde Git pokulhává a Hg exceluje.

• V podstatě není pravda, že by Git měl více funkcí než Mercurial
  

  Mercurial je totiž stále ve vývoji. Sice byly věci, které oproti Gitu neuměl, ale ve většině případů tam už byly dodělány.

  Spousta příkazů Gitu jsou na Windows mnohem pomalejší.

• Github
  

  Github je skvělý a popravdě v současné době nejlepší. Je to hlavní, a z mého pohledu jediná, výhoda Gitu (protože Github umí jen Git). Nicméně třeba tokový Bitbucket je rovněž velmi dobrý, zlepšuje se a pochybuji, že by Vám nestačil.

• Git je 15x pomalejší při práci přes http
  

  Při použití http protokolu je Git drasticky pomalejší než Mercurial. Zase musíte jít a nastavit Gitu, aby se použil jeho speciální protokol. Při použití gitového protokolu je pomalejší už jen o zanedbatelně málo. Takže zase jestli chcete řešit, proč je to pomalé, a chcete si dávat pozor na to, co jak kde nastavíte, vezměte si Git.

• GUI nástroje pro Mercurial
  

  Pro Mercuriál existuje pěkný a především udržovaný a funkční GUI nástroj TortoiseHg. Pro Windows i Linux. (GUI existuje snad i pro Mac)

  Podpora v různých IDE je srovnatelná.

• Mercurial dbá na zpětnou kompatibilitu.
• Mercurial má krásně udělané pluginy.

Takový vtipný bonmot:
Proč se o Gitu hodně mluví? Protože ho skoro nikdo neumí pořádně používat a všichni řeší, jak udělat tohle a tamto, místo toho aby programovali. Kdežto Mercuriál prostě funguje, a tak jeho uživatelé nemají potřebu tlachat o tom, jak verzovat svůj kód.

Závěr

Git není špatný, ale proboha používejte Mercurial, protože s ním prostě verzujete.

Java - Jak poznat, že adresa je localhost

Již několikrát jsem bojoval s tím, že jsem nebyl schopen rozumě poznat, že adresy "myComputer", "192.168.2.8" patří localhostu. Bylo to, když jsem potřeboval zjistit, že ten s kým komunikuji běží na stejném počítači.

Zdá se, že jsem náhodou konečně narazil na řešení, které se zdá být zatím funkční. Našel jsem ho na stackoverflow http://stackoverflow.com/questions/2406341/how-to-check-if-an-ip-address-is-the-local-host-on-a-multi-homed-system.

A vypadá takto:

import java.net.*;

public class Util {

    public static boolean isLocalhost(String address) {
        InetAddress addr = null;
        try {
            addr = InetAddress.getByName(address);
            if (addr.isAnyLocalAddress() || addr.isLoopbackAddress()) {
                return true;
            }
            // Check if the address is defined on any interface
            try {
                return NetworkInterface.getByInetAddress(addr) != null;
            } catch (SocketException e) {
                return false;
            }
        } catch (UnknownHostException e) {
            return false;
        }
    }
}

Maven - Která dependence má přednost?

Příspěvek se týká buildovacího nástroje Maven

Otázka:

Představte si, že máte větší strom závislostí, kde se projekty odkazují na další projekty a ty na další...
Pokud se v takovém stromě stane, že máme závislost (dependency) na stejný artefact (stejné groupId i artefactId) a liší se pouze verze artefaktu.
Která závislost se použije?

Odpověd:

Jaká verze knihovny se použije se určí podle těchto pravidel:

1. Když jsou knihovny na stejné úrovni, vyhodnotí se jako vítězná ta co je jako první v pom.xml
2. Pokud jsou knihovny na různých úrovních v závislostech, vyhraje ta s nejnižším stupněm zanoření v grafu
1. eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Řečeno jinak použije se ta knihovna, která se při prohledávání grafu závislostí do šířky najde jako první.

Zcela nedůležitá poznámka:

Mě osobně to trochu překvapilo, protože jsem spíš očekával, že se použije ta knihovna, která se najde jako první při prohledávání do hloubky (a ne do šířky).

Pokud někdo víte proč to funguje takhle zvláštně do šířky a ne do hloubky, tak mi to prosím vysvětlete.

Začínám být z toho Mavenu pěkně otrávený, proč musím build projektu programovat v nějakých hloupých XML souborech. Jak to mám debugovat? Proč se musím učit syntaxy pom.xml a pak složitě zjišťovat co to vlastně udělá. Jak krásné by bylo napsat to v Jave a v případě problému si to pustit v Debugu. Chvilemi se mi chce psát si vlastní build nastroj. Ach jo... :)

Jak převést Subversion repo do Mercurialu

Jak převést Subversion repository do Mercurialu?

Postup:

• přepnout se do prázdného adresáře
• "hg convert https://<adresa svn repa>/svn/<produkt>/trunk ."
• "hg update"

Poznámky:

Instalace Mercurialu

Nainstalovat Mercurial samostatně, nebo ho získat společně s mým oblíbeným TortoiseHg.

Povolit příkaz hg convert

Po nainstalování Mercurialu není příkaz "hg convert" povolen.

Jednou možností jak jej povolit je vytvořit/editovat soubor .hgrc ve svém domovském adresáři. Na Windows to bude např. c:\Users\<user_name>\.hgrc (nebo mercurial.ini) a napsat do něj:

[extensions]
hgext.convert=

Od teď půjde příkaz "hg convert" použít

Jak převest i branche a ne jen trunk

Místo:
"hg convert https://<adresa svn repa>/svn/<produkt>/trunk ."
použít:
"hg convert https://<adresa svn repa>/svn/<produkt> ."

Převod jiným způsobem - pomocí HgSubversion

http://vondrnotes.blogspot.cz/2014/01/jak-prevest-subversion-repo-do.html

Dva Tomcaty s různými čísly portu.

Odpověď na otázku: "Jak docílit toho, aby jsme měli najednou spuštěné dva Tomcaty s různými čísli portu?". Tady je jeden ze způsobů jak toho docílit, mýslím, že ten nejjednodušší. Klidně mi napište o lepších (nebo hroších) způsobech, nebo o problémech - budu rád.

Takhle to funguje s Tomcatem 7. Mýslím, že stejně se to dělá i u Tomcatu 6.

Apache Tomcat změna portu. Tomcat 7, Tomcat 6

Návod

Máme nainstalovaný tomcat a chceme rozjet sním ještě jeden na jiném portu.

1. Zkopírujeme celý adresář s tomcatem
2. Upravíme tři porty v souboru "<adresář s tomcatem>/conf/server.xml"

   1. <Server port="8005" shutdown="SHUTDOWN">

      8005 změníme třeba na 8006

   2. <Connector port="8080" protocol="HTTP/1.1"
                 connectionTimeout="20000"
                 redirectPort="8443" />

      8080 změníme třeba na 8081

   3. <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

      8009 změníme třeba na 8010

Teď půjdou spustit oba tomcaty, jeden poběží na portu 8080, druhý na portu 8081.

Na takové to domácí žvýkání by to mělo stačit :-)

DBCP - validationQuery for various Databases

Info

When you are using DBCP pool, you can use property testOnBorrow and testOnReturn to test if connection is still valid. Unfortunately you have to set property validationQuery to make it work.
Problem is: What value should be in validationQuery?

What is validationQuery

validationQuery is the SQL query that will be used to validate connections. This query MUST be an SQL SELECT statement that returns at least one row.

Unfortunately for every database works another validationQuery. After some googling I have collected this:

Database	validationQuery	notes
hsqldb	select 1 from INFORMATION_SCHEMA.SYSTEM_USERS
Oracle	select 1 from dual
DB2	select 1 from sysibm.sysdummy1
mysql	/* ping */ select 1	not tested
microsoft sql	select 1	not tested
postgresql	select version();	not tested
ingres	select 1	not tested
derby	values 1	not tested
H2	select 1	not tested

Idea: Get validationQuery according to JDBC driver

If you support multiple databases, you can select validationQuery according to JDBC driver.

Here is simple class, which return validationQuery according to JDBC driver class name.

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

public class ValidationQuery {

    public String getValidationQuery(String driver) {
        Properties properties = loadProperties();
        return properties.getProperty(driver, "");
    }

    private Properties loadProperties() {
        String propertyFilename = "db.validation.properties";
        try {
            Properties props = new Properties();
            InputStream resourceAsStream = this.getClass().getClassLoader().getResourceAsStream(propertyFilename);
            props.load(resourceAsStream);
            resourceAsStream.close();
            return props;
        } catch (IOException e) {
            throw new RuntimeException("Cannot load properties file '" + propertyFilename + "'.", e);
        }
    }

    //Example: Get validationQuery for hsqldb
    public static void main(String[] args) {
        System.out.println(new ValidationQuery().getValidationQuery("org.hsqldb.jdbcDriver"));
    }
}

And here is properties file, that you have to put on classpath and name it as "db.validation.properties"

#hsqldb
org.hsqldb.jdbcDriver=select 1 from INFORMATION_SCHEMA.SYSTEM_USERS

#Oracle
oracle.jdbc.driver.OracleDriver=select 1 from dual

#DB2
com.ibm.db2.jcc.DB2Driver=select 1 from sysibm.sysdummy1

#mysql
com.mysql.jdbc.Driver=/* ping */ select 1
org.gjt.mm.mysql.Driver=/* ping */ select 1

#microsoft sql
com.microsoft.sqlserver.jdbc.SQLServerDriver=select 1

#postgresql
org.postgresql.Driver=select version();

#ingres
com.ingres.jdbc.IngresDriver=select 1

#derby
org.apache.derby.jdbc.ClientDriver=values 1

#H2
org.h2.Driver=select 1

If you have better idea how to set validationQuery or you have an tip for update of "db.validation.properties" file. Do not hesitate and let me know.

More validation queries can be found here StackOverflow - dbcp-validationquery-for-different-databases.

Groovy + Maven

Groovy je skvělé, můžete v něm psát jako v Javě, ale přitom to taky můžete napsat mnohem stručněji. Navíc díky tomu, že se jedná o dynamicky typovaný jazyk je v něm práce s XML, JSONem atd. o mnoho pohodlnější a přehlednější. Takže pokud nepotřebujete, aby váš kód byl rychlý, pak Groovy mohu jen doporučit. Pokud chce někdo začít s Groovy doporučuji, začít vněm psát testy.
Bohužel jsem zjistil, že rozchodit Groovy v Mavenu není jen jeden řádek. Existuji na to sice pluginy, ale u mě prostě nefungovaly :(. Takže tady je jenden navod jak rozchodit sice je dlouhý, ale funkční
(update: ještě lepší způsob je tady: Kompilace Groovy pomocí groovy-eclipse-compiler pluginu).

Java + Groovy s Mavenem

Je potřeba udělat 2 věci v pom.xml
1) Nejprve přidat do projektu závislost na groovy:
2) Pak je potřeba nakonfigurovat maven, aby překládal groovy fily (v hlavním projektu a v testech).
No a je to! :). Upozornil bych jen, že *.groovy zdrojáky se hledají normálně mezi .java zdrojáky, což lze ale snadno upravit změnou cest srcdir="${basedir}/src/main/java/" popř. srcdir="${basedir}/src/test/java/"

Poznámka - Použití Groovy pouze pro testy.

Pokud chcete používat groovy pouze v testech:
1) dependency na groovy nastavime pouze pro testy:
2) Definici pluginu nastavíme pouze pro testy a přidáme groovy do závislostí pluginu, protože jinak by mu při kompilaci chybělo: Přeji mnoho štastných groovy dnů.

Stopařův průvodce po galaxii - ePub

Je tu kniha:
Douglas Adams
Stopařův průvodce po galaxii
Ve formátu ePub http://pisar.wz.cz/bonus/Stoparuv_pruvodce_po_galaxii.epub

Není to sice žádný zázrak, ale zato to je nenáročné.