Differentiators

Pico components (to remind you) are beans with one constructor and simple rules for parameters. No meta XML for dependencies.



Sun specified nearly-IoC Containers & Component designs

It could be said that Sun have created a few container/component designs.......



Enterprise Java Beans

Clearly Entity and Session beans run inside a container.  The API is well defined, and to varying degrees of success one can deploy EJB appllications to WebLogic, WebSphere, Orion and JBoss etc.  High use of element-normal XML for assembly and configuration. There are some mandated parent objects and interfaces for various to extend and/or implement. Resolution is done by the components themselves via JNDI more often than not.



Servlets

Not so obvious - Servlets are contained by a servlet container. They are generally bundled with (or replaced by) value added propositions like JSP, but it is still a container/component design.   High use of XML for assembly and configuration.  Servlets have no concept of parent container or the conatainer above that (sometimes EJB) and  its provision of components, which is very unfortunate. Servlets have a number of interfaces to honor, none of which is too malignent. Servlets typically deal with external (or parent) components via RMI or JNDI.  In more recent releases of EJB, local interfaces rather than RMI may be the mechanism for connection the parent components.  WebLogic have always provided a optimizing mechanism for this interoperation.



Applets

Applets, though not so often used by people presently, are a good example of Container/Component separations.  There is very little XML in use by Appletss.  Configuration is typlically delivered in applet tags in HTML. Applets are granted some access to the parent container, the brower, and  its DOM model for pages and other applets.  There little standardisation for Browser as a container.



Mainable (Sun)

"public static void main(String[] args) {}"  Familiar? Hopefully not :-) No component that is statically launched is a IoC component. This includes static launching of Java Webstart (JNLP) applications.



Singleton (pattern)

The singleton pattern was detailed in the "Design Patterns" book.  It seems like a good idea, is typlically statically and publicly accessed in Java.  Overuse makes for bad solutions.  In the IoC world we would replace this with a container managed single instance.



Static Factory (pattern)

Used in a similar way the Singleton pattern (and similarly detailed in "Design Patterns"), this allows disparate classes to create/get other components.  Very dirty applications result from overuse of static factories



JNDI

A huge map of clunkily access components via a very non-IoC mechanism. It has to be strapped with much XML to prevent inappropriate access.  This is not IoC because the component reaches out for external component dependancies whenever it feels like.  This last fact coulds Serlvets and EJB in use.



AWT, Swing, SWT (gfx toolkits)

Nice container/component designs. In the case of Swing, perhaps a little dificult for coders to easily assemble applications.



Eclipse (platform)

The Eclipse platform is very compelling.  It supports the notion of a pluggable application concept. Each component statically accesses other components via a factory (which at least Paul does not like), though it is clear that some complex classloader magic is going on.



Avalon-Framework and associated containers

Apache hosts a project that has been running for years called Avalon. It has many components that fit that its design and many containers.  Avalon components are characterised by implementation of many optional interfaces. Avalon components are distributed with meta-information in XML in the jar file.



Avalon Interface

PicoContainer equivalent

LogEnabled No logging design

Contextualizable n/a
Serviceable (used to be called Composable) Args in Constructor

Configurable Args in Constructor

Parameterizable n/a
Initializable Constructor is eqivalent lifecycle place.

Startable Startable

Suspendable n/a
Recontextualizable n/a
Recomposable n/a
Reconfigurable n/a
Reparameterizable n/a

Stoppable Stoppable
Disposable Disposable

Carbon

todo