jira.codehaus.org

  • Log In Access more options
    • Online Help
    • 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)
  • PicoContainer
  • PICO-386

Component resolution should respect scope from which it was resolved

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.14.1
  • Fix Version/s: None
  • Component/s: PicoContainer (Java)
  • Labels:
    None

Description

I've encountered behavior which looks like a bug to me, but this is maybe by design. I'm not really fluent in Java so I'll write example in Scala. Hope that's ok.

class A(b: B)
class B(name: String)

val container = new DefaultPicoContainer
container.addComponent(classOf[A])
container.addComponent(new B("root"))
val scope = container.makeChildContainer
scope.addComponent(new B("child"))

val a = scope.getComponent(classOf[A])

expected: a.b.name = "child"
actual: a.b.name = "root"

It seems that Pico doesn't respect full dependency path when resolving components registered in parent container. It resolves component based on registration path, not resolution path. This makes it unusable for chaining state and overriding non-trivial components.

I suspect that this change will probably be code invasive, so before I take a better look at what Pico is doing I'm just wondering if you are interested in this behavior, did you try to implement it, but it was to complex, or any other info.

Thanks,
Rikard

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Michael Rimov added a comment - 25/Jan/12 3:22 PM

I understand what you're saying in the example you gave, but right now it isn't possible to do what you describe. That said, I've often thought about how nice it would be to have that feature. You're right that AFAICT, it would be very code invasive, which is why I haven't tried to brave it for that kind of feature.

Paul or others? Any thoughts?

Show
Michael Rimov added a comment - 25/Jan/12 3:22 PM I understand what you're saying in the example you gave, but right now it isn't possible to do what you describe. That said, I've often thought about how nice it would be to have that feature. You're right that AFAICT, it would be very code invasive, which is why I haven't tried to brave it for that kind of feature. Paul or others? Any thoughts?
Hide
Permalink
Rikard Pavelic added a comment - 14/Feb/12 1:17 PM

I finally found some time to take a look at this.
I've got it working in a hackish way
You can take a look at https://github.com/zapov/picocontainer/commit/d103eb52a62d17399df313d1640fd5706c0715f3 too see what I had to do.
If you like this approach I can refine it some more, although I think it would be better if someone more familiar with the code refined it

Regards,
Rikard

Show
Rikard Pavelic added a comment - 14/Feb/12 1:17 PM I finally found some time to take a look at this. I've got it working in a hackish way You can take a look at https://github.com/zapov/picocontainer/commit/d103eb52a62d17399df313d1640fd5706c0715f3 too see what I had to do. If you like this approach I can refine it some more, although I think it would be better if someone more familiar with the code refined it Regards, Rikard

People

  • Assignee:
    Paul Hammant
    Reporter:
    Rikard Pavelic
Vote (0)
Watch (0)

Dates

  • Created:
    25/Jan/12 6:34 AM
    Updated:
    14/Feb/12 1:17 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.