exist-development — eXist Developer's List

Re: [Exist-development] First draft of "A Beginners Guide to XRX on eXist"

[George C. B. <ge...@ox...>]

Hi,

On 3/28/10 10:32 AM, Wolfgang Meier wrote:
>> 5. I noticed that CDATA was difficult to insert in the code samples.
>> >  Does anyone have any suggestions on this?
> I think you have to switch to the "Text" mode in Oxygen and enter the
> CDATA manually. I could not find any shortcuts for this.

In oXygen in Author mode if you press Enter you get the list with 
proposals. At the end there are some special entries, rendered with 
italic style, one of them is /cdata/ with the annotation [Insert CDATA]. 
If you select that then a CDATA section will be inserted. Note that you 
can type to filter the proposals, so basically to quicly inser a CDATA 
section in a DocBook document you can use

Enter
Type cd (you will get cdata as the only proposal)
Enter

Best Regards,
George
-- 
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

[Exist-development] re xproc broken

[James F. <jam...@ex...>]

FYI: xproc will be broken for a bit whilst I work through serialization ...
no issues outside of xproc, will give a shout when I have things working
again.

J

Re: [Exist-development] First draft of "A Beginners Guide to XRX on eXist"

[Wolfgang M. <wol...@ex...>]

> 5. I noticed that CDATA was difficult to insert in the code samples.
> Does anyone have any suggestions on this?

I think you have to switch to the "Text" mode in Oxygen and enter the
CDATA manually. I could not find any shortcuts for this.

We use the following conventions for the syntax highlighting in
eXist's standard stylesheets:

XQuery code example:

<example>
  <title>A Simple Query</title>
  <programlisting language="xquery"><![CDATA[for $m in
//SPEECH[ft:query(., "boil bubble")]
order by ft:score($m) descending
return $m]]></programlisting>
</example>

XML code:

<example>
  <title>collection.xconf fragment</title>
  <programlisting><markup><![CDATA[<lucene>
    <text qname="p"/>
    <text qname="note"/>
    <ignore qname="note"/>
</lucene>]]></markup>
</programlisting>

Single line of XQuery:

<synopsis language="xquery">//p[ft:query(., "note")]</synopsis>

Using those elements should give you nicely rendered code.

Wolfgang

Re: [Exist-development] First draft of "A Beginners Guide to XRX on eXist"

[Joe W. <jo...@gm...>]

Hi Dan,

The Beginners XRX file is excellent.  I made some edits as I read
through it to get a sense of how you're structuring the tutorial.  I
haven't addressed your "big" questions yet, but I'm attaching the
edited DocBook file here.  I focused solely on the text and not the
graphics.  Please take my edits with a grain of salt, and
accept/reject the diffs as you see fit.  I've also spelled out some
comments here:

1. I did my editing in oXygen's Author mode, which worked very nicely.
 Did you know that oXygen has a spell checker?  I figured out how to
turn it on: Preferences > Spell Check > Automatic Spell Check.  It
lets you add words to its dictionary, and underlines misspelled words
very clearly.  This is a great feature that we should all make use of
in editing DocBook content!

2. I removed this from the XQuery intro paragraph:

"One caution. There are some things that are prohibited in XQuery that
you should be aware of. In general, XQuery variables are only set once
but never changed. So functions like let $x := $x + 1 are not
permitted. There are also restrictions on what can be done inside
FLOWR statements. We will illustrate these in examples later in the
beginner guides."

I removed it because I thought it doesn't need to be in the 'intro to
XQuery' statement.  Also, let $x := $x+1 is a valid XQuery statement:

let $x := 1
let $x := $x + 1
return $x

... returns 2, proving that the value of variables can change.  What
is the point you're trying to convey?

3. I tried to make the code samples consistent in indents (4 spaces)
and linebreaks (e.g. 1 linebreak between the xquery declaration and
the prolog).  I removed the linebreaks at the beginning and end of
code samples, since it seemed to me that this was a presentation duty
that CSS should perform.  I also standardized the style of comments to
make comments like "this logs us in as admin..." into "log in as
admin".

4. I tried to standardize the final commas in lists, e.g. "a, b, c,
and d" instead of "a, b, c and d".  Both styles are valid, but I
consider the former clearer for readers.

