exist-development — eXist Developer's List

Re: [Exist-development] xquery: xslt in recursive function

[Dan M. <dan...@gm...>]

The following article is a good comparison of recursive copy functions in
both XSLT and XQuery:

http://en.wikipedia.org/wiki/Identity_transform

This should help you get started with the concepts of recursive filters.

There are also many examples of recursion in the XQuery Wikibook:

http://en.wikibooks.org/wiki/XQuery/

Specifically you may want to read the "Filtering Nodes" examples:

http://en.wikibooks.org/wiki/XQuery/Filtering_Nodes

- Dan

2011/5/19 Василий Старцев <wst...@gm...>

> hi!
>
> i try to transform document with xslt in recursive function like:
>
> declare function local:clean-document(node, xslt){
> (: transform node with xslt :)
>
> (: check transformation result :)
>
> (: if need do it again :)
> local:clean-document(document, xslt)
>
> (: else return node :)
> }
>
> and this transformation except with memory allocation error.
>
> i want to clearly understand: xq copy node in each call function?
>
> how to make recursive function to work with one node in each iteration?
>
> --
> С наилучшими пожеланиями
> Василий Старцев
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>


-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

Re: [Exist-development] xquery: xslt in recursive function

[Dannes W. <da...@ex...>]

On 19 May 2011, at 19:09 , Василий Старцев wrote:

> i try to transform document with xslt in recursive function like:
> 
> and this transformation except with memory allocation error.

Sorry I do not understand your mail? If it is about XSLT.... this mailing list might not be the right location, or is it about something else, so please could you be more clear on what you try to achieve?

thnx


Dannes

--
Dannes Wessels
eXist-db Open Source Native XML Database
e: da...@ex...
w: http://www.exist-db.org 

Re: [Exist-development] xquery: xslt in recursive function

[Вячеслав С. <sch...@gm...>]

in other words question is about tail recursion optimization in eXist?

i am interested too :)

19 мая 2011 г. 21:09 пользователь Василий Старцев <wst...@gm...> написал:
> hi!
> i try to transform document with xslt in recursive function like:
> declare function local:clean-document(node, xslt){
> (: transform node with xslt :)
> (: check transformation result :)
> (: if need do it again :)
> local:clean-document(document, xslt)
> (: else return node :)
> }
> and this transformation except with memory allocation error.
> i want to clearly understand: xq copy node in each call function?
> how to make recursive function to work with one node in each iteration?
>
> --
> С наилучшими пожеланиями
> Василий Старцев
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>

Re: [Exist-development] Friday's teleconference call

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

> Dan McCreary, Dave Finton, and I met for lunch today to discuss the eXist documentation project.  Can we use the Friday teleconference call to discuss the eXist documentation project?  I would like to have it an hour earlier, because I have a meeting later that morning.  I will try to have a project plan written up before then.

Ok, so we'll schedule the conference call for 3pm UTC.

Wolfgang

[Exist-development] xquery: xslt in recursive function

[Василий С. <wst...@gm...>]

hi!

i try to transform document with xslt in recursive function like:

declare function local:clean-document(node, xslt){
(: transform node with xslt :)

(: check transformation result :)

(: if need do it again :)
local:clean-document(document, xslt)

(: else return node :)
}

and this transformation except with memory allocation error.

i want to clearly understand: xq copy node in each call function?

how to make recursive function to work with one node in each iteration?

-- 
С наилучшими пожеланиями
Василий Старцев

Re: [Exist-development] Installer failing

[Dannes W. <da...@ex...>]

Dear list,

sorry for having this message passed. it is a bit too large....... counted
in kilo-bytes.

sorry....

D.




On Wed, May 18, 2011 at 6:09 PM, Loren Cahlander
<lor...@gm...>wrote:

> There appears to be a problem with the installer off of trunk for rev 14481
>
> *Commandline*
>
> Loren-Cahlanders-MacBook-Pro-2:exist lcahlander$ java -jar
> installer/eXist-setup-1.5.0dev-rev14481.jar -p ~/lctmp
> Installing into directory: /Users/lcahlander/lctmp
> [ Starting automated installation ]
> java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
> java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
> at java.util.Vector.elementAt(Vector.java:427)
>  at
> com.izforge.izpack.installer.AutomatedInstaller.updateInstanceCount(Unknown
> Source)
> at com.izforge.izpack.installer.AutomatedInstaller.doInstall(Unknown
> Source)
>  at
> org.exist.izpack.CommandLineInstaller$EXistAutomatedInstaller.run(CommandLineInstaller.java:127)
> at
> org.exist.izpack.CommandLineInstaller.execute(CommandLineInstaller.java:101)
>  at
> org.exist.izpack.CommandLineInstaller.main(CommandLineInstaller.java:137)
> [ Automated installation FAILED! ]
> Loren-Cahlanders-MacBook-Pro-2:exist lcahlander$
>


-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

[Exist-development] Cryptographic extension?

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

I am curious as to why the new Cryptographic extension (from Claudius) does not follow the typical
extension conventions where the source is found under
/extensions/src/modules/org/exist/xquery/modules?

It is located in it's own source tree under
/extensions/src/modules/ro/kuberam, which seems like quite a departure from normal.

This module also does not include the standard eXist license header and is licensed under different
terms than the rest of our extension modules.

In my opinion that it should be consistent with all the other extensions, if it is to be part of the
main eXist source tree in SVN. If it is a proprietary extension, then it should not be part of the
eXist svn code base and should be hosted elsewhere.

I'm planning to fix this soon, when I get a bit of time, unless I hear back why I shouldn't.

Thanks!

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

[Exist-development] Strange PathExpr warnings in log....

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

Wolfgang:

I'm testing latest trunk.  Getting a bunch of warnings like the following:

2011-05-18 12:30:28,671 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found: $matchDate[child::v3:code/attribute::codeSystem =
$syscode]; in: exists($syscode)
2011-05-18 12:30:28,671 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found: $matchDate[child::v3:code/attribute::codeSystemName
= $sysname]; in: exists($sysname)
2011-05-18 12:30:28,671 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found:
$matchValCode[text:matches-regex(child::v3:statusCode/attribute::code, $pattern)]; in:
$caseSensitive = "true"
2011-05-18 12:30:28,673 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found: $encounters[contains(child::v3:text, $pattern)];
in: $caseSensitive = "true"
2011-05-18 12:30:28,673 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found: $observations[contains(child::v3:value, $pattern)];
in: $caseSensitive = "true"
2011-05-18 12:30:28,673 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found: $observations[text:matches-regex(child::v3:value,
$pattern)]; in: $caseSensitive = "true"
2011-05-18 12:30:28,674 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found:
$observations[contains(child::v3:value/attribute::value, $pattern)]; in: $caseSensitive = "true"
2011-05-18 12:30:28,674 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found:
$observations[text:matches-regex(child::v3:value/attribute::value, $pattern)]; in: $caseSensitive =
"true"
2011-05-18 12:30:28,675 [DefaultQuartzScheduler_Worker-4] WARN  (PathExpr.java
[replaceExpression]:119) - Expression not found:
common:get-sections-with-data($patientRecord)[common:get-section-id(self::node()) = $id]; in:
common:get-section-by-id(item()*, item()*) item()*

