Develop Reference

java.lang.IllegalArgumentException: The servlets named [A] and [A] are both mapped to the url-pattern [/testurl] which is not permitted

I'm hoping someone can help me figure this one out:
I have two projects on my Eclipse (Spring Tool Suite 3 to be exact) setup:
Our own project with our source code.
Another project from a provider, which our project references as a dependency.
We execute the application locally using a Tomcat v8.5 server.
It was all working fine until recently, when I performed a git pull to update my local code and messed up everything (I'm not sure if I changed something else).
Now, when I try to execute the application, I get the following error (everything compiles and builds correctly):
java.lang.IllegalArgumentException: The servlets named [A] and [A] are both mapped to the url-pattern [/XXXX] which is not permitted.
I didn't make a typo. The error message mentions the same servlet twice, treating it as if it was two different servlets that use the same url-pattern.
Searching for the servlet, I can only find it in a JAR that's downloaded into the local .m2 repository.
I mean, this isn't our servlet, it comes from the provider libraries.
I've seen the other answers to this problem, but those don't work here because:
1) I don't have two servlets steping on each other. There's only one.
2) I can't check if the servlet is defined on the web.xml and on an anotation because it's not ours, but it works for my colleagues so it should be correct.
3) As mentioned before, this servlet is loaded from a dependency, so I can't even try to change anything to try an understand what's happening.
Do you have any idea of what I may have wrong on my setup?
It works correctly for my colleagues, so it isn't a problem with the code.
I've deleted and setup everything from scratch (except deleting the Tomcat server); cleaned and updated the project several times, but I can't get rid of this.
My last attempt was purging and updating the local .m2 repository, but that didn't work either.
Any tips or ideas are much welcomed.

I think you are declaring the servlet mapping both in web.xml and in an annotation, if i remember correctly some tomcat versions allow that.
You said it works for your collegues, check if you all have the same tomcat version.

Web application deployment under embedded Tomcat 7.0.32

We have been using tomcat 7.0.19 successfully in embedded mode. However recently due to some fixes in our area of concern we decided to move to tomcat 7.0.32. Most things work as expected with same code and newer version, however the war deployment for some reason has'nt worked well. I have a couple of servlets registered with my tomcat. Facing below 2 issues,
Has something changed from 7.0.19 to 7.0.32 from embedded tomcat behavior. To detail this out let me explain the behavior difference, with 7.0.19, i could deploy my application and when i hit the "host:port/contextpath" it loaded the applications start page (i.e. welcome page, this page is UI centric and does not need a server intervention, so none of my servlets get called). However with 7.0.32 the same url results in my servlet being called.
So to debug the problem, i commented most of my code so that i have a vanilla tomcat implementation, just the very basic stuff, i.e. setting the engine name, default host, setting host properties, adding a connector (nio, with default properties) and deploying a war. No servlets and other things, just to check if the very basic stuff works. To my surprise when i ran this code it still failed with the same problem within my servlet, how did that happen, now that my code is commented it does not register any servlets, still where does it find it from? Does embedded tomcat store some old references, which are not getting cleaned on subsequent runs? I tried changing the port, but that too didn't help.
I am hitting the wall here, not able to understand this wierd behavior, if i figure out #2, only then can i make some progress on #1.
Thanks in advance,
Vikram

Figured out what the problems were.
In reverse order,
2 - This actually was a weird behavior with the vanilla embedded tomcat code too invoking the servlets which never were registered in the first place. The problem here was with eclipse, for some reason it picked up the old reference of my class. The moment i ran the same code from outside of eclipse i.e. via command prompt, things were back to normal.
1 - This problem was related to web deployment, in my code i was additionally setting my classloader into WebappLoader and eventually adding my application jars into it. This for whatever reasons worked fine with 7.0.19, however did not with 7.0.32, the moment i externalized all my jars to be loaded during application startup via classpath this problem too was resolved.
Thanks,
Vicky

No Class Def Found Error : EJB EAR Packaging or Referencing issue

I have the following projects
EJBWebClient
EJBProj
EJBDataAccess
I first created EJBProj. Created EJBDataAccess and added it to EJBProj.ear. Then created EJBWebClient and added it to same ear respectively.
Now from EJBWebClient I look up an EJB inside EJBProj, its looked up and working fine. Inside the bean implementation, I call a DAO inside EJBDataAccess and it throws NoClassDefFound error for that DAO.
Ex. PersonSerivceBean calls PersonDAO.getAllPeople() which is present inside EJBDataAccess. Here is where it throws NoClassDefFound.
I have referenced EJBDataAccess into the buildpath of EJBProj which in turn is referenced for EJBWebClient.
Any idea what's wrong here?