5. I noticed that CDATA was difficult to insert in the code samples.
Does anyone have any suggestions on this?

Joe


On Wed, Mar 24, 2010 at 9:04 PM, Dan McCreary <dan...@gm...> wrote:
> Here is a link to a very early DRAFT of "A Beginners Guide to XRX".
>
> http://www.syntactica.com/training/xrx/beginners/index.html
>
> You will find links to:
>
> the HTML and PDF versions of the beginner's guide
> the DocBook source
> a zip file of the source code
> a link to a the demo CRUDS app running on the Syntactica web server
>
> I have just used the default oXygen DocBook rendering and I am still playing
> around with the image scaling and formatting.  Any suggestions on DocBook
> formatting or options would be appreciated.
>
> My real questions are what are the critical "learning points" of getting new
> people up and running using eXist and XRX to build simple CRUDS
> applications?  What are the learning barriers we need to get people over?
> Will very simple templates and examples help?  How can we combine our
> DocBook versions with the WikiBooks?  How can we move to a "topic-based"
> system that will work with an overall search engine to help people quickly
> find the example code they need to solve a specific tasks?
>
> Thanks! - Dan
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>

Re: [Exist-development] Plugable world...

[Andrzej J. T. <an...@ch...>]

Dmitriy begged:

> PS give me pluggable world!

OK...since you asked:  http://www.productappeal.com/photos/couples_costumes/couple_costumes_plug.jpg

LOL

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] Moving access method mechanisms...

[Dmitriy S. <sha...@gm...>]

On Thu, 2010-03-25 at 11:27 -0400, Andrzej Jan Taramina wrote:
> > We also just don't have the development resources to work on too
> many
> > side-projects. We should stick to the really important stuff. The
> 1.4
> > release does seem to run very stable and I'm not ready to risk the
> > achieved stability by starting unnecessary redesigns. There are
> enough
> > things to work at in the core.
> 
> +1 on that, though in the long term I think some re-architecting to
> make various access methods and extensions external
> and pluggable would go a long way to simplifying the eXist core and
> thus making it more easily maintainable and
> extensible in the long term.

"Good" refactoring can help in stabilization (emphasize bugs).

-- 
Cheers,

Dmitriy Shabanov

PS give me pluggable world!

Re: [Exist-development] a new experiment was ....Re: Renaming the "lib" extension

[Dmitriy S. <sha...@gm...>]

Evgeny, you can send Russian version & I'll translate it.
 
On Fri, 2010-03-26 at 09:58 +0000, Adam Retter wrote:
> As well as your native languages, is there a common language that you
> and Dmitriy share? Perhaps he would be kind enough to translate for
> you, his English is very good.
> 
> On 25 March 2010 17:13, Evgeny Gazdovsky <gaz...@gm...> wrote:
> > I'm agree, but my English is so bad :(
> > I don't speak over ten years.

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] DVCS - Distributed Version Control?

[Andrzej J. T. <an...@ch...>]

Adam:

> Mercurial sounds very interesting and SourceForge even have some
> support for it -
> 
> http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial

Cool....I didn't know that sf had support for Mercurial. That's good to know.

> However, the biggest limitation in my mind is that write access to
> repository can only be achieved over SSH.
> 
> Before we moved to Subversion, CVS used to be a major pain in the ass
> for me, because I work from far too many locations (offices, airports,
> trains, cafes etc) where the only access out is HTTP, Subversion works
> perfectly over HTTP. If SourceForge were to enable Mercurial writes
> over HTTP then I might be sold on the idea ;-)

Yeah...that might be a problem with firewalls and the like blocking the standard SSH port 22.

I wonder if git suffers from the same issue.  Or maybe there are other hosting providers like sourceforge that support
Mercurial over plain HTTP?

Worse case, we could set up a relay/proxy that would expose HTTP and relay over SSH to sourceforge.

However, first we probably need to discuss the pros/cons of DVCS for the eXist project, timelines and then which DVCS to
use, who would host the repository and so forth....so it's a long path still before we would even get there.

I just figured it would be good to at least start a discussion on the topic and see what everyone thinks. ;-)

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] Cache logging [was: log entries]

