Nabble - Jackrabbit - Dev

[jira] Updated: (JCR-1691) Includes new (old) mimetypes that OpenOfficeTextExtractor can handle

2008-07-24T12:09:32Z

[ https://issues.apache.org/jira/browse/JCR-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leslie H. Watter updated JCR-1691:
----------------------------------

Attachment: OpenOfficeTextExtractor-mimetype.patch

patch file to add mimetypes supported.

> Includes new (old) mimetypes that OpenOfficeTextExtractor can handle
> --------------------------------------------------------------------
>
> Key: JCR-1691
> URL: https://issues.apache.org/jira/browse/JCR-1691
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-text-extractors
> Affects Versions: core 1.4.5
> Environment: OS: Linux Debian kernel 2.6.18
> java version "1.5.0_14"
> Reporter: Leslie H. Watter
> Priority: Trivial
> Attachments: OpenOfficeTextExtractor-mimetype.patch
>
>
> The following patch adds the old openoffice (1.0 version) mimetypes to have their contents extracted.
> I've tested with simple files and it worked here.
> $ cat OpenOfficeTextExtractor-mimetype.patch
> --- jackrabbit-1.4/jackrabbit-text-extractors/src/main/java/org/apache/jackrabbit/extractor/OpenOfficeTextExtractor.java 2007-12-19 12:57:58.000000000 -0200
> +++ jackrabbit-1.4-modified/jackrabbit-text-extractors/src/main/java/org/apache/jackrabbit/extractor/OpenOfficeTextExtractor.java 2008-07-24 15:01:08.000000000 -0300
> @@ -54,7 +54,11 @@
> "application/vnd.oasis.opendocument.graphics",
> "application/vnd.oasis.opendocument.presentation",
> "application/vnd.oasis.opendocument.spreadsheet",
> - "application/vnd.oasis.opendocument.text"});
> + "application/vnd.oasis.opendocument.text",
> + "application/vnd.sun.xml.calc",
> + "application/vnd.sun.xml.draw",
> + "application/vnd.sun.xml.impress",
> + "application/vnd.sun.xml.writer"});
> }
> //-------------------------------------------------------< TextExtractor >

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1691) Includes new (old) mimetypes that OpenOfficeTextExtractor can handle

2008-07-24T11:11:31Z

Includes new (old) mimetypes that OpenOfficeTextExtractor can handle
--------------------------------------------------------------------

Key: JCR-1691
URL: https://issues.apache.org/jira/browse/JCR-1691
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-text-extractors
Affects Versions: core 1.4.5
Environment: OS: Linux Debian kernel 2.6.18
java version "1.5.0_14"

Reporter: Leslie H. Watter
Priority: Trivial

The following patch adds the old openoffice (1.0 version) mimetypes to have their contents extracted.
I've tested with simple files and it worked here.

$ cat OpenOfficeTextExtractor-mimetype.patch
--- jackrabbit-1.4/jackrabbit-text-extractors/src/main/java/org/apache/jackrabbit/extractor/OpenOfficeTextExtractor.java 2007-12-19 12:57:58.000000000 -0200
+++ jackrabbit-1.4-modified/jackrabbit-text-extractors/src/main/java/org/apache/jackrabbit/extractor/OpenOfficeTextExtractor.java 2008-07-24 15:01:08.000000000 -0300
@@ -54,7 +54,11 @@
"application/vnd.oasis.opendocument.graphics",
"application/vnd.oasis.opendocument.presentation",
"application/vnd.oasis.opendocument.spreadsheet",
- "application/vnd.oasis.opendocument.text"});
+ "application/vnd.oasis.opendocument.text",
+ "application/vnd.sun.xml.calc",
+ "application/vnd.sun.xml.draw",
+ "application/vnd.sun.xml.impress",
+ "application/vnd.sun.xml.writer"});
}

//-------------------------------------------------------< TextExtractor >

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1632) Mixin type loss

2008-07-24T09:55:31Z

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616533#action_12616533 ]

Grégory Joseph commented on JCR-1632:
-------------------------------------

wow that'd be awesome :)

> Mixin type loss
> ---------------
>
> Key: JCR-1632
> URL: https://issues.apache.org/jira/browse/JCR-1632
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.4, 1.5
> Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
> Reporter: Frederic Laugier
> Fix For: core 1.4.6
>
> Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1216) Unreferenced sessions should get garbage collected

2008-07-24T08:15:31Z

[ https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616500#action_12616500 ]

Thomas Mueller commented on JCR-1216:
-------------------------------------

The problem seems to be TransientRepository.session, which is a HashSet.

> Unreferenced sessions should get garbage collected
> --------------------------------------------------
>
> Key: JCR-1216
> URL: https://issues.apache.org/jira/browse/JCR-1216
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Thomas Mueller
>
> If an application opens many sessions and doesn't close them, they are never garbage collected. After some time, the virtual machine will run out of memory. This code will run out of memory after a few thousand logins:
> Repository rep = new TransientRepository();
> for (int i = 0; ; i++) {
> rep.login(new SimpleCredentials("", new char[0]));
> }
> Using a finalizer to close SessionImpl doesn't work, because it seems there are references from the (hard referenced part of the cache) to the SessionImpl objects. Maybe it is possible to remove those references, or change them to weak references.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1632) Mixin type loss

2008-07-24T07:37:31Z

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-1632:
-------------------------------

Fix Version/s: (was: 1.5)
core 1.4.6

No problem. Merged to the 1.4 branch in revision 679425. Would you like us to make an official jackrabbit-core 1.4.6 release with this fix?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Component releases, proposed solution

2008-07-24T07:20:40Z

Hi,

>> If done correctly, major new development can be done in the trunk
>> without risk.
>
> Sure, if it only concerns a single location or limited set of locations. If
> it touches multiple places, this is not that easy.

USE_DATA_STORE is used in multiple places, I don't think it's a big
problem. And at some point the setting can be removed (I think it
could be removed by now).

> I basically like the idea but have my reservations with respect to system
> property use: It makes it difficult in embedded situations and even almost
> makes it impossible to use in app server or servlet container environments.

This system property is only enabled for testing. If disabled by
default, it can be enabled to test an unreleased feature. If enabled
by default, it can be used as a 'kill switch' to test if this
functionality is responsible for a problem. I don't see a use case
where you want to start multiple repositories with different settings.

> For example: you want to have two repositories in the same Java VM, one with
> and one without data store....

I don't see a use case for that currently. The system property is not
something that people need to or should use (unless they want to
explicitly test).

> If is really just for testing, a "public" field is bad, because this quickly
> becomes (de-facto) API. And a branch may still be better suited.

It is a final field, and initialized only once. The system property is
not final, but if clearly documented I don't think there is a risk
people use it in production. This flag is used instead of branching,
and given the disadvantages of branching I think it is worth thinking
about it.

> Probably better -- also for visibility -- would be to have a functionality
> to provide this kind of setup as part of the Repository descriptors.

In that case there is a bigger risk that people use it in production I
think. Also, it couldn't be used in all components: only in those that
have access to the repository.

> Maybe the use case is slightly wrong in that the InternalValue
> should just use a "store", which in turn either uses the new data store code
> or the old code and has to be setup somehow)

It is doing that: it is eighter using BLOBValue (the old mechanism) or
BLOBIn* (the new mechanism). InternalValue acts as the factory. Of
course you could add another class that acts as the factory, but it
wouldn't really simplify things.

Regards,
Thomas

[jira] Commented: (JCR-1632) Mixin type loss

2008-07-24T07:15:33Z

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616484#action_12616484 ]

Grégory Joseph commented on JCR-1632:
-------------------------------------

Any chance this could be backported to 1.4 ?

> Mixin type loss
> ---------------
>
> Key: JCR-1632
> URL: https://issues.apache.org/jira/browse/JCR-1632
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.4, 1.5
> Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
> Reporter: Frederic Laugier
> Fix For: 1.5
>
> Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1690) PM - Simple vs. Bundle - mixin removal handling

2008-07-24T05:35:31Z

[ https://issues.apache.org/jira/browse/JCR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guggisberg resolved JCR-1690.
------------------------------------

Resolution: Duplicate
Fix Version/s: 1.5

resolving as duplicate of JCR-1632 which i just fixed.

> PM - Simple vs. Bundle - mixin removal handling
> -----------------------------------------------
>
> Key: JCR-1690
> URL: https://issues.apache.org/jira/browse/JCR-1690
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: core 1.4.5
> Reporter: Jan Haderka
> Fix For: 1.5
>
>
> Following code (assuming node had mixin mix:versionable before):
> node.removeMixin("mix:versionable");
> node.save();
> leads to difference in stored data based on PM used.
> If you perform the operation above and restart your repository
> call to:
> node.isMixinType("mix:versionable");
> will return false after restart in both cases, but
> doing:
> hasMixin(node, "mix:versionable");
> will return true when repository is using bundled PM. The hasMixin()
> method just iterates over all values of jcr:mixinTypes property:
> public static void hasMixin(Node node, String mixin) {
> try {
> Value[] vals = node.getProperty("jcr:mixinTypes").getValues();
> for (int i = 0; i < vals.length; i++) {
> log.debug(vals[i].getString());
> if (mixin.equals(vals[i].getString())) {
> return true;
> }
> }
> } catch (PathNotFoundException e) {
> // property not found == can't contain anything
> return false;
> }
> return false;
> }
> I think the difference is caused by following code (JR 1.4.5) in
> AbstractBundledPersistenceManager (which doesn't seem to have equivalent
> in simple PM)
> 557 // skip primaryType pr mixinTypes properties
> 558 if (id.getName().equals(QName.JCR_PRIMARYTYPE)
> 559 || id.getName().equals(QName.JCR_MIXINTYPES)
> 560 || id.getName().equals(QName.JCR_UUID)) {
> 561 continue;
> 562 }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1632) Mixin type loss

