[jboss-dev-forums] [Design of JBoss Transaction Services] - 'public' API stability when embedded in JBossAS

The long term support commitments for JBossTS CP maintenance involve not making public API changes, the intention being that users can be confident that moving between CP releases won't cause linker type errors. Unfortunately this is at odds with the need to fix bugs, which can sometimes require API changes. As we prepare to fork another long term maintenance branch I think we should spend some time considering this dilemma. What is the API we wish to support? We have got ahead of the game with XTS, explicitly packaging (i.e. different .jar) the API distinct from the implementation. For the rest of JBossTS it's all bundled up together, so we have to consider any 'public' class to be part of our published API. For a long time the codebase has used .internal. packages to denote implementation, but users are not necessarily aware of this distinction. A lot of code which end users need to access directly when running standalone, is abstracted by the app server when running embedded. Arguably the only public API for JBossTS when embedded in JBossAS, is the TransactionManagerService mbean, CORBA interceptors, ObjectStore and possibly a recovery class or two. The rest is all abstracted via javax.transaction. But this is at odds with the 'if we ship it we support it' model, since the binaries still include e.g. TxOJ and TransactionalDriver, neither of which JBossAS uses. My personal preference would be to publish the list of interfaces/classes we consider stable and make clear that everything else is subject to change in CPs, regardless of .internal. or 'public' modifiers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208938#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...