You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by piero <pi...@cazzati.it> on 2004/01/24 15:05:09 UTC
Help CPS usage!
Hi community,
Are there somebody that can explain me about the Common Portlet Services
usage ?
Where can I found some documents about this issue ?
I want to realize a mini component portlet service for Jetspeed-2.
I saw rewriter test sample, but I don't understood the purpose.
I read about the aggregation services pattern design, but I have the
confused ideas.
Thanks,
Piero.
Re: FYI: work in progress
Posted by Barnhill William <ba...@bah.com>.
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
Re: FYI: work in progress
Posted by Jun Yang <ju...@cisco.com>.
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
FYI: work in progress
Posted by Barnhill William <ba...@bah.com>.
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