I wonder, would you be able to enhance it by extracting an interface from the CurrentTimeService class and showing the use of CDI to inject one of two (or more) possible implementations of this interface into the HelloService class?

Way to go Adam; thanks a bunch for clarifying this. Strangely enough, though EJB _development_ itself is more fun (and also easier) than ever with recent Java EE versions, finding a right build and module structure still feels painful at times. This one definitely helped, and it feels good to give up on EAR after all. ;)

As an additional question however, as this seems to cause problems once in a while: Given such a setup, what would be a sane way to easily make HelloService accessible to another (external) web app? So far, I see a load of EJB 3.1 documentation focussing on things being easy as long as all the functionality lives inside one application context, be that jar or war or whatever. How, in such a situation, would an "external" webapp access this structure? I assume it would end up introducing a @Remote interface to HelloService and a dedicated external client jar (assuming the "external" webapp runs inside the same application server)?
Cheers,
Kristian

first thx for your articles about Java EE - helped me a lot many times.

I would like to ask what is the proper JARs structure (which are then added to such Java EE WAR) if you have entities inside. Where should be persistence.xml? In every single JAR (under META-INF) or in top-level WAR (WEB-INF/classes/persistence.xml)? I can imagine that almost every such module would like to use same DB (~? DS/PU).

The real example could be AccountsService which is interface injected via CDI. It might have various implementations in various JARs. First impl might just delegate the requests to some external service/server while the other impl might want to use local DB to manage accounts (credentials..etc.) so it will have some AccountEntity which will need its persistence.xml, right?:)