2008-07-24T05:35:31Z

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guggisberg updated JCR-1632:
-----------------------------------

Fix Version/s: 1.5

> Mixin type loss
> ---------------
>
> Key: JCR-1632
> URL: https://issues.apache.org/jira/browse/JCR-1632
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.4, 1.5
> Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
> Reporter: Frederic Laugier
> Fix For: 1.5
>
> Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1632) Mixin type loss

2008-07-24T05:33:31Z

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guggisberg resolved JCR-1632.
------------------------------------

Resolution: Fixed

fixed in svn r 679389

> Mixin type loss
> ---------------
>
> Key: JCR-1632
> URL: https://issues.apache.org/jira/browse/JCR-1632
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.4, 1.5
> Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
> Reporter: Frederic Laugier
> Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Component releases, proposed solution

2008-07-24T04:16:02Z

Hi,

On Wed, Jul 23, 2008 at 9:35 AM, Felix Meschberger <fmeschbe@...> wrote:
> As corrolary to these notes, I would add (yes these will be controversial, I
> know):
>
> * Branches are used for development and not for releases.
> * Releases are (almost) only cut from trunk
> * In case of an important bugfix to be applied to an old
> release, a branch will be created from the respective
> release tag [...]

-1 I'm more a fan of release branches than development branches. Why?

a) It makes it easy to produce patch releases containing just bug
fixes. Such maintenance releases are important as they can be easily
applied in production with low risk of regressions and zero need for
configuration changes.

b) Release branches only require "one-way merging" from trunk. This is
quite simple and pretty well supported by Subversion. Development
branches however require "two-way merging", first to keep up with
other changes in trunk and then to merge changes back to trunk. The
merge tracking feature in Subversion 1.5 makes this easier, but it's
still tricky.

c) I think it's important that we have all development happening in
the same tree. Any extensive development effort that lasts longer than
a few weeks will require coordination with other developers, and the
easiest way to do that is to keep it in trunk.

Our trunk is (and should be) the place where bleeding edge development
happens. We use branches so that trunk can continue to evolve while a
feature release is being stabilized or maintenance releases are being
prepared.

BR,

Jukka Zitting

Re: PM - Simple vs. Bundle - mixin removal handling

2008-07-24T02:49:13Z

On Thu, Jul 24, 2008 at 9:59 AM, Marcel Reutegger
<marcel.reutegger@...> wrote:
> Hi,
>
> not sure, but I think this has already been reported before. this issue
> looks very similar:
>
> https://issues.apache.org/jira/browse/JCR-1632

right, i agree. it's the same problem:

there's a bug in AbstractBundlePersistenceManager which may lead
to jcr:mixinTypes properties not reflecting the actual set of assigned
mixin types.

cheers
stefan

>
> regards
> marcel
>
> Jan Haderka wrote:
>>>
>>> it's a bug. thanks for your detailed analysis!
>>> could please create a jira issue?
>>>
>>
>> You're welcome. :)
>> Reported on jira as https://issues.apache.org/jira/browse/JCR-1690
>>
>> Cheers,
>> Jan
>>
>>
>
>

[jira] Resolved: (JCR-1689) Multiple tests test for locking instead of versioning

2008-07-24T01:25:31Z

