Search code examples
javaweb-serviceshostnameapache-tika

Java web service only responds on localhost, not by hostname (Apache Tika)

It's easier to show than to tell. This is from the Apache Tika web service:

http://pastebin.com/jrCsVVtt

On line 89 of that file, localhost is hard-coded:

sf.setProviders(providers);
sf.setAddress("http://localhost:" + TikaServerCli.DEFAULT_PORT + "/");
BindingFactoryManager manager = sf.getBus().getExtension(
                                BindingFactoryManager.class);

This means that if you're running the web service on your local machine, you cannot access it via http://hostname:9998/tika or http://hostname.domain.net:9998/tika. It must be accessed as http://localhost:9998/tika.

My Java is extremely rusty, but after some Googling, I added a few lines:

sf.setProviders(providers);
String hostname;
try
{
  InetAddress ia = InetAddress.getLocalHost();
  hostname = ia.getCanonicalHostName() + ":";
}
catch (Exception e)
{
  //I'll do something else with this later
  hostname = "http://localhost:";
}
sf.setAddress(hostname + TikaServerCli.DEFAULT_PORT + "/");
BindingFactoryManager manager = sf.getBus().getExtension(
                                BindingFactoryManager.class);

This allows me to access it by hostname and by FQDN, but NOT via localhost.

Is there an idiomatic way to get a web service to respond in all of its possible forms?

  • 127.0.0.1 (when accessed locally)
  • localhost (when accessed locally)
  • hostname
  • FQDN
  • IP address
  • Whatever else I'm missing

I guess I could compute and more-or-less complete enumeration at runtime, but it seems like there's probably a better way(?).

Solution

  • I submitted a patch which added an optional commandline parameter, and changed the default behavior to listen to all valid hostnames and IPs. (Whether this new default behavior stays remains to be seen.)

    More details, as well as the patch, can be found on the Jira ticket:

    https://issues.apache.org/jira/browse/TIKA-1196