Thursday, 13 April 2023

Migrate to Spring Boot 3, but stay with jaxws-api 2.3.1

There are good guides (Spring Boot 3.0 Migration Guide) to migrate a Spring Boot 2.7.x project to 3.0.x, but in my case I got some technical debt from jaxws.

The project consumes a lot of different services (soap, rest) where the generated code is capsuled in a little jar. This jars are used by some other projects, so I could not touch them. This means the project has to use jaxws-api 2.3.1.

I got a lot of errors when following the normal migration guides with the jaxb stuff which all could be solved with the proper dependencies.

Dependencies before migration:


     	<dependency>
            <groupid>javax.xml.ws</groupid>
            <artifactid>jaxws-api</artifactid>
        </dependency>
        <dependency>
            <groupid>com.sun.xml.ws</groupid>
            <artifactid>rt</artifactid>
            <version>2.3.2</version>
            <exclusions>
                <!--this is excluded to have fewer log entries on startup-->
                <exclusion>
                    <artifactid>ha-api</artifactid>
                    <groupid>org.glassfish.ha</groupid>
                </exclusion>
            </exclusions>
        </dependency>

After a lot of trail and error I came up with the following solution:

        <dependency>
            <groupId>javax.xml.ws</groupId>
            <artifactId>jaxws-api</artifactId>
            <version>2.3.1</version>
        </dependency>
        <!-- needed for java.lang.ClassNotFoundException: com.sun.xml.bind.api.JAXBRIContext -->
        <dependency>
            <groupId>com.sun.xml.bind</groupId>
            <artifactId>jaxb-impl</artifactId>
            <version>2.3.2</version>
        </dependency>
        <dependency>
            <groupId>com.sun.xml.messaging.saaj</groupId>
            <artifactId>saaj-impl</artifactId>
            <version>1.5.3</version>
        </dependency>
        <dependency>
            <groupId>org.jvnet.staxex</groupId>
            <artifactId>stax-ex</artifactId>
            <version>1.8.1</version>
        </dependency>
        <dependency>
            <groupId>com.sun.xml.ws</groupId>
            <artifactId>rt</artifactId>
            <version>2.3.1</version>
            <exclusions>
                <!-- this is excluded to have fewer log entries on startup -->
                <exclusion>
                    <artifactId>ha-api</artifactId>
                    <groupId>org.glassfish.ha</groupId>
                </exclusion>
            </exclusions>
        </dependency>


Tuesday, 28 June 2016

Richfaces.showModalPanel is not working with IE11 under some circumstances

IE 11
Richfaces 3.3.3.Final
JSF 1.2

Under some circumstances (in our case it is a page change, a download of a document and some other stuff), we did not figure out whats the exact problem, the javascript call Richfaces.showModalPanel() is not working anymore in IE 11. No problem with IE 10, Firefox or Chrome.

Usually you upgrade the JSF and Richfaces version to something thats maintained and forget this old stuff problems, but this was not possible for other reasons.

The solution we found is to change the code from

oncomplete="if(#{!list.errorMessages}){Richfaces.showModalPanel('myPanel');}jQuery.unblockUI();"
to

oncomplete="if(#{!list.errorMessages}){#{rich:component('myPanel')}.show()};jQuery.unblockUI();"

Now the ModalPanel is working in IE 11.





Thursday, 2 June 2016

Export Postgresql data and tables with Squirrel

Squirrel Version 3.7

Its really easy, just mark your tables in the Objects tab, right click and choose Scripts -> Create Data Script, or Scripts -> Create Table Script




The result is shown in the SQL tab.



Thursday, 17 July 2014

Exception durch jaxws-maven-plugin

Maven 3.0.4
jaxws-maven-plugin 2.3

Meine Überraschung war ziemlich groß als ich ein Projekt, das sich in einem Eclipse Workspace wunderbar mit Maven bauen lies plötzlich, als ich es in einen anderen importierte (anderes Eclipse) plötzlich diesen Fehler schmiss:

java.lang.AssertionError cannot be cast to java.lang.Exception

Grund war die Java Version, ab JDK 7u40 wird in JAXP (v1.5) genauer geprüft, somit gehen gewisse wsdl nicht mehr durch. Ausweg bietet sich folgender an:

org.jvnet.jax-ws-commons jaxws-maven-plugin 2.3 generate-sources wsimport -Djavax.xml.accessExternalSchema=all


Wednesday, 13 November 2013

WSDL Location im generierten WebServiceClient passt nicht

Maven 3.0.4
jaxws-maven-plugin 2.1

Generiert man sich aus einem wsdl mit Maven über jaxws-maven-plugin den Client bastelt er einen einen schönen Konstruktor für den Aufruf des Services, der auch funktioniert, wenn man ihn an Ort und Stelle ausprobiert.

Deployed man das dann jedoch auf einen Server geht nichts mehr:
ERROR MyServiceImpl - Service method 'public abstract MyClass myMethod()' threw an unexpected exception: javax.xml.ws.WebServiceException: The following WSDL exception occurred: WSDLException: faultCode=WSDL4JWrapper : : javax.wsdl.WSDLException: WSDLException: faultCode=WSDL4JWrapper : : java.io.FileNotFoundException: unsinnigerPfadzurWSDL (A file or directory in the path name does not exist.)
Der Pfad wird irgendwie unsinnig zusammengesetzt, weil man den default Konsturktor des Services verwendet hat, es gibt aber noch einen zweiten:
MyWebService(URL wsdlLocation, QName serviceName)
Hier kann man sich den Pfad nun selber zusammenbasteln:
MyWebService svc = new MyWebService (WebServiceUtil.class.getClassLoader().getResource("wsdl/MyWSDL.wsdl"), new QName(diesen Teil aus dem default Konstruktor einfach kopieren));
Auf diese Weise wird das wsdl File immer gefunden, egal wo man das Projekt deployed.