[Andrzej J. T. <an...@ch...>]

Wolfgang:

>> How about if I change the default appender for the cache log entries back to the exist.core (ie. exist.log file)
>> appender in the log4j.xml file?  That would basically bring us back to the same logging output/destination file to
>> what we had before my change, but.....
> 
> Ok, sounds good. Please do so. And I will think about how we could
> improve the cache statistics to be useful.

Done! YWIMC! LOL

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] Cache logging [was: log entries]

[Wolfgang M. <wol...@ex...>]

> How about if I change the default appender for the cache log entries back to the exist.core (ie. exist.log file)
> appender in the log4j.xml file?  That would basically bring us back to the same logging output/destination file to
> what we had before my change, but.....

Ok, sounds good. Please do so. And I will think about how we could
improve the cache statistics to be useful.

Wolfgang

Re: [Exist-development] Some rules to start with

[Pierrick B. <pie...@fr...>]

Le 26/03/2010 17:12, Adam Retter a écrit :

>> I would add : test every extension, at least from time to time. I've had
>> some pretty hard work to make the spatial stuff work again ;-)
>
> Just wondering if this could this be solved with test cases or
> integration tests? Ideally we want to reduce the ammount of manual
> testing involved as we move forward.

Well, yes... a "developer's" local.properties in 
eXist/extensions/indexes just makes it :-)

Maybe to be harmonized with the local.build.properties file in 
eXist/extensions, but... anyway...

Cheers,

p.b.

Re: [Exist-development] DVCS - Distributed Version Control?

[Thomas W. <tho...@gm...>]

Here is a list of free hosting of Mercurial repositories 
http://mercurial.selenic.com/wiki/MercurialHosting

Thomas

----- Original Message ----- 
From: "Adam Retter" <ad...@ex...>
To: "Andrzej Jan Taramina" <an...@ch...>
Cc: "eXist development" <exi...@li...>
Sent: Friday, March 26, 2010 4:10 PM
Subject: Re: [Exist-development] DVCS - Distributed Version Control?


>> But as our ranks get larger and the subprojects people are interested in 
>> and work on become bigger and more elaborate,
>> maybe we should consider moving to a DVCS - Distributed Version Control 
>> system, which would provide much more flexible
>> and easier branch/merge capability? Might help alleviate some of the 
>> issues in the longer term.
>>
>> Something like GIT or Mercurial....
>>
>> For those not familiar with DVCS's, Joel Spolsky posted a great article 
>> on DVCSs here:
>>
>> http://www.joelonsoftware.com/items/2010/03/17.html
>>
>> Thoughts?
>
> Mercurial sounds very interesting and SourceForge even have some
> support for it -
>
> http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial
>
> However, the biggest limitation in my mind is that write access to
> repository can only be achieved over SSH.
>
> Before we moved to Subversion, CVS used to be a major pain in the ass
> for me, because I work from far too many locations (offices, airports,
> trains, cafes etc) where the only access out is HTTP, Subversion works
> perfectly over HTTP. If SourceForge were to enable Mercurial writes
> over HTTP then I might be sold on the idea ;-)
>
>> --
>> Andrzej Taramina
>> Chaeron Corporation: Enterprise System Solutions
>> http://www.chaeron.com
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
>>
>
>
>
> -- 
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
> 

Re: [Exist-development] Some rules to start with

[Adam R. <ad...@ex...>]

On 26 March 2010 16:06, Pierrick Brihaye <pie...@fr...> wrote:
> Hi,
>
> Le 26/03/2010 17:01, Adam Retter a écrit :
>
>> The "eXist-db Developers Manifesto" is now available for reading. Just
>> committed to trunk as revision 11572 - devguide_manifesto.xml - liked
>> to from the main documentation page.
>>
>> I would ask that each contributor to eXist read this and pay head to it.
>>
>> So far it has had input from the core developers, if you have input or
>> changes that you wish to make to it, then please bring them to me for
>> discussion rather than changing that document directly.
>
> I would add : test every extension, at least from time to time. I've had
> some pretty hard work to make the spatial stuff work again ;-)

Just wondering if this could this be solved with test cases or
integration tests? Ideally we want to reduce the ammount of manual
testing involved as we move forward.

