[jira] Created: (JCR-562) 'OR' in XPath query badly interpreted
'OR' in XPath query badly interpreted - Key: JCR-562 URL: http://issues.apache.org/jira/browse/JCR-562 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.0.1 Reporter: Szymon Kuzniak Attachments: tree.JPG executing query: //[EMAIL PROTECTED] and @b=2 or @c=3] leads to creating wrong query tree. The builded tree looks like for query: //[EMAIL PROTECTED] and @b=2 and @c=3](see attachement). using brackets resolves the problem, but without brackets output query is different from input query. When AND and OR are switched(so the OR is in first palce - //[EMAIL PROTECTED] or @b=2 and @c=3]) everything is ok. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-563) encode/decode
encode/decode - Key: JCR-563 URL: http://issues.apache.org/jira/browse/JCR-563 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.0.1 Reporter: Szymon Kuzniak As I mention in my email executing codeISO9075.decode(StringWith$inside)/code leads to exception: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at java.lang.String.charAt(String.java:444) at java.util.regex.Matcher.appendReplacement(Matcher.java:559) at com.day.crx.domino.util.NameEncoderDecoder.decode(NameEncoderDecoder.java:117) at integration.query.QueryTest.testQuery(QueryTest.java:49) 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:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) The problem is in Matcher.appendReplacement() method, because it didn't correctly interpret '$' and '\' sign. Both have to be escaped with '\' sign. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-550) ObservationManagerFactory) -
OutOfMemoryError when re-indexing the repository
In-Reply-To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
[ http://issues.apache.org/jira/browse/JCR-550?page=3Dcomments#action_1=
2432776 ]=20
=20
Claus K=C3=B6ll commented on JCR-550:
hi marcel
the vm argument -Xrunhprof:heap=3Dsites,doe=3Dn=20
does not work in my case. the re-index process stops after about 1-2 minute=
s with a outofmemory-error
is there another way to get a dump file ?
claus
ObservationManagerFactory) -
OutOfMemoryError when re-indexing the repository
-=
-
Key: JCR-550
URL: http://issues.apache.org/jira/browse/JCR-550
Project: Jackrabbit
Issue Type: Bug
Components: indexing
Affects Versions: 1.0.1
Environment: tomcat 5.0 [256 up to 512 mb of ram]=20
jackrabbit 1.0.1=20
jdk 1.4.2_12=20
Intel Xeon 3.2GHz with 2Gb of memory
poi-3.0-alpha2-20060616.jar
poi-contrib-3.0-alpha2-20060616.jar
poi-scratchpad-3.0-alpha2-20060616.jar
jackrabbit-core-1.0.1.jar
jackrabbit-index-filters-1.0.1.jar
jackrabbit-jcr-commons-1.0.1.jar
jcr-1.0.jar
tm-extractors-0.4.jar
lucene-1.4.3.jar
Reporter: Christian Zanata
Assigned To: Marcel Reutegger
Attachments: log_files.zip
[ERROR] 20060825 17:06:40
(org.apache.jackrabbit.core.observation.ObservationManagerFactory) -
Synchronous EventConsumer threw exception. java.lang.OutOfMemoryError
when we try to re-index a repository, the repository is quite big (more t=
hen 4 Gb of disk usage) and sometimes it stores 40Mb size documents.
As attach I put all the last logs we registered, with the full stack trac=
es.
Related to this whe have also errors with Lucene:
[DEBUG] 20060803 08:24:01 (org.apache.jackrabbit.core.query.LazyReader)
- Dump:=20
java.io.IOException: Invalid header signature; read 8656037701166316554,
expected -2226271756974174256
at org.apache.jackrabbit.core.query.MsWordTextFilter
and then this ones:
[DEBUG] 20060803 08:37:17 (org.apache.jackrabbit.core.ItemManager) -
removing item 8637bf5f-4689-4e75-888f-b7b89bef40c8 from cache
[ WARN] 20060803 08:40:13 (org.apache.jackrabbit.core.RepositoryImpl) -
Existing lock file at C:\Wave\Repository\.lock deteteced. Repository was
not shut down properly.
[ERROR] 20060803 09:33:14
(org.apache.jackrabbit.core.observation.ObservationManagerFactory) -
Synchronous EventConsumer threw exception.
java.lang.NullPointerException: null values not allowed
this is our repository.xml configuration for indexing
SearchIndex
class=3Dorg.apache.jackrabbit.core.query.lucene.SearchIndex
param name=3Dpath value=3D${wsp.home}/index/
param name=3DtextFilterClasses
value=3Dorg.apache.jackrabbit.core.query.lucene.TextPlainTextFilter,
org.apache.jackrabbit.core.query.MsExcelTextFilter,
org.apache.jackrabbit.core.query.MsPowerPointTextFilter,=20
org.apache.jackrabbit.core.query.MsWordTextFilter,
org.apache.jackrabbit.core.query.PdfTextFilter,
org.apache.jackrabbit.core.query.HTMLTextFilter,
org.apache.jackrabbit.core.query.XMLTextFilter,
org.apache.jackrabbit.core.query.RTFTextFilter,
org.apache.jackrabbit.core.query.OpenOfficeTextFi=
lter/
param name=3DuseCompoundFile value=3Dtrue/
param name=3DminMergeDocs value=3D100/
param name=3DvolatileIdleTime value=3D3/
param name=3DmaxMergeDocs value=3D10/
param name=3DmergeFactor value=3D10/
param name=3DbufferSize value=3D10/
param name=3DcacheSize value=3D1000/
param name=3DforceConsistencyCheck value=3Dfalse/
param name=3DautoRepair value=3Dtrue/
param name=3DrespectDocumentOrder value=3Dfalse/
param name=3Danalyzer
value=3Dorg.apache.lucene.analysis.standard.StandardAnalyzer/
/SearchIndex
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-561) Add support to provide custom classloader for class instantiation from configuration
[ http://issues.apache.org/jira/browse/JCR-561?page=all ]
Felix Meschberger closed JCR-561.
-
I think this can be closed now.
Add support to provide custom classloader for class instantiation from
configuration
Key: JCR-561
URL: http://issues.apache.org/jira/browse/JCR-561
Project: Jackrabbit
Issue Type: Improvement
Components: config
Affects Versions: 1.0, 1.0.1, 0.9
Reporter: Felix Meschberger
Assigned To: Felix Meschberger
Fix For: 1.1
The configuration framework is based around a BaseConfig class, which
provides functionality to instantiate a class whose name is configured in the
repository configuration file. Examples of such classes are the FileSystem or
the PersistenceManager elements.
The current implementation of the BeanConfig.newInstance() method is to use
the default classloader to load configured classes. That is, the class
loader of the BeanConfig class is actually used. This is - generally - the
class loader which loads the repository. In certain environments, classes may
be provided from outside the core repository class loader. An example fo such
an environment is an OSGi setup where each bundle gets its own class laoder,
which is separate from all other class loaders except declared by
configuration.
I propose to enhance the BeanConfig class as follows:
public class BeanConfig {
...
// Current default class loader, default is BeanConfig's class loader
private static ClassLoader defaultClassLoader =
BeanConfig.class.getClassLoader();
// Current instance class loader
private ClassLoader classLoader;
...
// Sets the default class loader for new BeanConfig instances
public static void setDefaultClassLoader(ClassLoader loader);
// Returns the default class loader for new BeanConfig instances
public static ClassLoader getClassLoader();
// Sets the class loader of this BeanConfig instance
public void setClassLoader(ClassLoader loader);
// Returns the class loader of this BeanConfig instance
public ClassLoader getClassLoader();
}
The BeanConfig.newInstance method would then use the following to use the
class:
public Object newInstance() throws ConfigurationException {
Class clazz = Class.forName(getClassName(), true, getClassLoader());
...
}
This has also been discussed on the dev list:
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200607.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Improving the accessibility of the Jackrabbit core
Hi All, Dave, thanks a lot for your input. . Screenshots or easily downloadable sample app which actually does something with custom node types. the base war download is good, but how far could you go with it. Most open source applications have a contacts application or a phone book, or something similar. something that has a face, like a jsp to view whats in the repository would be great . the wiki has not been updated regularly, either the information is old or not many people go to it . the deployment models - creating a complete tomcat dist, which has the various deployment options running right out of the box would be nice. . a java example to add node types, for example for a phone book, which CRUDs the node types would be nice . maybe a page, which lists the possibilities of applications that could be built with JR will be useful for newbies. I completely agree with you that all of the above are excellent measures that we should be looking at to ease the adoption of new content application developers. I think it is very important that people get things up and running very quickly and are equipped with very good user documentation. Personally, I think we have to separate the concerns though, I think Jukka's initial post was going into the direction of making the internals of the core more accessible to more developers. I think that there are a number of steps that we can take into that direction and I also think that for example the separation eventually provided by the SPI will bring some more architectural clarity. While I agree that we need to have a modular design where people can plug-in their extensions at certain defined interfaces and extension points, I would discourage the idea that every user needs to be able to submit patches to the core. In my mind the core should be very compact and very controlled since it has to be extremely stable and scalable, meaning that there is not really a need to have dozens of developers working on a more smallish core. regards, david
Re: Improving the accessibility of the Jackrabbit core
On 9/6/06, David Nuescheler [EMAIL PROTECTED] wrote: While I agree that we need to have a modular design where people can plug-in their extensions at certain defined interfaces and extension points, I would discourage the idea that every user needs to be able to submit patches to the core. In my mind the core should be very compact and very controlled since it has to be extremely stable and scalable, meaning that there is not really a need to have dozens of developers working on a more smallish core. Hi, My two cents on the subject drawing from my experience on the backup tool. At first Jukka and I wanted to avoid impact on the core for the reasons you mentionned. It turned out we had to eventually update some parts of the core: some functionnalities were simply not there. We minimized the changes (only a few lines)... But they were quite bad (I exposed something that shouldn't). After some rethinking and a few try out, I am back to my initial plan with a few classes added to the core. This example shows the Core is not over in the sense, it lacks some functionnality (for instance in my case a way to import the versions). I think we need to remember JR is still a fairly new project and some use cases have still not been detected. Some functionnalities have not been needed yet for the core contributors but might emerge from other companies/individual (for instance my company would need to extend JR to support our needs). I think discouraging those contributions can be a bad idea: we should encourage them, keep the code and refactor them if necessary. This way both the contributor and the communitu take benefit from it: a new functionnality with a cleaner code. I agree with you though that we should encourage contribution and not update to the core. But we should document the core. In my case, it took me a lot of time the part I needed (I wrote a new UpdatableStateManager since I couldn't figure out how the EventFactory was working). BR Nicolas my blog! http://www.deviant-abstraction.net !!
Re: Improving the accessibility of the Jackrabbit core
Hi, On 9/6/06, David Nuescheler [EMAIL PROTECTED] wrote: Personally, I think we have to separate the concerns though, I think Jukka's initial post was going into the direction of making the internals of the core more accessible to more developers. Correct. In any case, Dave's points are a valuable addition to the feedback I gathered a while ago before the 1.0 release with the issue of streamlining the end-user experience. While I agree that we need to have a modular design where people can plug-in their extensions at certain defined interfaces and extension points, I would discourage the idea that every user needs to be able to submit patches to the core. I'm most concerned about the overhead for people going in trying to trace why Jackrabbit is behaving the way it does in some specific issue. This is often the first step of becoming a contributor, and in my opinion it's currently quite a high step to overcome. In my mind the core should be very compact and very controlled since it has to be extremely stable and scalable, meaning that there is not really a need to have dozens of developers working on a more smallish core. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Improving the accessibility of the Jackrabbit core
On 9/6/06, Nicolas [EMAIL PROTECTED] wrote: On 9/6/06, David Nuescheler [EMAIL PROTECTED] wrote: While I agree that we need to have a modular design where people can plug-in their extensions at certain defined interfaces and extension points, I would discourage the idea that every user needs to be able to submit patches to the core. In my mind the core should be very compact and very controlled since it has to be extremely stable and scalable, meaning that there is not really a need to have dozens of developers working on a more smallish core. Hi, My two cents on the subject drawing from my experience on the backup tool. At first Jukka and I wanted to avoid impact on the core for the reasons you mentionned. It turned out we had to eventually update some parts of the core: some functionnalities were simply not there. We minimized the changes (only a few lines)... But they were quite bad (I exposed something that shouldn't). After some rethinking and a few try out, I am back to my initial plan with a few classes added to the core. This example shows the Core is not over in the sense, it lacks some functionnality (for instance in my case a way to import the versions). I think we need to remember JR is still a fairly new project and some use cases have still not been detected. Some functionnalities have not been needed yet for the core contributors but might emerge from other companies/individual (for instance my company would need to extend JR to support our needs). I think discouraging those contributions can be a bad idea: we should encourage them, keep the code and refactor them if necessary. This way both the contributor and the communitu take benefit from it: a new functionnality with a cleaner code. i don't follow your argumentation. why would this lead to cleaner code? cheers stefan I agree with you though that we should encourage contribution and not update to the core. But we should document the core. In my case, it took me a lot of time the part I needed (I wrote a new UpdatableStateManager since I couldn't figure out how the EventFactory was working). BR Nicolas my blog! http://www.deviant-abstraction.net !!
Status of the clustering effort?
Hi, My company is currently evaluating Jackrabbit as a replacement for our current content repository. But for this, we would definitely needs clustering both for HA and scaling out (we currently host several To of data). I have seen the open issue on JIRA (JCR 169). It seems we are still thinking about it but nothing is in the pipe. Is this assumption correct please? Since I am at the same time writing my master's thesis, I was thinking of working on this task (and write my thesis on it) if it is still needed. I can dedicate enough time on this (basically this would be my work of the year). Therefore my question is: what is the current status of this effort? Is it still needed? BR Nico my blog! http://www.deviant-abstraction.net !!
Re: Object-content mapping tool in Graffito
Hi, Thanks for all the comments! Based on the positive feedback I'll continue the process within the Graffito project and hope to graduate the Graffito JCR mapping tool into a Jackrabbit subproject once all the details and the incubation exit criteria are taken care of. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Improving the accessibility of the Jackrabbit core
Hi Nico, Thanks for your mail. I will work on the documentation directly on the wiki (when I can start this task). I will ask a lot of questions *though*. Looking forward to it ;) One precision on the backup tool: it is working (and I am polishing the code that needs to fit in Core). And with my new JR understanding, I plan to start implementing a version 2 in my spare time having hotbackup. Excellent, thanks for all your efforts. I did not mean to imply that the backup tool was not working. If I should have said anything like that, I would like to apologize. regards, david
Re: Improving the accessibility of the Jackrabbit core
Hi, On 9/6/06, David Nuescheler [EMAIL PROTECTED] wrote: Got it. Generally, I am more of a given the right eyeballs, all bugs are shallow type of person to begin with. Perhaps we can find common ground at enough right eyeballs. ;-) If I currently take look at the shallowness of actual core bugs ;) in Jackrabbit I see that the Jackrabbit community has an outstanding bug resolution time. To me this is probably one of the biggest strengths of Jackrabbit and its community. Do you see this as a weakness that needs improvement? Definitely not. :-) What I do see as a weakness is that we rely on a handful of core developers to keep up this level of support when we could better tap the great potential within the community. In fact I'd rather see the core developers spending more time being proactive designing new features and improvements (like improving performance, scalability, etc.) than reactive analyzing user issues when large parts of that work could be distributed. I think in the end it all boils down to matter of priorities and I would be very interested in having a discussion around what we think drives and hinders the Jackrabbit adoption and community today and tomorrow, and therefore what we should focus on. +1 There's already quite a lot of feedback on the adoption part, but that would need to be summarized and analyzed to better focus the efforts. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
getting the latest version of a checkedout node
Hello, when the property jcr:isCheckedOut of a node is true, I want to retrieve this node without the changes which are possibly made during the checkout state. So I want to retrieve the node as it was, when it was last checked in. Only when the checkedout node is checkedin the changes are final so then I want to retrieve the node with ithe changes. Is this possible? If so, how would I achieve this? I am looking at the frozennode property, am I on the right track? -- View this message in context: http://www.nabble.com/getting-the-latest-version-of-a-checkedout-node-tf2227841.html#a6173979 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: Improving the accessibility of the Jackrabbit core
On Sep 6, 2006, at 4:14 AM, David Nuescheler wrote: Personally, I believe that for example a restore facility has to be buried deep down in the core and therefore the code has to comply with the high quality requirements that we have for code in the core and for the seasoned Jackrabbit experience of a developer. That is why each of the core developers has veto power over the code. If we want to ensure that every line is adequately reviewed, then ask for the core code to be governed by the RTC (review-then-commit) rule. Note, however, that such a requirement will extend to all commits on that part of the code. In my mind your experience with developing very close to the heart of Jackrabbit should not lead us to opening up the core so inexperienced Jackrabbit developers can contribute, but it should help us realize that we have very high requirements for Jackrabbit developers that make modifications to the core. I don't think you understand. This is an Apache project and anyone can contribute to any part of it. The degree of review we require of those contributions is decided by the PMC (our committers). We can increase the requirements on review of the core code and we can separate compatible and incompatible changes into versioned branches, but we cannot ask of others what we do not accept of ourselves. In my opinion, the core code continues to evolve as people try to do larger and more expressive things with Jackrabbit and apply JCR to real problem sets. We need to welcome that and change things based on their technical merits, not any preconceived notions of how much a person knows about the current (highly opaque) core architecture. Most likely, this will mean simplifying the core by removing or refactoring some of the spaghetti dependencies. One of those things that will change is the degree of extensibility, since that is the heart of any successful open source project and Jackrabbit isn't even halfway there yet. I am sure that others with fresh energy will see new ways to solve the same problem that will not be burdened with the legacy decisions that we made for one reason or another. When those ideas are presented, they will be subject to intense scrutiny and adopted based only on their proven benefits. They will not be judged based on who wrote them or how much time they spent writing the initial core code. Roy
