The solution has been committed.
This turned out to be a bug in my code, but had a lot to do with the way
WTP treated things that counted as modules but were in fact binary
files. Basically, the "name" of most wtp modules (ear projects, ejb
projects, web projects) is just the name of the project itself.
The name for a binary ejb inside an ear project, however, is actually
something ridiculous like
lib/myEAR99/EarContent/jboss-seam.jar
I have no idea why that's it. Don't ask me. What makes it even worse is
that this, however, is that even this module has "members".
The way my publisher had been handling things was to get the project
name, which should have been the same as the module name. Unfortunately
binary objects *do* have projects, and those projects are the ones they
are contained in. Therefore, my deploy folder became something like
jbosshome/server/default/deploy/myEAR.ear/myEAR.jar
It recognized the child was an ejb, but the name it was using was from
the project. Dumb mistake.
However what compounded it was that the ejb module *also* has
"members". In a project scenerio, that works out just fine because you
would likely append any member directly after the path of the module
itself. For example,
someEar.ear/myEJB.jar and then append each member, such as
someEar.ear/myEJB.jar/META-INF/application.xml
However, in the case of a binary object, you'd end up getting something like
someEar.ear/myEJB.jar/myEJB.jar
The worst part of all is that there's no way to tell whether a "module"
is binary or is a project. There's simply no API for it.
Well, I did my best. I checked to see if the "name" of the module has
more than one "segment" in a Path.
Good luck to us.
- RS