1

I have the following 

String pattern = "\\b(" + StringUtils.join(mypattern, "|") + ")\\b";

and in pom.xml, I have dependency for

<dependency>
    <groupId>commons-lang</groupId>
    <artifactId>commons-lang</artifactId>
    <version>2.6</version>
</dependency>

However when I execute, I am getting the following errors inspite of having commons-lang

java.lang.NoSuchMethodError:org.apache.commons.lang.StringUtils.join (Ljava/util/Collection;Ljava/lang/String;)Ljava/lang/String;

How can I resolve this issue?

Update 1

War contents

enter image description here

War structure

enter image description here

Jacob
  • 14,463
  • 65
  • 207
  • 320
  • 1
    Is the jar in your runtime classpath? – Mureinik Jan 28 '15 at 06:51
  • @Mureinik It is packaged in war file with application jar files and deployed to application server, Exception is thrown at runtime. – Jacob Jan 28 '15 at 06:53
  • 1
    Do you have an old (before 2.3) version of commons-lang on your classpath? – Mark Rotteveel Jan 28 '15 at 06:53
  • @MarkRotteveel I do not have commons-lang jar 2.3 in my classpath. I have included war file layout in my question. – Jacob Jan 28 '15 at 06:57
  • 1
    That's not really a layout - it's just a list of jar files. It doesn't show where they are *within* the war file. What about elsewhere on the server - does that have an older version of commons-lang somewhere that might be causing the problem? – Jon Skeet Jan 28 '15 at 06:58
  • I said **before** 2.3, and also look at the classpath of the application server itself, not just of your war. My point was : `StringUtils.join(Collection, String)` was added in 2.3, so if your application has been compiled with 2.3 or later, but runs with 2.2 or earlier, you will get a `NoSuchMethodError` – Mark Rotteveel Jan 28 '15 at 07:01
  • 1
    @Polppan no, you haven't. You have only shown the top-level folders and files in the war. We still don't know where the jar files are located in the war file. – JB Nizet Jan 28 '15 at 07:07
  • Sounds like on runtime an older commons-.lang is visible to your application. This could be for example a container version if no proper classpath separation is configed. Check if there is anywhere else a commons-lang jar which you can upgrade. – eckes Jan 28 '15 at 07:07
  • @JBNizet jar files are located under WEB-INF-->lib folder. – Jacob Jan 28 '15 at 07:10
  • 2
    Right - *that's* the bit I'd been after from the very start. Oh well. I have a diagnostic step you could use - earlier in your code, print out `StringUtils.class.getClassLoader().getResource("org/apache/commons/lang/StringUtils.class")` - that will show you where the class is being loaded from. – Jon Skeet Jan 28 '15 at 07:12
  • @eckes In weblogic server, there is `com.bea.core.apache.commons.lang_2.1.0.jar`, so this must be causing the issue? If so how not to use server version of jar? – Jacob Jan 28 '15 at 07:12
  • 1
    Side note: the servlet-api jar should NOT be in the war file. The right version of the API is provided by weblogic. Mark this dependency as a provided-scoped dependency in your pom. – JB Nizet Jan 28 '15 at 07:14
  • 1
    That comment doesn't answer what happens if you print `StringUtils.class.getClassLoader().getResource("org/apache/commons/lang/StringU‌​tils.class")` - I'd expect `com.bea.core.apache.commons.lange_2.1.0.jar` to different packages, but it might not... – Jon Skeet Jan 28 '15 at 08:24
  • @JonSkeet The following resulted in `null` at runtime. `log.info("class *** " + StringUtils.class.getClassLoader().getResource( "org/apache/commons/lang/StringU‌​‌​tils.class"));` – Jacob Jan 28 '15 at 08:48
  • @Polppan: That's strange. I really don't understand that at all... hmm. – Jon Skeet Jan 28 '15 at 08:50
  • @JonSkeet `com.bea.core.apache.commons.lange_2.1.0.jar` contains `org\apache\commons\lang\StringUtils.class` So is this is the culprit? – Jacob Jan 28 '15 at 09:00
  • @Polppan: Yes, that sounds like it may well be. Where *is* that jar file? In an ideal world, it would only be loaded by a classloader which didn't get used for your code... – Jon Skeet Jan 28 '15 at 09:04
  • @JonSkeet it's in `wls1036\modules` – Jacob Jan 28 '15 at 09:34
  • @Polppan: Okay. I wouldn't *expect* that to be a problem then, although I haven't used Weblogic much. If you're able to attach a debugger to it, looking at the classloader being used for StringUtils would be useful. – Jon Skeet Jan 28 '15 at 09:42
  • I dont know about the ClassLoader structure in a WLS, but if we asume you cannot fix it, then you can either use commons-lang 2.1 in your compile (provided scope - you wont be able to use the not working newer methods) or you can deploy commons-lang3 (java6+) in addition (it has its own package so it hopefully wont conflict). – eckes Jan 28 '15 at 18:56
  • @eckes You mean to say in WLS upgrade `commons-lang` jar to newer version? If os how do I do that? – Jacob Jan 29 '15 at 10:49
  • @Polppan no I mean "since this looks like a official WLS library and I think you dont get permission to upgrade it, better try to downgrade your lang2 or use lang3 in your project) – eckes Jan 29 '15 at 18:18

1 Answers1

1
  1. Review that the error is being throw in the line you posted (check the full stacktrace).
  2. Review that commons-lang.jar is inside the war (folder /WEB-INF/lib/) and is the same jar version that you expected.
  3. Review that there is no other commons-lang being loaded. For example, if you are deploying in Tomcat, check that there is no other commons-lang in tomcat/lib directory.
ARIS
  • 342
  • 3
  • 11
  • In weblogic server, there is `com.bea.core.apache.commons.lang_2.1.0.jar`, so this must be causing the issue? If so how not to use server version of jar? – Jacob Jan 28 '15 at 07:28