Turns out that everything that the applet is going to use had to go into my applet ear. So, the classes reside in two places, but theoretically, should never conflict because they're the same classes.
As far as never conflicting, there definitely could be a problem there. In a very similar deployment scheme, I was getting ClassCastExceptions because I had redundant files in different archives. In looking into the matter, I found similar stories with most developers blaming the fact that java identifies classes, not only by their byte-code, but also by the classloader that loaded them. In JBoss (I believe), every archive in the deploy directory gets its own classloader. So, if a class is created with the class from one archive and later cast (as mine was after being down cast to an Object) to the class from the second archive, you'll get a ClassCastException. I only managed to resolve the problem by grouping everything into an exploded ear which eliminated the redundant file.
I'm still working my way through the classloader paradigm, and, it seems, 4.0 has made some changes. If I've missed the lollipop on this, someone correct me.