castor

Remove logic from LocalConfiguration and put it into XMLContext

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.2
  • Component/s: XML
  • Labels:
    None
  • Number of attachments :
    6

Description

Currently LocalConfiguration is responsible to:
1) provide access to configuration properties and
2) provide some methods that are largely used in the framework and
3) keeping states of processing...
that is to much!

Also LocalConfiguration is accessed in a static way which leads to trouble in multithreded environments.

The new Configuration (which is already available) is pure again only providing access to configuration properties - a good step!

Now a place is needed to put the other responsibilities of curent LocalConfiguration.

My approach is to use XMLContext for this stuff.
And in addition I try to remove as much static access as possible - for the sake of thread-safe-ness and such.

  1. Text File
    castor-XMLContext-20070820.txt
    22/Aug/07 5:33 AM
    209 kB
    Joachim Grüneis
  2. Text File
    patch.CASTOR-2119.20070828-1112.txt
    28/Aug/07 4:26 AM
    270 kB
    Joachim Grüneis
  3. Text File
    patch-c2119-20070922-1236.txt
    22/Sep/07 5:41 AM
    446 kB
    Joachim Grüneis
  4. Text File
    patch-c2119-20070922-1339.txt
    22/Sep/07 6:40 AM
    453 kB
    Joachim Grüneis
  5. Text File
    patch-c2119-20070928.txt
    28/Sep/07 2:46 AM
    353 kB
    Joachim Grüneis
  6. Text File
    patch-c2119-20071001.txt
    01/Oct/07 5:09 PM
    356 kB
    Joachim Grüneis

Issue Links

is depended upon by

Sub-task - The sub-task of the issue CASTOR-2056 Use refactored Castor configuration at XML modul

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Sub-task - The sub-task of the issue CASTOR-2056 Use refactored Castor configuration at XML modul

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joachim Grüneis added a comment -

Issue 2119 reduces LocalConfiguration to make 2056 possible.

Show
Joachim Grüneis added a comment - Issue 2119 reduces LocalConfiguration to make 2056 possible.
Hide
Permalink
Joachim Grüneis added a comment -

castor-XMLContext-20070820.txt
shows the current state of my effort to reduce LocalConfiguration to configuration responsibilities only, to enable XMLContext to be the 'mother of all dwelling' and to access XMLContext in a NON static way.
I'm still working on this patch but I also wanted to put a first 'beta' of it out to show the direction and hopefully get some early feedback

Show
Joachim Grüneis added a comment - castor-XMLContext-20070820.txt shows the current state of my effort to reduce LocalConfiguration to configuration responsibilities only, to enable XMLContext to be the 'mother of all dwelling' and to access XMLContext in a NON static way. I'm still working on this patch but I also wanted to put a first 'beta' of it out to show the direction and hopefully get some early feedback
Hide
Permalink
Joachim Grüneis added a comment -

An a little bit overworked version of the XMLContext patch

Show
Joachim Grüneis added a comment - An a little bit overworked version of the XMLContext patch
Hide
Permalink
Werner Guttmann added a comment -

A few comments after a quite longish discussion a few days ago:

  • The general concept introduced is great.
  • A new class will be introduced that will hold configuration information (more than properties) related to any XML processing. This will be completely different from the XMLContext class.
  • The (remaining) XMLContext class will be nothing more than a collection of factory methods, and a way of setting configuration properties manually.

After this has been implemented, there will be this new class (to be named) sitting on top of XMLConfiguration, and XMLContext as a new entry point into Castor.

Show
Werner Guttmann added a comment - A few comments after a quite longish discussion a few days ago: The general concept introduced is great. A new class will be introduced that will hold configuration information (more than properties) related to any XML processing. This will be completely different from the XMLContext class. The (remaining) XMLContext class will be nothing more than a collection of factory methods, and a way of setting configuration properties manually. After this has been implemented, there will be this new class (to be named) sitting on top of XMLConfiguration, and XMLContext as a new entry point into Castor.
Hide
Permalink
Joachim Grüneis added a comment -

Now all old configuration stuff is no longer used. Peer review with Werner is next step .

Show
Joachim Grüneis added a comment - Now all old configuration stuff is no longer used. Peer review with Werner is next step .
Hide
Permalink
Joachim Grüneis added a comment -

Configuration defaults are now in castor.xml.properties and nowhere else

Show
Joachim Grüneis added a comment - Configuration defaults are now in castor.xml.properties and nowhere else
Hide
Permalink
Werner Guttmann added a comment -

It looks, though, as the XML CTF suite does not finish under Java 1.4, whereas it finishes successfully under Java 5.0.

Show
Werner Guttmann added a comment - It looks, though, as the XML CTF suite does not finish under Java 1.4, whereas it finishes successfully under Java 5.0.
Hide
Permalink
Werner Guttmann added a comment -

Joachim, Steven and I spent some time yesterday on this issue with regards to the Java 1.4 problems, and came to realize that with all the code rewrites, a little bit more refactoring is required in the test framework classes. I'll post a small patch later that shows the required modification when - in a CTF test descriptor - the random attribute is set to true.

Show
Werner Guttmann added a comment - Joachim, Steven and I spent some time yesterday on this issue with regards to the Java 1.4 problems, and came to realize that with all the code rewrites, a little bit more refactoring is required in the test framework classes. I'll post a small patch later that shows the required modification when - in a CTF test descriptor - the random attribute is set to true.
Hide
Permalink
Werner Guttmann added a comment -

When looking into the last remaining issue (wrong element order during marshalling for classes in an extend hierarchy), I cam to realize that the Introspector has been refactored a lot. Which makes me wonder whether all this code changes going on in that class is a result of just introducing InternalContext, or whether you refactored some internals of the Introspector on purpose ?

Show
Werner Guttmann added a comment - When looking into the last remaining issue (wrong element order during marshalling for classes in an extend hierarchy), I cam to realize that the Introspector has been refactored a lot. Which makes me wonder whether all this code changes going on in that class is a result of just introducing InternalContext, or whether you refactored some internals of the Introspector on purpose ?
Hide
Permalink
Joachim Grüneis added a comment -

The big introspector refactoring is in Issue 2084. The introspector modifications in this issue are only related to the introduction of InternalContext.

Show
Joachim Grüneis added a comment - The big introspector refactoring is in Issue 2084. The introspector modifications in this issue are only related to the introduction of InternalContext.
Hide
Permalink
Joachim Grüneis added a comment -

Now I've switched to work with JDK1.4.2 as there had been some problems that haven't occured working with JDK1.5 . I fixed all problems but one. The last test that still fails is:
marshalling/xsi-type
I'll be looking at it later today - I just wanted to have a version in jira and show some progress.

Show
Joachim Grüneis added a comment - Now I've switched to work with JDK1.4.2 as there had been some problems that haven't occured working with JDK1.5 . I fixed all problems but one. The last test that still fails is: marshalling/xsi-type I'll be looking at it later today - I just wanted to have a version in jira and show some progress.
Hide
Permalink
Joachim Grüneis added a comment -

Please see mail thread 'xsi:type handling and CASTOR-2119' on castor-dev where I started to discuss the topic of the last test that fails...

Show
Joachim Grüneis added a comment - Please see mail thread 'xsi:type handling and CASTOR-2119 ' on castor-dev where I started to discuss the topic of the last test that fails...
Hide
Permalink
Joachim Grüneis added a comment -

This patch works! No more failing tests. I've manipulated the test case to clear the descriptor cache.

Show
Joachim Grüneis added a comment - This patch works! No more failing tests. I've manipulated the test case to clear the descriptor cache.
Hide
Permalink
Werner Guttmann added a comment -

Committed as is. Thanks, Joachim, for this work. And your patience with me being super-pessimistic during the last few weeks.

Show
Werner Guttmann added a comment - Committed as is. Thanks, Joachim, for this work. And your patience with me being super-pessimistic during the last few weeks.

People

  • Assignee:
    Joachim Grüneis
    Reporter:
    Joachim Grüneis
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: