David Le Strat wrote:
Thanks Jun.
This sounds like quite a great and promising use of
Cornerstone. JMX support for all components will be
quite nice.
I have a few questions.
Use case:
Let's say we have a persistence service (e.g with
several methods add, delete, query, etc.).
Another service, for instance registry, needs to use
the persistence service for building the portal
registry.
1. From a configuration stand point, will we be able
to package persistence and registry as 2 self
contained jar file where each jar contains the
configuration required for each service?
Yes. Each service will have its own config file packaged with it, just
like what you have outlined in your proposal.
2. Will we be able to centralize the configuration for
each service? Will we still need to define the
registry or will it be built from the service
configuration in order to resolve dependencies?
The config file packaged with a component is its out-of-box
configuration. If central configration is not available, the component
will be configured just as specified by this config file. If central
configuration is available, then central configuration is used as an
override for out-of-box configuration. In another word, central
configuration is optional. Central configuration enables the support
for preservation of customization and "configuration planes".
3. How will it support unit testing? Will we be able
to only load the service dependencies required for
unit test? For instance, to test registry, only the
persistence service is needed?
Yes.
As an aside, it may be interesting to look/use Leo
Simons components TCK, so that we can make sure that
our components are portable to other containers
http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/platform/container/tck/
and http://www.jroller.com/page/lsd/20040114
This is very interesting.
What are you thoughts?
Regards.
David.
Jun
--- Jun Yang <[EMAIL PROTECTED]> wrote:
We thank David Le Strat for doing a great job on the
service framework
proposal.
Here is what we'd like to suggest to add to the
proposal:
1. Cornerstone JMX
picoextras/jmx supports registering pico components
as JMX components in
a special JMX-aware pico container directly with an
MBean Server.
Cornerstone JMX is designed for a different purpose:
JMX-enable any
object with no JMX knowledge. When a component is
configured to be
JMX-enabled, all its states are managed by a
standard JMX adapter (The
name "adapter" maybe misleading to someone
unfamiliar with JMX. It's
basically a tool that allows you to manage JMX
components). A developer
doesn't need to know anything about JMX to make
his/her components
manageable by JMX. We generate MBeans dynamically.
We can make Cornerstone JMX a self-contained package
to be used in
Jetspeed so that all services are JMX-enabled with
ease without a
special pico container.
2. Cornerstone Customization
The forte of the Cornerstone Framework is its
ability to support
customizations in many dimensions (component,
relationship, flow and
preservation over upgrades). Right now it supports
type 2 IoC. But we
can change it slightly to support both type 2 and
type 3 (same as pico)
while maintaining the same configuration format. We
can make the
implementation manager part of Cornerstone a
self-contained package as
an approach to wiring pico components based on
configuration to give
pico components the following capabilities:
- Configuration-based (properties files or database)
wiring.
- Finer-grain configuration than that
picoextras/script's XML solution
allows (per component configuration file vs. one
file per container),
which is important in supporting the next 2 points.
- Multiple "planes" of configuration with user
defined order of override.
- Preservation of customization over upgrades.
For service orchestration, we are in the process of
settling on the
optimal among several solutions.
Thanks!
Jun and Emad
David Le Strat wrote:
All,
We had quite a few threads on the service framework
topic, IRC sessions regarding Cornerstone. In
order
for J2 to shine, the Jetspeed developers community
needs to come to a consensus and a decision around
a
service framework for Jetspeed.
I have prepared a document (zip file enclosed) that
tries to articulate what J2 needs from a service
framework and proposes a direction. That should
help
provide a basis for a discussion that hopefully
will
lead to a decision / vote on the best alternative
for
the future of Jetspeed.
Regards,
David Le Strat.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
