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 Sean Taylor <da...@bluesunrise.com> on 2004/02/03 06:51:41 UTC
Re: [J2] Service Framework Proposal
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 "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