Which just look very suspicious, since I don't see how the new and old expressions might be
related....and I've never seen these warnings in the past.

I wonder if it might be related to the repeated attribute expression values bug that I've been
seeing (copied that post below for reference) since both relate to expression handling in XQuery?

I still haven't managed to create a simple test case (I've been trying!) to replicate the repeated
attribute bug....though in my production XQuery code (which is very complex) it happens consistently.

Help!

Thanks.

.....Andrzej

> More testing on this issue:
> 
> I changed the test function to not use the Binary stuff, so it looks like this:
> 
> declare function common:test()
> {
>     let $line := <property name="java.naming.security.credentials"
> 	                   value="{ xs:string( 'dGVzdA==' ) }"/>
> 
>     let $debug2 := util:log-system-out( concat( "Credentials XML String: ",
> 		       util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )
> 
>     return $line
> };
> 
> And I still get the erroneous result, with 8 repeated values:
> 
> (Line: 494) Credentials XML String: <property name="java.naming.security.credentials"
>             value="dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA=="/>
> 
> 
> So that means your Binary stuff is off the hook, Adam!  The problem is somewhere else....maybe in
> the query parser or execution engine.
> 
> Changing the line that creates the xml snippet to:
> 
>    let $line := <property name="java.naming.security.credentials"
> 	                  value="{ let $tmp := 'dGVzdA==' return $tmp }"/>
> 
> shows the same issue....8 repeated strings, delimited with a space for the @value attribute.
> 
> But this variant does NOT repeat the values!
> 
> 	let $tmp := 'dGVzdA=='
> 
> 	let $line := <property name="java.naming.security.credentials" value="{ $tmp }"/>
> 
> and neither does this one:
> 
> 	let $tmp := 'dGVzdA=='
> 
>     	let $line := <property name="java.naming.security.credentials"
> 			       value="{ xs:string( 'dGVzdA==' ) }"/>
> 
> Which leads me to believe that the bug is partially position sensitive.  If the creation of the xml
> snippet is the first line of code in the function, then the values get replicated 8 times.  If there
> is any code prior to that line, then it does not replicate.
> 
> I then changed the test function to take a parameter (the string being replicated) and changed the
> calling function to pass in the string:
> 
> So this version:
> 
> declare function common:test( $tmp )
> {
>     let $line := <property name="java.naming.security.credentials" value="{ xs:string( $tmp ) }"/>
> 
>     .....
> };
> 
> replicates the attribute value 8 times (showing the bug), but this one:
> 
> declare function common:test( $tmp )
> {
>     let $line := <property name="java.naming.security.credentials" value="{ $tmp }"/>
> 
>     .....
> };
> 
> does not replicate (no bug!).
> 
> This leads me to believe that the bug is somewhere in how code fragments inside attribute values are
> evaluated.
> 
> Not being very familiar with the xquery parser nor evaluation engine, I can't easily dive into the
> code (which is very complex) to figure out what is going on. I'm hoping that all of these different
> test cases might twig something with you, Wolfgang, since creating a simple test case to replicate
> this is proving difficult.
> 
> .....Andrzej
> 
> 
>> > On 30 April 2011 00:55, Andrzej Jan Taramina <an...@ch...> wrote:
>>> >> Wolfgang:
>>> >>
>>> >> I've hit a very weird error in trunk, that could potentially be very serious.
>>> >>
>>> >> I have some code in a module that looks like this:
>>> >>
>>> >> declare function common:test()
>>> >> {
>>> >>    let $line := <property name="java.naming.security.credentials"
>>> >>                           value="{ util:binary-to-string( xs:base64Binary( 'dGVzdAoK' ) ) }"/>
>>> >>
>>> >>    let $debug2 := util:log-system-out( concat( "Credentials XML: ",
>>> >>                        util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )
>>> >>
>>> >>    return $line
>>> >> };
>>> >>
>>> >> declare function common:get-ldap-connection()  as xs:integer
>>> >> {
>>> >>    let $test := common:test()
>>> >>
>>> >>    let $contextProps :=
>>> >>    <properties>
>>> >>       <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>>> >>       <property name="java.naming.provider.url"
>>> >>                 value="{ common:get-config()/config/ldap/url/text() }"/>
>>> >>       <property name="java.naming.security.authentication" value="simple"/>
>>> >>       <property name="java.naming.security.principal"
>>> >>                 value="{ common:get-config()/config/ldap/adminUser/text() }"/>
>>> >>       <property name="java.naming.security.credentials"
>>> >>                 value="{ util:binary-to-string( xs:base64Binary(
>>> >>                                common:get-config()/config/ldap/adminPswd/text() ) ) }"/>
>>> >>    </properties>
>>> >>
>>> >>    let $ctx := jndi:get-dir-context( $contextProps )
>>> >>
>>> >>    return $ctx
>>> >> };
>>> >>
>>> >> I then have a xquery that includes this module, and does something like this:
>>> >>
>>> >>        let $cnx := common:get-ldap-connection()
>>> >>
>>> >> All works fine if I call this from the sandbox and in the console log I will see the following line
>>> >> produced by the common:test() function:
>>> >>
>>> >> (Line: 494) Credentials XML: <property name="java.naming.security.credentials"
>>> >>                                       value="test&#xA;&#xA;"/>
>>> >>
>>> >>
>>> >> The problem I run into is that when I run this xquery from the scheduler (which is how it's intended
>>> >> to run...it's a batch reporting job), cause then I get the following output in the console log:
>>> >>
>>> >> (Line: 494) Credentials XML: <property name="java.naming.security.credentials" value="test&#xA;&#xA;
>>> >> test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA;
>>> >> test&#xA;&#xA;"/>
>>> >>
>>> >> I get 8 concatenated decoded values in the value attribute!!!!
>>> >>
>>> >> This should never happen!!!!  Of course, in that situation, I fail to get an LDAP connection since
>>> >> the password (the credentials) is a concatenation of 8 copies of the actual password, and so fails,
>>> >> if I remove the call to the test function.  If I leave in the call to the test function, then the
>>> >> correct (non-replicated) password is inserted into the credentials element of the $contextProps
>>> >> variable. If I remove the test function call, then I get the same replication in $contextProps.
>>> >>
>>> >> What is weird is that the error only shows in the one place and is sensitive to order. If I put the
>>> >> call to the test function after the construction of the $contextProps value, then $contextProps gets
>>> >> the repeated value and the test function returns a correct, unrepeated value.
>>> >>
>>> >> I've been trying to create a simple test case to replicate this, but have not yet been successful.
>>> >> It seems I need to run the big batch job, where the included module is 3600 lines long, and the
>>> >> actual xquery is very long and complex as well.
>>> >>
>>> >> But the code snippet that causes this bug is static code in the common:test() function, and should
>>> >> always return the correct result.
>>> >>
>>> >> I'm not sure what is causing this.  Could it be the new Binary Value caching/handling under weird
>>> >> conditions that only happen when running under a scheduled task?  I've never managed to reproduce
>>> >> this when calling xqueries directly (the ldap connection call is made all over the place in our web
>>> >> app for authentication purposes).  Maybe util:binary-to-string() is at fault, but that seems
>>> >> unlikely.  Maybe some of your path wrapper stuff?
>>> >>
>>> >> This exact same code runs just fine as a scheduled task in an older version of trunk (from late
>>> >> summer last year), so it's definitely something new in trunk that has manifested since then.
>>> >>
>>> >> Any ideas on what might cause something this strange?  I has me very worried since this is pretty
>>> >> basic stuff....and thus might cause other things like DB corruption, or incorrect values being
>>> >> written or wrong logic paths being followed.
>>> >>
>>> >> I'll keep trying to create a simple test case that illustrates this, but I think it may not be
>>> >> possible to do so.
>>> >>

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

[Exist-development] Installer failing

[Loren C. <lor...@gm...>]

There appears to be a problem with the installer off of trunk for rev 14481

Commandline

Loren-Cahlanders-MacBook-Pro-2:exist lcahlander$ java -jar installer/eXist-setup-1.5.0dev-rev14481.jar -p ~/lctmp
Installing into directory: /Users/lcahlander/lctmp
[ Starting automated installation ]
java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
	at java.util.Vector.elementAt(Vector.java:427)
	at com.izforge.izpack.installer.AutomatedInstaller.updateInstanceCount(Unknown Source)
	at com.izforge.izpack.installer.AutomatedInstaller.doInstall(Unknown Source)
	at org.exist.izpack.CommandLineInstaller$EXistAutomatedInstaller.run(CommandLineInstaller.java:127)
	at org.exist.izpack.CommandLineInstaller.execute(CommandLineInstaller.java:101)
	at org.exist.izpack.CommandLineInstaller.main(CommandLineInstaller.java:137)
[ Automated installation FAILED! ]
Loren-Cahlanders-MacBook-Pro-2:exist lcahlander$ 

GUI Install

[Exist-development] Friday's teleconference call

[Loren C. <lor...@gm...>]

Dan McCreary, Dave Finton, and I met for lunch today to discuss the eXist documentation project.  Can we use the Friday teleconference call to discuss the eXist documentation project?  I would like to have it an hour earlier, because I have a meeting later that morning.  I will try to have a project plan written up before then.

Cheers,

Loren

[Exist-development] New Triggers

[Patrick B. <pat...@jo...>]

Hi devs,

I've committed my new multi-trigger system into
branches/pbosek/new-triggers-in-trunk. It has XQuery tests that show it
works for everything except copy. I'll probably implement copy in the near
future, but I've got a really tight deadline right now.

Also, for those interested, I've ported the new triggers back to 1.4.x,
located in pbosek/1.4-trunk-triggers, which includes a modification of the
VersioningTrigger. So far my tests show it working quite well. Our software
will be making very heavy use of this code, so within the month I'll be able
to confidently stamp it rock solid. Needless to say, I'm pretty happy this
worked out. Hope it's useful to others!


Cheers,

Patrick

-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Very weird and serious error in trunk!

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

Still happening with the latest fixes (BTree caching)....so it's not related to that.

....A

> More testing on this issue:
> 
> I changed the test function to not use the Binary stuff, so it looks like this:
> 
> declare function common:test()
> {
>     let $line := <property name="java.naming.security.credentials"
> 	                   value="{ xs:string( 'dGVzdA==' ) }"/>
> 
>     let $debug2 := util:log-system-out( concat( "Credentials XML String: ",
> 		       util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )
> 
>     return $line
> };
> 
> And I still get the erroneous result, with 8 repeated values:
> 
> (Line: 494) Credentials XML String: <property name="java.naming.security.credentials"
>             value="dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA=="/>
> 
> 
> So that means your Binary stuff is off the hook, Adam!  The problem is somewhere else....maybe in
> the query parser or execution engine.
> 
> Changing the line that creates the xml snippet to:
> 
>    let $line := <property name="java.naming.security.credentials"
> 	                  value="{ let $tmp := 'dGVzdA==' return $tmp }"/>
> 
> shows the same issue....8 repeated strings, delimited with a space for the @value attribute.
> 
> But this variant does NOT repeat the values!
> 
> 	let $tmp := 'dGVzdA=='
> 
> 	let $line := <property name="java.naming.security.credentials" value="{ $tmp }"/>
> 
> and neither does this one:
> 
> 	let $tmp := 'dGVzdA=='
> 
>     	let $line := <property name="java.naming.security.credentials"
> 			       value="{ xs:string( 'dGVzdA==' ) }"/>
> 
> Which leads me to believe that the bug is partially position sensitive.  If the creation of the xml
> snippet is the first line of code in the function, then the values get replicated 8 times.  If there
> is any code prior to that line, then it does not replicate.
> 
> I then changed the test function to take a parameter (the string being replicated) and changed the
> calling function to pass in the string:
> 
> So this version:
> 
> declare function common:test( $tmp )
> {
>     let $line := <property name="java.naming.security.credentials" value="{ xs:string( $tmp ) }"/>
> 
>     .....
> };
> 
> replicates the attribute value 8 times (showing the bug), but this one:
> 
> declare function common:test( $tmp )
> {
>     let $line := <property name="java.naming.security.credentials" value="{ $tmp }"/>
> 
>     .....
> };
> 
> does not replicate (no bug!).
> 
> This leads me to believe that the bug is somewhere in how code fragments inside attribute values are
> evaluated.
> 
> Not being very familiar with the xquery parser nor evaluation engine, I can't easily dive into the
> code (which is very complex) to figure out what is going on. I'm hoping that all of these different
> test cases might twig something with you, Wolfgang, since creating a simple test case to replicate
> this is proving difficult.
> 
> .....Andrzej
> 
> 
>> On 30 April 2011 00:55, Andrzej Jan Taramina <an...@ch...> wrote:
>>> Wolfgang:
>>>
>>> I've hit a very weird error in trunk, that could potentially be very serious.
>>>
>>> I have some code in a module that looks like this:
>>>
>>> declare function common:test()
>>> {
>>>    let $line := <property name="java.naming.security.credentials"
>>>                           value="{ util:binary-to-string( xs:base64Binary( 'dGVzdAoK' ) ) }"/>
>>>
>>>    let $debug2 := util:log-system-out( concat( "Credentials XML: ",
>>>                        util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )
>>>
>>>    return $line
>>> };
>>>
>>> declare function common:get-ldap-connection()  as xs:integer
>>> {
>>>    let $test := common:test()
>>>
>>>    let $contextProps :=
>>>    <properties>
>>>       <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>>>       <property name="java.naming.provider.url"
>>>                 value="{ common:get-config()/config/ldap/url/text() }"/>
>>>       <property name="java.naming.security.authentication" value="simple"/>
>>>       <property name="java.naming.security.principal"
>>>                 value="{ common:get-config()/config/ldap/adminUser/text() }"/>
>>>       <property name="java.naming.security.credentials"
>>>                 value="{ util:binary-to-string( xs:base64Binary(
>>>                                common:get-config()/config/ldap/adminPswd/text() ) ) }"/>
>>>    </properties>
>>>
>>>    let $ctx := jndi:get-dir-context( $contextProps )
>>>
>>>    return $ctx
>>> };
>>>
>>> I then have a xquery that includes this module, and does something like this:
>>>
>>>        let $cnx := common:get-ldap-connection()
>>>
>>> All works fine if I call this from the sandbox and in the console log I will see the following line
>>> produced by the common:test() function:
>>>
>>> (Line: 494) Credentials XML: <property name="java.naming.security.credentials"
>>>                                       value="test&#xA;&#xA;"/>
>>>
>>>
>>> The problem I run into is that when I run this xquery from the scheduler (which is how it's intended
>>> to run...it's a batch reporting job), cause then I get the following output in the console log:
>>>
>>> (Line: 494) Credentials XML: <property name="java.naming.security.credentials" value="test&#xA;&#xA;
>>> test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA;
>>> test&#xA;&#xA;"/>
>>>
>>> I get 8 concatenated decoded values in the value attribute!!!!
>>>
>>> This should never happen!!!!  Of course, in that situation, I fail to get an LDAP connection since
>>> the password (the credentials) is a concatenation of 8 copies of the actual password, and so fails,
>>> if I remove the call to the test function.  If I leave in the call to the test function, then the
>>> correct (non-replicated) password is inserted into the credentials element of the $contextProps
>>> variable. If I remove the test function call, then I get the same replication in $contextProps.
>>>
>>> What is weird is that the error only shows in the one place and is sensitive to order. If I put the
>>> call to the test function after the construction of the $contextProps value, then $contextProps gets
>>> the repeated value and the test function returns a correct, unrepeated value.
>>>
>>> I've been trying to create a simple test case to replicate this, but have not yet been successful.
>>> It seems I need to run the big batch job, where the included module is 3600 lines long, and the
>>> actual xquery is very long and complex as well.
>>>
>>> But the code snippet that causes this bug is static code in the common:test() function, and should
>>> always return the correct result.
>>>
>>> I'm not sure what is causing this.  Could it be the new Binary Value caching/handling under weird
>>> conditions that only happen when running under a scheduled task?  I've never managed to reproduce
>>> this when calling xqueries directly (the ldap connection call is made all over the place in our web
>>> app for authentication purposes).  Maybe util:binary-to-string() is at fault, but that seems
>>> unlikely.  Maybe some of your path wrapper stuff?
>>>
>>> This exact same code runs just fine as a scheduled task in an older version of trunk (from late
>>> summer last year), so it's definitely something new in trunk that has manifested since then.
>>>
>>> Any ideas on what might cause something this strange?  I has me very worried since this is pretty
>>> basic stuff....and thus might cause other things like DB corruption, or incorrect values being
>>> written or wrong logic paths being followed.
>>>
>>> I'll keep trying to create a simple test case that illustrates this, but I think it may not be
>>> possible to do so.
>>>
>>> Help!
>>>
>>> Thanks!
>>>
>>> --
>>> Andrzej Taramina
>>> Chaeron Corporation: Enterprise System Solutions
>>> http://www.chaeron.com
>>>
>>
>>
>>
> 
> 


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

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Patrick B. <pat...@jo...>]

