Discussion:
Container hierarchy
Martin Larsson
2009-03-18 10:50:19 UTC
Permalink
I'm just starting out with PicoContainer, so this might be a somewhat
confused question...
I tried searching the archives, but the search is apparently broken,
no matter what I typed
in, the result set was empty, even 'container' which is displayed with
a large font on the
archive page.

Anyways.
I have a class MyClass that depends on another Dependency. Adding them both to a
DefaultPicoContainer works nicely, and objects of MyClass is created easily.

In some special cases, I don't want Dependency, but rather it's subclass
SpecialDependency. So, I create a child container of my main
container, and add this
new class. However, asking the child container for a MyClass-object
still links it to
Dependency. To link it to SpecialDependency, I have to add MyClass to the child
container as well.

Is that really necessary? After all, I am asking the child container
for the object,
and it has all the new dependencies defined.

M.

Code fragments (all code attached):
public class MyClass {
private Dependency d;
public MyClass(Dependency d) {
this.d = d;
}

public String toString() {
return getClass().getName() + " - " + d.getClass().getName();
}
}

public class Start {
private void go() {
MutablePicoContainer pico;
MutablePicoContainer special_pico;

pico = new DefaultPicoContainer();
pico.addComponent(Dependency.class);
pico.addComponent(MyClass.class);

special_pico = pico.makeChildContainer();
special_pico.addComponent(Dependency.class, SpecialDependency.class);

// Should this be necessary?
//special_pico.addComponent(MyClass.class);

// This prints 'picotest.MyClass - picotest.Dependency' as expected
MyClass my = pico.getComponent(MyClass.class);
System.out.println(my);

// This only prints 'picotest.MyClass - picotest.SpecialDependency'
// when special_pico.addComponent(MyClass.class); above is
// uncommented.
my = special_pico.getComponent(MyClass.class);
System.out.println(my);
}
}
Konstantin Priblouda
2009-03-18 10:55:53 UTC
Permalink
Subject: [picocontainer-user] Container hierarchy
Date: Wednesday, March 18, 2009, 12:50 PM
I'm just starting out with PicoContainer, so this might
be a somewhat
confused question...
I tried searching the archives, but the search is
apparently broken,
no matter what I typed
in, the result set was empty, even 'container'
which is displayed with
a large font on the
archive page.
Anyways.
I have a class MyClass that depends on another Dependency.
Adding them both to a
DefaultPicoContainer works nicely, and objects of MyClass
is created easily.
In some special cases, I don't want Dependency, but
rather it's subclass
SpecialDependency. So, I create a child container of my
main
container, and add this
new class. However, asking the child container for a
MyClass-object
still links it to
Dependency. To link it to SpecialDependency, I have to add
MyClass to the child
container as well.
Is that really necessary? After all, I am asking the child
container
for the object,
and it has all the new dependencies defined.
Container hierarchies work like classloaders - dependencies
necessary for instantiating a class, will be looked up from
instantiating container and down to the root of hierarchy.

Thus dependency defined in child container will be never used
to instantiate something off parent ( even if you ask for it through child )

In fact, parent container components are not aware of existence
of children



regards,
----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-19 00:56:54 UTC
Permalink
On Wed, Mar 18, 2009 at 11:55 AM, Konstantin Priblouda
Thus  dependency defined in child container will be never used
to instantiate something off parent ( even if you ask for it through child )
Ok. That's a design choice. It wouldn't be strange if PicoContainer
searched the same
path when searching for the dependencies as when searching for the
requested class.
Though it might make behavior rather unpredictable.

Thanks for the answer, and sorry for the additional followup. Your
answer ended up in
my spam-folder for some unknown reason...

M.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Paul Hammant
2009-03-19 05:47:14 UTC
Permalink
Konstantin often ends up in a spam folder ;-)

What you're trying to do is use a container for overrides. Really you
should have something like this below

public class Start {
private void go() {
MutablePicoContainer pico;

pico = new DefaultPicoContainer();
pico.addComponent(Dependency.class, SpecialDependency.class);
pico.addComponent(MyClass.class);

MyClass my = pico.getComponent(MyClass.class);

}
}

It is more correct. Can you tell us more about your case ?

Regards,

