portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barnhill William" <barnhill_will...@bah.com>
Subject Re: FYI: work in progress
Date Mon, 26 Jan 2004 15:07:27 GMT

I took a look at JicarillaFramework. In his words it's...
The Jicarilla-Framework builds upon Type-3 IoC, adding an Active 
interface to better support multi-threaded components. Besides some 
pretty generic utility code (like a set of base classes for nested 
exceptions), it adds basic abstractions for the building blocks of 
lightweight event-based systems, like sources, sinks, stages, 
multicasters, etc.

The goal of commons-services is to provide an Apache-licensed product 
for accessing any type of service framework with the same API and 
provide a lightweight service mechanism.  A sub-goal is to make use of 
Apache products BSF and commons-configuration to add flexibility.

JicarillaFramework seems designed to support primarily Type-3 IoC, and 
primarily for embedding into a web server, which makes sense as the 
parent project Jicarilla is a web server.

The tree of service frameworks commons-services would eventually support 
the containers in the outline below that I found on picccontainer's web 
site (The initial emphasis will be on Apache hosted frameworks such as 
Cornerstone, Avalon, Fulcrum).  I am not sure where exactly 
Cornerstone,Hivemind,Fulcrum, and JicarillaFramework go in this 
outline.  It probably would be good to capture this outline with that 
information added.

1.Inversion of Control
1.1 Dependency Injection (former type 3)
    1.1.1 Constructor Dependency Injection
          Examples :
          Spring Framework <http://www.springframework.org/>
    1.1.2 Setter Dependency Injection (former type 2)
          Examples :
          Spring Framework <http://www.springframework.org/>
     1.1.3 Interface Driven Setter Dependency Injection
              Examples :
              XWork <http://wiki.opensymphony.com/space/XWork>
              WebWork 2 <http://wiki.opensymphony.com/space/WebWork2>
     1.1.4 Field Dependency Injection
          Examples :
          Plexus <http://plexus.codehaus.org/>(to be confirmed)
  1.2 Contextualized Dependency Lookup
    1.2.1 Pull approach (registry concept)
          Examples :
          EJB that leverages JNDI
          Servlets that leveraging JNDI
    1.2.2 Push approach (former type 1)
          Examples :
          Servlets that leverage ServletContext
          Avalon <http://avalon.apache.org>
          JContainer's DNA <http://dna.jcontainer.org/>
          OSGi (to be confirmed)
          Keel <http://keelframework.org/>(uses Avalon)

Another point I would like to stress is that this is not a service 
framework in itself. At it's highest level it basically provides a 
common means for configuration, and event dispatcher which knows only 
about the event identifier (a URI) and an event data map, and a service 
dispatcher that knows what services/resources a ServiceFactorySource 
provides through its ServiceFactory instances.  Rather than create 
another framework, I am trying to provide a mechanism to use any 
framework, preferably with not or little change in the passed in 
configuration. So instead of having the debate of 'let's use xxx for 
jetspeed2', we will hopefully have statements like 'these are my 
experiences using xxx/yyy/zzz as the service framework  implementation 
with jetspeed2'.

Bill Barnhill

Weaver, Scott wrote:

