This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 197519 - Binding service - separating framework vs. extension code
Summary: Binding service - separating framework vs. extension code
Status: RESOLVED WONTFIX
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Cosmos (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Don Ebright CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 196050
  Show dependency tree
 
Reported: 2007-07-23 14:10 EDT by Hubert Leung CLA
Modified: 2012-01-03 13:53 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hubert Leung CLA 2007-07-23 14:10:35 EDT
The current design of the framework requires developers who provide a assembly component implementation to write a "binding service", which reads in the "factory" value from the assembly XML, and instantiate the component object, register the object, and doing other things.  The assembly XML is an input to the framework.  We should not require developers to read in values from the XML to process in the extension code. It's the job of the framework.  If we need to provide the flexibility for instantiating the component object, we can provide a public API for the component implementation to control how the class is instantiated through a factory class.  In fact, the assembly XML is already set up to do this.  For example: 

<sink cosmos:factory="org.eclipse.cosmos.dc.sample.components.sink.StatisticalPersistor">

The cosmos:factory attribute defines the factory class that returns an instance of the component implementation.  We need to require all factory classes to implement a "getInstance" method that returns a reference to the component object.  The getInstance method will be invoked by the framework and not extension code.  The factory can return a singleton class or a new instance of the component and it allows the use of custom classloaders.  With this approach, you can replace the object instantiation code in the binding service with a call to this factory class, and push the rest of the code to the framework layer (i.e. InboundContext and OutboundContext).
Comment 1 David Whiteman CLA 2008-08-13 10:51:43 EDT
reopen later if necessary