POJO service module

Hello,

I have been working on a small module which allows the developer to write
services as simple POJO implementations, and then generates the following
artefacts from the implementation:

1) Service interface (extracted from all public methods of the
implementation, unless specifically marked
to be excluded).
2) Stateless Session Bean facade (which will then be processed by ejbdoclet)
3) Business Delegate which uses the local interface of the SLSB facade
4) Business Delegate which uses the remote interface of the SLSB
5) Business Delegate which uses the POJO directly (by spring tags to be
later processed by springdoclet).  If this option is used then developers
will most likely need a different spring config grafting transactional
behaviour on the POJOs).

The driver behind this is to support IOC style development, to facilitate
coding to interfaces and POJOs, changing the role of EJB to an
implementation decision, and increasing productivity by generating the
majority of artefacts.

So the developers can choose whether they want to work in a remote EJB
invocation environment, local EJB invocation environment (because they know
it will be a single tier deployment), or POJO invocation (because they only
want to deploy in a web container, not a full J2EE container).

Currently, this module contains a few hard-wired assumptions geared towards
our particular scenarios, but they are fairly easy to remove.

The question is, do XDoclet developers see this as a worthwhile module for
core XDoclet?  Personally, I do, because this style of development is
becoming mainstream.

If it is seen as worthwhile to be included, I would be happy to contribute /
maintain it.

--
Simon Godden