commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Java Developer (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CONFIGURATION-394) 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.
Date Sat, 06 Mar 2010 06:24:27 GMT

    [ https://issues.apache.org/jira/browse/CONFIGURATION-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842197#action_12842197
] 

Java Developer edited comment on CONFIGURATION-394 at 3/6/10 6:23 AM:
----------------------------------------------------------------------

Here I've attached the more better code to describe functionality(ConfigFramework.zip),

Please take look at these classes to find out how it works(It is almost working, except the
save()  and load() methods to write values inside properties file) :

        com.test.cfg.sample.CacheConfigImpl
        com.test.cfg.sample.BankEARConfigImpl

        com.test.cfg.sample.Test1
        com.test.cfg.sample.Test2
        com.test.cfg.sample.Test3
        com.test.cfg.sample.Test
        com.test.cfg.sample.Test4

Please follow the instructions of main() methods of Test(1-4) classes to find out how it works.

I've used the .properties file to store and load the config data, and I've used the 'One readWriteLock
per .properties' to synchronize access to the ConfigBeans which are loaded from the same properties
file.

You can also use Preferences API to load/save data(or even XML files).

      was (Author: myapacheaccount):
    Here I've attached the more better code to describe functionality(ConfigFramework.zip),

Please take look at these classes to find out how it works(It is almost working, except the
save()  and load() methods to write values inside properties file) :

        com.test.cfg.sample.CacheConfigImpl
        com.test.cfg.sample.BankEARConfigImpl

        com.test.cfg.sample.Test1
        com.test.cfg.sample.Test2
        com.test.cfg.sample.Test3
        com.test.cfg.sample.Test
        com.test.cfg.sample.Test4

Please follow the instructions of main() methods of Test(1-4) classes to find out how it works.

I've used the .properties file to store and load the config data, and I've used the 'One readWriteLock
per .properties' to synchronized access to the ConfigBeans which are loaded from same properties
file.

But you can also use Preferences API to load/save data(or XML files).
  
> 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: BeanDiff.zip, ConfigFramework.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.


Mime
View raw message