[
https://issues.apache.org/jira/browse/CONFIGURATION-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Java Developer updated CONFIGURATION-394:
-----------------------------------------
Description:
Sorry for English and for such a generic summary:
If you have ever worked with Weblogic AdminConsole(Weblogic 10.3 in my case)
you would find out that it save your changes temporary and finally by clicking
"Apply changes" it would save all changes in configurations. If one of the
changes is failed then Weblogic would rollback all changes of configurations.
Something like database transaction.
The general idea could be that you create a clone of your entire or some parts
of your configuration hierarchy, then change the cloned version, and finally
apply back the cloned version on original version of hierarchy. Here when you
ask the original configuration hierarchy to accept new changes then the
original hierarchy would compute the Diff between itself and cloned version and
deliver the changes to all listeners that have registered for configuration
changes. If any of listeners are not agree with new changes then all process of
applying configuration would be rolled back!
Here in this scenario you need some facility to be added to Apache Commons
Config and also to Apache Commons BeanUtils:
1- A BeanDiff class that can compute the difference between two JavaBeans.
These JavaBeans are custom classes that programmers write for application
configuration (e.g. CacheConfiguration class). These custom configuration
classes would use the apache common config classes to to store and retrieve the
configuration from any source. It can be extended to have ConfigurationDiff
that would represent the changes between two Configuration(shows which
properties are altered)
2- Cloning entire hierarchy of configuration, I actually do not know whether
currently Apache Commons Config support this feature.
3- The most important part is adding some method to Configuration interface
which enables Configuration interface to accept a whole configuration hierarchy
and then apply that hierarchy to itself. The apply process consist of
traversing the hierarchy and visiting each node, then computing
ConfigurationDiff for each node and then notifying the registered listeners of
that node for all updates that node has. If one of listeners reject the update
then the process would call rollback method of listeners.
4- Some class like ConfigurationUpdateListener(or BeanUpdateListener) that has
some method like :
public abstract void prepareUpdate(ConfigurationUpdateEvent updateevent)
throws ConfigurationUpdateRejectedException;
public abstract void activateUpdate(ConfigurationUpdateEvent updateevent)
throws ConfigurationUpdateFailedException;
public abstract void rollbackUpdate(ConfigurationUpdateEvent updateevent);
All classes that are interested in configuration changes(batch changes not just
one property changes) can implement this class and register themselves in
Configuration node in hierarchy.
------------------------------
After some research! in Weblogic classes and jar files you can find the
"com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder.
After another research you can find some interesting classes like
BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor inside
"weblogic.descriptor" package. And also another interesting class
"weblogic.descriptor.internal.BeanDiff" class. Looking at them is useful!!
I could not completely understand the model that Weblogic works but that point
are what I understood about it.
I some useful features can be added to Apache Commons Config by looking at
weblogic works. It also can ease the process of writing ConfigurationMBeans for
applications.
was:
Sorry for English and for such a generic summary:
If you have ever worked with Weblogic AdminConsole(Weblogic 10.3 in my case)
you would find out that it save your changes temporary and finally by clicking
"Apply changes" it would save all changes in configurations. If one of the
changes is failed then Weblogic would rollback all changes of configurations.
Something like database transaction.
The general idea could be that you create a clone of your entire or some parts
of your configuration hierarchy, then change the cloned version, and finally
apply back the cloned version on original version of hierarchy. Here when you
ask the original configuration hierarchy to accept new changes then the
original hierarchy would compute the Diff between itself and cloned version and
deliver the changes to all listeners that have registered for configuration
changes. If any of listeners are not agree with new changes then all process of
applying configuration would be rolled back!
Here in this scenario you need some facility to be added to Apache Commons
Config and also to Apache Commons BeanUtils:
1- A BeanDiff class that can compute the difference between two JavaBeans.
These JavaBeans are custom classes that programmers write for application
configuration (e.g. CacheConfiguration class). These custom configuration
classes would use the apache common config classes to to store and retrieve the
configuration from any source. It can be extended to have ConfigurationDiff
that would represent the changes between two Configuration(shows which
properties are altered)
2- Cloning entire hierarchy of configuration, I actually do not know whether
currently Apache Commons Config support this feature.
3- The most important part is adding some method to Configuration interface
which enables Configuration interface to accept a whole configuration hierarchy
and then apply that hierarchy to itself. The apply process consist of
traversing the hierarchy and visiting each node, then computing
ConfigurationDiff for each node and then notifying the registered listeners of
that node for all updates that node has. If one of listeners reject the update
then the process would call rollback method of listeners.
4- Some class like ConfigurationUpdateListener(or BeanUpdateListener) that has
some method like :
public abstract void prepareUpdate(ConfigurationUpdateEvent updateevent)
throws ConfigurationUpdateRejectedException;
public abstract void activateUpdate(ConfigurationUpdateEvent updateevent)
throws ConfigurationUpdateFailedException;
public abstract void rollbackUpdate(ConfigurationUpdateEvent updateevent);
All classes that are interested in configuration changes(batch changes not just
one property changes) can implement this class and register themselves in
Configuration node in hierarchy.
------------------------------
After some research! in Weblogic classes and jar files you can find the
"com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder.
After another research using Decompilers you can find some interesting classes
like BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor inside
"weblogic.descriptor" package. And also another interesting class
"weblogic.descriptor.internal.BeanDiff" class. Looking at the source of them is
useful!!
I could not completely understand the model that Weblogic works but that point
are what I understood about it.
I some useful features can be added to Apache Commons Config by looking at
weblogic works. It also can ease the process of writing ConfigurationMBeans for
applications.
> Providing BeanDiff(or ConfigurationDiff), BeanBatchUpdateListener, and some
> merge facility for Configuration(Specially for HierarchialConfiguration) to
> implement two-phase-commit-like protocol to alter entire configuration
> hierarchy in atomic manner.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-394
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-394
> Project: Commons Configuration
> Issue Type: Improvement
> Reporter: Java Developer
> Original Estimate: 2016h
> Remaining Estimate: 2016h
>
> Sorry for English and for such a generic summary:
> If you have ever worked with Weblogic AdminConsole(Weblogic 10.3 in my case)
> you would find out that it save your changes temporary and finally by
> clicking "Apply changes" it would save all changes in configurations. If one
> of the changes is failed then Weblogic would rollback all changes of
> configurations. Something like database transaction.
> The general idea could be that you create a clone of your entire or some
> parts of your configuration hierarchy, then change the cloned version, and
> finally apply back the cloned version on original version of hierarchy. Here
> when you ask the original configuration hierarchy to accept new changes then
> the original hierarchy would compute the Diff between itself and cloned
> version and deliver the changes to all listeners that have registered for
> configuration changes. If any of listeners are not agree with new changes
> then all process of applying configuration would be rolled back!
> Here in this scenario you need some facility to be added to Apache Commons
> Config and also to Apache Commons BeanUtils:
> 1- A BeanDiff class that can compute the difference between two JavaBeans.
> These JavaBeans are custom classes that programmers write for application
> configuration (e.g. CacheConfiguration class). These custom configuration
> classes would use the apache common config classes to to store and retrieve
> the configuration from any source. It can be extended to have
> ConfigurationDiff that would represent the changes between two
> Configuration(shows which properties are altered)
> 2- Cloning entire hierarchy of configuration, I actually do not know whether
> currently Apache Commons Config support this feature.
> 3- The most important part is adding some method to Configuration interface
> which enables Configuration interface to accept a whole configuration
> hierarchy and then apply that hierarchy to itself. The apply process consist
> of traversing the hierarchy and visiting each node, then computing
> ConfigurationDiff for each node and then notifying the registered listeners
> of that node for all updates that node has. If one of listeners reject the
> update then the process would call rollback method of listeners.
> 4- Some class like ConfigurationUpdateListener(or BeanUpdateListener) that
> has some method like :
> public abstract void prepareUpdate(ConfigurationUpdateEvent updateevent)
> throws ConfigurationUpdateRejectedException;
> public abstract void activateUpdate(ConfigurationUpdateEvent updateevent)
> throws ConfigurationUpdateFailedException;
> public abstract void rollbackUpdate(ConfigurationUpdateEvent updateevent);
> All classes that are interested in configuration changes(batch changes not
> just one property changes) can implement this class and register themselves
> in Configuration node in hierarchy.
> ------------------------------
> After some research! in Weblogic classes and jar files you can find the
> "com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder.
> After another research you can find some interesting classes like
> BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor inside
> "weblogic.descriptor" package. And also another interesting class
> "weblogic.descriptor.internal.BeanDiff" class. Looking at them is useful!!
> I could not completely understand the model that Weblogic works but that
> point are what I understood about it.
> I some useful features can be added to Apache Commons Config by looking at
> weblogic works. It also can ease the process of writing ConfigurationMBeans
> for applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
