RE: [picocontainer-dev] Providers

> My Guice buddies are divided on whether their providers feature is
> mainstream or niche.  It allows you to have a factory that can help
> make deps on a just in time basis (for the particular scope) for other
> components to use.
> 
> The interface goes like so :
> 
>     interface Provider<T> {\
>           T get();
>     }
> 
> For Pico, as of a commit yesterday, we have a provider too.  It's a
> little different. It's less generic than the Guice one :
> 
>    interface Provider {
>    }
> 
> It's a convention idiom. Have one method provide that returns the type
> you're interested in providing, but have as many concrete arguments
> for that method as you require. As long as those deps can be satisfied
> by the PicoContainer instance that is managing it, then it'll be fine.
> 
> Have a look at Chocolatier and Chocolatier2 in
> http://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/src/tes
> t/org/picocontainer/injectors/ProviderTestCase.java
> (yes there are two ways of working with Providers).

At first when I read your design of Chocolatier in the test case, I thought...
"Why do this when we have Behaviors in the first place???"....  Then when I hit
Chocolatier2, I finally realized where you were going with it and thought ...
"Way cool" :)

Thoughts:
--How do you consider using a marker interface vs an annotation.  ie:

@Provider
public class MyProvider {

}

vs

public class MyProvider implements Provider {

}

?

--I think the thing I like most about it is that it allows people to create
Factory objects without deep knowledge of the inner workings of PicoContainer
like Custom ComponentAdapters require.  

--I don't think its fringe... I think it is far more accessible to developers
for providing custom ways of getting at your components.  For example:

public class JNDILookupProvider<T> implements Provider {

	public JNDILookupProvider(String contextPath) {
		/* ex contextPath = ' java:comp/env/jdbc/default' */
	};

	public <T> provide(IntialContext ctx) { 
		/*Perform lookup on initialContext using contextPath*/ 
		return T; 
	}
}

Nice and simple (if you can ever call JNDI lookups 'simple'! :) )... and the
build of the container is logical:

import javax.mail.Session;

container.as(NO_CACHE).addComponent(InitialContext.class)
	.addAdapter(Session.class, new ProviderAdapter(new
JNDILookupProvider<Session>("java:comp/env/mail/default"));


Although from a usability standpoint, it would be nicer to have

container.as(NO_CACHE).addComponent(InitialContext.class)
	.addComponent(Session.class, new
JNDILookupProvider<Session>("java:comp/env/mail/default"));

and like instance registrations, have provider registrations wrapped in the
appropriate adapter.

Or possibly even delayed instantiation of the provider:

container.as(NO_CACHE).addComponent(InitialContext.class)
	.addComponent(Session.class, new JNDILookupProvider.class, new
ConstantParameter("java:comp/env/mail/default"));



Opposing thoughts: (Or as Tevya would say:  "On the other hand...")

--But just as ComponentAdapters have gotten more complicated over the years to
handle specific use cases, is Provider too simple? For example, does it need
lifecycle events?  I'd personally hate to destroy the simplicity to handle those
additional use cases.

--Is there too much overlap between Providers and ComponentAdapters in the first
place?  After all, in the past, if I needed a custom provider, I just made a new
ComponentAdapter.  (Or even a custom ComponentParameter!).  In fact, code base
has JNDIComponentParameter, and I have in my own code a JNDIParameter:

container.addComponent(EmailService.class, 
				EmailService.class, 
				new
JNDIParameter("java:comp/env/mail/default"));

So do we need yet another way to instantiate a component?

Just thoughts :)  

	
-Mike



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

    http://xircles.codehaus.org/manage_email