We Keep Coding

How to use Vaadin add-on with Spring Boot?

I'm using Vaadin 7.6.3 with Spring Boot. I'm trying to use the PopupButton add-on (but I don't think the issue is specific to the add-on).
I added the add-on as a dependency to gradle. This is the code for creating a PopupButton:
PopupButton btn = new PopupButton("Test Button");
btn.setContent(new Label("Test"));
layout.addComponent(btn);
Via the Vaadin plugin for Gradle I ran the task vaadinCompile which created the file src/main/resources/addon/client/ListaideWidgetset.gwt.xml and serveral files in src/main/webapp/VAADIN/gwt-unitCache and
src/main/webapp/VAADIN/widgetsets/addon.client.ListaideWidgetset. I also added #Widgetset("addon.client.ListaideWidgetset") to my UI. I confirmed that the widgetset is used via the client's ?debug mode.
Content of ListaideWidgetset.gwt.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Vaadin//DTD Vaadin 7//EN" "https://raw.github.com/vaadin/gwt/master/distro-source/core/src/gwt-module.dtd">
<!-- WS Compiler: manually edited -->
<module>
<inherits name="com.vaadin.DefaultWidgetSet" />
<set-configuration-property name="devModeRedirectEnabled" value="true" />
<set-property name="user.agent" value="ie8,ie9,gecko1_8,safari,ie10" />
<source path="client" />
<source path="shared" />
<collapse-all-properties />
<set-property name="compiler.useSymbolMaps" value="true" />
</module>
The problem is that on the client the button shows up as a standard button (no chevron) and doesn't open a popup when clicked.

Your widgetset does not contain the addon. See the the example:
<inherits name="org.vaadin.hene.popupbutton.widgetset.PopupbuttonWidgetset" />
Once added, recompile the widgetset, restart your application.
Usually the gradle plugin can handle this for you, but that feature can be disabled and or some other configuration error could prevent it. Hard to tell without the build.gradle...
edit
The gradle vaadin plugin seems not to be able to handle this addon properly. As a workaround disable the automatic management for widgetset, which prevents regeneration of the gwt.xml. See manageWidgetset in https://github.com/johndevs/gradle-vaadin-plugin/wiki/Tasks-and-configuration-DSL). E.g. add vaadinCompile.manageWidgetset = false in your vaadin{}-block.

Why are Ant lib folders different

I am using Eclipse Helios with Tomcat 7 on Windows and have imported Apache Ant-1.8.4 and works fine but I had to set up the same environment on another machine and when I attempted to build the project using Ant in Eclipse it failed with the following message;
C:\eclipsehelios\workspace\projectname\build.xml:207: Problem: failed to
create task or type emmajava
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken
place
I have had this error before and just required to ensure the build file had the correct path to the Ant folder but this didn't resolve things this time. I found by copying in the following files to the Ant's lib folder solved the problem but these were not required in my own PC and wondered if someone would tell me if this was the correct way to resolve this problem and if so why do I not require these on my own PC?
antlr-2.7.6.jar
commons-beanutils-1.8.3-javadoc.jar
commons-beanutils-1.8.3-sources.jar
commons-beanutils-1.8.3.jar
commons-beanutils-bean-collections-1.8.3.jar
commons-beanutils-core-1.8.3.jar
commons-cli-1.2-javadoc.jar
commons-cli-1.2-sources.jar
commons-cli-1.2.jar
commons-logging.jar
ganymed.jar
guava-13.0.1-sources.jar.sav
guava-13.0.1.jar.sav
guava-gwt-13.0.1-sources.jar.sav
guava-r07-javadoc.jar.sav
guava-r07-sources.jar.sav
guava-r07.jar.sav
jna.jar
svnant-1.3.1.jar
svnant.jar
svnClientAdapter.jar
svnjavahl.jar
svnkit.jar
EDIT:
If I click on the line "C:\eclipsehelios\workspace\projectname\build.xml:207" it goes to the following section of the build file with the top line "
<emmajava enabled="${emma.enabled}" libclasspathref="emma.lib"
fullmetadata="yes" filter="${emma.filter}" sourcepath="src"
classname="the.company.domain.test.EmmaLoginMain">
<classpath>
<pathelement path="test" />
<pathelement path="build/classes" />
<pathelement path="build_tests/classes" />
<pathelement path="test" />
<fileset dir="${libDir}">
<include name="**/*.jar" />
</fileset>
<fileset dir="${tomcat_lib}">
<include name="**/*.jar" />
</fileset>
<fileset dir="${test_lib}">
<include name="**/*.jar" />
</fileset>
</classpath>
<!-- regular <java> options are still available: -->
<!--<arg value="somearg" /> -->
<!-- <emmajava> option extensions [see the reference manual for
complete details]: -->
<xml outfile="${test.reports.dir}/emma/coverage.xml" />
<txt outfile="${test.reports.dir}/emma/coverage.txt" />
<html outfile="${test.reports.dir}/emma/coverage.html" />
</emmajava>

Android Ant Build

I would like to build two versions of my Androidapplication using an Apache ant file. The problem is, that both versions are identical except the advertisement in the lite version. I read about using Configurations with ant to build debug versions.
The following class defines some constants that can be referenced within the application.
public class Config {
// Whether or not to include logging in the app.
public final static boolean LOGGING = true;
}
And here is an example on how to use this constants to determine if logging is enabled or not.
if (Config.LOGGING) {
Log.d(TAG, "[onCreate] Success");
}
Now i can enable and disable logging in my properties file.
# Turn on or off logging.
config.logging=true
That does not work, because before using this config I have to create a second config file and use filterset and copy.
public class Config {
// Whether or not to include logging in the app.
public final static boolean LOGGING = #CONFIG.LOGGING#;
}
That's pretty easy, but how I could use this to build two versions of my application with and without advertisement. And how could I change the package names using ant, so the android market would accept both packages (Full and Lite).
Thank you, for your suggestions, but I still have some problems.
I managed to write some basic targets that cleanup my builds and copy all files needed to build the application in two folders /full and /lite. So I have two directories with the same content. Now I rename all matches of the applications package name in all *.java files and the AndroidManifest file (target prepare).
To really build two different version I would now have to include the code from my first post. But how do I have to do this and how can I build both versions in the release target and write the resulting *.apk files into the build directoy?
Finally ... Would that be all I have to do to build running *.apks that would be accepted by the android market?
<?xml version="1.0" encoding="UTF-8"?>
<project name="my.application" default="help" basedir=".">
<!-- Load the custom property files -->
<property file="build.properties" />
<property file="passwords.properties" />
<!-- Set global properties for this build -->
<property name="my.application.pkg" value="my.application"/>
<property name="my.application.pkg.full" value="my.application.full"/>
<property name="my.application.pkg.lite" value="my.application.lite"/>
<property name="my.application" location="."/>
<property name="my.application.build" location="build"/>
<property name="my.application.src" location="src"/>
<property name="my.application.res" location="res"/>
<property name="my.application.gen" location="gen"/>
<property name="my.application.full" location="full"/>
<property name="my.application.full.src" location="full/src"/>
<property name="my.application.full.res" location="full/res"/>
<property name="my.application.full.gen" location="full/gen"/>
<property name="my.application.full.build" location="full/build"/>
<property name="my.application.lite" location="lite"/>
<property name="my.application.lite.build" location="lite/build"/>
<property name="my.application.lite.src" location="lite/src"/>
<property name="my.application.lite.res" location="lite/res"/>
<property name="my.application.lite.gen" location="lite/gen"/>
<!-- Create and update the local.properties file -->
<loadproperties srcFile="local.properties" />
<!-- Load the ant.properties file -->
<property file="ant.properties" />
<!-- Load the project.properties file -->
<loadproperties srcFile="project.properties" />
<!-- Quick check on sdk.dir. -->
<fail
message="sdk.dir is missing."
unless="sdk.dir" />
<!-- Version-tag: 1 -->
<import file="${sdk.dir}/tools/ant/build.xml" />
<target name="release" depends="report, prepare">
<echo>Building the target!</echo>
</target>
<target name="prepare" depends="cleanup" >
<!-- Copy the Manifest.xml to the full copy -->
<copyfile src="${my.application}/AndroidManifest.xml"
dest="${my.application.full}/AndroidManifest.xml" />
<!-- Copy the source files to the full copy -->
<copy todir="${my.application.full.src}" overwrite="true">
<fileset dir="${my.application.src}" />
</copy>
<!-- Copy the resources to the full copy -->
<copy todir="${my.application.full.res}" overwrite="true">
<fileset dir="${my.application.res}" />
</copy>
<!-- Copy the generated to the full copy -->
<copy todir="${my.application.full.gen}" overwrite="true">
<fileset dir="${my.application.gen}" />
</copy>
<!-- Replace the package name in the full manifest file -->
<replaceregexp file="${my.application.full}/AndroidManifest.xml"
match='package="(.*)"'
replace='package="${my.application.pkg.full}"'
byline="false" />
<!-- Change the package name in all Java files -->
<replaceregexp flags="g" byline="false">
<regexp pattern="${my.application.pkg}" />
<substitution expression="${my.application.pkg.full}" />
<fileset dir="${my.application.full.src}" includes="**/*.java" />
</replaceregexp>
<!-- Copy the Manifest.xml to the lite copy -->
<copyfile src="${my.application}/AndroidManifest.xml"
dest="${my.application.lite}/AndroidManifest.xml" />
<!-- Copy the source files to the lite copy -->
<copy todir="${my.application.lite.src}" overwrite="true">
<fileset dir="${my.application.src}" />
</copy>
<!-- Copy the resources to the lite copy -->
<copy todir="${my.application.lite.res}" overwrite="true">
<fileset dir="${my.application.res}" />
</copy>
<!-- Copy the generated to the lite copy -->
<copy todir="${my.application.lite.gen}" overwrite="true">
<fileset dir="${my.application.gen}" />
</copy>
<!-- Replace the package name in the lite manifest file -->
<replaceregexp file="${my.application.lite}/AndroidManifest.xml"
match='package="(.*)"'
replace='package="${my.application.pkg.lite}"'
byline="false" />
<!-- Change the package name in all Java files -->
<replaceregexp flags="g" byline="false">
<regexp pattern="${my.application.pkg}" />
<substitution expression="${my.application.pkg.lite}" />
<fileset dir="${my.application.lite.src}" includes="**/*.java" />
</replaceregexp>
</target>
<!-- Deletes all directories, not needed anymore after compiling the source files -->
<target name="cleanup">
<!-- Delete the full version build dir -->
<delete dir="${my.application.full}"/>
<!-- Delete the lite version build dir -->
<delete dir="${my.application.lite}"/>
<!-- Delete the *.apk file -->
<delete file="my.application.full.apk"/>
<!-- Delete the *.apk file -->
<delete file="my.application.lite.apk"/>
</target>
</project>

There are a number of ways in which you could achieve what you require.
Here are a couple of ideas that I have used in the past,
1) Have two application 'heads' that pull in a common Android library.
Each head initializes static data that sets up the library to behave as either the lite or the full version of your application.
This has the advantage that you can perform the build from Eclipse projects as well as with Ant.
2) Have two seperate build targets that share common build targets to create two seperate apk files.
In the Ant build script have it build two versions of the APK.
One that is the full version and then the other which builds the lite version.
The difference between the two targets are that they build using slightly different files (either by copying, directing to diferent directories or modifying with scripts).
This can all be done in Ant using targets and properties.
If at the top level of your build you have a release target depending on two other targets.
e.g.
<target name="release"
depends="release-Full, release-Lite">
</target>
<target name="release-Full">
<ant antfile="thisbuild.xml" inheritAll="true" target="full">
<property name="MyCustomProperty" value="Full" />
</ant>
</target>
<target name="release-Lite">
<ant antfile="thisbuild.xml" inheritAll="true" target="lite">
<property name="MyCustomProperty" value="Lite" />
</ant>
</target>
You can then use these targets and properties to modify your build to do whatever you require to build each of the APK files.

