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 David Le Strat <dl...@yahoo.com> on 2003/12/29 02:42:54 UTC
[J2] Service Framework Proposal
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.
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: [J2] Service Framework Proposal
Posted by David Le Strat <dl...@yahoo.com>.
Glenn,
Some more details:
- JMX: java management extensions.
Here is a good overview of JMX:
http://www.ebizq.net/topics/objects_components/features/1738.html
It basically allows you to manage your components once
deployed.
- Self contained, self configurable component: what i
mean by that a component and its functionality can be
encapsulated as a "jar" file and easily reused. Let's
take the persistence component (in J2 the persistence
plugin), assuming that you can just include the jar
file with its metadata when deploying that component,
it becomes straightforward to leverage it in the
portal framework and in portlets independently from
the portal framework. This is one possible scenario,
many others are possible. A little bit what EJBs are
trying to achieve but wihtout the overhead.
Regards,
David.
--- "Glenn R. Golden" <gg...@umich.edu> wrote:
> David -
>
> Can you elaborate on a few of these areas:
>
> What exactly is JMX and what does supporting it mean
> for us?
>
> What are self contained / self configurable
> components?
>
> Thanks.
>
> - Glenn
>
> On Jan 4, 2004, at 9:45 AM, David Le Strat wrote:
>
> > Glenn,
> >
> > This is the kind of debate we should be having.
> > Spring actually falls into the AOP/IoC realm
> though
> > Spring is actually much bigger than that as it
> > provides an MVC framework and so on.
> >
> > If we stick to IoC/AOP, whichever framework is
> being
> > used, I believe that IoC 2 or 3 are the best
> choices
> > as you don't need a ServiceManager or JNDI to
> fetch
> > the dependencies from.
> >
> > Spring also supports AOP and even has its own AOP
> > implementation.
> >
> > On the drawbacks side, using Spring you have to
> > provide quite a bit of component metadata (which I
> > don't think is really a big deal, but some people
> may
> > think so) and we would have to implement JMX
> support.
> >
> > Another drawback of Spring seems to be the
> component
> > configuration itself. It does not seem possible
> to
> > allow deploying self contained components / self
> > configurable components. Configuration seems to
> be
> > tight to the web application configuration
> (through
> > the applicationContext.xml). So you would not be
> able
> > to package your application services independently
> of
> > the application. Please correct me if I missed
> > something here.
> >
> > I have not implemented a service using Spring per
> say.
> > If we could work around the configuration issue
> and
> > JMX, Spring could actually be a good fit for
> Jetspeed.
> > Any comments from others?
> >
> > Just my 2 cents.
> >
> > David.
> >
> > --- "Glenn R. Golden" <gg...@umich.edu> wrote:
> >> David, and Jetspeed all -
> >>
> >> Thanks for the proposal. We are also evaluating
> >> component frameworks
> >> for our CHEF project, which has been based on
> >> Jetspeed 1 and the
> >> Jetspeed / Turbine service model, which seems a
> type
> >> 1 IoC like Avalon.
> >>
> >> I am currently very interested in Spring's
> component
> >> framework, which
> >> can handle type 2 or 3 IoC. You mention it in
> your
> >> analysis, but did
> >> not end up recommending using it. Any specific
> >> comments of the merits
> >> or problems of Spring, in general, and for
> Jetspeed?
> >>
> >> Thanks.
> >>
> >> - Glenn
> >>
> >>
> >>
> >
>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> jetspeed-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> jetspeed-dev-help@jakarta.apache.org
> >>
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Find out what made the Top Yahoo! Searches of 2003
> > http://search.yahoo.com/top2003
> >
> >
>
---------------------------------------------------------------------
> > 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
>
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by "Glenn R. Golden" <gg...@umich.edu>.
David -
Can you elaborate on a few of these areas:
What exactly is JMX and what does supporting it mean for us?
What are self contained / self configurable components?
Thanks.
- Glenn
On Jan 4, 2004, at 9:45 AM, David Le Strat wrote:
> Glenn,
>
> This is the kind of debate we should be having.
> Spring actually falls into the AOP/IoC realm though
> Spring is actually much bigger than that as it
> provides an MVC framework and so on.
>
> If we stick to IoC/AOP, whichever framework is being
> used, I believe that IoC 2 or 3 are the best choices
> as you don't need a ServiceManager or JNDI to fetch
> the dependencies from.
>
> Spring also supports AOP and even has its own AOP
> implementation.
>
> On the drawbacks side, using Spring you have to
> provide quite a bit of component metadata (which I
> don't think is really a big deal, but some people may
> think so) and we would have to implement JMX support.
>
> Another drawback of Spring seems to be the component
> configuration itself. It does not seem possible to
> allow deploying self contained components / self
> configurable components. Configuration seems to be
> tight to the web application configuration (through
> the applicationContext.xml). So you would not be able
> to package your application services independently of
> the application. Please correct me if I missed
> something here.
>
> I have not implemented a service using Spring per say.
> If we could work around the configuration issue and
> JMX, Spring could actually be a good fit for Jetspeed.
> Any comments from others?
>
> Just my 2 cents.
>
> David.
>
> --- "Glenn R. Golden" <gg...@umich.edu> wrote:
>> David, and Jetspeed all -
>>
>> Thanks for the proposal. We are also evaluating
>> component frameworks
>> for our CHEF project, which has been based on
>> Jetspeed 1 and the
>> Jetspeed / Turbine service model, which seems a type
>> 1 IoC like Avalon.
>>
>> I am currently very interested in Spring's component
>> framework, which
>> can handle type 2 or 3 IoC. You mention it in your
>> analysis, but did
>> not end up recommending using it. Any specific
>> comments of the merits
>> or problems of Spring, in general, and for Jetspeed?
>>
>> Thanks.
>>
>> - Glenn
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jetspeed-dev-help@jakarta.apache.org
>>
>
>
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
>
> ---------------------------------------------------------------------
> 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: [J2] Service Framework Proposal
Posted by David Le Strat <dl...@yahoo.com>.
Glenn,
This is the kind of debate we should be having.
Spring actually falls into the AOP/IoC realm though
Spring is actually much bigger than that as it
provides an MVC framework and so on.
If we stick to IoC/AOP, whichever framework is being
used, I believe that IoC 2 or 3 are the best choices
as you don't need a ServiceManager or JNDI to fetch
the dependencies from.
Spring also supports AOP and even has its own AOP
implementation.
On the drawbacks side, using Spring you have to
provide quite a bit of component metadata (which I
don't think is really a big deal, but some people may
think so) and we would have to implement JMX support.
Another drawback of Spring seems to be the component
configuration itself. It does not seem possible to
allow deploying self contained components / self
configurable components. Configuration seems to be
tight to the web application configuration (through
the applicationContext.xml). So you would not be able
to package your application services independently of
the application. Please correct me if I missed
something here.
I have not implemented a service using Spring per say.
If we could work around the configuration issue and
JMX, Spring could actually be a good fit for Jetspeed.
Any comments from others?
Just my 2 cents.
David.
--- "Glenn R. Golden" <gg...@umich.edu> wrote:
> David, and Jetspeed all -
>
> Thanks for the proposal. We are also evaluating
> component frameworks
> for our CHEF project, which has been based on
> Jetspeed 1 and the
> Jetspeed / Turbine service model, which seems a type
> 1 IoC like Avalon.
>
> I am currently very interested in Spring's component
> framework, which
> can handle type 2 or 3 IoC. You mention it in your
> analysis, but did
> not end up recommending using it. Any specific
> comments of the merits
> or problems of Spring, in general, and for Jetspeed?
>
> Thanks.
>
> - Glenn
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by "Glenn R. Golden" <gg...@umich.edu>.
David, and Jetspeed all -
Thanks for the proposal. We are also evaluating component frameworks
for our CHEF project, which has been based on Jetspeed 1 and the
Jetspeed / Turbine service model, which seems a type 1 IoC like Avalon.
I am currently very interested in Spring's component framework, which
can handle type 2 or 3 IoC. You mention it in your analysis, but did
not end up recommending using it. Any specific comments of the merits
or problems of Spring, in general, and for Jetspeed?
Thanks.
- Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by David Le Strat <dl...@yahoo.com>.
Tim,
I actually looked into OSGI a bit. For those who need
an overview, check:
http://www.osgi.org/resources/spec_overview.asp
I looked in particular at Oscar and the new plugin
eclipse framework Equinox based on OSGI as well.
http://oscar-osgi.sourceforge.net/
http://www.eclipse.org/equinox/
OSGI seemed initially designed to target the embedded
device market and has evolved over time to make it
into Eclipse (v3) and other projects.
It did not seems completely obvious to me how to
bootstrap those type of containers in a web
application and what benefits would be derived from
using that type of containers (I believe they mostly
rely on type 2 IoC) as opposed to the ones outlined in
the proposal.
I would be very interested in knowing if you see any
specific benefits in using such containers. There
really seems to be only 2 options out there (Oscar and
Equinox).
Regards,
David.
--- Tim Price <tp...@iupui.edu> wrote:
> Yes, very good proposal.
>
> Just curious - why wasn't OSGI considered as a
> possible service framework?
>
> Tim.
>
>
> > 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:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by Tim Price <tp...@iupui.edu>.
Yes, very good proposal.
Just curious - why wasn't OSGI considered as a possible service framework?
Tim.
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: [J2] Service Framework Proposal
Posted by "Suchisubhra Sinha (susinha)" <su...@cisco.com>.
If you need any help from me lemme know.
~suchi
-----Original Message-----
From: Jun Yang [mailto:junyang@cisco.com]
Sent: Monday, February 02, 2004 11:51 PM
To: Jetspeed Developers List
Subject: Re: [J2] Service Framework Proposal
We will start implementation now. Will do Cornerstone JMX first and
then Cornerstone Customization for PicoContainer.
Jun
David Sean Taylor wrote:
>
> On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>
> +1 on moving out Cornerstone's JMX into its own module
>
>
>> 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.
>
>
> I think we should get started on moving Jetspeed to the new service
> architecture now.
> I am ready to help out.
> My vote is +1 on yours and DLS's combined proposals.
---------------------------------------------------------------------
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: [J2] Service Framework Proposal
Posted by Jun Yang <ju...@cisco.com>.
We will start implementation now. Will do Cornerstone JMX first and
then Cornerstone Customization for PicoContainer.
Jun
David Sean Taylor wrote:
>
> On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>
> +1 on moving out Cornerstone's JMX into its own module
>
>
>> 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.
>
>
> I think we should get started on moving Jetspeed to the new service
> architecture now.
> I am ready to help out.
> My vote is +1 on yours and DLS's combined proposals.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by Emad Benjamin <eb...@cisco.com>.
At 08:17 AM 2/9/2004 -0700, BaTien Duong wrote:
>Jun Yang wrote:
>
>>Cornerstone JMX is ready for use.
>>
>>I have checked in cornerstone-jmx-demo under jakarta-jetspeed-2. I will
>>be checking in cornerstone-jmx after I merge the changes into
>>cornerstone. jetspeed-cornerstone-jmx-1.0.jar is checked in under
>>cornerstone-jmx-demo as a temporary measure to let the demo run. Read
>>how-to-run.txt. The demo shows how simple it is to use Cornerstone JMX
>>to put any object under the management of JMX.
>
>Hello Jun
>
>It's great. There are so many excellent things going on with open
>technologies and i cannot find time to get back to J2 and Pluto. Anyway, i
>have a quick and simple question regarding to JMX implementation. Would
>you please shed some light on the current implementation in relation to
>standard JMX in J2SE 1.5
I did a quick review of the JMX APIs in J2SE1.5 and I see that they have a
good wide coverage of the JMX set, but I couldn't see where they have made
it easier for a java.lang.Object to be auto-JMX-ed. I think long term we
can compliment the J2Se1.5 by adding our solution as a helper class.
Here is some background information:
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
http://www.developer.com/java/data/article.php/2213791 <--- article on what
Sun plans to do
http://java.sun.com/developer/technicalArticles/releases/j2se15/ <---
scroll down to manageability
>Thanks.
>
>BaTien
>DBGROUPS
>
>>
>>Jun
>>
>>PS: The Cornerstone JMX code was done by Emad Benjamin. I merely did
>>repackaging to strip away anything else unnecessary in Cornstone for just
>>the JMX purpose. We shall probably make him a committer too for him to
>>maintain it.
>>
>>David Sean Taylor wrote:
>>
>>>
>>>On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>>+1 on moving out Cornerstone's JMX into its own module
>>>
>>>
>>>>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.
>>>
>>>
>>>
>>>I think we should get started on moving Jetspeed to the new service
>>>architecture now.
>>>I am ready to help out.
>>>My vote is +1 on yours and DLS's combined proposals.
>>
>>
>>
>>---------------------------------------------------------------------
>>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
Re: [J2] Service Framework Proposal
Posted by BaTien Duong <ba...@dbgroups.com>.
Hello Jun and Emad
Thanks.
BaTien
DBGROUPS
Jun Yang wrote:
> Hi BaTien,
>
> Cornerstone JMX is not a JMX implementation per se. It's a bridge
> between an object you want to manage (e.g. an instance of a service)
> and the complex JMX API. It takes the hard part out of using JMX.
> For example, here is what you need to do to make logService manageable
> by JMX:
>
> IJMXManager jmxManager = (IJMXManager)
> Cornerstone.getManager(IJMXManager.class);
> jmxManager.manage(logService);
>
> And yes, that's all you need. With a standard JMX tool, you manage
> all constructors, properties and methods (operations) of logService
> (e.g. change the level log at runtime).
>
> Jun
>
> BaTien Duong wrote:
>
>> Jun Yang wrote:
>>
>>> Cornerstone JMX is ready for use.
>>>
>>> I have checked in cornerstone-jmx-demo under jakarta-jetspeed-2. I
>>> will be checking in cornerstone-jmx after I merge the changes into
>>> cornerstone. jetspeed-cornerstone-jmx-1.0.jar is checked in under
>>> cornerstone-jmx-demo as a temporary measure to let the demo run.
>>> Read how-to-run.txt. The demo shows how simple it is to use
>>> Cornerstone JMX to put any object under the management of JMX.
>>
>>
>>
>> Hello Jun
>>
>> It's great. There are so many excellent things going on with open
>> technologies and i cannot find time to get back to J2 and Pluto.
>> Anyway, i have a quick and simple question regarding to JMX
>> implementation. Would you please shed some light on the current
>> implementation in relation to standard JMX in J2SE 1.5
>>
>> Thanks.
>>
>> BaTien
>> DBGROUPS
>>
>>>
>>> Jun
>>>
>>> PS: The Cornerstone JMX code was done by Emad Benjamin. I merely
>>> did repackaging to strip away anything else unnecessary in Cornstone
>>> for just the JMX purpose. We shall probably make him a committer
>>> too for him to maintain it.
>>>
>>> David Sean Taylor wrote:
>>>
>>>>
>>>> On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>>>>
>>>> +1 on moving out Cornerstone's JMX into its own module
>>>>
>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I think we should get started on moving Jetspeed to the new service
>>>> architecture now.
>>>> I am ready to help out.
>>>> My vote is +1 on yours and DLS's combined proposals.
>>>
>>>
>
> ---------------------------------------------------------------------
> 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: [J2] Service Framework Proposal
Posted by Jun Yang <ju...@cisco.com>.
Hi BaTien,
Cornerstone JMX is not a JMX implementation per se. It's a bridge
between an object you want to manage (e.g. an instance of a service) and
the complex JMX API. It takes the hard part out of using JMX. For
example, here is what you need to do to make logService manageable by JMX:
IJMXManager jmxManager = (IJMXManager)
Cornerstone.getManager(IJMXManager.class);
jmxManager.manage(logService);
And yes, that's all you need. With a standard JMX tool, you manage all
constructors, properties and methods (operations) of logService (e.g.
change the level log at runtime).
Jun
BaTien Duong wrote:
> Jun Yang wrote:
>
>> Cornerstone JMX is ready for use.
>>
>> I have checked in cornerstone-jmx-demo under jakarta-jetspeed-2. I
>> will be checking in cornerstone-jmx after I merge the changes into
>> cornerstone. jetspeed-cornerstone-jmx-1.0.jar is checked in under
>> cornerstone-jmx-demo as a temporary measure to let the demo run.
>> Read how-to-run.txt. The demo shows how simple it is to use
>> Cornerstone JMX to put any object under the management of JMX.
>
>
> Hello Jun
>
> It's great. There are so many excellent things going on with open
> technologies and i cannot find time to get back to J2 and Pluto.
> Anyway, i have a quick and simple question regarding to JMX
> implementation. Would you please shed some light on the current
> implementation in relation to standard JMX in J2SE 1.5
>
> Thanks.
>
> BaTien
> DBGROUPS
>
>>
>> Jun
>>
>> PS: The Cornerstone JMX code was done by Emad Benjamin. I merely did
>> repackaging to strip away anything else unnecessary in Cornstone for
>> just the JMX purpose. We shall probably make him a committer too for
>> him to maintain it.
>>
>> David Sean Taylor wrote:
>>
>>>
>>> On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>>>
>>> +1 on moving out Cornerstone's JMX into its own module
>>>
>>>
>>>> 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.
>>>
>>>
>>>
>>>
>>> I think we should get started on moving Jetspeed to the new service
>>> architecture now.
>>> I am ready to help out.
>>> My vote is +1 on yours and DLS's combined proposals.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by BaTien Duong <ba...@dbgroups.com>.
Jun Yang wrote:
> Cornerstone JMX is ready for use.
>
> I have checked in cornerstone-jmx-demo under jakarta-jetspeed-2. I
> will be checking in cornerstone-jmx after I merge the changes into
> cornerstone. jetspeed-cornerstone-jmx-1.0.jar is checked in under
> cornerstone-jmx-demo as a temporary measure to let the demo run. Read
> how-to-run.txt. The demo shows how simple it is to use Cornerstone
> JMX to put any object under the management of JMX.
Hello Jun
It's great. There are so many excellent things going on with open
technologies and i cannot find time to get back to J2 and Pluto. Anyway,
i have a quick and simple question regarding to JMX implementation.
Would you please shed some light on the current implementation in
relation to standard JMX in J2SE 1.5
Thanks.
BaTien
DBGROUPS
>
> Jun
>
> PS: The Cornerstone JMX code was done by Emad Benjamin. I merely did
> repackaging to strip away anything else unnecessary in Cornstone for
> just the JMX purpose. We shall probably make him a committer too for
> him to maintain it.
>
> David Sean Taylor wrote:
>
>>
>> On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>>
>> +1 on moving out Cornerstone's JMX into its own module
>>
>>
>>> 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.
>>
>>
>>
>> I think we should get started on moving Jetspeed to the new service
>> architecture now.
>> I am ready to help out.
>> My vote is +1 on yours and DLS's combined proposals.
>
>
>
> ---------------------------------------------------------------------
> 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: [J2] Service Framework Proposal
Posted by Jun Yang <ju...@cisco.com>.
Thanks, David! Will let you know if we need any help.
Jun
David Le Strat wrote:
>Jun, Emad,
>
>I just tried out the JMX demo and this is great! Let
>us know if you need help for the Pico phase of the
>service framework.
>
>Regards,
>
>David.
>
>--- Jun Yang <ju...@cisco.com> wrote:
>
>
>>Cornerstone JMX is ready for use.
>>
>>I have checked in cornerstone-jmx-demo under
>>jakarta-jetspeed-2. I will
>>be checking in cornerstone-jmx after I merge the
>>changes into
>>cornerstone. jetspeed-cornerstone-jmx-1.0.jar is
>>checked in under
>>cornerstone-jmx-demo as a temporary measure to let
>>the demo run. Read
>>how-to-run.txt. The demo shows how simple it is to
>>use Cornerstone JMX
>>to put any object under the management of JMX.
>>
>>Jun
>>
>>PS: The Cornerstone JMX code was done by Emad
>>Benjamin. I merely did
>>repackaging to strip away anything else unnecessary
>>in Cornstone for
>>just the JMX purpose. We shall probably make him a
>>committer too for
>>him to maintain it.
>>
>>David Sean Taylor wrote:
>>
>>
>>
>>>On Saturday, January 17, 2004, at 09:33 PM, Jun
>>>
>>>
>>Yang 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.
>>>>
>>>>
>>>>
>>>+1 on moving out Cornerstone's JMX into its own
>>>
>>>
>>module
>>
>>
>>>
>>>
>>>>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.
>>>>
>>>>
>>>I think we should get started on moving Jetspeed
>>>
>>>
>>to the new service
>>
>>
>>>architecture now.
>>>I am ready to help out.
>>>My vote is +1 on yours and DLS's combined
>>>
>>>
>>proposals.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[J2] OJB Plugin Issue
Posted by David Le Strat <dl...@yahoo.com>.
I committed the security service code and have been
running in issues with the OJB plugin. I am not sure
why but if I use OJBPB, the security service tests
fail, but pass if I use OJBODMG. However, when I use
OJBODMG, the following test failed.
<!-- Excluded due to persistence plugin issues -->
<exclude>org/apache/jetspeed/deployment/TestSimpleDeployment.java</exclude>
<exclude>org/apache/jetspeed/services/registry/TestRegistry.java</exclude>
<exclude>org/apache/jetspeed/tools/pamanager/TestPortletDescriptor.java</exclude>
<!-- End Excluded due to persistence plugin issues -->
I excluded them from running for now (I wanted to
validated my commit). Any ideas on what could be
wrong?
Regards,
David.
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
CVS Commit Question
Posted by David Le Strat <dl...@yahoo.com>.
Hello there,
Just wanted to quickly ask a question to this list to
see if any of you knew how to work around a problem I
am running into when trying to commit code.
On commit action, I am getting a "Pre-commit check
failed error", I can create directories fine but the
above error is thrown when trying to commit files.
Any suggestion?
Best regards,
David Le Strat.
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by David Le Strat <dl...@yahoo.com>.
Jun, Emad,
I just tried out the JMX demo and this is great! Let
us know if you need help for the Pico phase of the
service framework.
Regards,
David.
--- Jun Yang <ju...@cisco.com> wrote:
> Cornerstone JMX is ready for use.
>
> I have checked in cornerstone-jmx-demo under
> jakarta-jetspeed-2. I will
> be checking in cornerstone-jmx after I merge the
> changes into
> cornerstone. jetspeed-cornerstone-jmx-1.0.jar is
> checked in under
> cornerstone-jmx-demo as a temporary measure to let
> the demo run. Read
> how-to-run.txt. The demo shows how simple it is to
> use Cornerstone JMX
> to put any object under the management of JMX.
>
> Jun
>
> PS: The Cornerstone JMX code was done by Emad
> Benjamin. I merely did
> repackaging to strip away anything else unnecessary
> in Cornstone for
> just the JMX purpose. We shall probably make him a
> committer too for
> him to maintain it.
>
> David Sean Taylor wrote:
>
> >
> > On Saturday, January 17, 2004, at 09:33 PM, Jun
> Yang 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.
> >>
> > +1 on moving out Cornerstone's JMX into its own
> module
> >
> >
> >> 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.
> >
> >
> > I think we should get started on moving Jetspeed
> to the new service
> > architecture now.
> > I am ready to help out.
> > My vote is +1 on yours and DLS's combined
> proposals.
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by Jun Yang <ju...@cisco.com>.
Cornerstone JMX is ready for use.
I have checked in cornerstone-jmx-demo under jakarta-jetspeed-2. I will
be checking in cornerstone-jmx after I merge the changes into
cornerstone. jetspeed-cornerstone-jmx-1.0.jar is checked in under
cornerstone-jmx-demo as a temporary measure to let the demo run. Read
how-to-run.txt. The demo shows how simple it is to use Cornerstone JMX
to put any object under the management of JMX.
Jun
PS: The Cornerstone JMX code was done by Emad Benjamin. I merely did
repackaging to strip away anything else unnecessary in Cornstone for
just the JMX purpose. We shall probably make him a committer too for
him to maintain it.
David Sean Taylor wrote:
>
> On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>>
> +1 on moving out Cornerstone's JMX into its own module
>
>
>> 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.
>
>
> I think we should get started on moving Jetspeed to the new service
> architecture now.
> I am ready to help out.
> My vote is +1 on yours and DLS's combined proposals.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Saturday, January 17, 2004, at 09:33 PM, Jun Yang 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.
>
+1 on moving out Cornerstone's JMX into its own module
> 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.
I think we should get started on moving Jetspeed to the new service
architecture now.
I am ready to help out.
My vote is +1 on yours and DLS's combined proposals.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by Jun Yang <ju...@cisco.com>.
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 <ju...@cisco.com> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by David Le Strat <dl...@yahoo.com>.
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?
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?
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?
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
What are you thoughts?
Regards.
David.
--- Jun Yang <ju...@cisco.com> 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:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by Jun Yang <ju...@cisco.com>.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Service Framework Proposal
Posted by David Sean Taylor <da...@bluesunrise.com>.
I
On Sunday, December 28, 2003, at 05:42 PM, 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.
>
I checked in the proposal under the docs directory in the jetspeed-2 cvs
Hivemind is interesting. Hopefully the licensing issues will be resolved
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org