Ok, I figured it out. Totally my fault *face palm*, sorry guys. Thanks for
the help though.


Cheers,

Patrick

On Thu, May 12, 2011 at 5:54 PM, Patrick Bosek <pat...@jo...>wrote:

> Ok, that makes sense. It appears the actual issue here is that the
> Collection being used in LocalCollection doesn't have a
> CollectionConfiguration, where as it does have one when I run xmldb:store
> operations. I'm still investigating... Any thoughts?
>
>
> On Thu, May 12, 2011 at 5:30 PM, Adam Retter <ad...@ex...> wrote:
>
>> On 12 May 2011 23:04, Patrick Bosek <pat...@jo...> wrote:
>> > Fairly sure:
>> >
>> > from file
>> /exist-trunk/src/org/exist/xquery/functions/xmldb/XMLDBRemove.java
>> >
>> > package org.exist.xquery.functions.xmldb;
>> >
>> > import org.apache.log4j.Logger;
>> > import org.exist.dom.QName;
>> > import org.exist.xquery.Cardinality;
>> > import org.exist.xquery.FunctionSignature;
>> > import org.exist.xquery.XPathException;
>> > import org.exist.xquery.XQueryContext;
>> > import org.exist.xquery.value.AnyURIValue;
>> > import org.exist.xquery.value.FunctionParameterSequenceType;
>> > import org.exist.xquery.value.Sequence;
>> > import org.exist.xquery.value.SequenceType;
>> > import org.exist.xquery.value.Type;
>> > import org.xmldb.api.base.Collection;
>> > import org.xmldb.api.base.Resource;
>> > import org.xmldb.api.base.XMLDBException;
>> > import org.xmldb.api.modules.CollectionManagementService;
>> >
>> > .... (line 78)
>> >
>> > Resource resource = collection.getResource(doc);
>> >                 if (resource == null) {
>> >                     logger.error("Resource " + doc + " not found");
>> >                     throw new XPathException(this, "Resource " + doc + "
>> not
>> > found");
>> >                 }
>> >                 collection.removeResource(resource);
>> >
>> >
>> > Am I missing something?
>>
>> Perhaps. That XMLDB Collection actually maps onto either
>> LocalCollection or RemoteCollection in org.exist.xmldb - so if you
>> look at removing a resource for example in LocalCollection (line 612)
>> then it calls org.exist.collections.Collection.removeResource (line
>> 745), and the trigger is called (line 779 ands 786).
>> RemoteCollection should function in a simialr manner, ignoring the
>> XML-RPC middle layer, it will resolve down to calls on
>> org.exist.collections.Collection.
>>
>> The only reason a Trigger should not be called for xmldb:remove, would
>> be if you are already operating in a trigger environment when invoking
>> that function i.e. an XQueryTrigger.
>>
>> > Cheers,
>> >
>> > Patrick
>> >
>> >
>> > On Thu, May 12, 2011 at 4:55 PM, Adam Retter <ad...@ex...> wrote:
>> >>
>> >> Erm, Are you sure that is the case?
>> >>
>> >> XMLDB module functions should call the xmldb either local or remote
>> >> implementation, but at some point that code has to enter into the
>> >> internal API which is where the trigger should be effected from?
>> >>
>> >> On 12 May 2011 22:41, Patrick Bosek <pat...@jo...> wrote:
>> >> > Hello dev team,
>> >> >
>> >> > I'm making good progress on my upgrade to the triggers in eXist, but
>> >> > I've
>> >> > hit a bump and need some guidance. I've found that xmldb:remove uses
>> >> > "org.xmldb.api.base.Collection" to remove the resource, there by
>> never
>> >> > hitting the trigger code. So, after looking through it I figured I'd
>> >> > change
>> >> > the xmldb:remove to use the remove functions in
>> >> > org.exist.collections.Collection. Is this ok? Or is there another
>> method
>> >> > you
>> >> > would prefer I use?
>> >> >
>> >> >
>> >> > Cheers,
>> >> >
>> >> > --
>> >> > Patrick Bosek
>> >> > Jorsek Software
>> >> > Cell (585) 820 9634
>> >> > Office (585) 239 6060
>> >> > Jorsek.com
>> >> >
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------------
>> >> > Achieve unprecedented app performance and reliability
>> >> > What every C/C++ and Fortran developer should know.
>> >> > Learn how Intel has extended the reach of its next-generation tools
>> >> > to help boost performance applications - inlcuding clusters.
>> >> > http://p.sf.net/sfu/intel-dev2devmay
>> >> > _______________________________________________
>> >> > 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
>> >
>> >
>> >
>> > --
>> > Patrick Bosek
>> > Jorsek Software
>> > Cell (585) 820 9634
>> > Office (585) 239 6060
>> > Jorsek.com
>> >
>> >
>>
>>
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>>
>
>
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (585) 239 6060
> Jorsek.com
>
>


-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Patrick B. <pat...@jo...>]