> Cheers,
>
> p.b.
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] DVCS - Distributed Version Control?

[Adam R. <ad...@ex...>]

> But as our ranks get larger and the subprojects people are interested in and work on become bigger and more elaborate,
> maybe we should consider moving to a DVCS - Distributed Version Control system, which would provide much more flexible
> and easier branch/merge capability?  Might help alleviate some of the issues in the longer term.
>
> Something like GIT or Mercurial....
>
> For those not familiar with DVCS's, Joel Spolsky posted a great article on DVCSs here:
>
>        http://www.joelonsoftware.com/items/2010/03/17.html
>
> Thoughts?

Mercurial sounds very interesting and SourceForge even have some
support for it -

http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial

However, the biggest limitation in my mind is that write access to
repository can only be achieved over SSH.

Before we moved to Subversion, CVS used to be a major pain in the ass
for me, because I work from far too many locations (offices, airports,
trains, cafes etc) where the only access out is HTTP, Subversion works
perfectly over HTTP. If SourceForge were to enable Mercurial writes
over HTTP then I might be sold on the idea ;-)

> --
> Andrzej Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] Some rules to start with

[Pierrick B. <pie...@fr...>]

Hi,

Le 26/03/2010 17:01, Adam Retter a écrit :

> The "eXist-db Developers Manifesto" is now available for reading. Just
> committed to trunk as revision 11572 - devguide_manifesto.xml - liked
> to from the main documentation page.
>
> I would ask that each contributor to eXist read this and pay head to it.
>
> So far it has had input from the core developers, if you have input or
> changes that you wish to make to it, then please bring them to me for
> discussion rather than changing that document directly.

I would add : test every extension, at least from time to time. I've had 
some pretty hard work to make the spatial stuff work again ;-)

Cheers,

p.b.

[Exist-development] eXist-db Developer Manifesto - PLEASE READ

[Adam R. <ad...@ex...>]

The "eXist-db Developers Manifesto" is now available for reading. Just
committed to trunk as revision 11572 - devguide_manifesto.xml - linked
to from the main documentation page.

I would ask that each contributor to eXist-db read this and pay head to it.

So far it has had input from the core developers, if you have input or
changes that you wish to make to it, then please bring them to me for
discussion rather than changing that document directly, this thread on
the eXist-development mailing list is a good place for initial
feedback.


Thanks Adam.

-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

[Exist-development] DVCS - Distributed Version Control?

[Andrzej J. T. <an...@ch...>]

Guys (hey...don't we need some female eXist developers? ;-) ):

I believe that some of the problems that we've seen with functions spread across multiple commits, partial commits of
new features and the like might be partially due to, or at least exacerbated, by our use of a "classic" source code
control system like Subversion.  Branches and merges are a real pain with a tool like Subversion for anything beyond
simple changes.

Now don't get me wrong....I've used Subversion for a long time and like it, and do not relish learning a new approach or
giving up my current SVN tool of choice (the Oxygen SVNClient tool)....

But as our ranks get larger and the subprojects people are interested in and work on become bigger and more elaborate,
maybe we should consider moving to a DVCS - Distributed Version Control system, which would provide much more flexible
and easier branch/merge capability?  Might help alleviate some of the issues in the longer term.

Something like GIT or Mercurial....

For those not familiar with DVCS's, Joel Spolsky posted a great article on DVCSs here:

	http://www.joelonsoftware.com/items/2010/03/17.html

Thoughts?

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] Some rules to start with

[Adam R. <ad...@ex...>]

The "eXist-db Developers Manifesto" is now available for reading. Just
committed to trunk as revision 11572 - devguide_manifesto.xml - liked
to from the main documentation page.

I would ask that each contributor to eXist read this and pay head to it.

So far it has had input from the core developers, if you have input or
changes that you wish to make to it, then please bring them to me for
discussion rather than changing that document directly.

I will also post a new thread for this purpose...

