http://blogs.sun.com/watt/resource/jvm-options-list.html

Wenn sie sich primär auch auf Solaris/SPARC beziehen mag, ist sie mehr als nützlich.

<property environment="env" /> <property name="dist-conf" location="${env.DIST_PATH}/conf" />

Dann kann man diese Variable an der Kommandozeile wie folgt überschreiben:

ant -Denv.DIST_PATH=/path/to/the/dir

Um einmal gesetzte Variablen zu überschreiben, ist der Ant-Contrib-Variable-Task (siehe http://ant-contrib.sourceforge.net/) die Lösung der Wahl.

Der Grund: Abhängige Module benötigen ab Maven 2.06 immer in ihrer eigenen pom.xml ebenfalls die Angabe der Versionsnummer. Zur Umstellung siehe die gesonderte Seite hier.

Glücklicherweise arbeite ich mit einer Struktur, in der ich Build-Tools in ein Defaultverzeichnis "current" packe, so dass schnell auf eine andere Version gewechselt werden kann.

Nichtsdestotrotz finde ich es wenig verständlich, wenn in einem Minor-Release eine derart elementare strukturelle Veränderung vorgenommen wird. Als Maven-Anwender hätte ich mir allenfalls eine Warnung gewünscht mit Rückfall auf die ältere Funktionalität.

Wozu gibt man denn in Maven die Versionsnummer im <modelVersion>-Element der pom.xml überhaupt an, wenn nicht auch für eine Abwärtskompatibilität? Sehr merkwürdig.

Abhilfe schafft, über Windows->Preferences->Validation den jeweiligen Button in der Spalte Settings zu wählen und dann einen Validator-Typen zu wählen, danach ggf. noch Project->Clean.

Hinweis für Eclipse: Deselektiert man über Windows->Preferences->Validation eine Validierung komplett und sollte eine Datei bereits als invalid markiert sein, hilft, erneut Validate im Kontextmenü des Eintrags im Project-/Package-Explorer/Navigator zu wählen (geht mit Clean nicht weg).

-Djavax.xml.transform.TransformerFactory=com.icl.saxon.TransformerFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl-Dorg.xml.parsers.sax.parser=org.apache.xerces.parsers.SAXParser 

Siehe dazu auch nur Xerces als Default-Parser setzen. 

 Nun ja, aber wenn das Problem bekannt ist, braucht es nur noch umgangen zu werden.

Wie auch immer, für mich ist guter Stil, zu begründen, weshalb man ein Singleton verwendet. Ebenso, wie man manchmal explizit nichts in einem Code-Block ausführen möchte:

if(this){  do();}else if (scary){  // empty on purpose!}else{  doOther();}

(da gäbs sicherlich bessere Beispiele, ein besseres wäre der leere private Konstruktor von nicht instantiierbaren Klassen),  sollte man im JavaDoc eines Singletons erwähnen, dass es sich um eines handelt, weshalb es als Singleton verwendet wird und ggf. wie es getestet werden kann resp. welche Besonderheiten für das Testen von Klassen anfallen, die das Singleton verwenden.

Das geht höchstwahrscheinlich darüber hinaus, was z.B. in Spring mit den DAO-Klassen erfolgt (sollen die alle schlecht sein?), ist aber gerade für die Arbeit im Team nützlich. 

    UIManager.put("ClassLoader", LookUtils.class.getClassLoader());    UIManager.setLookAndFeel(new Plastic3DLookAndFeel()); 

Backslash maskieren

  <replaceregexp    match="a:\\"    replace="b:\\\\"    flags="gi">    <fileset dir="${build}${/}xml" id="XmlStuff">      <include name="takeme*.xml"/>    </fileset>  </replaceregexp></target> 

Punkt maskieren (z.B. für Paktebezeichner)

<replaceregexp  match="com\.old\.style\.business"  replace="org\.new\.style\.business"  flags="gi">  <fileset dir="${the.path}" id="pathy">    <include name="Groov*y.java"/>  </fileset></replaceregexp>

 Das Flag "gi" bedeutet: global (alle Vorkommen der gefundenen Zeichenfolge), [case-] insensitive (Groß-/Kleinschreibung nicht beachten).

Die Lösung funktioniert – einfach nur darauf achten, dass die Lib eingebunden ist, dann gehts. Hier mein TypoScript:

# Menu 1 cObjectlib.menu_1 = HMENUlib.menu_1 {  ### Erste Ebene - special value ist die Startseite mit den Servicemenüeinträgen ###     special = directory     special.value = 50    1 = TMENU    1 {          NO.allWrap = <div class="nav"> | </div>          ACT = 1          ACT.allWrap = <div class="nav"> | </div>       }    ### Zweite Ebene ###    2 = TMENU    2 {           NO.allWrap = <div class="navsub"> | </div>           ACT = 1           ACT.allWrap = <div class="navsub"> | </div>       }   }}

[PIDinRootline = 50]    lib.menu_1.special >    lib.menu_1.entryLevel = 1[END]        

Das ansonsten phantastische CSS-Menü von Stu Nicholls vermochte ich nicht dazu bewegen, die überlangen <li>-Tags nicht umzubrechen.

Wie auch immer – während der Beschäftigung mit dem Layout fiel mir immer wieder auf, wie wenig standardkonform doch der Internet Explorer ist. Und dass sich Webdesigner offenbar überwiegend damit beschäftigen, ihre Seiten für alle Browser, insbesondere aber für den IE wie gewünscht präsentieren zu können.

Welch ein Wahnsinn ist das nur? Da wird ein objektiv (der W3C-Standard ist objektiv) fehlerhaftes Softwareprodukt gebündelt mit einem Betriebssystem zur Verfügung gestellt und wegen der hinter diesem Betriebssystem stehenden beherrschenden Marktposition müssen Unternehmen auf der ganzen Welt Geld ausgeben, um die Fehler dieser Software zu umgehen.

Ich glaube nicht, dass dies die Arbeitsplätze der Webdesigner sichert – deren Arbeit ist so oder so gefragt. Aber ihre Leistung wird verschlechtert, da sie sich um Dinge in der zur Verfügung stehenden Zeit kümmern müssen, die eigentlich gar nichts mit ihrer Tätigkeit zu tun haben.

All die Stunden der sinnlos mit IE-Inkompatiblitäten vergeudeten Zeit zusammengerechnet liegt hier ein betriebs- und volkswirtschaftlicher Schaden in Milliardenhöhe vor, um den sich niemand kümmert. Da glaubt man lieber Zusicherungen, der IE sei doch sehr standardkonform und belässt es dabei. Beängstigend.

mysql -u USER -p DBNAME < dump.sql

Der direkte Befehl an der Kommandozeile ist besonders nützlich, um das Default-Characterset zu übergeben:

mysql -u USER -p  DBNAME --default-character-set=utf8 < /path/to/dump.sql 

Oder einloggen, use DBNAME und den Pfad des Dumpfiles mit 'source' angeben. Also:

mysql> show databases

mysql> use DBNAME

mysql> source /path/to/dump.sql 

 Da müsste das Charset allerdings über die Session (?) resp. beim Login geändert werden (???).

Falls es sich schließlich um eine Remote-DB handelt (auch hier nützlich fürs Charset):

mysql -u DBUSER -p -h DBSERVER DBNAME < dump.sql

-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

        <buildCommand>            <name>org.eclipse.jdt.core.javabuilder</name>            <arguments>            </arguments>        </buildCommand> 

einfügen (direkt via Eclipse, im geöffneten Projekt funktioniert). 

Am einfachsten geht's aber mittlerweile mit Maven, siehe http://wiki.apache.org/myfaces/MyFaces_Archetypes_for_Maven.

Eigentlich sind solche Archteypen ja etwas für MDA-"FUDders", denn der Unterschied hinsichtlich der Vorgehensweise zur JSF-Cartridge von AndroMDA ist gar nicht so groß. 

Zur Dokumentation: 

<?xml version="1.0"?><web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> 

    <context-param>        <description>            State saving method: "client" or "server" (= default)            See JSF Specification 2.5.2        </description>            <param-name>javax.faces.STATE_SAVING_METHOD</param-name>        <param-value>server</param-value>    </context-param>

    <context-param>        <description>            This parameter tells MyFaces if javascript code should be allowed in the            rendered HTML output.            If javascript is allowed, command_link anchors will have javascript code            that submits the corresponding form.            If javascript is not allowed, the state saving info and nested parameters            will be added as url parameters.            Default: "true"        </description>            <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>        <param-value>true</param-value>    </context-param>

    <context-param>        <description>            This parameter tells MyFaces if javascript code should be allowed in the            rendered HTML output.            If javascript is allowed, command_link anchors will have javascript code            that submits the corresponding form.            If javascript is not allowed, the state saving info and nested parameters            will be added as url parameters.            Default: "false"

            Setting this param to true should be combined with STATE_SAVING_METHOD "server" for            best results.

            This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping below to get            JavaScript detection working.        </description>        <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>        <param-value>false</param-value>    </context-param>

    <context-param>        <description>            If true, rendered HTML code will be formatted, so that it is "human readable".            i.e. additional line separators and whitespace will be written, that do not            influence the HTML code.            Default: "true"        </description>        <param-name>org.apache.myfaces.PRETTY_HTML</param-name>        <param-value>true</param-value>    </context-param>

    <context-param>        <description>            If true, a javascript function will be rendered that is able to restore the            former vertical scroll on every request. Convenient feature if you have pages            with long lists and you do not want the browser page to always jump to the top            if you trigger a link or button action that stays on the same page.            Default: "false"        </description>            <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>        <param-value>true</param-value>    </context-param>

    <!-- Extensions Filter -->    <filter>        <filter-name>MyFacesExtensionsFilter</filter-name>        <filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>        <init-param>            <description>Set the size limit for uploaded files.                Format: 10 - 10 bytes                        10k - 10 KB                        10m - 10 MB                        1g - 1 GB            </description>        			<param-name>maxFileSize</param-name>			<param-value>20m</param-value>        </init-param> </filter> <filter-mapping>  <filter-name>MyFacesExtensionsFilter</filter-name>  <!-- servlet-name must match the name of your javax.faces.webapp.FacesServlet entry -->  <servlet-name>Faces Servlet</servlet-name> </filter-mapping> <!-- extension mapping for serving page-independent resources (javascript, stylesheets, images, etc.)  --> <filter-mapping>  <filter-name>MyFacesExtensionsFilter</filter-name>  <url-pattern>/faces/myFacesExtensionResource/*</url-pattern> </filter-mapping> <filter-mapping>  <filter-name>MyFacesExtensionsFilter</filter-name>  <url-pattern>*.jsp</url-pattern> </filter-mapping>

 <!-- Listener, that does all the startup work (configuration, init). --> <listener>  <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> </listener> <!-- Faces Servlet --> <servlet>  <servlet-name>Faces Servlet</servlet-name>  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>  <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping>  <servlet-name>Faces Servlet</servlet-name>  <url-pattern>*.jsf</url-pattern> </servlet-mapping> <servlet-mapping>  <servlet-name>Faces Servlet</servlet-name>  <url-pattern>/faces/*</url-pattern> </servlet-mapping> <login-config>  <auth-method>BASIC</auth-method> </login-config></web-app>

Schließlich half, t3lib/class.t3lib_div.php zu bearbeiten:

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 0); // Changed from 0 to 1 by KG curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

 So schleicht sich die Homepage für die Gemeinde voran, immerhin ist die neue cal-Extension exzellent.

Solution: Try to point to Xerces, e.g. by using a system var or remove suspicious jars, e.g. gnujaxp.jar from your classpath.

(Asked by a colleague today).

A better error message would be useful, must check how the behaviour is in Axis2.

http://lists.netfielders.de/pipermail/typo3-english/2005-November/015469.html

1. Programm mit -XX:+HeapDumpOnOutOfMemoryError aufrufen, um eine HeapDump-Datei zu erstellen.
2. Jetzt mit jhat -J-mx768m [HeapDump-Datei, z.B. java_pid804.hprof] die Datei analysieren lassen. Wie auch bei den "integrierten" WebServices wird dabei ein interner Http-Server gestartet, der grundsätzlich auf Port 7000 lauscht.
3. Jetzt über http://localhost:7000 analysieren… OQL wird auch unterstützt.

Gefällt mit besser als das frustrierende Geraffel mit der Eclipse TPTP, auch wenn diese schönere Icons vorweisen kann. Die Lösung aus dem JDK scheint mir einfacher, stabiler und vor allem funktionaler zu sein. (Der TPTP-Agent selbst muss z.B. derzeit unter 1.4 laufen, das soll man einmal wissen).

Der Autor ist, als Spring-"Committer" neben Jürgen Höller der einzige native Deutschsprachler im Team und aufgrund seiner Autorentätigkeit beim Java-Magazin sowie seiner freundlich-intelligenten Vortragsart bei Konferenzen vorzüglich geeignet, ein Buch über Spring zu verfassen. Das Buch behandelt, dem Inhaltsverzeichnis folgend, so ziemlich alle Bereiche:

Von den Grundkonzepten (DI, AOP) über Persistenz zu JAAS, MVC bis hin zu Spring.NET. Da drängt sich einem der Eindruck auf: Das kann man unmöglich auf gut dreihundert Seiten behandeln!

Tatsächlich wird der Text sich für jemanden, der noch nicht mit Spring gearbeitet hat, so hermetisch darstellen, dass er ohne gleichzeitiges Nachvollziehen mit einem Beispielprojekt hoffnungslos verloren sein dürfte. Das stellt sich die Frage, ob vielleicht mehr Informationen über die Codebeispiele zu erhalten sind. Aber hier fangen die Probleme an:

Eberhard Wolff stellt ein Eclipse-Projekt zur Verfügung, das auf User-Libraries basiert, deren Inhalt aber nirgends erwähnt ist. Eine ant.properties-Datei, die in der einzigen Hilfestellung, LiesMich.txt, aufgeführt ist, geht fehl, da die build.xml auf einen anderen Pfad verweist als die eigentlich zu verwendende Variable xdoclet.home aus der Property-Datei. Das ist sehr lieblos gemacht und Wolff ebenso wie seinem Lektor vorzuwerfen, die offenbar gar nicht versucht haben, die Konfiguration einmal auf einem frischen System auszuprobieren.

Allein der Umstand, dass nicht erwähnt wird, mit welchem JDK (grundsätzlich eher 1.4, aber wohl auch Tiger), welcher Version von JBoss oder Tomcat oder JUnit gearbeitet wird und wie, ist einfach mangelhaft – im Arbeitsalltag wollte man nicht auf diese Weise in ein Projekt eingeführt werden. Aber da hätte man den Trost, dafür bezahlt zu werden.

Diesen Trost hat man hier nicht. Im Gegenteil.

Ich habe immer mehr den Eindruck, viele der IT-Bücher werden nur noch verfasst, um den Autoren die Möglichkeit zu geben, sich zu profilieren, nicht aber: Um Wissen weiterzugeben.

Dass es anders ginge, beweist ja gerade AppFuse von Matt Raible, das ja auf dem Buch Spring Live weitgehend basiert. Und in der Version 2 von AppFuse macht Raible auch vor, wie das aussehen kann: Einfach mit Maven sich das Projekt holen, konfigurieren – fertig! Selbst wenn Eberhard Wolff sich diese Mühe nicht machen wollte (und die Bandbreite für ein Maven Repository nicht zur Verfügung stand) – ein "Out-of-the-Box" Projekt für Eclipse wäre doch sicherlich zu erwarten gewesen, immerhin kostet Wolffs Buch 36,- EUR, das ist zu teuer, als dass man auch noch Stunden mit dem Einrichten des Beispielprojekts verbringen muss.

Oder wenigstens *.userlibraries-Dateien zum Importieren/Nachvollziehen anbieten… oder ggf. die SpringIDE erwähnen, wenn er von dieser ausgehen sollte. Dieses Buch scheint mir nur für Schulungen geeignet, in denen E. Wolff ein "Hands-On-Training" durchführt und den Anwesenden das Buch als Vademecum überreicht.

<xsl:if test="contains($myExpr, "'")">

etc. Bei den meisten XPath-Tools darauf achten, dass nicht die XML-Entität, sondern das Zeichen verwendet wird.

Leider funktioniert das nicht mit concat() oder generell nicht immer. Bombensicher ist daher nur Michael Kays Vorschlag.

Also

<xsl:variable name="apos">'</x:variable>

und dann verwenden:

<xsl:value-of select="concat('//', '*[@type=', $apos, 'sthg2concat:', @name, $apos, ']')" />