[
https://issues.apache.org/jira/browse/CONFIGURATION-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Java Developer updated CONFIGURATION-394:
-----------------------------------------
Attachment: BaseConfigBean.fixed.zip
FinalConfigClasses.enh2.zip
I know issue is closed, but current implementation has some benefits(e.g. using
oracle Berkeley DB XML).
thanks!
> 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
> Attachments: BaseConfigBean.fixed.zip, BeanDiff.zip,
> cfggenengine.jar, ConfigFramework.zip, FinalConfigClasses.enh2.zip,
> FinalConfigClasses.zip
>
> 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(http://issues.apache.org/jira/browse/BEANUTILS-304) 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.
