Hey,
My use case is: some components from my enterprise application will be marked as transactional. Throught qdox or xjavadoc we'll collection these information and generate a .meta or something:
/**
* @transaction.aware
*/
public class HailToTheThiefImpl implements HailToTheThief
{
/**
* @transaction.support type="required"
*/
public void Hail1()
{
}
/** * @transaction.support type="requiresnew" */ public void Hail2() { } }
The best option is to not complicate even more the life from ours developers, so if they just obtain a instance of this class throught lookup a proxy will be returned and this proxy knows how to "read" and understand this transactional configuration.
I didn't think twice: lifecycle extensions! So I explored a little the lifecycle extension support in fortress and got a bit disappointed :-\
The lifecycle extensions only deal with the addition of a stage in the lifecycle phase handling - as such its a useful mechanism but its not going to solve the problem you thinking about.
- There is a no extension for each method call - ok, this will be a performance killer, but fortress already returns a proxy for each lookup.
Sounds like you want method level interceptors.
- The current lifecycle extensions phases are creation and accessor (when the container lookups). That would be enough if I could return my own instance that should be returned to the client, but I can't do that:
/** * Retrieve the object and execute access extensions. * * @return the object * @throws Exception if unable to aquire object */ public Object get() throws Exception { final Object object = m_componentHandler.get(); m_extManager.executeAccessExtensions( object, m_context ); return object; }
My proposal is change this to:
/** * Retrieve the object and execute access extensions. * * @return the object * @throws Exception if unable to aquire object */ public Object get() throws Exception { Object object = m_componentHandler.get(); Object newobject = m_extManager.executeAccessExtensions( object, m_context ); return (newobject == null) ? object : newobject; }
Or add an new phase just to allow the extension developer to switch instances... But then'll have to find out a new verb to this :-)
Mucking around with the return type on the current lifecycle stage extension would not be an option as this is a released interface. Instead - I think you need to think about an alternative mechanism such as a factory interceptor or something along these lines.
How do you like that?
Can I go through a painless vote process? ;-)
If it involves modification of the released lifecycle interfaces then expect pain and suffering and if the proposed modifications and not backward compatible then prepare for failure. If on the other hand its something new - then I would suggest working something up in sandbox and see what it looks like.
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