Ok, that makes sense. It appears the actual issue here is that the
Collection being used in LocalCollection doesn't have a
CollectionConfiguration, where as it does have one when I run xmldb:store
operations. I'm still investigating... Any thoughts?

On Thu, May 12, 2011 at 5:30 PM, Adam Retter <ad...@ex...> wrote:

> On 12 May 2011 23:04, Patrick Bosek <pat...@jo...> wrote:
> > Fairly sure:
> >
> > from file
> /exist-trunk/src/org/exist/xquery/functions/xmldb/XMLDBRemove.java
> >
> > package org.exist.xquery.functions.xmldb;
> >
> > import org.apache.log4j.Logger;
> > import org.exist.dom.QName;
> > import org.exist.xquery.Cardinality;
> > import org.exist.xquery.FunctionSignature;
> > import org.exist.xquery.XPathException;
> > import org.exist.xquery.XQueryContext;
> > import org.exist.xquery.value.AnyURIValue;
> > import org.exist.xquery.value.FunctionParameterSequenceType;
> > import org.exist.xquery.value.Sequence;
> > import org.exist.xquery.value.SequenceType;
> > import org.exist.xquery.value.Type;
> > import org.xmldb.api.base.Collection;
> > import org.xmldb.api.base.Resource;
> > import org.xmldb.api.base.XMLDBException;
> > import org.xmldb.api.modules.CollectionManagementService;
> >
> > .... (line 78)
> >
> > Resource resource = collection.getResource(doc);
> >                 if (resource == null) {
> >                     logger.error("Resource " + doc + " not found");
> >                     throw new XPathException(this, "Resource " + doc + "
> not
> > found");
> >                 }
> >                 collection.removeResource(resource);
> >
> >
> > Am I missing something?
>
> Perhaps. That XMLDB Collection actually maps onto either
> LocalCollection or RemoteCollection in org.exist.xmldb - so if you
> look at removing a resource for example in LocalCollection (line 612)
> then it calls org.exist.collections.Collection.removeResource (line
> 745), and the trigger is called (line 779 ands 786).
> RemoteCollection should function in a simialr manner, ignoring the
> XML-RPC middle layer, it will resolve down to calls on
> org.exist.collections.Collection.
>
> The only reason a Trigger should not be called for xmldb:remove, would
> be if you are already operating in a trigger environment when invoking
> that function i.e. an XQueryTrigger.
>
> > Cheers,
> >
> > Patrick
> >
> >
> > On Thu, May 12, 2011 at 4:55 PM, Adam Retter <ad...@ex...> wrote:
> >>
> >> Erm, Are you sure that is the case?
> >>
> >> XMLDB module functions should call the xmldb either local or remote
> >> implementation, but at some point that code has to enter into the
> >> internal API which is where the trigger should be effected from?
> >>
> >> On 12 May 2011 22:41, Patrick Bosek <pat...@jo...> wrote:
> >> > Hello dev team,
> >> >
> >> > I'm making good progress on my upgrade to the triggers in eXist, but
> >> > I've
> >> > hit a bump and need some guidance. I've found that xmldb:remove uses
> >> > "org.xmldb.api.base.Collection" to remove the resource, there by never
> >> > hitting the trigger code. So, after looking through it I figured I'd
> >> > change
> >> > the xmldb:remove to use the remove functions in
> >> > org.exist.collections.Collection. Is this ok? Or is there another
> method
> >> > you
> >> > would prefer I use?
> >> >
> >> >
> >> > Cheers,
> >> >
> >> > --
> >> > Patrick Bosek
> >> > Jorsek Software
> >> > Cell (585) 820 9634
> >> > Office (585) 239 6060
> >> > Jorsek.com
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Achieve unprecedented app performance and reliability
> >> > What every C/C++ and Fortran developer should know.
> >> > Learn how Intel has extended the reach of its next-generation tools
> >> > to help boost performance applications - inlcuding clusters.
> >> > http://p.sf.net/sfu/intel-dev2devmay
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> > --
> > Patrick Bosek
> > Jorsek Software
> > Cell (585) 820 9634
> > Office (585) 239 6060
> > Jorsek.com
> >
> >
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>



-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

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

On 12 May 2011 23:04, Patrick Bosek <pat...@jo...> wrote:
> Fairly sure:
>
> from file /exist-trunk/src/org/exist/xquery/functions/xmldb/XMLDBRemove.java
>
> package org.exist.xquery.functions.xmldb;
>
> import org.apache.log4j.Logger;
> import org.exist.dom.QName;
> import org.exist.xquery.Cardinality;
> import org.exist.xquery.FunctionSignature;
> import org.exist.xquery.XPathException;
> import org.exist.xquery.XQueryContext;
> import org.exist.xquery.value.AnyURIValue;
> import org.exist.xquery.value.FunctionParameterSequenceType;
> import org.exist.xquery.value.Sequence;
> import org.exist.xquery.value.SequenceType;
> import org.exist.xquery.value.Type;
> import org.xmldb.api.base.Collection;
> import org.xmldb.api.base.Resource;
> import org.xmldb.api.base.XMLDBException;
> import org.xmldb.api.modules.CollectionManagementService;
>
> .... (line 78)
>
> Resource resource = collection.getResource(doc);
>                 if (resource == null) {
>                     logger.error("Resource " + doc + " not found");
>                     throw new XPathException(this, "Resource " + doc + " not
> found");
>                 }
>                 collection.removeResource(resource);
>
>
> Am I missing something?

Perhaps. That XMLDB Collection actually maps onto either
LocalCollection or RemoteCollection in org.exist.xmldb - so if you
look at removing a resource for example in LocalCollection (line 612)
then it calls org.exist.collections.Collection.removeResource (line
745), and the trigger is called (line 779 ands 786).
RemoteCollection should function in a simialr manner, ignoring the
XML-RPC middle layer, it will resolve down to calls on
org.exist.collections.Collection.

The only reason a Trigger should not be called for xmldb:remove, would
be if you are already operating in a trigger environment when invoking
that function i.e. an XQueryTrigger.

> Cheers,
>
> Patrick
>
>
> On Thu, May 12, 2011 at 4:55 PM, Adam Retter <ad...@ex...> wrote:
>>
>> Erm, Are you sure that is the case?
>>
>> XMLDB module functions should call the xmldb either local or remote
>> implementation, but at some point that code has to enter into the
>> internal API which is where the trigger should be effected from?
>>
>> On 12 May 2011 22:41, Patrick Bosek <pat...@jo...> wrote:
>> > Hello dev team,
>> >
>> > I'm making good progress on my upgrade to the triggers in eXist, but
>> > I've
>> > hit a bump and need some guidance. I've found that xmldb:remove uses
>> > "org.xmldb.api.base.Collection" to remove the resource, there by never
>> > hitting the trigger code. So, after looking through it I figured I'd
>> > change
>> > the xmldb:remove to use the remove functions in
>> > org.exist.collections.Collection. Is this ok? Or is there another method
>> > you
>> > would prefer I use?
>> >
>> >
>> > Cheers,
>> >
>> > --
>> > Patrick Bosek
>> > Jorsek Software
>> > Cell (585) 820 9634
>> > Office (585) 239 6060
>> > Jorsek.com
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Achieve unprecedented app performance and reliability
>> > What every C/C++ and Fortran developer should know.
>> > Learn how Intel has extended the reach of its next-generation tools
>> > to help boost performance applications - inlcuding clusters.
>> > http://p.sf.net/sfu/intel-dev2devmay
>> > _______________________________________________
>> > 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
>
>
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (585) 239 6060
> Jorsek.com
>
>



-- 
Adam Retter

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

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Patrick B. <pat...@jo...>]

Are you referring to the eval function in
org.exist.xquery.functions.xmldb.XMLDBAbstractCollectionManipulator? Because
that appears to call the code I referenced:

line 168:
evalWithCollection(collection, args, contextSequence);


Cheers,

Patrick

On Thu, May 12, 2011 at 5:09 PM, Dannes Wessels <da...@ex...> wrote:

>
> On 12 May 2011, at 23:04 , Patrick Bosek wrote:
>
> > Resource resource = collection.getResource(doc);
> >                 if (resource == null) {
> >                     logger.error("Resource " + doc + " not found");
> >                     throw new XPathException(this, "Resource " + doc + "
> not found");
> >                 }
> >                 collection.removeResource(resource);
> >
> >
> > Am I missing something?
>
> the actual work is done elsewhere....
>
> anyway before committing code, I'd 'appreciate' if you have your code
> changed reviewed, e.g. by adam or dmitiry
>
> thx
>
> Dannes
>
>
> --
> Dannes Wessels
> eXist-db Open Source Native XML Database
> e: da...@ex...
> w: http://www.exist-db.org
>
>
>
>
>
>
>


-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Dannes W. <da...@ex...>]

On 12 May 2011, at 23:06 , Patrick Bosek wrote:

> I'm not sure. I start the database with bin/startup.sh, then I run my test cases through XQuery as is described in the documentation.

you refer to newly added documentation, right?

myself, I run the test queries as part of the junit test suite, there is no bin/startup.sh involved for me?

regards

Dannes


--
Dannes Wessels
eXist-db Open Source Native XML Database
e: da...@ex...
w: http://www.exist-db.org 

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Dannes W. <da...@ex...>]

