You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Hamilton Verissimo de Oliveira (Engenharia - SPO)" <ha...@agenciaclick.com.br> on 2004/02/14 19:41:39 UTC
[Proposal] Augmenting Fortress extensions support
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 :-\
- 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.
- 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 :-)
How do you like that?
Can I go through a painless vote process? ;-)
--
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Augmenting Fortress extensions support
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
> There is nothing stopping evolution. All I'm saying is that you can not
> change the return time on the existing lifecycle extension interface
> methods because that would break backward compatibility.
I heard ya.
> It is clear
> the the approaches to container extension are open territory for
> evolution - just do it under a fortress scoped package name and you'll
> be safe.
Then we'll end having two - or more - ways of doing the same thing -
semantically, at least. But I'll think about it.
--
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Augmenting Fortress extensions support
Posted by Stephen McConnell <mc...@apache.org>.
hammett wrote:
> ----- Original Message -----
> From: "Stephen McConnell" <mc...@apache.org>
>
>>Mucking around with the return type on the current lifecycle stage
>>extension would not be an option as this is a released interface.
>
>
> So we're tied to each released interface... Not sound particulary good as
> this limits evolving.
There is nothing stopping evolution. All I'm saying is that you can not
change the return time on the existing lifecycle extension interface
methods because that would break backward compatibility. It is clear
the the approaches to container extension are open territory for
evolution - just do it under a fortress scoped package name and you'll
be safe.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Augmenting Fortress extensions support
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> Mucking around with the return type on the current lifecycle stage
> extension would not be an option as this is a released interface.
So we're tied to each released interface... Not sound particulary good as
this limits evolving.
> Instead - I think you need to think about an alternative mechanism such
> as a factory interceptor or something along these lines.
Why not add one more method to the interface? Oh, it will break current
implementations.. oh well. I'll fork fortress and that solves my problem :-)
>
> Cheers, Stephen.
regards.
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Augmenting Fortress extensions support
Posted by Stephen McConnell <mc...@apache.org>.
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] Augmenting Fortress extensions support
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "andreas oberhack" <de...@softwarefabrik.biz>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Sunday, February 15, 2004 4:32 AM
Subject: RE: [Proposal] Augmenting Fortress extensions support
> Let me try to understand your requirements first. I assume, that you are
> talking about transactions to persist objects?
Yup. I'm trying to push Avalon a loosely couple BO framework. Then I'd like
to start in little steps :-)
> >
> > - There is a no extension for each method call
>
> And you would like to declare a transaction per method call, so that the
> transaction context could be set automatically?
Exactly. See my article about JTA:
http://www.apache.org/~hammett/articles/jta.html
Its just evolving this implementation.
--
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Proposal] Augmenting Fortress extensions support
Posted by andreas oberhack <de...@softwarefabrik.biz>.
Hi Hamilton,
> My use case is: some components from my enterprise application will be
> marked as transactional.
Let me try to understand your requirements first. I assume, that you are
talking about transactions to persist objects?
>
> - There is a no extension for each method call
And you would like to declare a transaction per method call, so that the
transaction context could be set automatically?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org