I believe this is a problem with your EJB container. I am not sure what you are using (JBoss, WebSphere, WebLogic, etc), and I am no expert on any of them (we stopped using EJBs a long time ago), but any time you get a NoClassDefFound error, it means the current ClassLoader (the one that loaded the .class your code id "in") cannot find a referenced class.
I know many, many moons ago, JBoss used to have the idea of a "Universal ClassLoader". Basically, all JARs/EARs/WARs were loaded in one big pool. The problem is that a lot of time the code needed different versions of the same JAR, and they were not always compatible. Also, there technically a security risk if someone drops a "custom" class/JAR into the mix ahead of yours. I think it was around JBoss 3.5 that they switched away from the Universal ClassLoader, as I remember our app needed a LOT of work to fix things up to work right. Most of this was a packaging issue for us.

I resolved the issue by manually including the jar names in MANIFEST.MF

servlets and classpath

I apologize for the crummy subject line.
I started at a new company last week and was thrown into the lion's den immediately. We had a application on the verge of going into production... One of my guys had the app running and QA'ed so I didn't delve too much into the details of what he was doing.
We had this:
../legacy/ROOT/
..............index.jsp
..............WEB-INF/
.....................lib/
.........................(libs)
.....................classes/
............................x.class
There's a virtual host in conf/server.xml that defined the root as ROOT.
The new application seems to have started as a copy/paste of the legacy app. It has no entry in server.xml. It piggybacks, so to speak, on the legacy app even though it is wholly separate. The new application is rooted at legacy/ROOT/NewApp:
../legacy/ROOT/
..............index.jsp
..............WEB-INF/
.....................lib/
........................(libs)
.....................classes/
............................x.class
..............NewApp/
....................index.jsp
....................WEB-INF/
...........................lib/
..............................(libs)
...........................classes/
..................................x.class
To get to the legacy app, you browse to http://theUrl. To get to NewApp, you browse to http://theUrl/NewApp. That all works fine. Maybe.
We installed the new application on Saturday night. Monday morning, we find that while NewApp works great, our users can't log in to the legacy site. They get an application-generated 'bad username' error.
It occurs to me I don't know why NewApp works at all. I did not change web.xml. So I surmise that Tomcat finds a URL it likes by looking at the HOST definitions, then sees /NewApp in the URL and is happy to traverse into the legacy/ROOT/NewApp sub-directory where it finds an index.jsp and we're off to the races.
Now I get very confused. The legacy code has a WEB-INF folder, and NewApp/WEB-INF also exists. I don't know why Tomcat is doing anything with the NewApp/WEB-INF. Yet it is because NewApp works great. To make matters worse, the libs and and class files in both apps are nearly identical in name and content. The x.class file in NewApp is slightly different than the one in legacy - NewApp has a new login method. NewApp's x.class still has the old login method in it, however, though nothing in NewApp uses it.
I'm trying to determine how legacy's failure is related to our deployment. It must be - but it's hard to see how. We checked file dates. Nothing in legacy has been changed. I'm thinking it's a classpath issue somehow.
So, do I have one application here, or two? I thought it was the latter. But I'm not so sure. I'm so confused I can't even ask a good question :-/
The only other oddity was that Tomcat didn't explode the WAR file though the configuration looked like it should have. We had to do it by hand - and it worked.
This is what happens when your lead developer says, "3 months" and management says, "No, 1 month." It's a credit it works at all.