On 12 May 2011, at 23:04 , Patrick Bosek wrote:

> Resource resource = collection.getResource(doc);
>                 if (resource == null) {
>                     logger.error("Resource " + doc + " not found");
>                     throw new XPathException(this, "Resource " + doc + " not found");
>                 }
>                 collection.removeResource(resource);
> 
> 
> Am I missing something?

the actual work is done elsewhere....

anyway before committing code, I'd 'appreciate' if you have your code changed reviewed, e.g. by adam or dmitiry

thx

Dannes


--
Dannes Wessels
eXist-db Open Source Native XML Database
e: da...@ex...
w: http://www.exist-db.org 

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Patrick B. <pat...@jo...>]

I'm not sure. I start the database with bin/startup.sh, then I run my test
cases through XQuery as is described in the documentation.

On Thu, May 12, 2011 at 5:05 PM, Dannes Wessels <da...@ex...> wrote:

> are you referring to a 'embedded' situation or a remote one?
>
> for the remote situation, then there is probably something missing in the
> xmlrpc code......
> D.
>
>
> On 12 May 2011, at 22:41 , Patrick Bosek wrote:
>
> > I'm making good progress on my upgrade to the triggers in eXist, but I've
> hit a bump and need some guidance. I've found that xmldb:remove uses
> "org.xmldb.api.base.Collection" to remove the resource, there by never
> hitting the trigger code. So, after looking through it I figured I'd change
> the xmldb:remove to use the remove functions in
> org.exist.collections.Collection. Is this ok? Or is there another method you
> would prefer I use?
>
> --
> Dannes Wessels
> eXist-db Open Source Native XML Database
> e: da...@ex...
> w: http://www.exist-db.org
>
>
>
>
>
>
>


