avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@codehaus.org
Subject [jira] Assigned: (PNIX-34) Auto-Assembly of Applications
Date Wed, 06 Aug 2003 04:52:44 GMT
Message:

   The following issue has been re-assigned.

   Assignee:  (mailto:)
---------------------------------------------------------------------
View the issue:

  http://jira.codehaus.org/secure/ViewIssue.jspa?key=PNIX-34


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: PNIX-34
    Summary: Auto-Assembly of Applications
       Type: Bug

     Status: Unassigned
   Priority: Critical

 Time Spent: Unknown
  Remaining: 0 minutes

    Project: phoenix
 Components: 
             Deployment Archive Format
   Versions:
             4.1

   Assignee: 
   Reporter: Peter Donald

    Created: Sat, 12 Apr 2003 12:05 AM
    Updated: Tue, 5 Aug 2003 11:51 PM

Description:
Assembly of an application can be simplified by allowing the user to only specify the minimum
amount of information required to assemble a component. Currently Phoenix requires all components
to explicitly declare all the other components that they depend upon. 

However in many cases it is possible to automatically deduce the dependencys for a component.
Each component is described by a BlockInfo object. The BlockInfo object defines a set of services
it depends upon. 

So for each service the following process could be followed;
* If user specifies it in assembly.xml then use that
* If user leaves it unsepcified, search all the Blocks in an application and find out which
of those blocks implement service.
  - If no blocks implement service then generate an error
  - If one block implements service then use that
  - If multiple blocks implement service then Select one based on heuristics

The way to implement this is as follows;

1. Define a set of classes similar to those in metadata package. With the exception that they
are read-write and capable of being changed at runtime. You will end up with BlockCandidate,
DependencyCandidate, etc 
2. Extend the assembly.xml file format to take a version attribute at top of file (ie <assembly
version="1.1">)
3. Read assembly.xml into Candidate objects.
4. Create a pluggable interface via which selection of service can be done (when multiple
blocks implement required service). Something like

interface ServiceSelector
{
  float rateService( ComponentCandidate consumer,  
                     ComponentCandidate provider, 
                     ServiceDescriptor service )
   throws Exception;
}

5. Scan through blocks to find the candidate services, rank them using the selector and choose
the hihest ranked service.
6. When all dependencies are resolved turn the candidate objects into MetaData objects and
procede with application startup


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message