Wow! Definitely a face-palm moment for you. :-(
Here's my stab at understanding it, and of course I could be quite wrong: at runtime Tomcat doesn't care necessarily what is at the same level on the filesystem as the application root, so long as it finds what it thinks is a valid WAR in the root. And it would make sense Tomcat would check to see if a given folder structure in a URL matches a webapp before looking to see if it's a folder IN a webapp. So that would explain the "new" app.
As for the original app, if it doesn't reference the "NewApp" folder at all, then Tomcat would have no reason to even look in there, and if it did it would ignore the fact it looks like a webapp. It's just another folder of files. I suspect you can probably access any file in there directly by hand-constructing a URL to it. Handy. :-p (Edit: probably not, thinking about it again, Tomcat would likely just take any 'NewApp' reference to mean the new app, not a file in the old app.)
So... you have two webapps. I think Tomcat will keep them separate. But... it would give me the heebie-jeebies to think I had something like that in production...

I echo what Rodney has said. Tomcat looks for WAR files and treats them as an individual webapp (I think...). In your case, as Rodney says, from Tomcat's point of view all you have there is a webapp that happens to have a folder with some class files in it.
What I suspect is happening is that NewApp has the same packages/class names as legacy, and therefore one is overwriting the other (as Tomcat is probably picking up the NewApp WEB-INF folder - I don't quite understand how but there you go).
This isn't what you or your company wants to hear, but they should never have been bundled together as two separate apps. If NewApp depends on Legacy, then you could have JAR'd up the required code from Legacy and included it as a dependency for NewApp. But as you have it now, they should be separate, and I would say that Tomcat is getting pretty confused.
But maybe someone else has a way to solve it as it exists right now... but I'd be surprised to be honest.

Weblogic application complains about some classes missing, how to debug?

I have a rather complex J2EE app I don't have any documentation for and I am trying to get it to run.
I have gotten the ant build script to compile a EAR file that contains a WAR file, but this application even though I get "successfully deployed" on weblogic console is still not working.
There are many required jars missing from the EAR file, hence I get errors about missing classes on the console log when I deploy the app. Sometimes even after I check a particular class is there I still get the error.
What is a best way to debug and get this application running?
Is there any shortcuts in J2EE/Java to "find all dependencies", apps anybody knows to analyze code and find dependencies or anything like that?

Is there any shortcuts in J2EE/Java to "find all dependencies", apps anybody knows to analyze code and find dependencies or anything like that?
Do you mean a compiler? I'm actually semi serious here (even if the compiler won't give you the name of a missing JAR). Indeed, if you are compiling that application successfully with Ant, then you likely have all dependencies required at compile time (you may need more of them at runtime but, well, you'll need to execute the code to identify them). Maybe you just need to add more of them in the EAR during the packaging. Or maybe you need to add more dependencies at the app server classpath level.
In both case, search engines like jarFinder.com or Docjar.com or Jarhoo.com might help you to identify missing JARs and to solve your ClassNotFoundException or NoClassDefFoundError.
You should actually give readers more details about the missing classes, I'm sure people will be able to give you some hints and point you in the right direction.

I know of no easy way to deal with this. If the application provides an ant task build the EAR then the result should be a self-contained deployable application EAR. It is possible that the EAR requires extra libraries to be added to some class path, without documentation it's really hard to know what.
This phrase is, I guess, at the heart of the problem: "Sometimes even after I check a particular class is there I still get the error." Exactly what do you mean?
You are getting a class not found error but you can see the class in the EAR file? If that's the case then things are really difficult, and may well be some kind of classloader issue. I don't know WebLogic at all, but in WebSphere when deploying an application you have a choice of whether to give precedence to JARs in the EAR or to the same JAR in WebSphere itself. Some Applications demand one or the other setting. If there's anything like that in WebLogic then this may be your problem.
Another possible problem is that the app may depend on infrastructure libraries (Eg. XML parsers) that are supplied by WebLogic, but expects a different version that is supplied with the WebLogic version you are using.
Without documentation that the app is supported on the version of WebLogic you are using, I fear you're fighting a long, hard (or even a losing) battle.

I'd assume you managed to get this application put together and compiled in an IDE, maybe Eclipse. Why not simply put all the Jars that you had available at build time, into the EAR?
If you're having to debug this by trial and error, you can look at the list of missing classes and figure out which jars they belong to by Googling for the class names, or maybe you can find them in your IDE too.
If you have a lot of trouble identifying some classes, post the class names (or the error messages) here and someone should be able to tell you where to find the Jar it belongs in.

If you are able to successfully build and deploy the app, but still getting the errors about missing classes, probably some of the jar classes are called through reflection. You may want to search for reflection API calls in the Project through your IDE.
These calls may be something like,
"Class cls = Class.forName(..); cls.newInstance()."
Sometimes even after I check a
particular class is there I still get
the error.
This may be a deployment issue. check the classpath. Some of the jars may be missing from the Classpath.

Is there any shortcuts in J2EE/Java to
"find all dependencies", apps anybody
knows to analyze code and find
dependencies or anything like that?
I'd start by having another go at getting documentation ... or help ... from the original developers, if you can find them. [IMO, people who develop / provide software without any documentation deserve to be bugged incessantly by people asking silly questions.] But I guess you've already tried that.
Then there are the jarfinder.com and other services as mentioned in another answer. (New to me!)
If that fails, I'd try doing a Google search on the FQNs. The chances are that if the missing classes are part of a commonly used library you will hit the Javadocs ... or a posting from someone else with a similar problem to yours.
If the "Google it" approach fails, use the clues in the package naming for the missing classes to try and find where they come from. If they follow the Sun recommendations, the names should map to a company or (real or pseudo-) organization that you can locate by a web search.