I think it would be easier to follow what's going on with this quickstart if the code were split according to where it runs (client-side or server-side). Additionally it would be great if this were instead built on top of the ejb-remote quickstart as I believe this is the more common scenario, where a standalone remote client needs to access EJBs while switching the caller's identity.
"Additionally it would be great if this were instead built on top of the ejb-remote quickstart as I believe this is the more common scenario"
This quick start was developed based on gathered requirements and demonstrates various approaches we have been asked to provide support for. This quick start must not be simplified down to a remote EJB client only scenario.
Regarding the splitting into two, personally I find that style of quickstart harder to work with as you end up with multiple projects imported into an IDE and multiple locations to execute commands.
In addition it is complicated further in this quick start that we have a requirement to demonstrate server to server calls
so what is in the client ends up on the server leaving us with very little that is purely about a remote client.
I didn't mean to split it into two separate project as I agree that just makes things more difficult to follow. I meant to split things into separate packages.
Sure, both ends may be running inside a server, but one set of classes is acting as a client still. Other classes may be shared and others will be only on the server.
No objection to having a couple of packages added and the classes moved if it makes it easier to group them into related categories.
Pull requests welcome ;-)