portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: FYI: work in progress
Date Mon, 26 Jan 2004 16:37:55 GMT
Hi Bill,

I think we are pretty much going to use Pico as our component framework and
use Cornerstone with Pico components to:

- Apply transparent JMX on those components.
- Use the Cornerstone's configuration system.
- Use Cornerstone to orchestrate Pico components when needed.
- Eventually use Cornerstone to transparently publish Pico components as Web

  Services.

What are you ideas on fitting this into the common services api?


Regards,
*================================* 
| 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 10:07 AM
> To: Jetspeed Developers List
> Subject: Re: FYI: work in progress
> 
> Scott,
> 
> I took a look at JicarillaFramework. In his words it's...
> <quote>
> 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.
> </quote>
> 
> 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.
> 
> <quote>
> 1.Inversion of Control
> 1.1 Dependency Injection (former type 3)
>     1.1.1 Constructor Dependency Injection
>           Examples :
>           PicoContainer
>           Spring Framework <http://www.springframework.org/>
>     1.1.2 Setter Dependency Injection (former type 2)
>           Examples :
>           Spring Framework <http://www.springframework.org/>
>           PicoContainer
>      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)
> </quote>
> 
> 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:
> 
> >FYI,
> >
> >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.
> >
> >Regards,
> >*================================*
> >| 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
> >>
> >>Jun,
> >>
> >>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,
> >>
> >>Bill
> >>
> >>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.
> >>>
> >>>Jun
> >>>
> >>>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
> >>>>commons-configuration
> >>>>
> >>>>2. MUST NOT access property files, but instead use commons-
> >>>>
> >>>>
> >>configuration
> >>
> >>
> >>>>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
> >>>>HierarchicalConfiguration
> >>>>
> >>>>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
> >>>>done.
> >>>>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.
> >>>>
> >>>>Thanks,
> >>>>
> >>>>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

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


Mime
View raw message