-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Dannes W. <da...@ex...>]

are you referring to a 'embedded' situation or a remote one?

for the remote situation, then there is probably something missing in the xmlrpc code......
D.


On 12 May 2011, at 22:41 , Patrick Bosek wrote:

> I'm making good progress on my upgrade to the triggers in eXist, but I've hit a bump and need some guidance. I've found that xmldb:remove uses "org.xmldb.api.base.Collection" to remove the resource, there by never hitting the trigger code. So, after looking through it I figured I'd change the xmldb:remove to use the remove functions in org.exist.collections.Collection. Is this ok? Or is there another method you would prefer I use?

--
Dannes Wessels
eXist-db Open Source Native XML Database
e: da...@ex...
w: http://www.exist-db.org 

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

[Patrick B. <pat...@jo...>]

Fairly sure:

from file /exist-trunk/src/org/exist/xquery/functions/xmldb/XMLDBRemove.java

package org.exist.xquery.functions.xmldb;

import org.apache.log4j.Logger;
import org.exist.dom.QName;
import org.exist.xquery.Cardinality;
import org.exist.xquery.FunctionSignature;
import org.exist.xquery.XPathException;
import org.exist.xquery.XQueryContext;
import org.exist.xquery.value.AnyURIValue;
import org.exist.xquery.value.FunctionParameterSequenceType;
import org.exist.xquery.value.Sequence;
import org.exist.xquery.value.SequenceType;
import org.exist.xquery.value.Type;
import org.xmldb.api.base.Collection;
import org.xmldb.api.base.Resource;
import org.xmldb.api.base.XMLDBException;
import org.xmldb.api.modules.CollectionManagementService;

