[jira] Commented: (JCR-1697) Simple Google style query
[ https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840064#action_12840064 ] Paco Avila commented on JCR-1697: - GQL is already in jcr-commons, so the purity is broken. Anyway, my principal problem is that I can paginate the result of GQL, because the optimized method seems to be: ((QueryImpl) query).setLimit(limit); ((QueryImpl) query).setOffset(offset); and it return a RowIterator. Simple Google style query - Key: JCR-1697 URL: https://issues.apache.org/jira/browse/JCR-1697 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5.0 In the Sling project there's a need for a simple query language. See SLING-573. I've created a parser that translates the simple query into an XPath query statement and executes it on a JCR workspace. I'll commit it to the jackrabbit-jcr-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1248) Helper Method to escape illegal XPath Search Term
[
https://issues.apache.org/jira/browse/JCR-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840068#action_12840068
]
Paco Avila commented on JCR-1248:
-
By the way, this sample code at
http://wiki.apache.org/jackrabbit/EncodingAndEscaping is recursive:
String q =
/jcr:root/foo/element(*, foo) +
[jcr:contains(@title, ' +
Text.escapeIllegalXpathSearchChars(q).replaceAll(', '') + ')] +
[...@itemid = ' + itemID.replaceAll(', '') + '];
Helper Method to escape illegal XPath Search Term
-
Key: JCR-1248
URL: https://issues.apache.org/jira/browse/JCR-1248
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-jcr-commons
Reporter: Claus Köll
Assignee: Claus Köll
Priority: Minor
Fix For: 1.5.0
Attachments: patch.txt
If you try to perform a search like this
//element(*, nt:base)[jcr:contains(., 'test!')]
you get this exception
javax.jcr.RepositoryException: Exception building query:
org.apache.jackrabbit.core.query.lucene.fulltext.ParseException: Encountered
EOF at line 1, column 6.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1248) Helper Method to escape illegal XPath Search Term
[
https://issues.apache.org/jira/browse/JCR-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840071#action_12840071
]
Paco Avila commented on JCR-1248:
-
I'm not sure if is a bug or a feature. The query
String term = pe[]pe;
String scapedTerm = Text.escapeIllegalXpathSearchChars(term).replaceAll(',
'')
String query = /jcr:root//*[jcr:contains(okm:content,'+escapedTerm+')]
should fail or the term pe[]pe should be escaped as pe\[\]pe?
Helper Method to escape illegal XPath Search Term
-
Key: JCR-1248
URL: https://issues.apache.org/jira/browse/JCR-1248
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-jcr-commons
Reporter: Claus Köll
Assignee: Claus Köll
Priority: Minor
Fix For: 1.5.0
Attachments: patch.txt
If you try to perform a search like this
//element(*, nt:base)[jcr:contains(., 'test!')]
you get this exception
javax.jcr.RepositoryException: Exception building query:
org.apache.jackrabbit.core.query.lucene.fulltext.ParseException: Encountered
EOF at line 1, column 6.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2524) Reduce memory usage of DocIds
[ https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840074#action_12840074 ] Thomas Mueller commented on JCR-2524: - Caching the most recently used DocIds and reuse them might help to reduce the memory usage +1 DocIds that could be represented with a short instead of an int According to my test, this will not reduce memory usage: http://h2database.com/p.html#da4c6a321d0dc84a2b7b96cdbf468a47 For the Sun JVM (JDK 1.5, 32 bit), objects with one field of type boolean, byte, short, character, integer, and long all need 16 bytes. A small BigInteger uses 56 bytes, a small BigDecimal uses 32 bytes (probably re-uses the same BigInteger internally), and a String uses 24 bytes. Object uses 8 bytes. For JDK 1.6, 32 bit and 64 bit, it's a bit different: 20 bytes for an object, 24 bytes for boolean - long. For JDK 1.5, 64 bit, it's again different: 16 bytes for an object, 24 bytes for boolean - long. Reduce memory usage of DocIds - Key: JCR-2524 URL: https://issues.apache.org/jira/browse/JCR-2524 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Attachments: JCR-2524.patch Implementations of DocIds are used to cache parent child relations of nodes in the index. Usually there are a lot of duplicate objects because a DocId instance is used to identify the parent of a node in the index. That is, sibling nodes will all have DocIds with the same value. Currently a new DocId instance is created for each node. Caching the most recently used DocIds and reuse them might help to reduce the memory usage. Furthermore there are DocIds that could be represented with a short instead of an int when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Patch for JCR-2503 inconsistent session and persistent state after ReferentialIntegrityException
Hi, The JCR-2503 issue is given us a lot of problems and we have provided a junit test and patch. Could someone take a look at it? Greetings, Stephan Huttenhuis
[jira] Issue Comment Edited: (JCR-1697) Simple Google style query
[ https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840135#action_12840135 ] Paco Avila edited comment on JCR-1697 at 3/2/10 12:02 PM: -- Sorry, I have created a new issue at JCR-2526, so we can move the discussion there. was (Author: monkiki): Sorry, I have created a new issue at JCR-2526. Simple Google style query - Key: JCR-1697 URL: https://issues.apache.org/jira/browse/JCR-1697 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5.0 In the Sling project there's a need for a simple query language. See SLING-573. I've created a parser that translates the simple query into an XPath query statement and executes it on a JCR workspace. I'll commit it to the jackrabbit-jcr-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1697) Simple Google style query
[ https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840135#action_12840135 ] Paco Avila commented on JCR-1697: - Sorry, I have created a new issue at JCR-2526. Simple Google style query - Key: JCR-1697 URL: https://issues.apache.org/jira/browse/JCR-1697 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5.0 In the Sling project there's a need for a simple query language. See SLING-573. I've created a parser that translates the simple query into an XPath query statement and executes it on a JCR workspace. I'll commit it to the jackrabbit-jcr-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2526) Make o.a.j.commons.query.GQL modular
[ https://issues.apache.org/jira/browse/JCR-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840159#action_12840159 ] Alexander Klimetschek commented on JCR-2526: method which translates the GQL query to XPath I think it should rather translate to the abstract query model (JCR 2.0). Make o.a.j.commons.query.GQL modular Key: JCR-2526 URL: https://issues.apache.org/jira/browse/JCR-2526 Project: Jackrabbit Content Repository Issue Type: Wish Components: jackrabbit-jcr-commons Affects Versions: 1.6.1 Reporter: Paco Avila Priority: Minor The GQL.execute() returns a RowIterator and would be nice to return a QueryResult, so I can make a result.getColumnNames() to get the returned column names. Or perhaps better, make public the method which translates the GQL query to XPath so I can pass it to the QueryManager and execute it. Previously discussed at JCR-1697. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2527) Fix and simplify CryptedSimpleCredentials
Fix and simplify CryptedSimpleCredentials
-
Key: JCR-2527
URL: https://issues.apache.org/jira/browse/JCR-2527
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.0.0
Reporter: angela
Assignee: angela
Fix For: 2.0.1
the credentials retrieved from UserImpl and used to validate the
simplecredentials passed to the repository login is overly complex
and buggy as it tries to match all kind credentials variants with and without
hashed password.
in particular it contains the following problems:
- simplecredentials containing the hashed pw are considered valid
- passwords startign with {something} cause inconsistencies and may even
prevent the user from login
it should be improved as follows:
- simplecredentials are always expected to contain the plain text password both
for creation and
comparison with the cryptedsimplecredentials.
- creating cryptedsimplecredentials from uid/pw however is left unchanged: the
specified pw is
hashed with the default algorithm if it turns out not to be in the hashed
format.
- in addition the pw should also be hashed if it has the form
{something}whatever but something
is an invalid algorithm.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2523) StaleItemStateException during distributed transaction
[ https://issues.apache.org/jira/browse/JCR-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated JCR-2523: --- Attachment: JCRRepository.java UpdateTestServlet.java Sample code that helps reproduce the error. The Source File contains a servlet that runs in a application server and is therfore able to create a user transaction. Within that user transaction, we use two XA Resources: The Jackrabbit JCA Adapter and a MySQL Database for which we emulate two-phase commit. The overall behaviour is somewhat strange: First deploy the Servlet with the update statement active. No call the servlet once and the call will succeed. Upon subsequent calls to the servlet with the insert statement removed, the error will show up. Maybe this is because only after the first call Jackrabbit uses a SharedItemStateManager? StaleItemStateException during distributed transaction -- Key: JCR-2523 URL: https://issues.apache.org/jira/browse/JCR-2523 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core, jackrabbit-jca Affects Versions: 2.0.0 Environment: weblogic 10.3, jdk1.6.0_05, linux Reporter: Daniel Hasler Attachments: JCRRepository.java, UpdateTestServlet.java We use the Jackrabbit JCA Component within a Weblogic 10.3 Application Server with distributed transactions between an Oracle Database an the Jackrabbit JCA. Updating a node property multiple times in a transaction results in a XAException. Root cause seems to be a StaleItemStateException (see Stack-Trace). Googling revealed, that a similar bug was fixed for Jackrabbit 1.5.3. Looking through the code showed, that the proposed fix in JCR-1554 seems not to be applied on Jackrabbit 2.0 (tag and trunk). I tried to apply the proposed fix on the trunk code base, but this seemed not to help. Stack-Trace: javax.ejb.TransactionRolledbackLocalException: Error committing transaction:; nested exception is: javax.transaction.xa.XAException at weblogic.ejb.container.internal.EJBRuntimeUtils.throwTransactionRolledbackLocal(EJBRuntimeUtils.java:238) at weblogic.ejb.container.internal.EJBRuntimeUtils.throwEJBException(EJBRuntimeUtils.java:133) at weblogic.ejb.container.internal.BaseLocalObject.postInvoke1(BaseLocalObject.java:623) at weblogic.ejb.container.internal.BaseLocalObject.postInvokeTxRetry(BaseLocalObject.java:424) at ch.ejpd.sireneit.facade.ejb.ablage.DokumentFacadeBean_7xdnsq_DokumentFacadeImpl.updateStructuredDokument(DokumentFacadeBean_7xdnsq_DokumentFacadeImpl.java:340) at ch.ejpd.sireneit.access.rest.ablage.DokumentResource.update(DokumentResource.java:453) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:175) at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