- Paul
Post by Martin Larsson
On Wed, Mar 18, 2009 at 11:55 AM, Konstantin Priblouda
Post by Konstantin Priblouda
Thus dependency defined in child container will be never used
to instantiate something off parent ( even if you ask for it
through child )
Ok. That's a design choice. It wouldn't be strange if PicoContainer
searched the same
path when searching for the dependencies as when searching for the
requested class.
Though it might make behavior rather unpredictable.
Thanks for the answer, and sorry for the additional followup. Your
answer ended up in
my spam-folder for some unknown reason...
M.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-20 09:32:38 UTC
Permalink
Post by Paul Hammant
What you're trying to do is use a container for overrides.
Yes, that's correct. And I'm mainly using the container as a factory. However,
I'm just looking at various options. OSGi might be "more correct" for
my purposes,
but it's a bit more complex (to say the least).
Post by Paul Hammant
Can you tell us more about your case ?
I need to instantiate objects for various countries. Most objects will be quite
similar, but there might be slight differences as well, and not just regarding
language. An example would be a class Person. Most things are equal, but
the rules for the personal ID (SSN or whatever they might call it) will be
somewhat different. There are, of course, various ways of handling this,
and currently I'm exploring what that would look like with PicoContainer.
The idea was to put all common classes in the root-container, and then add
special cases to country-specific child containers. So if I want a Canadian
Person-object, I query the Canadian container. If it's not located there, it
will automatically check the default container.

I also need to be able to mix objects from various countries in the
same session. IOW. I need both the US Person implementation and
the Canadian Person implementation simultaneously.

M.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Konstantin Priblouda
2009-03-20 09:47:42 UTC
Permalink
Subject: Re: [picocontainer-user] Container hierarchy
Date: Friday, March 20, 2009, 11:32 AM
On Thu, Mar 19, 2009 at 6:47 AM, Paul Hammant
Post by Paul Hammant
What you're trying to do is use a container for
overrides.
Yes, that's correct. And I'm mainly using the
container as a factory. However,
I'm just looking at various options. OSGi might be
"more correct" for
my purposes,
but it's a bit more complex (to say the least).
Post by Paul Hammant
Can you tell us more about your case ?
I need to instantiate objects for various countries. Most
objects will be quite
similar, but there might be slight differences as well, and
not just regarding
language. An example would be a class Person. Most things
are equal, but
the rules for the personal ID (SSN or whatever they might
call it) will be
somewhat different. There are, of course, various ways of
handling this,
and currently I'm exploring what that would look like
with PicoContainer.
The idea was to put all common classes in the
root-container, and then add
special cases to country-specific child containers. So if I
want a Canadian
Person-object, I query the Canadian container. If it's
not located there, it
will automatically check the default container.
... Or you explicitely query for CanadianPerson
I also need to be able to mix objects from various
countries in the
same session. IOW. I need both the US Person implementation
and
the Canadian Person implementation simultaneously.
Nothing prevent your canadian and american persons to sit in
the same container ( except mutual latent aversion as shown
in various films ;) ) and have distinct set of dependencies.

The you may query for
- canadian person[s]
- american person[s]
or even any persons.

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-20 10:07:14 UTC
Permalink
On Fri, Mar 20, 2009 at 10:47 AM, Konstantin Priblouda
Post by Konstantin Priblouda
Nothing prevent your canadian and american persons to sit in
the same container  ( except mutual latent aversion as shown
in various films ;) )  and have distinct set of dependencies.
Certainly, the question is how to get the one you need. What
information is needed and known at the point where a Person
should be instantiated (we all know instantiation of Persons
quite often involves alcohol, so obviously, only the tiniest
amount of information can be trusted to be present and
accurate...)
Post by Konstantin Priblouda
The you may query for
 - canadian person[s]
 - american person[s]
or even any persons.
Hm. I assume this would require a hierarchy of classes?
AmericanPerson and CanadianPerson derives from Person?

I don't really want that. I'd rather have a single Person-class
with various dependencies, i.e. one for the validation of the
personal ID. There will be others, and adding a subclass for
each combination will be rather messy.