.... (line 78)

Resource resource = collection.getResource(doc);
                if (resource == null) {
                    logger.error("Resource " + doc + " not found");
                    throw new XPathException(this, "Resource " + doc + " not
found");
                }
                collection.removeResource(resource);


Am I missing something?

Cheers,

Patrick


On Thu, May 12, 2011 at 4:55 PM, Adam Retter <ad...@ex...> wrote:

> Erm, Are you sure that is the case?
>
> XMLDB module functions should call the xmldb either local or remote
> implementation, but at some point that code has to enter into the
> internal API which is where the trigger should be effected from?
>
> On 12 May 2011 22:41, Patrick Bosek <pat...@jo...> wrote:
> > Hello dev team,
> >
> > I'm making good progress on my upgrade to the triggers in eXist, but I've
> > hit a bump and need some guidance. I've found that xmldb:remove uses
> > "org.xmldb.api.base.Collection" to remove the resource, there by never
> > hitting the trigger code. So, after looking through it I figured I'd
> change
> > the xmldb:remove to use the remove functions in
> > org.exist.collections.Collection. Is this ok? Or is there another method
> you
> > would prefer I use?
> >
> >
> > Cheers,
> >
> > --
> > Patrick Bosek
> > Jorsek Software
> > Cell (585) 820 9634
> > Office (585) 239 6060
> > Jorsek.com
> >
> >
> >
> ------------------------------------------------------------------------------
> > Achieve unprecedented app performance and reliability
> > What every C/C++ and Fortran developer should know.
> > Learn how Intel has extended the reach of its next-generation tools
> > to help boost performance applications - inlcuding clusters.
> > http://p.sf.net/sfu/intel-dev2devmay
> > _______________________________________________
> > 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
>



-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Need Guidance :: Change to xmldb:remove()

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

Erm, Are you sure that is the case?

XMLDB module functions should call the xmldb either local or remote
implementation, but at some point that code has to enter into the
internal API which is where the trigger should be effected from?

On 12 May 2011 22:41, Patrick Bosek <pat...@jo...> wrote:
> Hello dev team,
>
> I'm making good progress on my upgrade to the triggers in eXist, but I've
> hit a bump and need some guidance. I've found that xmldb:remove uses
> "org.xmldb.api.base.Collection" to remove the resource, there by never
> hitting the trigger code. So, after looking through it I figured I'd change
> the xmldb:remove to use the remove functions in
> org.exist.collections.Collection. Is this ok? Or is there another method you
> would prefer I use?
>
>
> Cheers,
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (585) 239 6060
> Jorsek.com
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> 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

[Exist-development] Need Guidance :: Change to xmldb:remove()

[Patrick B. <pat...@jo...>]

Hello dev team,

I'm making good progress on my upgrade to the triggers in eXist, but I've
hit a bump and need some guidance. I've found that xmldb:remove uses
"org.xmldb.api.base.Collection" to remove the resource, there by never
hitting the trigger code. So, after looking through it I figured I'd change
the xmldb:remove to use the remove functions in
org.exist.collections.Collection. Is this ok? Or is there another method you
would prefer I use?


Cheers,

-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (585) 239 6060
Jorsek.com

Re: [Exist-development] Very weird and serious error in trunk!

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

More testing on this issue:

I changed the test function to not use the Binary stuff, so it looks like this:

declare function common:test()
{
    let $line := <property name="java.naming.security.credentials"
	                   value="{ xs:string( 'dGVzdA==' ) }"/>

    let $debug2 := util:log-system-out( concat( "Credentials XML String: ",
		       util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )

    return $line
};

And I still get the erroneous result, with 8 repeated values:

(Line: 494) Credentials XML String: <property name="java.naming.security.credentials"
            value="dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA== dGVzdA=="/>


So that means your Binary stuff is off the hook, Adam!  The problem is somewhere else....maybe in
the query parser or execution engine.

Changing the line that creates the xml snippet to:

   let $line := <property name="java.naming.security.credentials"
	                  value="{ let $tmp := 'dGVzdA==' return $tmp }"/>

shows the same issue....8 repeated strings, delimited with a space for the @value attribute.

But this variant does NOT repeat the values!

	let $tmp := 'dGVzdA=='

	let $line := <property name="java.naming.security.credentials" value="{ $tmp }"/>

and neither does this one:

	let $tmp := 'dGVzdA=='

    	let $line := <property name="java.naming.security.credentials"
			       value="{ xs:string( 'dGVzdA==' ) }"/>

Which leads me to believe that the bug is partially position sensitive.  If the creation of the xml
snippet is the first line of code in the function, then the values get replicated 8 times.  If there
is any code prior to that line, then it does not replicate.

I then changed the test function to take a parameter (the string being replicated) and changed the
calling function to pass in the string:

So this version:

declare function common:test( $tmp )
{
    let $line := <property name="java.naming.security.credentials" value="{ xs:string( $tmp ) }"/>

    .....
};

replicates the attribute value 8 times (showing the bug), but this one:

declare function common:test( $tmp )
{
    let $line := <property name="java.naming.security.credentials" value="{ $tmp }"/>

    .....
};

does not replicate (no bug!).

This leads me to believe that the bug is somewhere in how code fragments inside attribute values are
evaluated.

Not being very familiar with the xquery parser nor evaluation engine, I can't easily dive into the
code (which is very complex) to figure out what is going on. I'm hoping that all of these different
test cases might twig something with you, Wolfgang, since creating a simple test case to replicate
this is proving difficult.

.....Andrzej


> On 30 April 2011 00:55, Andrzej Jan Taramina <an...@ch...> wrote:
>> Wolfgang:
>>
>> I've hit a very weird error in trunk, that could potentially be very serious.
>>
>> I have some code in a module that looks like this:
>>
>> declare function common:test()
>> {
>>    let $line := <property name="java.naming.security.credentials"
>>                           value="{ util:binary-to-string( xs:base64Binary( 'dGVzdAoK' ) ) }"/>
>>
>>    let $debug2 := util:log-system-out( concat( "Credentials XML: ",
>>                        util:serialize(  $line, "method=xml media-type=text/xml indent=yes" ) ) )
>>
>>    return $line
>> };
>>
>> declare function common:get-ldap-connection()  as xs:integer
>> {
>>    let $test := common:test()
>>
>>    let $contextProps :=
>>    <properties>
>>       <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
>>       <property name="java.naming.provider.url"
>>                 value="{ common:get-config()/config/ldap/url/text() }"/>
>>       <property name="java.naming.security.authentication" value="simple"/>
>>       <property name="java.naming.security.principal"
>>                 value="{ common:get-config()/config/ldap/adminUser/text() }"/>
>>       <property name="java.naming.security.credentials"
>>                 value="{ util:binary-to-string( xs:base64Binary(
>>                                common:get-config()/config/ldap/adminPswd/text() ) ) }"/>
>>    </properties>
>>
>>    let $ctx := jndi:get-dir-context( $contextProps )
>>
>>    return $ctx
>> };
>>
>> I then have a xquery that includes this module, and does something like this:
>>
>>        let $cnx := common:get-ldap-connection()
>>
>> All works fine if I call this from the sandbox and in the console log I will see the following line
>> produced by the common:test() function:
>>
>> (Line: 494) Credentials XML: <property name="java.naming.security.credentials"
>>                                       value="test&#xA;&#xA;"/>
>>
>>
>> The problem I run into is that when I run this xquery from the scheduler (which is how it's intended
>> to run...it's a batch reporting job), cause then I get the following output in the console log:
>>
>> (Line: 494) Credentials XML: <property name="java.naming.security.credentials" value="test&#xA;&#xA;
>> test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA; test&#xA;&#xA;
>> test&#xA;&#xA;"/>
>>
>> I get 8 concatenated decoded values in the value attribute!!!!
>>
>> This should never happen!!!!  Of course, in that situation, I fail to get an LDAP connection since
>> the password (the credentials) is a concatenation of 8 copies of the actual password, and so fails,
>> if I remove the call to the test function.  If I leave in the call to the test function, then the
>> correct (non-replicated) password is inserted into the credentials element of the $contextProps
>> variable. If I remove the test function call, then I get the same replication in $contextProps.
>>
>> What is weird is that the error only shows in the one place and is sensitive to order. If I put the
>> call to the test function after the construction of the $contextProps value, then $contextProps gets
>> the repeated value and the test function returns a correct, unrepeated value.
>>
>> I've been trying to create a simple test case to replicate this, but have not yet been successful.
>> It seems I need to run the big batch job, where the included module is 3600 lines long, and the
>> actual xquery is very long and complex as well.
>>
>> But the code snippet that causes this bug is static code in the common:test() function, and should
>> always return the correct result.
>>
>> I'm not sure what is causing this.  Could it be the new Binary Value caching/handling under weird
>> conditions that only happen when running under a scheduled task?  I've never managed to reproduce
>> this when calling xqueries directly (the ldap connection call is made all over the place in our web
>> app for authentication purposes).  Maybe util:binary-to-string() is at fault, but that seems
>> unlikely.  Maybe some of your path wrapper stuff?
>>
>> This exact same code runs just fine as a scheduled task in an older version of trunk (from late
>> summer last year), so it's definitely something new in trunk that has manifested since then.
>>
>> Any ideas on what might cause something this strange?  I has me very worried since this is pretty
>> basic stuff....and thus might cause other things like DB corruption, or incorrect values being
>> written or wrong logic paths being followed.
>>
>> I'll keep trying to create a simple test case that illustrates this, but I think it may not be
>> possible to do so.
>>
>> Help!
>>
>> Thanks!
>>
>> --
>> Andrzej Taramina
>> Chaeron Corporation: Enterprise System Solutions
>> http://www.chaeron.com
>>
> 
> 
> 


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

Re: [Exist-development] [Teleconf] Any takers?

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

We usually do it, if someone says they have something to discuss... I
had not heard anything so I assumed it wasnt on.

On 6 May 2011 17:02, Patrick Bosek <pat...@jo...> wrote:
> We doing a Teleconf today? I'm ready!
>
> On Fri, Apr 29, 2011 at 7:29 AM, Adam Retter <ad...@ex...> wrote:
>>
>> Does anyone want to speak, discuss a topic or ask questions in a
>> Teleconference this evening at 5pm CEST?
>>
>> Thanks Adam.
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>
>
> --
> Patrick Bosek
> Jorsek Software
> Cell (585) 820 9634
> Office (585) 239 6060
> Jorsek.com
>
>



-- 
Adam Retter

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