if you have deployed EJBs and want to access them, then you need (at least) the @Remote or @Local interfaces in the jar file.
But you seem to want to do more, right?
I deploy my application as a single ear-file which contains one war-file and one ejb3-file.
We're doing some work to make EJBs be embeddable in a Swing app or Tomcat without the need for an app server...
If it is not possible to do this with a servlet and "load on startup" processing,
or even hook into the lifecycle of the servlets through a valve,
we could ask people to use a custom "Context" implementation
that will give access to the webapp deployment lifecycle and the other internal datastructures:
Another alternative would be to customize the classloader:
I would speak to Remy to get advice on the best approach.
We really need a concrete list of requirements/processing that *needs* to be done at deployment time.
Ideally, this should be as transparent as the user wishes.
1) it could be automatic
2) they may want to control it themselves, e.g. choosing which ejbs they want from a jar per deployment or bootstrapping ejbs if they are really required?
But I guess, that is something for further down the road, i.e. 5%/95%
Of course, in JBoss5 we will have the "Aspectized" deployment.
Everything is possible within servlet "load on startup" processing. The problem is, for simple configuration I need access to the actual JAR file that contains EJB3 classes/xml config. Since this will be in WEB-INF/lib I can't get access to the actual JAR file so that the EJB3Deployer can look at the contents of the JAR to figure out what to deploy.