you should be able to deploy your war unpacked (e.g. deploy/my.war/...).

You can then mess with files inside your app without repacking.

When you have finished 'touch' my.war/WEB-INF/web.xml and JBoss will reload the webapp.

I don't know how much caching Velocity does, but you may be able to get away without the last step....

As for the second question, here are my thoughts - this isn't my area, so don't assume they are gospel.

1. Local interfaces imply colocation of the beans providing and consuming them. This allows app servers to optimise calls across them. I believe that parameters are guranteed to be passed by reference, so you can have in/out params (i.e. parameters which are changed server-side during the call and then used by the client).

2. Remote interfaces do NOT imply colocation and do NOT support in/out params. Furthermore, params will need to be serialisable (checked at run-time - NOT compile-time) - in case the call is actually remote-ing.

HOWEVER - JBoss will optimise out serialisation between colocated remote-interface-consumers and providers (I'm not sure whether the check for Serialisable occurs before this optimisation takes place).


IN CONCLUSION -

IF you can avoid a need for in/out parameters AND params that are not serialisable THEN I believe that you can continue to use Remote interfaces at no particular runtime overhead (in JBoss), even when colocated. This means less effort if you decide at some later date that you wish to deploy your bean clients remotely from the beans themselves.


Jules

P.S.

There is another approach. I have seen various patterns talked about by which you abstract away from Local/Remote and write to a new interface, which can then be inherited from whichever you choose - If you can bear the thought of yet another set of bean interfaces washing around inside your app you could go this way.





Jules