On 24 March 2010 20:03, Wolfgang Meier <wol...@ex...> wrote:
> Hi guys,
>
> Adam is currently writing a draft for a general eXist-db Developers
> Manifesto, which will be available for your reading and discussion
> within the next days. In the meantime, I'd like to ask every
> contributor to adhere to some basic rules:
>
> * new features should be announced and discussed on exist-development
> *before* they are committed. In particular, you should try to explain
> why the feature will be beneficial to the project as a whole. I think
> we are a very open community, so nobody has to fear that he will be
> outright rejected. We may just have some suggestions.
>
> * new code must always be accompanied by test cases. Integration tests
> can be written in XQuery.
>
> * you must run the test suite(s) before committing. Changes to
> anything XQuery-related require the XQTS to be run. After major
> changes, make sure all the demo applications which ship with eXist are
> still working as before.
>
> * we want all commits to be checked by as many people as possible. It
> is thus important that related commits are kept together where
> possible. For example, I made only 2 commits to trunk during the past
> 2 days, while Evgeny did 13! This inflation of commits makes it
> difficult to detect problems.
>
> Please limit your changes to the necessary minimum. Don't touch code
> unless you really have to modify it. The less classes are changed, the
> easier it is for other people to understand the purpose of the commit.
> If you want to cleanup something, do it in a separate commit and mark
> it as "cleaning up".
>
> Wolfgang
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] Cache logging [was: log entries]

[Andrzej J. T. <an...@ch...>]

Wolfgang:

> Mmmh, I was hoping that JMX could become the central interface for
> getting administrative information from the db - and to some extend
> even change configuration parameters at runtime. As I understand it,
> JMX provides a large number of options to use it without compromising
> security. Even if I don't enable JMX, I can still use jconsole on the
> same machine to get information from my running eXist.

JMX is great for ad-hoc, realtime access. Using it for runtime config changes is great.

In many cases it's just a lot easier and more efficient to go look in a log file, rather than fire up a JMX interface
tool.  With long distance, flakey and slow net connections (common in the healthcare space, down at the primary care
clinic levels), JMX just doesn't work well....downloading a log file and then perusing it locally at your leisure (ie.
eliminating the network instabilities) works better.  Not everyone is on high speed connections yet. ;-)

JMX doesn't obviate the need for longer term and historical logging though. I think we need both in the long run.

>> After the fact, how do you easily get a picture of how the caching was doing over a historical period of time?
> 
> Normally I'm only interested in the maximum cache use over a longer
> period of time. As long as everything runs fine, I usually don't check
> the caches. The main information the caching statistics provide is if
> a certain cache can become a bottleneck under high load. The
> historical development of the cache doesn't really tell me that much -
> but I'm happy to learn.

OK...makes sense to me to some degree....but often you can't see the high load condition when it happens in
production...so having this info  (optionally) stream to a log would seem to make some sense. In fact, if you are in a
high load situation, getting response out of a JMX interface can be an issue, made worse if the network infrastructure
is flakey (as it can be in our client situations).

> Ok, but then we could also just assign a special logger to the cache
> logs. I *really* prefer to have all logs going into the same log file.
> Advantage: I can see all log messages in context. Having all logs in
> the same file makes it easy to relate events to each other. I can
> easily see what query causes an increase in memory consumption or
> cache space ;-)

I can see the value of that, and the changes that I put in place the other day actually take us very close to what
you're asking for, since I've assigned a special logger category to the cache logs at this stage ("org.exist.statistics"
instead of the class name). Though in that scenario, I think opening up two logs and looking at timestamps to
co-ordinate the cause/effect is pretty simple to do, at least in the case of the cache performance logging (though it is
harder for more general purpose debugging as Dannes noted).

How about if I change the default appender for the cache log entries back to the exist.core (ie. exist.log file)
appender in the log4j.xml file?  That would basically bring us back to the same logging output/destination file to what
we had before my change, but.....

I could now easily use our application's config file customization infrastructure (ant targets that dynamically modify
things like log4j.xml, conf.xml and other key config files), to route the cache logs to a different file
(statistics.log) for just our application implementation.

Say the word, Wolfie, and I shall "make it so" (said in my best Pickard voice. ;-) ).

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] Cache logging [was: log entries]

[Wolfgang M. <wol...@ex...>]

> It is not always convenient or even possible to use JMX on remote servers in many
> production environments, which makes your suggestion problematic.

