User DocumentationOne minute descriptionTwo minute tutorial Five minute introduction Advanced Topics FAQ Container Components Terminology Mock Objects Inversion of Control Types PatternsInversion of ControlDependency Injection Constructor Injection Setter Injection Interface-Impl Separation Lifecycle Antipatterns Developer DocumentationHow To ContributeRelative Volunteering Release Process Project InformationSloganMailing lists Source Repositories Open Issues Blog entries Statistics Team Sister Projects TShirts MiscellaneousDifferentiatorsNirvana Full Sitemap |
NirvanaAuthors: Paul Hammant OverviewIn an ideal world we see PicoContainer principles being applied to a lot of different container/component aspects of Java: ServletCurrently the servlet spec advises that a servlet should..
It would be quite cool, if the servlet container could determine the needs of a servlet as a component before instantiation. The servlet was allowed to get dependant component instances via one of its constructors. The need for servlet developers to break (2) above would be diminished because there is some place hier up the container tree for fatter components, that can provide services to request oriented servlets. The class visibity advice (for servlet container writers), would be relaxed too, allowing classes not supplied in the WAR file to be compiled against and delivered by the containing environment. public class PicoServletExample extends HttpServlet { private StockQuoteService stockQuoteService; public PicoServletExample(StockQuoteService sqs) { stockQuoteService = sqs } public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<html><body>"); out.println("Microsoft's Current Price =" + stockQuoteService.getQuote("MSFT")); out.println("</body></html>"); } } This may seem far fetched, but it is entirely possible given the number of Open Source Servlet containers. AppletAs for the servlet example, it would be nice for Applet to require that their container resolves component dependencies. This rather than have to do a fairly open ended JNDI or RMI lookup of a remote service. The implemetation is a component that may have several manifestations. A RMI Remote real example is where you might be headed as you write the application In the interim, the team may code and deliver various quick win solutions - a) Hard coded fake StockQuoteService, b) some real implementation that steals data from http://quotes.nasdaq.com for display in the applet, c) some centralized/proxied version of (b), d) a MockStockQuteService for Unit testing (not withstanding the fact that AppletUnit has not been written yet).public class PicoAppletExample extends Applet { private StockQuoteService stockQuoteService; public PicoAppletExample(StockQuteService sqs) { stockQuoteServic = sqs; } public void init() { // lay out trading GUI etc. } public void start() { //whatever } public void stop() { // whatever } public String getAppletInfo() { return "Hello"; } } Sadly, this remains far fetched, due to a dearth of Open Source Applet containers. Enterprise BeanSame story :public interface StockQuoteService { void BigDecimal getQuote(String stockTicker); } public class DefaultStockQuoteService implements StockQuoteService { QuoteRecorder quoteRecorder; public DefaultStockQuoteService(QuoteRecorderquoteRecorder) { this.quoteRecorder =quoteRecorder; } public void BigDecimal getQuote(String stockTicker) { quoteRecorder.recordQuote(stockTicker); return new BigDecimal()// TODO - makereal } } Desktop Operating SystemGetting boring now :public class QuotePanel extends JPanel implements { StockQuoteService stockQuoteService; public QuotePanel(StockQuoteService sqs) { this.stockQuoteService = sqs; this.add(new JTextField(""),BorderLayout.CENTER); //etc } } Yo you Eclipse guys, why'd ya have to adopt the OSGi stuff ? |