BillyTee's Blog
Evil software problems and their solutions.

May
21

Your Apache2 server can’t authenticate to your Windows domain controller via mod_ntlm or Apache2::AuthenNTLM?

First, make sure you have network connectivity and name resolution both ways (from apache -> dc and vice versa).

Then make sure SELinux isn’t disallowing the access. You can check by scanning /var/log/audit/audit.log for entries with ‘httpd’.

If it is SELinux, try telling SELinux to allow httpd to connect to outside servers:

# setsebool -P httpd_can_network_connect 1

Feb
10

Does “Ordinal 421 cannot be located in dll urlmon.dll” keep popping up, then firefox won’t display?

Don’t repair your WinXP installation yet until you try to disable your firefox extensions.

Start firefox in safe mode. Either right-click on a desktop icon or get to it in your start menu. Or run it from the command line. Whatever you want.

When presented with a bunch of checkmarks to make permanent, check ‘Disable all add-ons’. Click ‘Make changes and restart’.

Worked for me. If you still get the ordinal 421 message, you might be in WinXP hell and need to repair or *gulp* reinstall.

Link to article on how to disable add-ons in firefox and IE:
http://news.cnet.com/8301-13880_3-10081925-68.html

Sep
28

While using the JPA for the first time, I came across some first-time errors. If you’ve ever come across this message (which you will):

MappingException: Could not determine type for: java.util.Set, at table: 
   some_class, for columns: [org.hibernate.mapping.Column(some_set) ]

There are a couple of things you need to check. First, I’m assuming you have some sort of “owning side” relationship such as OneToMany or ManyToMany.

  1. Make sure both classes (owner and the inverse)  contain the proper relationship annotations. There is no need to use the ‘targetEntity’ parameter if you are using generics.
  2. Make sure both classes are annotated with @Entity
  3. If you did both already and are still getting the same error, check your classes for field-level vs. method-level annotations. You can’t mix and match how you do it. So either all of your fields are annotated, or your getter methods are annotated. Mixing them up will result in one type of annotations being ignored.
Sep
03

You see it in the central repository as json-lib-2.2.3-jdk15 , but maven can’t find it.

This one was new for me too. Some maven artifacts are both by artifact version AND JDK version.

json-lib 2.2.3 is available for both jdk1.4 and jdk1.5. To make the distinction, you need to add the <classifier> element to your dependency in your POM.

WRONG:

<dependency>
   <groupId>net.sf.json-lib</groupId>
   <artifactId>json-lib</artifactId>
   <version>2.2.3-jdk15</version>
 </dependency>

RIGHT:

<dependency>
   <groupId>net.sf.json-lib</groupId>
   <artifactId>json-lib</artifactId>
   <version>2.2.3</version>
   <classifier>jdk15</classifier>
 </dependency>
Sep
03

Someone gave you an XSD (or you created one yourself), and you need to generate Java classes using JAXB.

You come across this error:

Property "Value" is already defined. Use <jaxb:property> to resolve this conflict.

WTF? Well, this is probably due to an element being defined as an extension of xs:string, with an attribute with a name of ‘value’. The problem is that xs:string elements already have an attribute called ‘value’. To get around this, you must use bindings.

(Also, this binding file shows you how to specify a specific package, as well as make all generated classes implement <em>java.io.Serializable</em>, as well as give them a default <em>serialVersionUID</em> value. You’re welcome.)

<jxb:bindings version="1.0"
     xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
     xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
     jxb:extensionBindingPrefixes="xjc"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <jxb:bindings schemaLocation="schema.xsd" node="/xsd:schema">

        <!--
             ! Generate classes that implement java.lang.Serializable.
             ! Must run xjc with -extension option.
             ! see http://java.sun.com/webservices/docs/1.6/jaxb/vendorCustomizations.html
             !-->
       <jxb:globalBindings>
          <jxb:serializable uid="22454"/>
       </jxb:globalBindings>

       <jxb:schemaBindings>
           <jxb:package name="your.package.for.output"/>
       </jxb:schemaBindings>

       <jxb:bindings node="//xsd:complexType[@name='elementWithValueAttribute']">
         <jxb:bindings node=".//xsd:attribute[@name='value']">
             <jxb:property name="valueAttribute"/>
          </jxb:bindings>
        </jxb:bindings>

   </jxb:bindings>
</jxb:bindings>
Sep
03

If you’ve ever seen this exception it can be mighty frustrating.:

org.jboss.ws.WSException: arg0 is not a valid property on class com.whatever.your.Class
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getElementPropertyAccessor(JAXBContextImpl.java:926)

at org.jboss.ws.metadata.accessor.JAXBAccessorFactory.create(JAXBAccessorFactory.java:51)

According to the JBoss wiki, you should be careful to add annotations to your web service methods, such as

  @javax.xml.ws.RequestWrapper(className="package.UniqueClassName")
  @javax.xml.ws.ResponseWrapper(className="package.UniqueClassNameResponse")

But what if you already did that? You used JBoss’ wsconsume utility to generate my Java classes from WSDL. The tool generated all the necessary class, method, and field-level annotations. Why are you STILL getting that terrible exception when you deploy your web application?

What I found out is that you need to check to make sure all relevant package.name.package-info ‘classes’ were compiled and added into your WAR. Without these class files, JAXB has problems mapping packages to namespaces and resolving any naming conflicts.

If you are using Apache Ant version > 1.7, you run the risk of this small-but-very-important class file being omitted from your WAR. These versions of Ant only conditionally compile this class to avoid multiple compilations. If you do a typical clean/build/package type of deployment using Ant1.7.1, chances are you’ll see no package-info.class file in your finished WAR.
That happened to me, and I was almost pulling my hair out wondering why I couldn’t cleanly deploy a WAR file that another developer on the project could. It turned out he was using Ant 1.7.0 and didn’t have this issue.

According to the Ant javac docs, Ant >1.7.1 will compile java files named ‘package-info.java’ if:

  • If a package-info.class file exists and is older than the package-info.java file.
  • If the directory for the package-info.class file does not exist.
  • If the directory for the package-info.class file exists, and has an older modification time than the the package-info.java file. In this case will touch the corresponding .class directory on successful compilation.

So I chose to solve this problem by making sure the output directory where a newly-compiled package-info.class file would exist, then touch the timestamp on that directory to be very old. Then, the third condition in the above list is satisfied, and Ant would be forced to compile package-info.java. My build.xml snippet looks like this:

    <target name="build" description="Compile main source tree java files">
       <mkdir dir="${classes.dir}" />

       <touch datetime="09/10/1974 4:30 pm" file="${classes.dir}/package/name/with/package-info.class"
                    mkdirs="true"/>

       <javac destdir="${classes.dir}" >
            <src path="${src.dir}" />
            <classpath refid="master-classpath" />
        </javac>
      </target>

Another solution to the issue is posted here. I didn’t use this because in my environment it touched an actual source file, making cvs think it needed a commit.

Sep
03

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!