Mmmh, I was hoping that JMX could become the central interface for
getting administrative information from the db - and to some extend
even change configuration parameters at runtime. As I understand it,
JMX provides a large number of options to use it without compromising
security. Even if I don't enable JMX, I can still use jconsole on the
same machine to get information from my running eXist.

> After the fact, how do you easily get a picture of how the caching was doing over a historical period of time?

Normally I'm only interested in the maximum cache use over a longer
period of time. As long as everything runs fine, I usually don't check
the caches. The main information the caching statistics provide is if
a certain cache can become a bottleneck under high load. The
historical development of the cache doesn't really tell me that much -
but I'm happy to learn.

> And then possibly add a configuration capability to selectively turn the
> cache logging off at runtime for those that don't want or need it. The latter is now easily
> accomplished with a simple change to a deployed log4j config file, which was not possible
> before.

Ok, but then we could also just assign a special logger to the cache
logs. I *really* prefer to have all logs going into the same log file.
Advantage: I can see all log messages in context. Having all logs in
the same file makes it easy to relate events to each other. I can
easily see what query causes an increase in memory consumption or
cache space ;-)

Wolfgang

Re: [Exist-development] Cache logging [was: log entries]

[Andrzej J. T. <an...@ch...>]

Wolfgang:

> I had a look at the statistics logging. The cache log is more or less
> worthless now. It only prints statistics for those index files which
> have not been migrated to the new index architecture yet. The memory
> log might be useful.
> 
> The cache logs should be disabled.

I disagree at the moment, but am open to having my mind changed...

It is not always convenient or even possible to use JMX on remote servers in many production environments, which makes
your suggestion problematic.

After the fact, how do you easily get a picture of how the caching was doing over a historical period of time? Doesn't
JMX, as currently implemented in eXist, just show you the current status, not keep a historical view? Cache performance
is key to production performance with larger databases, and that typically requires historical information.

I would rather see an extension of the cache logging to support the new indexes as I believe that this would serve the
needs of production, real-world users better. And then possibly add a configuration capability to selectively turn the
cache logging off at runtime for those that don't want or need it. The latter is now easily accomplished with a simple
change to a deployed log4j config file, which was not possible before.

Since the cache log entries no longer clutter the main exist.log file,they are now closer to being "disabled". I thought
that was a good compromise to all the opinions that were expressed, and that would have the least potential impact on
production users in the short term.

> True. My first answer was "remove the log and use JMX" and I just did
> not have time to write a second email on this issue. There are dozens
> of weeks old emails which are waiting for an answer in my inbox.

See above comments. I am not convinced that JMX alone is a good long-term solution to this.

> We start to waste too much time on questions of minor importance. To
> avoid lengthy discussion threads which allow for many interpretations,
> everyone should probably try to give short, definite answers. 

No argument there from me. ;-)

> Adam said: please use exist-development.

I have moved this thread to the dev list. Should have done so a while ago...but didn't notice it was still on open.

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: [Exist-development] a new experiment was ....Re: Renaming the "lib" extension

[Adam R. <ad...@ex...>]

As well as your native languages, is there a common language that you
and Dmitriy share? Perhaps he would be kind enough to translate for
you, his English is very good.

On 25 March 2010 17:13, Evgeny Gazdovsky <gaz...@gm...> wrote:
> I'm agree, but my English is so bad :(
> I don't speak over ten years.
>
> -----------
> Evgeny
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] Renaming the "lib" extension

[Evgeny G. <gaz...@gm...>]

2010/3/25 Evgeny Gazdovsky <gaz...@gm...>:
> I have one more idea about securing jars.
>
> We can add in conf.xml the masks of shared jars (or another files)
> instead hardcode them.
>

Or create one more config and use it to sign and share jars.

Re: [Exist-development] Renaming the "lib" extension

[Evgeny G. <gaz...@gm...>]

I have one more idea about securing jars.

We can add in conf.xml the masks of shared jars (or another files)
instead hardcode them.

Re: [Exist-development] a new experiment was ....Re: Renaming the "lib" extension

[Evgeny G. <gaz...@gm...>]

> trying to follow 40+ email threads on something
> we don't understand very well in the beginning is difficult.
>
Agree this is need to see :)

----------
Evgeny