== Use Error Codes ==
What about using something like a hash code (for example of the current
stack trace) as error code? These would then automatically serve as hash
tags for Google searches. That is, errors pasted into a discussion forum
would be indexed by Google. Searching for 'Error
On Mon, Mar 1, 2010 at 5:41 AM, Thomas Müller thomas.muel...@day.com wrote:
The question is: should Jackrabbit 3 *require* (like now) that the
credentials for the storage are included in the repository
configuration? I think for some storage backends it should not require
that. Instead (only
I wouldn't call it error code, then: every time something changes
either in the calling code or in the code throwing the exception,
you'll get a different hash code.
Dominique
On Mon, Mar 1, 2010 at 10:32 AM, Michael Dürig michael.due...@day.com wrote:
== Use Error Codes ==
What about using
On Mon, Mar 1, 2010 at 9:32 AM, Michael Dürig michael.due...@day.com wrote:
What about using something like a hash code (for example of the current
stack trace) as error code? These would then automatically serve as hash
A good sample to deal with error messages:
Hi,
I am not clear what credentials you are refering to
I refer to the database user name and password that are currently
stored in the repository.xml (except when using JNDI):
http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.html
#
Dominique Pfister wrote:
I wouldn't call it error code, then: every time something changes
either in the calling code or in the code throwing the exception,
you'll get a different hash code.
Agreed, the stack trace might be too unstable. But I still like the idea
of using something cryptic
On Sun, Feb 28, 2010 at 16:41, Thomas Müller thomas.muel...@day.com wrote:
== Use Error Codes ==
Currently exception message are hardcoded (in English). When using
error codes, exception messages could be translated. I'm not saying we
should translate them ourselves, but if somebody wants to,
Hi,
-1 on defining this on this isolated level.
This should be part of a broader concept of how to architect/structure
JR3 and its backend connections.
Regards
Felix
On 28.02.2010 16:40, Thomas Müller wrote:
Currently Jackrabbit initializes the repository storage (persistence
manager) when
On Mon, Mar 1, 2010 at 11:50, Thomas Müller thomas.muel...@day.com wrote:
String factoryClass = ...;
String url = ...?user=sapassword=xyz;
RepositoryFactory factory = (RepositoryFactory)
Class.forName(factoryClass).newInstance();
MapString, String parameters = new HashMapString, String();
Hi,
Currently Jackrabbit doesn't support relayed initialization. Unless I
misunderstood Felix, he would also like to get rid of this
restriction.
Just to clarify: my suggestion is *not* about requiring the repository
is initialized when the first session is opened. It's also *not* about
[
https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839717#action_12839717
]
Marcel Reutegger commented on JCR-2524:
---
Some memory stats from a real life system: a
On Mon, Mar 1, 2010 at 14:42, Thomas Müller thomas.muel...@day.com wrote:
Couldn't this be done by a special wrapping Repository implementation?
That's problematic. Such a wrapper would have quite some overhead. The
JCR API is not easily wrapable if you want to do it correctly: you
would have
[
https://issues.apache.org/jira/browse/JCR-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839819#action_12839819
]
Paco Avila commented on JCR-1248:
-
A query like this will fail:
//element(*,
[
https://issues.apache.org/jira/browse/JCR-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839819#action_12839819
]
Paco Avila edited comment on JCR-1248 at 3/1/10 7:38 PM:
-
A query
[
https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-2524:
--
Status: Patch Available (was: Open)
Reduce memory usage of DocIds
[
https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-2524:
--
Attachment: JCR-2524.patch
Proposed patch.
Reduce memory usage of DocIds
[
https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839855#action_12839855
]
Marcel Reutegger commented on JCR-2524:
---
Forgot to mention that the proposed patch
[
https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839860#action_12839860
]
Paco Avila commented on JCR-1697:
-
The GQL.execute() returns a RowIterator and would be nice
[
https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839864#action_12839864
]
Paco Avila commented on JCR-1697:
-
Another option is to handle these kind of queries
[
https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839877#action_12839877
]
johann sorel commented on JCR-1697:
---
GQL has no relation with JCR. it is just a candidate
NodeState and NodeStateListener deadlock
Key: JCR-2525
URL: https://issues.apache.org/jira/browse/JCR-2525
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
[
https://issues.apache.org/jira/browse/JCR-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839913#action_12839913
]
Frederic Guilbeault commented on JCR-2525:
--
Proposed solution would be to introduce
22 matches
Mail list logo
