JIRA

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Use Agile By Default
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile Access more options (Alt+g)
  • Create Issue
  • Mule
  • MULE-1922

Improve Initialisation in 2.0

  • Agile Board
  • More Actions
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0.0-M1
  • Fix Version/s: 2.0.0-RC1
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    High
  • Similar Issues:
    None

Description

This is a bit vague because I don't understand all the issues.

However, it appears that the model initialisation process has changed in 2.0. It seems to be performed during Spring assembly which means that it occurs in a bottom-up manner: Spring generates a tree of objects and starts with the leaf nodes, creating and initialising them first, then creating parent nodes into which the children are injected.

I am not sure how things worked before, but the current approach causes problems because some information has to pass down through the object tree before components can be initialised. In particular, the endpoint type seems to be defined by the router in which it is embedded. So the endpoint does not "know" its own type until injected in a router, yet objects lower down the object tree require this information to initialise correctly themselves.

This has led to two problems, I believe. First, security filters need to know the endpoint type. To handle this I have changed the initialisation to be "lazy" - it is done the first time the filter is used. Second, I think the problems I had with transformers may be related to the late setting of type. By default the endpoint type is "send and receive". This is the value my tests cases were using – I suspect that they should in fact have been using send or receive, but that the transformers were chosen before this value was set (I have not verified this).

There is also a general impression, when rewriting tests, that "initialise" calls are somewhat random (IIRC endpoints now don't need them, while components do?).

I feel we are drifting towards an ever more ad-hoc initialisation process. My initial suggestion is to make intialisation a recursive process, performed after assembly, in which parents call intialise on their own children. This allows information to be both pushed down and pulled up the object tree.

At the same time there has been discussion on lifecycle issues which may be related. I have no idea how lifecycle is controlled - it's not something I have worked on yet. So this issue maybe addressed or involved in that work (whatever it is).

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. MULE-1957 Transformer set on Endpoint before type known

  • 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.

Task - A task that needs to be done. MULE-1956 Revise Lazy Init for Security Filters

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
Hide
Permalink
andrew cooke added a comment - 18/Jun/07 08:53 AM

Spring-specific solution might be to use "afterPropertiesSet" (from comment in acegi delegate).

Show
andrew cooke added a comment - 18/Jun/07 08:53 AM Spring-specific solution might be to use "afterPropertiesSet" (from comment in acegi delegate).
Hide
Permalink
andrew cooke added a comment - 25/Jun/07 09:29 AM

I have replaced this with the more specific MULE-1956 and MULE-1957.

Show
andrew cooke added a comment - 25/Jun/07 09:29 AM I have replaced this with the more specific MULE-1956 and MULE-1957.
Hide
Permalink
Andrew Perepelytsya added a comment - 27/Oct/07 01:15 PM

Reopening to correct the fix version

Show
Andrew Perepelytsya added a comment - 27/Oct/07 01:15 PM Reopening to correct the fix version

People

  • Assignee:
    andrew cooke
    Reporter:
    andrew cooke
Vote (0)
Watch (0)

Dates

  • Created:
    15/Jun/07 09:18 AM
    Updated:
    27/Oct/07 01:19 PM
    Resolved:
    27/Oct/07 01:19 PM

Agile

  • View on Board
  • Atlassian JIRA (v5.0.7#734-sha1:8ad78a6)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.