[ https://issues.apache.org/jira/browse/JCR-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger resolved JCR-1689.
-----------------------------------

Resolution: Fixed
Fix Version/s: 1.5

Applied patch in revision: 679300

Thank you for reporting this issue and providing a patch.

> Multiple tests test for locking instead of versioning
> -----------------------------------------------------
>
> Key: JCR-1689
> URL: https://issues.apache.org/jira/browse/JCR-1689
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-jcr-tests
> Environment: SVN trunk as of 23-Jul-08
> Reporter: Janne Jalkanen
> Priority: Minor
> Fix For: 1.5
>
> Attachments: jcr-tck-patch.txt
>
>
> Multiple tests claim to check whether versioning is supported, but in reality check for locking. Patch included.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: PM - Simple vs. Bundle - mixin removal handling

2008-07-24T00:59:52Z

Hi,

not sure, but I think this has already been reported before. this issue looks
very similar:

https://issues.apache.org/jira/browse/JCR-1632

regards
marcel

Jan Haderka wrote:

>> it's a bug. thanks for your detailed analysis!
>> could please create a jira issue?
>>
>
> You're welcome. :)
> Reported on jira as https://issues.apache.org/jira/browse/JCR-1690
>
> Cheers,
> Jan
>
>

Re: Component releases, proposed solution

2008-07-23T23:53:37Z

Hi,

Thomas Müller schrieb:
> Hi,
>
>> Major new developments -- the implementation of the foreseen JCR 2.0 ACL
>> functionality comes to mind -- should be done on development branches and
>> merged back into trunk as the developer(s) see fit aka ready for release.
>> Regular development still takes place on trunk, of course.
>
> If done correctly, major new development can be done in the trunk
> without risk.

Sure, if it only concerns a single location or limited set of locations.
If it touches multiple places, this is not that easy.

> How to do that: Use a (static final boolean) constant to
> enable / disable a certain new feature or new code path. It is used in
> the DataStore implementation. At first, it was disabled (only enabled
> when I run tests), and now it is enabled by default:
>
> class InternalValue {
> public static final boolean USE_DATA_STORE =
> Boolean.valueOf(System.getProperty("org.jackrabbit.useDataStore",
> "true")).booleanValue();
> }
>
> and then, everywhere where it is required, do this:
> if (USE_DATA_STORE) {
> // new code
> } else {
> // old code
> }
>
> As an added advantage, it's easy to find out if this feature is
> responsible for a problem, by disabling the system property.

I basically like the idea but have my reservations with respect to
system property use: It makes it difficult in embedded situations and
even almost makes it impossible to use in app server or servlet
container environments. For example: you want to have two repositories
in the same Java VM, one with and one without data store....

If is really just for testing, a "public" field is bad, because this
quickly becomes (de-facto) API. And a branch may still be better suited.

Probably better -- also for visibility -- would be to have a
functionality to provide this kind of setup as part of the Repository
descriptors. (And yes, I cannot imagine how to implement this in the
InternalValue class you presented. Maybe the use case is slightly wrong
in that the InternalValue should just use a "store", which in turn
either uses the new data store code or the old code and has to be setup
somehow)

Regards
Felix

Re: PM - Simple vs. Bundle - mixin removal handling

2008-07-23T13:33:35Z

> it's a bug. thanks for your detailed analysis!
> could please create a jira issue?
>

You're welcome. :)
Reported on jira as https://issues.apache.org/jira/browse/JCR-1690

Cheers,
Jan

[jira] Created: (JCR-1690) PM - Simple vs. Bundle - mixin removal handling

2008-07-23T13:31:31Z

PM - Simple vs. Bundle - mixin removal handling
-----------------------------------------------

Key: JCR-1690
URL: https://issues.apache.org/jira/browse/JCR-1690
Project: Jackrabbit
Issue Type: Bug
Affects Versions: core 1.4.5
Reporter: Jan Haderka

Following code (assuming node had mixin mix:versionable before):
node.removeMixin("mix:versionable");
node.save();
leads to difference in stored data based on PM used.
If you perform the operation above and restart your repository
call to:
node.isMixinType("mix:versionable");
will return false after restart in both cases, but
doing:
hasMixin(node, "mix:versionable");
will return true when repository is using bundled PM. The hasMixin()
method just iterates over all values of jcr:mixinTypes property:

public static void hasMixin(Node node, String mixin) {
try {
Value[] vals = node.getProperty("jcr:mixinTypes").getValues();
for (int i = 0; i < vals.length; i++) {
log.debug(vals[i].getString());
if (mixin.equals(vals[i].getString())) {
return true;
}
}
} catch (PathNotFoundException e) {
// property not found == can't contain anything
return false;
}
return false;
}

I think the difference is caused by following code (JR 1.4.5) in
AbstractBundledPersistenceManager (which doesn't seem to have equivalent
in simple PM)

557 // skip primaryType pr mixinTypes properties
558 if (id.getName().equals(QName.JCR_PRIMARYTYPE)
559 || id.getName().equals(QName.JCR_MIXINTYPES)
560 || id.getName().equals(QName.JCR_UUID)) {
561 continue;
562 }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Component releases, proposed solution

2008-07-23T09:50:40Z

Hi,

> Major new developments -- the implementation of the foreseen JCR 2.0 ACL
> functionality comes to mind -- should be done on development branches and
> merged back into trunk as the developer(s) see fit aka ready for release.
> Regular development still takes place on trunk, of course.

If done correctly, major new development can be done in the trunk
without risk. How to do that: Use a (static final boolean) constant to
enable / disable a certain new feature or new code path. It is used in
the DataStore implementation. At first, it was disabled (only enabled
when I run tests), and now it is enabled by default:

class InternalValue {
public static final boolean USE_DATA_STORE =
Boolean.valueOf(System.getProperty("org.jackrabbit.useDataStore",
"true")).booleanValue();
}

and then, everywhere where it is required, do this:
if (USE_DATA_STORE) {
// new code
} else {
// old code
}

As an added advantage, it's easy to find out if this feature is
responsible for a problem, by disabling the system property.

> * Releases are (almost) only cut from trunk
> * Branches are used for development and not for releases.
> Trunk should always be as stable as possible. Releases are built from tags
> based on trunk. This further simplifies the release procedure as there is no
> more branching and nore more bug fix back porting.

That's a good idea.

Regards,
Thomas

Re: PM - Simple vs. Bundle - mixin removal handling

2008-07-23T09:39:17Z

hi jan

On Wed, Jul 23, 2008 at 5:10 PM, Jan Haderka <jan.haderka@...> wrote:

> Hi,
>
> I have a question about purpose of perceived difference in handling
> mixins when using Simple or Bundled PM.
>
> Following code (assuming node had mixin mix:versionable before):
> node.removeMixin("mix:versionable");
> node.save();
> leads to difference in stored data based on PM used.
> If you perform the operation above and restart your repository
> call to:
> node.isMixinType("mix:versionable");
> will return false after restart in both cases, but
> doing:
> hasMixin(node, "mix:versionable");
> will return true when repository is using bundled PM. The hasMixin()
> method just iterates over all values of jcr:mixinTypes property:
>
> public static void hasMixin(Node node, String mixin) {
> try {
> Value[] vals = node.getProperty("jcr:mixinTypes").getValues();
> for (int i = 0; i < vals.length; i++) {
> log.debug(vals[i].getString());
> if (mixin.equals(vals[i].getString())) {
> return true;
> }
> }
> } catch (PathNotFoundException e) {
> // property not found == can't contain anything
> return false;
> }
> return false;
> }
>
> I think the difference is caused by following code (JR 1.4.5) in
> AbstractBundledPersistenceManager (which doesn't seem to have equivalent
> in simple PM)
>
> 557 // skip primaryType pr mixinTypes properties
> 558 if (id.getName().equals(QName.JCR_PRIMARYTYPE)
> 559 || id.getName().equals(QName.JCR_MIXINTYPES)
> 560 || id.getName().equals(QName.JCR_UUID)) {
> 561 continue;
> 562 }
>
> I'm not sure whether it is a bug or not, it doesn't seem to have any
> side effects.

it's a bug. thanks for your detailed analysis!
could please create a jira issue?

thanks
stefan

> Can someone explain to me what is the reason for skipping primary and
> mixin types property changes when persisting nodes?
>
> In case it is relevant: I discovered & tested this while working with
> Derby bundle & simple PM and using JR 1.4.5
>
> Thanks,
> Jan
>
>
>

[jira] Updated: (JCR-1689) Multiple tests test for locking instead of versioning

2008-07-23T08:17:31Z

[ https://issues.apache.org/jira/browse/JCR-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Janne Jalkanen updated JCR-1689:
--------------------------------

Attachment: jcr-tck-patch.txt

Patch fixes three TCK test cases to make the proper check.

> Multiple tests test for locking instead of versioning
> -----------------------------------------------------
>
> Key: JCR-1689
> URL: https://issues.apache.org/jira/browse/JCR-1689
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-jcr-tests
> Environment: SVN trunk as of 23-Jul-08
> Reporter: Janne Jalkanen
> Priority: Minor
> Attachments: jcr-tck-patch.txt
>
>
> Multiple tests claim to check whether versioning is supported, but in reality check for locking. Patch included.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1689) Multiple tests test for locking instead of versioning

2008-07-23T08:17:31Z

Multiple tests test for locking instead of versioning
-----------------------------------------------------

Key: JCR-1689
URL: https://issues.apache.org/jira/browse/JCR-1689
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-jcr-tests
Environment: SVN trunk as of 23-Jul-08
Reporter: Janne Jalkanen
Priority: Minor
Attachments: jcr-tck-patch.txt

Multiple tests claim to check whether versioning is supported, but in reality check for locking. Patch included.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

PM - Simple vs. Bundle - mixin removal handling

2008-07-23T08:10:12Z

Hi,

I have a question about purpose of perceived difference in handling
mixins when using Simple or Bundled PM.

Following code (assuming node had mixin mix:versionable before):
node.removeMixin("mix:versionable");
node.save();
leads to difference in stored data based on PM used.
If you perform the operation above and restart your repository
call to:
node.isMixinType("mix:versionable");
will return false after restart in both cases, but
doing:
hasMixin(node, "mix:versionable");
will return true when repository is using bundled PM. The hasMixin()
method just iterates over all values of jcr:mixinTypes property:

public static void hasMixin(Node node, String mixin) {
try {
Value[] vals = node.getProperty("jcr:mixinTypes").getValues();
for (int i = 0; i < vals.length; i++) {
log.debug(vals[i].getString());
if (mixin.equals(vals[i].getString())) {
return true;
}
}
} catch (PathNotFoundException e) {
// property not found == can't contain anything
return false;
}
return false;
}

I think the difference is caused by following code (JR 1.4.5) in
AbstractBundledPersistenceManager (which doesn't seem to have equivalent
in simple PM)

557 // skip primaryType pr mixinTypes properties
558 if (id.getName().equals(QName.JCR_PRIMARYTYPE)
559 || id.getName().equals(QName.JCR_MIXINTYPES)
560 || id.getName().equals(QName.JCR_UUID)) {
561 continue;
562 }

I'm not sure whether it is a bug or not, it doesn't seem to have any
side effects.
Can someone explain to me what is the reason for skipping primary and
mixin types property changes when persisting nodes?

In case it is relevant: I discovered & tested this while working with
Derby bundle & simple PM and using JR 1.4.5

Thanks,
Jan

[jira] Closed: (JCR-1688) Query parser builds invalid parse tree

2008-07-23T08:09:31Z

[ https://issues.apache.org/jira/browse/JCR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig closed JCR-1688.
------------------------------

Works great, thanks.

> Query parser builds invalid parse tree
> --------------------------------------
>
> Key: JCR-1688
> URL: https://issues.apache.org/jira/browse/JCR-1688
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-spi-commons
> Reporter: Michael Dürig
> Priority: Minor
> Fix For: 1.5
>
>
> Calling org.apache.jackrabbit.spi.commons.query.QueryParser.parse on
> SELECT prop1 FROM nt:unstructured WHERE prop1 IS NOT NULL ORDER BY prop1 ASC
> results in the following parse tree
> + Select properties: {}prop1
> + PathQueryNode
> + LocationStepQueryNode: NodeTest=* Descendants=true Index=NONE
> + RelationQueryNode: Op: NOT NULL Prop=@{}prop1 Type=STRING Value=%
> + NodeTypeQueryNode: Prop={http://www.jcp.org/jcr/1.0}primaryType Value={http://www.jcp.org/jcr/nt/1.0}unstructured
> + OrderQueryNode
> {}prop1 asc=true
> The RelationQueryNode should not have a second operand since the NOT NULL operator is unary.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1456) Database connection pooling

2008-07-23T07:37:32Z

[ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616064#action_12616064 ]

Matej Knopp commented on JCR-1456:
----------------------------------

Hi,

Thanks a lot for the comment. You're right, there might be a problem with different connections obtained. This could be handled by attaching active connection to current thread, so that the nested calls would always obtain the active connection. Anyway, I will look into it and post a new patch.

I agree that this is a substantial change and will require lot of testing. But i think at some point it will be necessary to bite the bullet and implement connection pooling, whether it will be based on my patch or not. The current situation is rather problematic, keeping opened connection per workspace doesn't scale well at all.

> Database connection pooling
> ---------------------------
>
> Key: JCR-1456
> URL: https://issues.apache.org/jira/browse/JCR-1456
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Jukka Zitting
> Fix For: 1.5
>
> Attachments: patch-1456-1.txt
>
>
> Jackrabbit should use database connection pools instead of a single connection per persistence manager, cluster journal, or database data store.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1688) Query parser builds invalid parse tree

2008-07-23T07:21:31Z

[ https://issues.apache.org/jira/browse/JCR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger resolved JCR-1688.
-----------------------------------

Resolution: Fixed
Fix Version/s: 1.5

Also fixed second issue. svn revision: 679093

Thank you for reporting this issue.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1672) Adding Event interface and isLocal()

2008-07-23T06:01:32Z

[ https://issues.apache.org/jira/browse/JCR-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler updated JCR-1672:
----------------------------------

Attachment: jackrabbit.patch

New patch adding the ExtendedEvent interface and the isExternal() method.

> Adding Event interface and isLocal()
> ------------------------------------
>
> Key: JCR-1672
> URL: https://issues.apache.org/jira/browse/JCR-1672
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-api, jackrabbit-core
> Affects Versions: 1.4
> Reporter: Carsten Ziegeler
> Fix For: 1.5
>
> Attachments: jackrabbit.patch, localeventlistener.patch
>
>
> when a repository cluster is used, it seems that a common problem many people have is to detect if an observation event is send because of changes on the local instance or a remote instance of the cluster.
> This is especially important if you want to do post processing of data
> based on observation (the post processing should only be done by one instance in the cluster).
> A current solution is to cast the jcr event object to the EventImpl of jackrabbit core which is obviously not a nice solution :)
> So what about adding an event interface to jackrabbit api which extends the jcr event interface and adds the isLocal() method?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1671) Support for external datasources with transactions

2008-07-23T05:49:32Z

[ https://issues.apache.org/jira/browse/JCR-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616001#action_12616001 ]

Jukka Zitting commented on JCR-1671:
------------------------------------

> Is there any documentation around managed transaction and any reference implementation details?

Not much. There are some related threads on the Jackrabbit mailing lists, you can find them by searching at http://jackrabbit.markmail.org/.

> Support for external datasources with transactions
> --------------------------------------------------
>
> Key: JCR-1671
> URL: https://issues.apache.org/jira/browse/JCR-1671
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core, transactions
> Environment: Websphere application server 6.0, DB2 database
> Reporter: Badal
> Assignee: Jukka Zitting
>
> Jackrabbit 1.3.1 should support transactions with external datasources

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (JCR-1672) Adding Event interface and isLocal()

2008-07-23T05:49:32Z

[ https://issues.apache.org/jira/browse/JCR-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler reopened JCR-1672:
-----------------------------------

As discussed in the mailing list, it's better to have the isExternal() method on an extension of the event interface.

> Adding Event interface and isLocal()
> ------------------------------------
>
> Key: JCR-1672
> URL: https://issues.apache.org/jira/browse/JCR-1672
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-api, jackrabbit-core
> Affects Versions: 1.4
> Reporter: Carsten Ziegeler
> Fix For: 1.5
>
> Attachments: localeventlistener.patch
>
>
> when a repository cluster is used, it seems that a common problem many people have is to detect if an observation event is send because of changes on the local instance or a remote instance of the cluster.
> This is especially important if you want to do post processing of data
> based on observation (the post processing should only be done by one instance in the cluster).
> A current solution is to cast the jcr event object to the EventImpl of jackrabbit core which is obviously not a nice solution :)
> So what about adding an event interface to jackrabbit api which extends the jcr event interface and adds the isLocal() method?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Connection pooling

2008-07-23T05:45:19Z

hi matej

On Tue, Jul 22, 2008 at 1:39 AM, Matej Knopp <matej.knopp@...> wrote:

> Hi,
>
> The idea of Jackrabbit managing DataSources didn't gain much support,
> so I decided to try implementing something much less intrusive. I have
> abstracted connection creation/closing (ConnectionProvider[1]) from
> the components that use database connections. There is one instance of
> ConnectionProvider per repository, configurable in repository.xml, but
> possibly with a sane default implementation so no configuration is
> necessary.
>
> The rest of jackrabbit (components that touch the database) would use
> ConnectionProvider to get the connections instead of just creating
> them and keeping opened. So far I've converted
> BundleDbPersistenceManager (and it's subclasses) to this approach. I
> would also tweak DatabasePersistenceManager and DbFileSystem to just
> borrow the connections instead of keeping them. As for journal,
> keeping one opened connection per repository probably doesn't make
> much difference.
>
> The benefit of this approach is that there is zero change in
> repository configuration, unless user wants to specify it's own
> ConnectionProvider class, which can be specified as a simple bean with
> element name ConnectionProvider.
>
> ConnectionProvider implementation that supports pooling must take
> different things into account, such as there can be request to various
> connections from different databases with different URLs. The manager
> must be intelligent enough to possibly maintain group of pools (e..g
> per database or even per connection URL)
>
> There is a SimplePoolingConnectionProvider implementation included in
> the patch that implements connection pooling, but it's only meant as
> proof of concept and doesn't try to substitute "real" connection
> pooling alternatives (dbcp, etc.)
>
> I've attached the first patch to https://issues.apache.org/jira/browse/JCR-1456

thanks for the patch. i added my comments on the jira issue.

cheers
stefan

>
> Kind regards,
> -Matej
>
> [1] ConnectionProvider class
>
> /**
> * Class responsible for providing SQL {@link Connection}s.
> * <p>
> * Implementation of this class can do connection pooling, in which case it must
> * take {@link ConnectionProperties} into account and only return connection
> * that matches the specified properties.
> */
> public interface ConnectionProvider {
>
> /**
> * Returns connection with given properties.
> *
> * @param properties
> * connection properties
> * @return SQL {@link Connection}
> *
> * @throws RepositoryException
> * @throws SQLException
> */
> public Connection getConnection(ConnectionProperties properties)
> throws RepositoryException, SQLException;
>
> /**
> * Closes the given connection. Classes that obtain connections through
> * {@link ConnectionProvider} must never call {@link Connection#close()}
> * directly. They are required to call {@link #closeConnection(Connection)}
> * instead.
> *
> * @param connection
> * SQL {@link Connection}
> *
> * @throws SQLException
> */
> public void closeConnection(Connection connection) throws SQLException;
>
> /**
> * Invoked when the repository is being shut down.
> *
> * @throws RepositoryException
> */
> public void dispose() throws RepositoryException;
>
> /**
> * Bean that holds properties necessary to create or identify a SQL
> * {@link Connection}.
> */
> public final static class ConnectionProperties {
> private String user;
> private String password;
> private String url;
> private String driver;
>
> public String getUser() {
> return user;
> }
>
> public void setUser(String user) {
> this.user = user;
> }
>
> public String getPassword() {
> return password;
> }
>
> public void setPassword(String password) {
> this.password = password;
> }
>
> public String getUrl() {
> return url;
> }
>
> public void setUrl(String url) {
> this.url = url;
> }
>
> public void setDriver(String driver) {
> this.driver = driver;
> }
>
> public String getDriver() {
> return driver;
> }
>
> private boolean equals(String s1, String s2) {
> return s1 == s2 || (s1 != null && s1.equals(s2));
> }
>
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj instanceof ConnectionProperties == false) {
> return false;
> }
> ConnectionProperties cp = (ConnectionProperties) obj;
> return equals(user, cp.user) && equals(password, cp.password)
> && equals(url, cp.url) && equals(driver, cp.driver);
>
> }
>
> private int hashCode(String s) {
> return s != null ? s.hashCode() : 0;
> }
>
> public int hashCode() {
> return hashCode(user) + 37 * hashCode(password) + 373
> & hashCode(url) + 1187 * hashCode(driver);
> }
> }
> }
>

[jira] Commented: (JCR-1456) Database connection pooling

2008-07-23T05:43:34Z

[ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615997#action_12615997 ]

Stefan Guggisberg commented on JCR-1456:
----------------------------------------

thanks for the patch, matej. that's very much appreciated.

i quickly browsed through the diff and noticed the following issue:

it seems like a connection is retrieved from the pool in every
PersistenceManager method. that's probably fine for
reading methods but that's not gonna work for writing methods
since they need to use the same connection (i.e. transaction).
all method calls within the store(ChangeLog) scope need
to use the same connection (with autoCommit set to false),
otherwise you'll end up with inconsistent/brokem repositories.

i am also a bit concerned about the impact of the proposed change
since it touches a lot of current code. the patch would have to be
thoroughly tested with all currently supported backends...

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1688) Query parser builds invalid parse tree

2008-07-23T03:07:31Z

[ https://issues.apache.org/jira/browse/JCR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615935#action_12615935 ]

Marcel Reutegger commented on JCR-1688:
---------------------------------------

Fixed the first issue in revision: 679054

> Query parser builds invalid parse tree
> --------------------------------------
>
> Key: JCR-1688
> URL: https://issues.apache.org/jira/browse/JCR-1688
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-spi-commons
> Reporter: Michael Dürig
> Priority: Minor
>
> Calling org.apache.jackrabbit.spi.commons.query.QueryParser.parse on
> SELECT prop1 FROM nt:unstructured WHERE prop1 IS NOT NULL ORDER BY prop1 ASC
> results in the following parse tree
> + Select properties: {}prop1
> + PathQueryNode
> + LocationStepQueryNode: NodeTest=* Descendants=true Index=NONE
> + RelationQueryNode: Op: NOT NULL Prop=@{}prop1 Type=STRING Value=%
> + NodeTypeQueryNode: Prop={http://www.jcp.org/jcr/1.0}primaryType Value={http://www.jcp.org/jcr/nt/1.0}unstructured
> + OrderQueryNode
> {}prop1 asc=true
> The RelationQueryNode should not have a second operand since the NOT NULL operator is unary.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1688) Query parser builds invalid parse tree

2008-07-23T02:31:34Z

[ https://issues.apache.org/jira/browse/JCR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615927#action_12615927 ]

Michael Dürig commented on JCR-1688:
------------------------------------

Another query which creates a bad parse tree:

SELECT * FROM nt:base WHERE jcr:path LIKE '/%' AND NOT jcr:path LIKE '/%/%'

results in

+ Select properties: *
+ PathQueryNode
+ LocationStepQueryNode: NodeTest={} Descendants=false Index=NONE
+ LocationStepQueryNode: NodeTest=* Descendants=false Index=NONE
+ AndQueryNode
+ NotQueryNode

Note the AndQueryNode having a single operand and the NotQueryNode having no operand at all.

> Query parser builds invalid parse tree
> --------------------------------------
>
> Key: JCR-1688
> URL: https://issues.apache.org/jira/browse/JCR-1688
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-spi-commons
> Reporter: Michael Dürig
> Priority: Minor
>
> Calling org.apache.jackrabbit.spi.commons.query.QueryParser.parse on
> SELECT prop1 FROM nt:unstructured WHERE prop1 IS NOT NULL ORDER BY prop1 ASC
> results in the following parse tree
> + Select properties: {}prop1
> + PathQueryNode
> + LocationStepQueryNode: NodeTest=* Descendants=true Index=NONE
> + RelationQueryNode: Op: NOT NULL Prop=@{}prop1 Type=STRING Value=%
> + NodeTypeQueryNode: Prop={http://www.jcp.org/jcr/1.0}primaryType Value={http://www.jcp.org/jcr/nt/1.0}unstructured
> + OrderQueryNode
> {}prop1 asc=true
> The RelationQueryNode should not have a second operand since the NOT NULL operator is unary.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-1688) Query parser builds invalid parse tree

2008-07-23T01:43:33Z

Query parser builds invalid parse tree
--------------------------------------

Key: JCR-1688
URL: https://issues.apache.org/jira/browse/JCR-1688
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-spi-commons
Reporter: Michael Dürig
Priority: Minor

Calling org.apache.jackrabbit.spi.commons.query.QueryParser.parse on

SELECT prop1 FROM nt:unstructured WHERE prop1 IS NOT NULL ORDER BY prop1 ASC

results in the following parse tree

+ Select properties: {}prop1
+ PathQueryNode
+ LocationStepQueryNode: NodeTest=* Descendants=true Index=NONE
+ RelationQueryNode: Op: NOT NULL Prop=@{}prop1 Type=STRING Value=%
+ NodeTypeQueryNode: Prop={http://www.jcp.org/jcr/1.0}primaryType Value={http://www.jcp.org/jcr/nt/1.0}unstructured
+ OrderQueryNode
{}prop1 asc=true

The RelationQueryNode should not have a second operand since the NOT NULL operator is unary.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.