>Look at http://jicarilla.sourceforge.net/. I think the David Le Strat had
>already made mention of this project, but will bring it to light this
>thread.  This project currently allows you to deploy components developed
>for other IoC containers into it.
>| Scott T Weaver                 |
>| <weaver@apache.org>            | 
>| Apache Jetspeed Portal Project |
>| Apache Pluto Portlet Container |
>>-----Original Message-----
>>From: Barnhill William [mailto:barnhill_william@bah.com]
>>Sent: Monday, January 26, 2004 7:32 AM
>>To: Jetspeed Developers List
>>Subject: Re: FYI: work in progress
>>Thank you.  This initial effort is basically a rough cut and I will want
>>any help I can get in improving the initial codebase.  I've been doing
>>some reading on Open Source and I think that I will post code once the
>>commons-service package is done and a commons-services-demo package  is
>>done.  The demo package will implement a very simple use of
>>commons-services to access beans in jar files as  services. I've changed
>>my mind because it seems more in the spirit of Open Source to get the
>>service framework developers in from the get-go on implementing the code
>>to use all the features of their framework through the common API.
>>On another note, I imagine that the scheme part of URI schemes I
>>suggested below should be prefixed with vnd.apache. , in conform with
>>IETF suggestions.
>>Thanks again,
>>Jun Yang wrote:
>>>Hi Bill,
>>>I am very excited at hearing this effort!  This is definitely not an
>>>easy task.  Thanks for doing it!  Please let me know if I can be of
>>>any help.
>>>Barnhill William wrote:
>>>>Hello all,
>>>>Just so everyone knows, I am currently working on a commons-services
>>>>package,  to attempt to do for service frameworks what
>>>>commons-logging has does for logging frameworks. It is progressing,
>>>>but not yet ready to publish. I plan to post code and docs on my web
>>>>site when it's ready.  I'll provide the URL at that time.  My aim is
>>>>for this to be accepted into the Jakarta commons sandbox, if I can
>>>>develop sufficient interest in the package.
>>>>The purpose of the package is to provide a common services API
>>>>suitable for use in an enterprise environment.  This package would
>>>>perform the same role for various service frameworks that te Jakarta
>>>>commons-logging package does for logging frameworks.
>>>>The requirements I am currently working from follow, and comments are
>>>>both welcome and appreciated:
>>>>1. MUST eat it's own dogfood when possible :), i.e. MUST user Jakarta
>>>>packages where applicable such as commons-logging and
>>>>2. MUST NOT access property files, but instead use commons-
>>>>3. MUST have a helper class that has a method to read a property file
>>>>into a commons-configuration HierarchicalConfiguration
>>>>4. MUST have a helper class that has a method to write a
>>>>commons-configuration HierarchicalConfiguration into a property file
>>>>5. MUST NOT access XML files, but instead use a
>>>>HierarchicalConfigurationXmlReader to access the XML stored within a
>>>>6. MUST not express any knowedge of a particular service framework in
>>>>the core package.
>>>>7. Services MUST be requested via a lookup mechanism based on
>>>>resource URIs. The following are the only requirements for the
>>>>resource URI: (1) It is Hierarchial, (2) It is not Opaque.  The
>>>>specific scheme and path meanings are purposely not specified and
>>>>would be decided outside this framework, but the following URI
>>>>formats are offered for possible use:
>>>>  ifc.java:///fully/qualified/pkg/ifcname -- To lookup a service by
>>>>the interface it provides
>>>>  ifc.java:///fully/qualified/pkg/  -- to look up a list of services
>>>>that provide interfaces in this package
>>>>ifc.java:///fully/qualified/pkg/...  -- to look up a list of services
>>>>that provide interfaces in this package and all subpackages
>>>>role:///role/hiearchary/rolename -- To lookup a service by the role
>>>>that it fulfills
>>>>  role:///role/hiearchary/  -- To lookup a list of services that
>>>>fulfill any role at that specified heirarchy level
>>>>  role:///role/hiearchary/... -- To lookup a list of services that
>>>>fulfill any role at that specified heirarchy level and any sublevels
>>>>8. The interfaces and conceptual purpose of its methods MUST coincide
>>>>with the following statements:
>>>>a. ServiceToolkit -- Manages ServiceFactorySource instances and their
>>>>associated metadata
>>>>b. ServiceFactorySource -- Maps resource Ids to ServiceFactories,
>>>>providing the ServiceFactories and their associated metadata
>>>>c. ServiceFactory -- Provides the ability to request/release service
>>>>instances, based on the passed resource identifier or service id
>>>>d. ServiceEventListener -- Event listener for service events, this
>>>>expected to be exposed as a service by event capable components.
>>>>e. ServiceEvent -- Encapsulate an event passed to services, includes
>>>>an event identifier URI and a map containing event data.
>>>>9. An example implementation of an adapter package MUST be provided
>>>>that uses these interfaces to provide access to a known service
>>>>framework. The initial implementation will be for Avalon's Merlin
>>>>framework.  Two other implementations are planned: Cornerstone, WSIF
>>>>Basically this is just to let everyone know my current intent, and
>>>>that my notes on Cornerstone are on hold until after the package is
>>>>The interfaces and configuration section are almost done, and I have
>>>>started the Avalon adapter package.
>>>>As soon as the Avalon adapter package is working I will post URLs to
>>>>sources and binaries for the following packages:
>>>>(1) org.apache.commons.services.api.*
>>>>(2) org.apache.commons.services.util.*
>>>>(3) org.apache.commons.services.avalon.*
>>>>(4) org.apache.commons.services.demo.*
>>>>Obviously, if I cannot get enough support for including this into the
>>>>commons then I'll need to change the org.apache.commons portion of
>>>>the package names.
>>>>Bill Barnhill
>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

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

View raw message