Getting JAX-WS client work on Weblogic 9.2 with ant

I've recently had lots of issues trying to deploy a JAX-WS web servcie client on Weblogic 9.2. It turns out there is no straightforward guide on how to achieve this, so I decided to put together this short wiki entry hoping it might be useful for others.
Firstly, Weblogic 9.2 does not support web servcies using JAX-WS in general. It comes with old versions of XML-related java libraries that are incompatible with the latest JAX-WS (similar issues occur with Axis2, only Axis1 seems to be working flawlessly with Weblogic 9.x but that's a very old and unsupported library).
So, in order to get it working, some hacking is required. This is how I did it (note that we're using ant in our legacy corporate project, you probably should be using maven which should eliminate 50% of those steps below):
1.Download the most recent JAX-WS distribution from https://jax-ws.dev.java.net/ (The exact version I got was JAXWS2.2-20091203.zip)
2.Place the JAX-WS jars with the dependencies in a separate folder like lib/webservices.
3.Create a patternset in ant to reference those jars:
<?xml version="1.0"?>
<patternset id="jaxws.classpath">
<include name="webservices/jsr173_api.jar" />
<include name="webservices/jsr181-api.jar" />
<include name="webservices/jaxb-api.jar" />
<include name="webservices/jaxb-impl.jar" />
<include name="webservices/jaxb-xjc.jar" />
<include name="webservices/jaxws-tools.jar" />
<include name="webservices/jaxws-rt.jar" />
<include name="webservices/jaxws-api.jar" />
<include name="webservices/policy.jar" />
<include name="webservices/woodstox.jar" />
<include name="webservices/streambuffer.jar" />
<include name="webservices/stax-ex.jar" />
<include name="webservices/saaj-api.jar" />
<include name="webservices/saaj-impl.jar" />
<include name="webservices/gmbal-api-only.jar" />
</patternset>
4.Include the patternset in your WAR-related goal. This could look something like:
<?xml version="1.0"?>
<copy todir="${wardir.lib}" includeEmptyDirs="false" flatten="true">
<fileset dir="${libs}">
<!--lots of libs here, related to your project -->
<patternset refid="jaxws.classpath"/>
</fileset>
</copy>
(not the flatten="true" parameter - it's important as Weblogic 9.x is by default not smart enough to access jars located in a different lcoation than WEB-INF/lib inside your WAR file)
5.In case of clashes, Weblogic uses its own jars by default. We want it to use the JAX-WS jars from our application instead. This is achieved by preparing a weblogic-application.xml file and placing it in META-INF folder of the deplotyed EAR file. It should look like this:
<?xml version="1.0"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>javax.xml.bind.*</package-name>
<package-name>javax.xml.crypto.*</package-name>
<package-name>javax.xml.registry.*</package-name>
<package-name>javax.xml.rpc.*</package-name>
<package-name>javax.xml.soap.*</package-name>
<package-name>javax.xml.stream.*</package-name>
<package-name>javax.xml.ws.*</package-name>
<package-name>com.sun.xml.api.streaming.*</package-name>
</prefer-application-packages>
</weblogic-application>
6.Remember to place that weblogic-application.xml file in your EAR! The ant goal for that may look similar to:
<?xml version="1.0"?>
<target name="build-ear" depends="war, manifest">
<delete dir="${dist}"/>
<mkdir dir="${dist}"/>
<jar destfile="${warfile}" basedir="${wardir}"/>
<ear destfile="${earfile}" appxml="resources/${app.name}/application.xml">
<fileset dir="${dist}" includes="${app.name}.war"/>
<metainf dir="resources/META-INF"/>
</ear>
</target>
7.Also you need to tell weblogic to prefer your WEB-INF classes to those in distribution. You do that by placing the following lines in your WEB-INF/weblogic.xml file:
<?xml version="1.0"?>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
8.And that's it for the weblogic-related configuration. Now only set up your JAX-WS goal. The one below is going to simply generate the web service stubs and classes based on a locally deployed WSDL file and place them in a folder in your app:
<?xml version="1.0"?>
<target name="generate-jaxws-client">
<taskdef name="wsimport" classname="com.sun.tools.ws.ant.WsImport">
<classpath path="classpath.main"/>
</taskdef>
<wsimport
destdir="${src}"
package="acme.somewhere.in.your.package.tree.webservices."
keep="true"
wsdl="http://localhost:8088/mockWebService?WSDL">
</wsimport>
</target>
Remember about the keep="true" parameter. Without it, wsimport generates the classes and... deletes them, believe it or not!
For mocking a web service I suggest using SOAPUI, an open source project. Very easy to deploy, crucial for web servcies intergation testing.
9.We're almost there. The final thing is to write a Java class for testing the web service, try to run it as a standalone app first (or as part of your unit tests)
10.And then try to run the same code from withing Weblogic. It should work. It worked for me. After some 3 days of frustration.
And yes, I know I should've put 9 and 10 under a single bullet-point, but the title "10 steps to deploy a JAX-WS web service under Web logic 9.2 using ant" sounds just so much better.
Please, edit this post and improve it if you find something missing!

This is not really a question but a guide so I'm answering it myself just to mark it as done.

Another way of dealing with web services on Weblogic 9.2 is using Apache CXF. This particularly well integrates with Spring as each web service is exposed as a bean and the actual classes don't even need to know that they are web services, it's all configuration driven.
A great guide about setting up Apache CXF on Weblogic can be found here: http://wheelersoftware.com/articles/spring-cxf-web-services.html
This works on Weblogic 9.2 as well and if you need to expose web services, not just connect to existing ones, this is by far better approach than using plain JAXWS (which is used by CXF anyway).

Is there a way to get Hibernate's hbm2ddl Ant task to exclude specific tables?

I use Hibernate to generate my database automatically for testing, and I have some tables in my schema that contain static data that takes a very long time to import. In the past, I've used the following code in my build file to generate the database (from mapping files):
<target name="schema-gen" depends="hibernate-gen">
<taskdef name="schemaexport" classname="org.hibernate.tool.hbm2ddl.SchemaExportTask" classpathref="project.classpath" />
<schemaexport properties="resources/hibernate.properties" text="false" quiet="false" delimiter=";" output="schema.sql">
<fileset dir="${build.doclets}">
<include name="**/*.hbm.xml" />
<exclude name="**/inert/*.hbm.xml" />
</fileset>
</schemaexport>
</target>
The .hbm.xml files were generated using XDoclet. I'm migrating to using Hibernate Annotations for mapping, so I'm moving to hibernatetools to generate the schema:
<target name="annotations-export" depends="hibernate-gen">
<hibernatetool destdir="${basedir}">
<annotationconfiguration configurationfile="${basedir}/resources/hibernate.cfg.xml" propertyfile="${basedir}/resources/hibernate.properties" />
<classpath>
<path refid="project.classpath" />
</classpath>
<hbm2ddl drop="true" create="true" export="true" outputfilename="schema.sql" delimiter=";" format="true" />
</hibernatetool>
</target>
I'd like to be able to tell hbm2ddl to leave out the classes in the "inert" package, just like I used to with schemaexport. Anyone know if there's a way to do so?

This should work:
<target name="annotations-export" depends="hibernate-gen">
<hibernatetool destdir="${basedir}">
<annotationconfiguration configurationfile="${basedir}/resources/hibernate.cfg.xml" propertyfile="${basedir}/resources/hibernate.properties">
<fileset dir="${build.doclets}">
<include name="**/*.class" />
<exclude name="**/inert/*.class" />
</fileset>
</annotationconfiguration>
<classpath>
<path refid="project.classpath" />
</classpath>
<hbm2ddl drop="true" create="true" export="true" outputfilename="schema.sql" delimiter=";" format="true" />
</hibernatetool>
</target>

The solution I wound up going with was creating a separate Hibernate configuration with exactly the classes I wanted to map, and using that for the export task instead of the other Hibernate configuration with all of the mapped classes.

have you tried the update attribute on the hbmddl tag?
<hbm2ddl update="true" ...
see here for the details
that should work

If you have this situation and you happen to not want Hibernate to update the data in the tables either, then you can replace:
<class name="FooClass" table="FOO_TABLE"></class>
with
<class name="Foo" subselect="select * from FOO_TABLE">
<synchronize table="FOO_TABLE">
</class>
then the schema export tool will ignore it, but so will any writes. At least, that's what the documentation suggests.
subselect (optional): maps an immutable and read-only entity to a
database subselect.
I discovered this through looking at the Table.isPhysicalTable function. You could also look into using AbstractUnionTables, which are the other exception.
I happen to want immutable objects.
My use case is that I want to load slightly differently shaped immutable editions of some hibernate managed objects without a risk of accidentally changing the schema export. So subselect is pretty well suited to that.
Unfortunately it will litter all your queries with that subselect, which the database should be able to optimize it away, but people have varying amounts of trust in database optimisation with good reason.