Revise Lazy Init for Security Filters

Details

  • User impact:
    Low
  • Effort points:
    0.5
  • Similar Issues:
    None

Description

The initialise method of AbstractEndpointSecurityFilter is called after the object is created and populated via Spring, but before it receives an endpoint (which is set from within the endpoint, when the filter is injected into the endpoint, which occurs after this object is created and initialised).

This means that when initialise() is called, the endpoint is not known. So the endpoint type cannot be checked. So the initialisation code which requires the endpoint type must be postponed until after the endpoint is set. At the moment we use lazy initialisation - the method lazyInit() is not called until the filter is used (by which point the endpoint should be set). Another alternative would be to initialise when the endpoint is set.

Anyway, Ross asked for this to be noted in an issue here for later consideration.

Issue Links

is duplicated by

Improvement - An improvement or enhancement to an existing feature or task. MULE-1922 Improve Initialisation in 2.0

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
andrew cooke added a comment -

Andrew P mentions that there is a "model complete" event of some kind that is available to Mule components. This would probably be the best way to do initialisation like this.

Show
andrew cooke added a comment - Andrew P mentions that there is a "model complete" event of some kind that is available to Mule components. This would probably be the best way to do initialisation like this.
Hide
Permalink
andrew cooke added a comment -

That event was related to the old mule manager (or whatever). We probably need a completely new event.

See also MULE-1957 which needs similar re-working.

Show
andrew cooke added a comment - That event was related to the old mule manager (or whatever). We probably need a completely new event. See also MULE-1957 which needs similar re-working.
Hide
Permalink
Daniel Feist added a comment -

Started looking into this, I think the MuleContext "start" phase is equivalent to the the "model complete" in 1.4, at least for cases like this.

The problem that prevents this implementation is the fact that securityFilters are prototypes in spring, so when the "start" lifecycle phase attempts to "start" the security filter, what the registry returns is a new "prototype" instance which of course is not what is wanted, and has the endpoint in null.

Looking at the abstract bean definition parser classes it seems singleton=false is the default. shouldn't this default be true, give than we are using spring as a "registry" in almost all cases i know of. Alternatively i suppose we can implement an abstract SecurityEndpointFilter BDP which sets singleton=true and extend that? thoughts?

Show
Daniel Feist added a comment - Started looking into this, I think the MuleContext "start" phase is equivalent to the the "model complete" in 1.4, at least for cases like this. The problem that prevents this implementation is the fact that securityFilters are prototypes in spring, so when the "start" lifecycle phase attempts to "start" the security filter, what the registry returns is a new "prototype" instance which of course is not what is wanted, and has the endpoint in null. Looking at the abstract bean definition parser classes it seems singleton=false is the default. shouldn't this default be true, give than we are using spring as a "registry" in almost all cases i know of. Alternatively i suppose we can implement an abstract SecurityEndpointFilter BDP which sets singleton=true and extend that? thoughts?
Hide
Permalink
andrew cooke added a comment -

if start will work that sounds good - i think what andrew p might have been referring to was an event rather than a lifecycle call (to be honest it's not clear why both mechanisms exist)? lifecycle calls are easier because you don't have to register to receive them.

Show
andrew cooke added a comment - if start will work that sounds good - i think what andrew p might have been referring to was an event rather than a lifecycle call (to be honest it's not clear why both mechanisms exist)? lifecycle calls are easier because you don't have to register to receive them.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: