Hi Jody,
Just noticed you are online while I am typing this rather long email …
Udig is a fantastic code base for plugin extension – really good work from you guys particularly of note because you seem to have many hats and representation on lots of Open Community development teams. Your names keep popping up everywhere.
It is not your problem, I think this may have been in there for quite some number of releases. I noticed it back at 1.2.0 which is where I first starting writing plugins after knowing absolutely nothing about RCP.
The gt jar bundled into the library plugin is well hidden and log4j uses reflections to find its log appenders, which is anti OSGI plugin and anti SPI paradigm and eclipse has the register hack to change the class loader for the plugins so marked. I suppose something can be done in the maven build part to fix up the bundling – I haven’t look yet – I am completely unfamiliar with maven and your conversion to it has caused me to do a bit of reading.
I just ignore the error report because I am more concerned about seeing all my plugins’ sl4j/logj log output – but it would be nice to know that we can capture the geo tools logger calls though.
I am 36 years old base 16 and have more than 30 years of development experience and loving every minute of it. With your initial RCP technology and now your migration to git and maven you are keeping we on my toes.
Well I have got udig 1.3.1 working and rendering well enough with a 64 bit JRE two nights ago (and really happy) after trying to get my 1.2.1 code base working in 64 bit Windoze and having a few false starts I decided to switch to the more progressive 1.3.1 code-base.
I am now re-adapting my plugins that are dependent on my derived renderer interfaces that I made for real-time rendering, and dependent on SLD and the printer modules that seem to have changed. I notice that Text labels and graphic marks have stopped working for me on my real-time layers to - so I plan to work on resolving that next.
I have been working fairly solidly, mainly on the weekends between flying, and sometimes to 0300 in the morning between my day job to get this going satisfactorily on the 64 bit JRE I have bundled together. I am a mad keen pilot and try to fly every weekend, and for my current day job I am assisting with writing Security Subsystem code for a very large community of interest, involving interaction with Entrust Get Access, federation across a WAN and trying to achieve policy engine decisions for 2000 concurrent users which decisions performed at a rate of 50000 per second with less than 3 seconds of latency in the responses. We have been working on this for a few weeks now performance tuning, load testing, re-design, replication, performance testing and so on. What a job?
I have experienced the following difficulties with the 1.3.1 code base when trying to get my old real-time plugins that worked at 1.2.1 going on 1.3.1 which has really leapt ahead of me:
1. Style building changes
2. Print DPI - my old code base had a dpi parameter on the map graphic renderers and I have to see how I can incorporate graphic and label scaling and mark scaling when printing to PDF
3. MapEditorWithPalette stole too much screen real-estate and is not only a visual change it is a functional change as we are used to having multiple maps open and one tool bar at the top. This side-tool only docks left and right, so I have reverted the MapEditor factory to construct the old prior MapEditor class instead. My real-time users would not tolerate such a change.
4. I have noticed that the ViewPort render is being invoked between 3 and 4 times each time the Composite renderer is DONE, although it is not visually noticeable, it is a performance issue with real-time rendering. I haven’t spent much time analysing just exactly how, and wether I introduced the problem, but it seems to be related to the event callback registrations.
5. The event callbacks are synchronous instead of asynchronous, of note is that the visibility check box widget for the layer has quite a deep call stack with an ultimate synchronous CompositeRenderer call at the bottom (which then triggers the ViewPortRender), all being performed in the Display thread. Under heavy real-time traffic loads, rendering times can get close to 0.5 seconds, which means changes to these controls take effect relatively slowly. So far we live with this but I think I need to decouple it so it asynchronously fires the CompositeRender instead. To me it seems counter to one of your programming standard suggestions. We have up to 15 real-time layers rendering concurrently with map layers sourced from shape files and map servers.
6. I also removed the DrawJob scheduling restriction so multiple file resources can render concurrently – modern computers are fast enough to read files concurrently and I cheated and used file URL for some of my layer data source configurations (perhaps I should switch to some other protocol?) . You may be surprised to learn how many real-time features these layers can render in parallel when the restriction is removed.
And on my wish list I really wished that MapEditors didn’t use EditorParts and instead used ViewParts because we would like to be able to undock them. What we have is a bunch of operators desirous of placing maps on more than one screen (the more the merrier), so I find that they often run two copies of the product simultaneously to obtain the desired effect (I am sometimes running with 4 maps rendering concurrently in real time while I am diagnosing system problems).
I was going to look at doing it – but I am not brave enough yet and there are other more pressing priorities. I have implemented special concurrent collections that downsize their foot-print as they empty out and ones that are highly concurrent and I have NO memory leaks, however, we have reached the memory limits of the 32 bit address space, which is why I am working on 64 bits now and take non-native jai hit on Windoze.
cheers,
Ralph
From: udig-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:udig-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jody Garnett
Sent: Wednesday, 11 January 2012 1:12 AM
To: Donovan Cameron
Cc: udig-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [udig-users] log4j error on opening uDig 1.3.1
If you are interested uDig uses a number of different open source project; and we do our best to collect the information from all of them into one spot.
Thanks for your feedback!
--
Jody Garnett
On Sunday, 8 January 2012 at 3:21 AM, Donovan Cameron wrote:
Morning list!
I downloaded the latest uDig 1.3.1 and when I open it up, the terminal outputs the following error:
log4j:WARN No appenders could be found for logger (org.geotools.factory).
log4j:WARN Please initialize the log4j system properly.
What do I need to do to "initialize the log4j system"?
Does it mean some files are missing from the zip: udig-1.3.1.linux.gtk.x86_64.zip
_______________________________________________
