Stub jars are not required, the client just needs jbossall-client.jar and the home and remote interfaces of the component.
Just like you said, the client just needs jbossall-client.jar and the home and remote interfaces, what I'm trying to do is get this home and remote interfaces from JBoss for client usage. Usually a stub jar can contain those things, I think in JBoss case I used the wrong word since JBoss is using Dynamic Proxy. But that Jar which contains home and remote interfaces plus maybe other dependent classes is indeed very useful, other application servers do generate this Jar(also this Jar is also mentioned in J2EE spec and it states that it should be implementation specifc). So I'm wondering if JBoss can do the same thing? For a client tooling environment, a use case would be a user browse for EJBs in JBoss, and he selects one and imports that Jar in his workspace and develop a client.
You will need to create the jars for the clients yourself so that they just contain the required classes.
If you are going to mention the specs, which spec (title and version), and which section are you referring to?
Ok, but it will be very hard for the client side to assemble this Jar because the user who consumes the EJB probably is not the one who develops this EJB, so the only way is resorting to the runtime, and I just think JBoss might do that for the client.
About the spec, I was wrong, "Because this JAR file is not covered by the J2EE specification, it is implementation-specific, intended only for the Application Server.", but as I said, many servers do generate this Jar.
Thanks for your reply!