If we take the Person-example further, I'd have a Person-class
that takes an IDValidator as a constructor parameter. The
default implementation just says everything is ok. I then add
an IDValidator_US and an IDValidator_Canada. How do I now
query for a Canadian or a Mexican (who would get the default
implementation)?

I understand this could be seen as abusing the container, and
that's fine. As I said, I'm just exploring possibilities. :*)

M.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Konstantin Priblouda
2009-03-20 10:20:40 UTC
Permalink
Subject: Re: [picocontainer-user] Container hierarchy
Date: Friday, March 20, 2009, 12:07 PM
On Fri, Mar 20, 2009 at 10:47 AM, Konstantin Priblouda
Post by Konstantin Priblouda
Nothing prevent your canadian and american persons to
sit in
Post by Konstantin Priblouda
the same container ( except mutual latent aversion
as shown
Post by Konstantin Priblouda
in various films ;) ) and have distinct set of
dependencies.
Certainly, the question is how to get the one you need.
What
information is needed and known at the point where a Person
should be instantiated (we all know instantiation of
Persons
quite often involves alcohol, so obviously, only the
tiniest
amount of information can be trusted to be present and
accurate...)
Well, if there is more than one of certain class, then your only option
is to retrieve by unique id.
Hm. I assume this would require a hierarchy of classes?
AmericanPerson and CanadianPerson derives from Person?
I don't really want that. I'd rather have a single
Person-class
with various dependencies, i.e. one for the validation of
the
personal ID. There will be others, and adding a subclass
for
each combination will be rather messy.
Well,it's a design choice. For my taste,there is nothing wrong
to have CanadianPerson derived from Person and taking
CanadianSSNValidator as constructor parameter
( while canadian ssn validator is derived from ssn validator )

If you perefer generic approach, you can register explicit dependencies
If we take the Person-example further, I'd have a
Person-class
that takes an IDValidator as a constructor parameter. The
default implementation just says everything is ok. I then
add
an IDValidator_US and an IDValidator_Canada. How do I now
query for a Canadian or a Mexican (who would get the
default
implementation)?
Apparently canadians would depend on canadian validators,
and mexican on mexican ones - but real stuff may as well live in
base class and use generic interface.
I understand this could be seen as abusing the container,
and
that's fine. As I said, I'm just exploring
possibilities. :*)
PicoContainer got used to be abused ;)





----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-20 10:26:07 UTC
Permalink
On Fri, Mar 20, 2009 at 11:20 AM, Konstantin Priblouda
Post by Konstantin Priblouda
Well,it's a design choice.
Yes, it is. :*)
Post by Konstantin Priblouda
For my taste,there is nothing wrong
to have CanadianPerson derived from Person and taking
CanadianSSNValidator as constructor parameter
( while canadian ssn validator is derived from ssn validator )
If you perefer generic approach,  you can register explicit dependencies
Yes.
IOW. either I need to define a class for each of my combinations,
or at least a unique name. Then I can put them all in one container.

Or, if I still want to use a hierarchy of containers, I need to
explicitly register Person when I register a new subclass of
IDValidator in a child container.

Thanks. :*)
Post by Konstantin Priblouda
PicoContainer got used to be abused ;)
Hehe. That's how good components and frameworks get built. :*)

M.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Michael Rimov
2009-03-20 10:37:37 UTC
Permalink
Post by Martin Larsson
Post by Konstantin Priblouda
For my taste,there is nothing wrong
to have CanadianPerson derived from Person and taking
CanadianSSNValidator as constructor parameter
( while canadian ssn validator is derived from ssn validator )
If you perefer generic approach,  you can register explicit dependencies
Yes.
IOW. either I need to define a class for each of my combinations,
or at least a unique name. Then I can put them all in one container.
Yes, and using that kind of key strategy, you can use ComponentParameters to get
what you want.

pico.addComponent(USIDValidator.class);
pico.addComponent("USPerson", USPerson.class, new
ComponentParameter(USIDValidator.class));
Post by Martin Larsson
Or, if I still want to use a hierarchy of containers, I need to
explicitly register Person when I register a new subclass of
IDValidator in a child container.
Correct. Or do a ThreadLocal person wrapper like I mentioned in my previous
post.

-Mike




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Konstantin Priblouda
2009-03-20 10:44:44 UTC
Permalink
Post by Martin Larsson
Yes.
IOW. either I need to define a class for each of my
combinations,
or at least a unique name. Then I can put them all in one
container.
It looks tome, that you already defined various validator classes,
so it's only a tiny step to derive subclass from your person
and override constructor with more specifific parameters
( does it make sense to you, to use mexicans with american ssn
validator, beside fooling INS? ;) - if not, dedicated subclass
would reliably perevent mistakes )
this option will allow you to use generic configuration.
otherwise you have to be explicit.

regards,


----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-20 11:33:56 UTC
Permalink
On Fri, Mar 20, 2009 at 11:44 AM, Konstantin Priblouda
Post by Konstantin Priblouda
It looks tome, that you already defined various validator classes,
so it's only a tiny step  to derive subclass from your person
Sure. But this is just an example, one that looks like the real problem,
while being easy to understand. The real application will have much
more of this. More classes, more plug-ins, many, many combinations.

I would like to be able to configure the composition of a Person, rather
than depending on unique classes. That way I can add Mexicans by
updating a configuration file. The ID-validation will be the default (iow,
not do any validation), but the application will know the difference, so
when we actually upgrade the application, Mexicans will be handled
correctly. (At this point, I feel I'm stretching the example, btw).

M.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Konstantin Priblouda
2009-03-20 11:41:27 UTC
Permalink
Post by Martin Larsson
I would like to be able to configure the composition of a
Person, rather
than depending on unique classes. That way I can add
Mexicans by
updating a configuration file. The ID-validation will be
the default (iow,
not do any validation), but the application will know the
difference, so
when we actually upgrade the application, Mexicans will be
handled
correctly. (At this point, I feel I'm stretching the
example, btw).
The point is, that application just does not care how
( and whether ) mexicans are validating their id.
I think you can achieve desired behaviour by configuration
as Mike said.

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Michael Rimov
2009-03-20 13:08:48 UTC
Permalink
Post by Konstantin Priblouda
Post by Martin Larsson
I would like to be able to configure the composition of a
Person, rather
than depending on unique classes. That way I can add
Mexicans by
updating a configuration file. The ID-validation will be
the default (iow,
not do any validation), but the application will know the
difference, so
when we actually upgrade the application, Mexicans will be
handled
correctly. (At this point, I feel I'm stretching the
example, btw).
The point is, that application just does not care how
( and whether ) mexicans are validating their id.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Konstantin, are you trying to make a political statement here?? :)

-Mike



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Konstantin Priblouda
2009-03-20 13:14:45 UTC
Permalink
Subject: RE: [picocontainer-user] Container hierarchy
Date: Friday, March 20, 2009, 3:08 PM
Post by Konstantin Priblouda
Post by Martin Larsson
I would like to be able to configure the
composition of a
Post by Konstantin Priblouda
Post by Martin Larsson
Person, rather
than depending on unique classes. That way I can
add
Post by Konstantin Priblouda
Post by Martin Larsson
Mexicans by
updating a configuration file. The ID-validation
will be
Post by Konstantin Priblouda
Post by Martin Larsson
the default (iow,
not do any validation), but the application will
know the
Post by Konstantin Priblouda
Post by Martin Larsson
difference, so
when we actually upgrade the application,
Mexicans will be
Post by Konstantin Priblouda
Post by Martin Larsson
handled
correctly. (At this point, I feel I'm
stretching the
Post by Konstantin Priblouda
Post by Martin Larsson
example, btw).
The point is, that application just does not care
how
Post by Konstantin Priblouda
( and whether ) mexicans are validating their id.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Konstantin, are you trying to make a political statement
here?? :)
-Mike
I try to demonstrate concept of seperation of concerns ;)
( I found that "not their freaking busines" or "geht am *** vorbei"
would be toorude ;) )

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Michael Rimov
2009-03-20 10:35:17 UTC
Permalink
Post by Martin Larsson
Post by Konstantin Priblouda
Nothing prevent your canadian and american persons to sit in
the same container  ( except mutual latent aversion as shown
in various films ;) )  and have distinct set of dependencies.
Certainly, the question is how to get the one you need. What
information is needed and known at the point where a Person
should be instantiated (we all know instantiation of Persons
quite often involves alcohol, so obviously, only the tiniest
amount of information can be trusted to be present and
accurate...)
Post by Konstantin Priblouda
The you may query for
 - canadian person[s]
 - american person[s]
or even any persons.
Hm. I assume this would require a hierarchy of classes?
AmericanPerson and CanadianPerson derives from Person?
I don't really want that. I'd rather have a single Person-class
with various dependencies, i.e. one for the validation of the
personal ID. There will be others, and adding a subclass for
each combination will be rather messy.
If we take the Person-example further, I'd have a Person-class
that takes an IDValidator as a constructor parameter. The
default implementation just says everything is ok. I then add
an IDValidator_US and an IDValidator_Canada. How do I now
query for a Canadian or a Mexican (who would get the default
implementation)?
I understand this could be seen as abusing the container, and
that's fine. As I said, I'm just exploring possibilities. :*)
It sounds like perhaps the façade for this system needs to contain a Country ->
PicoContainer map, with the Pico structure of:


Default Behavior
|- US
|- Canada
|- U.K.
.... etc


Then:

public Person constructPerson(String iso2CountryCode) {
PicoContainer correctPico = picoMap.get(iso2CountryCode);
return correctPico.getComponent(Person.class);
}

The biggest problem is that if you have additional services that rely on Person
in their constructors, you will also have to pull them down to the child
containers. The workaround there is to store a threadlocal wrapper object in
the parent container that allows you to
grab the "current person" in the thread and operate on it properly.

HTH,

-Mike






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-20 12:44:29 UTC
Permalink
threadlocal wrapper object in the parent container that allows you to
grab the "current person" in the thread and operate on it properly.
Sounds like fun. :*)
Is there any code somewhere showing this?

M.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Michael Rimov
2009-03-20 13:07:45 UTC
Permalink
Post by Martin Larsson
threadlocal wrapper object in the parent container that allows you to
grab the "current person" in the thread and operate on it properly.
Sounds like fun. :*)
Is there any code somewhere showing this?
Yes actually,



Take a look at PicoContainer-Web. It has the same problem,



Application Container -> Session Container -> Request Container



But I get a glaze looking over the code for the first time, so here's a simpler
example.

class PersonWrapper {

private ThreadLocal<Person> currentPerson;



//Getters and setters

}



public class ServiceDependingOnPeople {



private final PersonWrapper personWrapper;



public ServiceDependingOnPeople(PersonWrapper person) {

this.personWrapper = person;

}



public doSomething() {

Person currentPerson = personWrapper.getCurrentPerson();

//Perform operations

}

}



Pico Registration:

MutablePicoContainer pico = new
PicoBuilder().withCaching().withLifecycle().build();

pico.addComponent(PersonWrapper.class)

.addComponent(ServiceDependingOnPeople.class)



MutablePicoContainer child = pico.makeChildContainer();

child.addComponent(USPerson.class);



Before you perform your thread's operations:



//Or however you get the Particular Person

child.getComponent(PersonWrapper.class)

.setCurrentPerson(child.getComponent(USPerson.class));



This prevents ServiceDependingOnPeople from being pulled down to the child
container.



There's also org.picocontainer.behaviors.Storing, and
org.picocontainer.injectors.ProviderAdapter to help you, but I'll leave it to
Paul and others more knowledgable about their inner workings to answer questions
about them :)



HTH!

-Mike



P.S. Welcome to Pico-Land! :)
Konstantin Priblouda
2009-03-20 13:10:22 UTC
Permalink
Subject: Re: [picocontainer-user] Container hierarchy
Date: Friday, March 20, 2009, 2:44 PM
On Fri, Mar 20, 2009 at 11:35 AM, Michael Rimov
threadlocal wrapper object in the parent container
that allows you to
grab the "current person" in the thread and
operate on it properly.
Sounds like fun. :*)
Is there any code somewhere showing this?
There is a plenty of unit tests covering various funny component
adapters.


----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Martin Larsson
2009-03-19 00:49:42 UTC
Permalink
On Wed, Mar 18, 2009 at 11:50 AM, Martin Larsson
"Better" code attached this time, sorry ...

M.
Loading...