Stripes

proposal: terminate for ConfigurableComponent

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: Release 1.6
  • Component/s: None
  • Labels:
    None
  • Environment:
    any

Description

This proposal consists in defining a new method in ConfigurableComponent interface.

this method would be called once the application server perform a clean shotdown.
In a terminate method would be possible to commit several data uncommitted.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tim Fennell added a comment - 21/May/08 8:01 AM

I don't think it could hurt to have this, but since it might require code changes by users I don't think we can do it outside of a major release.

Show
Tim Fennell added a comment - 21/May/08 8:01 AM I don't think it could hurt to have this, but since it might require code changes by users I don't think we can do it outside of a major release.
Hide
Permalink
Richard Hauswald added a comment - 20/Apr/11 4:10 PM

Implemented this feature, all tests passed.

Show
Richard Hauswald added a comment - 20/Apr/11 4:10 PM Implemented this feature, all tests passed.
Hide
Permalink
Remi VANKEISBELCK added a comment - 21/Apr/11 1:53 AM

Hi Richard,

Just reviewed your patch. Seems good, but I think there could be a better way to do this, that doesn't force implementors to code the terminate method.

I think that you can do better by introducing a new interface and check if it's implemented by the component(s) before calling it :

interface Disposable { dispose(); }

class MyComponent implements ConfigurableComponent, Disposable { ... }

See what I mean ? This is, I think, good use of interfaces, and it won't break client code.

Cheers

Remi

Show
Remi VANKEISBELCK added a comment - 21/Apr/11 1:53 AM Hi Richard, Just reviewed your patch. Seems good, but I think there could be a better way to do this, that doesn't force implementors to code the terminate method. I think that you can do better by introducing a new interface and check if it's implemented by the component(s) before calling it : interface Disposable { dispose(); } class MyComponent implements ConfigurableComponent, Disposable { ... } See what I mean ? This is, I think, good use of interfaces, and it won't break client code. Cheers Remi
Hide
Permalink
Richard Hauswald added a comment - 23/Apr/11 3:47 AM

Hi Remi,
I do agree with you, this would be the perfect way to do. I also think that the current implementation needs refactoring to do the init and terminate stuff on two lists typed to the interfaces mentioned above. Additionally there is a lot of copy and past going on in DefaultConfiguration:
...
this.actionResolver = initActionResolver();
if (this.actionResolver == null) { this.actionResolver = new NameBasedActionResolver(); this.actionResolver.init(this); }

this.actionBeanPropertyBinder = initActionBeanPropertyBinder();
if (this.actionBeanPropertyBinder == null) { this.actionBeanPropertyBinder = new DefaultActionBeanPropertyBinder(); this.actionBeanPropertyBinder.init(this); }
...
IMHO this class should act as factory only. If this is done, stuff like :
if (this.objectFactory instanceof DefaultObjectFactory) { ... }
should be done in the classes init method currently checked by instanceof.

Since the original feature request was accepted I implemented it the requested way. I'm also fine your solution or a complete refactored version. So what's you preferred solution?
Regards,
Richard

Show
Richard Hauswald added a comment - 23/Apr/11 3:47 AM Hi Remi, I do agree with you, this would be the perfect way to do. I also think that the current implementation needs refactoring to do the init and terminate stuff on two lists typed to the interfaces mentioned above. Additionally there is a lot of copy and past going on in DefaultConfiguration: ... this.actionResolver = initActionResolver(); if (this.actionResolver == null) { this.actionResolver = new NameBasedActionResolver(); this.actionResolver.init(this); } this.actionBeanPropertyBinder = initActionBeanPropertyBinder(); if (this.actionBeanPropertyBinder == null) { this.actionBeanPropertyBinder = new DefaultActionBeanPropertyBinder(); this.actionBeanPropertyBinder.init(this); } ... IMHO this class should act as factory only. If this is done, stuff like : if (this.objectFactory instanceof DefaultObjectFactory) { ... } should be done in the classes init method currently checked by instanceof. Since the original feature request was accepted I implemented it the requested way. I'm also fine your solution or a complete refactored version. So what's you preferred solution? Regards, Richard
Hide
Permalink
Richard Hauswald added a comment - 26/Apr/11 2:19 PM

Hi,
this is only a proposal which shows what I mean by lists of interfaces. It won't work since the the initialization work done in DefaultConfiguration and RuntimeConfiguration is not yet extracted. I will do this in case you are about to accept this approach.

Regards,
Richard

Show
Richard Hauswald added a comment - 26/Apr/11 2:19 PM Hi, this is only a proposal which shows what I mean by lists of interfaces. It won't work since the the initialization work done in DefaultConfiguration and RuntimeConfiguration is not yet extracted. I will do this in case you are about to accept this approach. Regards, Richard

People

Vote (0)
Watch (1)

Dates

  • Created:
    07/Mar/07 2:36 AM
    Updated:
    26/Apr/11 2:19 PM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for Stripes Framework. Try JIRA - bug tracking software for your team.