System.getSecurityManager(); is null
Hello all, I've written some code that connects to the repository, loads an image (using ImageIO.read()) and i wish to store that image in the JCR. The problem is; as soon as i make a call to ImageIO.read() i am thrown an exception; reason for the exception is [SecurityManager security = System.getSecurityManager();] System.getSecurityManager() returning null somewhere in the File class. I've never really needed to 'setSecurityManager' as such before; is this something to do with Jackrabbit? Any ideas how to solve this? Thanks Neville -- View this message in context: http://www.nabble.com/System.getSecurityManager%28%29--is-null-tp24472460p24472460.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Build failed in Hudson: Jackra bbit-spi » SPI Test Client #162
See
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/162/
--
[INFO]
[INFO] Building SPI Test Client
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target
(included: [**], excluded: [])
[TASKS] Scanning folder
'http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/java'
for tasks ...
[TASKS] Found 0.
[TASKS] Scipping non-existent folder
'http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/resources'...
[TASKS] Found 0 annotations (0 new, 0 high, 0 normal, 0 low)
[TASKS] Don't changing build status, no threshold has been exceeded
[INFO] [remote-resources:process {execution: default}]
[TASKS] Scipping maven reporter: there is already a result available.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/resources
[INFO] Copying 3 resources
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[compiler:compile]
[INFO] Compiling 6 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/classes
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 7 resources
[INFO] Copying 3 resources
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[compiler:testCompile]
[INFO] Compiling 21 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/test-classes
[INFO] [surefire:test][TASKS] Scipping maven reporter: there is already a
result available.
[INFO] Surefire report directory:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/surefire-reports
---
T E S T S
---
Running org.apache.jackrabbit.test.TestAll
Tests run: 1042, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 40.449 sec
Running org.apache.jackrabbit.client.TestAll
Tests run: 444, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.174 sec
Results :
Tests run: 1486, Failures: 0, Errors: 0, Skipped: 0
[TASKS] Scipping maven reporter: there is already a result available.
[HUDSON] Recording test results
[INFO] [jar:jar]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT.jar
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT-sources.jar
Jul 13, 2009 6:49:12 PM hudson.remoting.Channel$ReaderThread run
SEVERE: Unable to read a command
java.lang.ClassNotFoundException: hudson.remoting.ProxyOutputStream$Unexport
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274)
at
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream
Build failed in Hudson: Jackra bbit-spi » SPI Test Client #161
See
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/161/
--
[INFO]
[INFO] Building SPI Test Client
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target
(included: [**], excluded: [])
[TASKS] Scanning folder
'http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/java'
for tasks ...
[TASKS] Found 0.
[TASKS] Scipping non-existent folder
'http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/resources'...
[TASKS] Found 0 annotations (0 new, 0 high, 0 normal, 0 low)
[TASKS] Don't changing build status, no threshold has been exceeded
[INFO] [remote-resources:process {execution: default}]
[TASKS] Scipping maven reporter: there is already a result available.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/resources
[INFO] Copying 3 resources
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[compiler:compile]
[INFO] Compiling 6 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/classes
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 7 resources
[INFO] Copying 3 resources
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[compiler:testCompile]
[INFO] Compiling 21 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/test-classes
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[surefire:test]
[INFO] Surefire report directory:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/surefire-reports
---
T E S T S
---
Running org.apache.jackrabbit.test.TestAll
Tests run: 1042, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 39.866 sec
Running org.apache.jackrabbit.client.TestAll
Tests run: 444, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.149 sec
Results :
Tests run: 1486, Failures: 0, Errors: 0, Skipped: 0
[TASKS] Scipping maven reporter: there is already a result available.
[HUDSON] Recording test results
[INFO] [jar:jar]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT.jar
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT-sources.jar
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[apache-rat:check {execution: default}]
[INFO] Exclude: release.properties
[TASKS] Scipping maven reporter: there is already a result available.
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/pom.xml
to
/export/home/hudson/hudson/jobs/Jackrabbit-spi/modules/org.apache.jackrabbit$jackrabbit-test-client/builds/2009-07-13_18-03-43/archive/org.apache.jackrabbit/jackrabbit-test-client/1.6-SNAPSHOT/pom.xml
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT.jar
to
/export/home/hudson/hudson/jobs/Jackrabbit-spi/modules/org.apache.jackrabbit$jackrabbit-test-client/builds/2009-07-13_18-03-43/archive/org.apache.jackrabbit/jackrabbit-test-client/1.6-SNAPSHOT/jackrabbit-test-client-1.6-SNAPSHOT.jar
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT-sources.jar
to
/export/home/hudson/hudson/jobs/Jackrabbit-spi/modules/org.apache.jackrabbit$jackrabbit-test-client/builds/2009-07-13_18-03-43/archive/org.apache.jackrabbit/jackrabbit-test-client/1.6-SNAPSHO
[jira] Updated: (JCR-2196) Add cause to ItemStateException in BundleDbPersistenceManager.store()
[ https://issues.apache.org/jira/browse/JCR-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2196: --- Fix Version/s: 1.6.0 Merged to the 1.x branch in revision 793623. > Add cause to ItemStateException in BundleDbPersistenceManager.store() > - > > Key: JCR-2196 > URL: https://issues.apache.org/jira/browse/JCR-2196 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 2.0-alpha4, 1.6.0 > > > Currently only the message of the causing exception is given to the > ItemStateException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)
On Mon, Jul 13, 2009 at 5:06 PM, Paco Avila wrote: > So using m2eclipse is the preferred way to deal with jackrabbit (subversion) > and eclipse. If I use m2eclipse is necessary to run "mvn eclipse:eclipse" ? No. The "mvn eclipse:eclipse" way creates a normal Eclipse java project from the pom(s) that you then can import (or refresh if you've already imported it and need to update it). Eclipse will then not be "aware" of the fact that the project is based on a meven pom. Eg. if you want to add a dependency, you always have to do it in the pom, adding it to the java project in Eclipse directly will only work inside Eclipse (and get lost upon the next mvn eclipse:eclipse + refresh) - this whole thing is only one way. The m2eclipse plugin enhances Eclipse to be able to directly import maven-based projects (so I think it adds a special project type to Eclipse). This will then be very much aware of the pom and allows you to modify the pom directly through various tools. I personally prefer the mvn eclipse:eclipse way, as I was always disappointed by the complexity / issues of m2eclipse or similar (older) plugins for Eclipse. But maybe I have to look at it again ;-) Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)
On Mon, Jul 13, 2009 at 4:06 PM, Paco Avila wrote: > So using m2eclipse is the preferred way to deal with jackrabbit (subversion) Just personal preference, both tools works WELL. > and eclipse. If I use m2eclipse is necessary to run "mvn eclipse:eclipse" ? No necessary to run this command any more. The plugin will generate necessary configuration files. > I'm not sure of this. Actually I'm not using the eclipse plugin so working > in the old-fashioned way, but it is working fine (more or less) I just start using m2eclipse recently for experiment, old-fashion always a good backup options :) --Guo
Build failed in Hudson: Jackra bbit-spi » SPI Test Client #160
See
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/160/
--
[INFO]
[INFO] Building SPI Test Client
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target
(included: [**], excluded: [])
[TASKS] Scanning folder
'http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/java'
for tasks ...
[TASKS] Found 0.
[TASKS] Scipping non-existent folder
'http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/resources'...
[TASKS] Found 0 annotations (0 new, 0 high, 0 normal, 0 low)
[TASKS] Don't changing build status, no threshold has been exceeded
[INFO] snapshot org.apache.jackrabbit:jackrabbit-spi2dav:1.6-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot org.apache.jackrabbit:jackrabbit-webdav:1.6-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot org.apache.jackrabbit:jackrabbit-jcr-server:1.6-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot org.apache.jackrabbit:jackrabbit-spi2jcr:1.6-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot org.apache.jackrabbit:jackrabbit-jcr-tests:1.6-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] [remote-resources:process {execution: default}]
[TASKS] Scipping maven reporter: there is already a result available.
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/src/main/resources
[INFO] Copying 3 resources
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[compiler:compile]
[INFO] Compiling 6 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/classes
[INFO] [TASKS] Scipping maven reporter: there is already a result
available.[resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 7 resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
Compiling 21 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/test-classes
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[surefire:test]
[INFO] Surefire report directory:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/surefire-reports
---
T E S T S
---
Running org.apache.jackrabbit.test.TestAll
Tests run: 1042, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 43.56 sec
Running org.apache.jackrabbit.client.TestAll
Tests run: 444, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.273 sec
Results :
Tests run: 1486, Failures: 0, Errors: 0, Skipped: 0
[TASKS] Scipping maven reporter: there is already a result available.
[HUDSON] Recording test results
[INFO] [jar:jar]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT.jar
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT-sources.jar
[TASKS] Scipping maven reporter: there is already a result available.[INFO]
[apache-rat:check {execution: default}]
[INFO] Exclude: release.properties
[TASKS] Scipping maven reporter: there is already a result available.
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/pom.xml
to
/export/home/hudson/hudson/jobs/Jackrabbit-spi/modules/org.apache.jackrabbit$jackrabbit-test-client/builds/2009-07-13_16-07-24/archive/org.apache.jackrabbit/jackrabbit-test-client/1.6-SNAPSHOT/pom.xml
[HUDSON] Archiving
http://hudson.zones.apache.org/hudson/job/Jackrabbit-spi/org.apache.jackrabbit$jackrabbit-test-client/ws/target/jackrabbit-test-client-1.6-SNAPSHOT.jar
to
/export/home/hudson/hudson/jobs/
[jira] Updated: (JCR-2194) EventImpl should implement toString
[ https://issues.apache.org/jira/browse/JCR-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2194: --- Fix Version/s: 1.6.0 Merged to the 1.x branch in revision 793614. > EventImpl should implement toString > --- > > Key: JCR-2194 > URL: https://issues.apache.org/jira/browse/JCR-2194 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi-commons >Reporter: Michael Dürig >Assignee: Michael Dürig > Fix For: 2.0-alpha4, 1.6.0 > > Attachments: JCR-2194.patch > > > This would simplify logging and debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Jackrabbit 2.0-alpha4
Hi, On Thu, Jul 9, 2009 at 5:45 PM, Jukka Zitting wrote: > Please vote on releasing this package as Apache Jackrabbit 2.0-alpha4. The vote passes as follows: +1 Dominique Pfister +1 Jukka Zitting +1 Julian Reschke Thanks for voting! I'll push the release out. BR, Jukka Zitting
[jira] Updated: (JCR-2208) update tests so that both Query.XPATH and Query:SQL are treated as optional features
[ https://issues.apache.org/jira/browse/JCR-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-2208: Issue Type: Sub-task (was: Task) Parent: JCR-1104 > update tests so that both Query.XPATH and Query:SQL are treated as optional > features > > > Key: JCR-2208 > URL: https://issues.apache.org/jira/browse/JCR-2208 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-tests >Reporter: Julian Reschke > > In JCR 2.0, both Query.XPATH and Query.SQL are optional (or, actually, > deprecated). > We either need to modify the tests so that they pass on a repository that > doesn't support them (-> NotExecutableException), or remove them altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2208) update tests so that both Query.XPATH and Query:SQL are treated as optional features
update tests so that both Query.XPATH and Query:SQL are treated as optional features Key: JCR-2208 URL: https://issues.apache.org/jira/browse/JCR-2208 Project: Jackrabbit Content Repository Issue Type: Task Components: jackrabbit-jcr-tests Reporter: Julian Reschke In JCR 2.0, both Query.XPATH and Query.SQL are optional (or, actually, deprecated). We either need to modify the tests so that they pass on a repository that doesn't support them (-> NotExecutableException), or remove them altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)
So using m2eclipse is the preferred way to deal with jackrabbit (subversion) and eclipse. If I use m2eclipse is necessary to run "mvn eclipse:eclipse" ? I'm not sure of this. Actually I'm not using the eclipse plugin so working in the old-fashioned way, but it is working fine (more or less) On Mon, Jul 13, 2009 at 2:28 PM, Guo Du wrote: > The article should still works, because it follow Michael's > instruction. Just noticed it's quite old: August 15, 2007. > > I did a try for m2eclipse recently and it give much better experience > than it's early version. It has a GUI to manage your pom (You don't > need to check the pom model manual any more) and update eclipse > dependencies automatically. Import and run goals inside IDE also give > better productivity. > > -- Guo > > On Mon, Jul 13, 2009 at 12:53 PM, Paco Avila wrote: > > > > This article is very clear about it: > > > > http://www.jroller.com/cdaniluk/entry/setting_up_an_eclipse_multi > > > > I will try this instructions. > > > > On Mon, Jul 13, 2009 at 1:09 PM, Michael Dürig > wrote: > >>> I've some problems developing with jackrabbit in Eclipse. Where can I > >>> find > >>> some info about this? > >> > >> There are many ways to do this, but I'm pretty happy with the > >> m2eclipse plugin from http://m2eclipse.sonatype.org/. > >> > >> The plugin installs cleanly from the update site at > >> http://m2eclipse.sonatype.org/update/, and after that I can use File > > >> Import... > Maven Projects and point the dialog to the root of my > >> checkout. The importer will correctly find and set up all the > >> components as separate projects in Eclipse. > > > > I use a similar approach but without the m2eclipse plugin. Rather I use > > Maven from the command line: > > > > mvn clean install > > mvn eclipse:eclipse > > > > and then import the generated eclipse project files with Eclipse. > > > > This approach works generally quite well. > > > > Michael > > > > > > > > -- > Kind regards, > > Du, Guo > __ > Phone : +353-86-176 6186 > Email : onl...@duguo.com > __ > http://duguo.com - Career Life Balance > -- Paco Avila GIT Consultors tel: +34 971 498310 fax: +34 971496189 e-mail: pav...@git.es http://www.git.es
[jira] Commented: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730372#action_12730372 ] Paco Avila commented on JCR-1972: - I've updated the patch and also added two JUnit test (CheckinCalendarTest and added a new method at NodeImplTest). In addNode(..., UUID) I can test if the node has the MIX_REFERENCEABLE mixing but I'm not sure if this good because the mixin can be added after the node creation. This check is commented in the patch. > Preserving UUID and document version history on repository migration > > > Key: JCR-1972 > URL: https://issues.apache.org/jira/browse/JCR-1972 > Project: Jackrabbit Content Repository > Issue Type: Wish > Components: jackrabbit-core >Affects Versions: core 1.4.8 >Reporter: Paco Avila > Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, > JCR-1972_1.x.patch > > > I have been working I an migration utility for OpenKM and I performed some > changes in jackrabit-core to enable version import, preserving > the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to > preserve UUID in the migration process. > This migration process is needed because there are changes in repository node > definition, and Jackrabbit can't deal with this actually. > I've attache a PDF with the changes needed in Jackrabbit-core. It works and > there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paco Avila updated JCR-1972: Comment: was deleted (was: In 1.x branch, the class org.apache.jackrabbit.core.NodeImpl.java is this: public synchronized NodeImpl addNode(Name nodeName, Name nodeTypeName, UUID uuid) So, it already accept an UUID parameter for new node creation.) > Preserving UUID and document version history on repository migration > > > Key: JCR-1972 > URL: https://issues.apache.org/jira/browse/JCR-1972 > Project: Jackrabbit Content Repository > Issue Type: Wish > Components: jackrabbit-core >Affects Versions: core 1.4.8 >Reporter: Paco Avila > Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, > JCR-1972_1.x.patch > > > I have been working I an migration utility for OpenKM and I performed some > changes in jackrabit-core to enable version import, preserving > the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to > preserve UUID in the migration process. > This migration process is needed because there are changes in repository node > definition, and Jackrabbit can't deal with this actually. > I've attache a PDF with the changes needed in Jackrabbit-core. It works and > there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paco Avila updated JCR-1972: Attachment: JCR-1972_1.x.patch Updated patch for the 1.x branch > Preserving UUID and document version history on repository migration > > > Key: JCR-1972 > URL: https://issues.apache.org/jira/browse/JCR-1972 > Project: Jackrabbit Content Repository > Issue Type: Wish > Components: jackrabbit-core >Affects Versions: core 1.4.8 >Reporter: Paco Avila > Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, > JCR-1972_1.x.patch > > > I have been working I an migration utility for OpenKM and I performed some > changes in jackrabit-core to enable version import, preserving > the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to > preserve UUID in the migration process. > This migration process is needed because there are changes in repository node > definition, and Jackrabbit can't deal with this actually. > I've attache a PDF with the changes needed in Jackrabbit-core. It works and > there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Per-repository thread pool in Jackrabbit
Hello Since Java 5 there is java.util.concurrent, which provides a ScheduledThreadPoolExecutor[1]. Maybe this suits the requirements. And it does not introduce another dependency. Regards Julian [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html On Mon, Jul 13, 2009 at 2:57 PM, Felix Meschberger wrote: > Hi, > > Marcel Reutegger schrieb: >> Hi, >> >> 2009/7/12 Jukka Zitting : >>> Hi, >>> >>> 2009/7/8 Marcel Reutegger : - paralleled execution of some work. this is primarily to make use of multi-core processors. execution should be distributed over and executed by N threads which is a factor of the available processors. >>> If I recall correctly we debated this already earlier. My point was >>> that limiting the number of tasks to the number of available >>> processors may not be a good approach as the tasks may be IO-bound or >>> block for other reasons, in which case having more task threads would >>> give you better throughput. But I recall being proven wrong, did we >>> have some benchmark for that? Do you remember where this discussion >>> was? >> >> I don't remember either... But let's just start a new one. >> >> I think this very much depends on the work that needs to be distributed. >> there >> is no prove that one way is better than the other. for CPU intensive work >> we'd >> probably want to limit the number of concurrent tasks. for I/O intensive work >> the concurrency should be higher. >> >> my above point was rather related to CPU intensive work. e.g. creating a >> posting >> list while content is indexed. but of course there might be other work that >> may >> be parallelized more aggressively. >> >> I guess the actual pool shouldn't care about that. some utility on top >> of the pool >> should provide that functionality. i.e. execute a number of tasks with a >> given >> level of concurrency. the utility would then dispatch the tasks to the pool >> accordingly. >> - Timers used in TransactionContext and MultiIndex. This could be turned into a scheduling mechanism that could also be used by the ClusterNode sync. Other classes that use periodic checks in a background thread: DatabaseJournal (ClusterRevisionJanitor), CooperativeFileLock (watch dog). >>> Yep. Perhaps we could also reuse some of the scheduling functionality in >>> Sling. >> >> I'm not sure this is needed. the java rt library already comes with >> Timer and Task >> classes. our needs are very simple and I'm not sure that justifies a >> new dependency. > > Yes, AFAICT Java also has ThreadPool implementations. If not, I urge to > still _not_ reinvent the wheel and take something existing even if it > would a single dependency. > > Regards > Felix > >> the more I think about it, the more I like your idea. but we should be careful with a maximum size for a repository wide pool. extensive use of the pool by a module should not lock up another module just because there are no more idle threads. maybe that global pool shouldn't have a maximum size... >>> That might make sense. Perhaps we should have some concept of >>> sub-pools (that borrow from the main pool) with fixed limits for tasks >>> that need them (see above). >> >> hmm, that doesn't sound flexible and generic. I just thought again how cool >> it was if we could deploy jackrabbit into a google app-engine. that however >> requires that all background threads are removed. if we have that generic >> pool and client code adjusted accordingly it could be as easy as turning >> the pool into a direct executor variant ;) well, that's very optimistic but >> sounds promising to me... >> >> regards >> marcel >> >
Re: Per-repository thread pool in Jackrabbit
Hi, Marcel Reutegger schrieb: > Hi, > > 2009/7/12 Jukka Zitting : >> Hi, >> >> 2009/7/8 Marcel Reutegger : >>> - paralleled execution of some work. this is primarily to make use of >>> multi-core processors. execution should be distributed over and >>> executed by N threads which is a factor of the available processors. >> If I recall correctly we debated this already earlier. My point was >> that limiting the number of tasks to the number of available >> processors may not be a good approach as the tasks may be IO-bound or >> block for other reasons, in which case having more task threads would >> give you better throughput. But I recall being proven wrong, did we >> have some benchmark for that? Do you remember where this discussion >> was? > > I don't remember either... But let's just start a new one. > > I think this very much depends on the work that needs to be distributed. there > is no prove that one way is better than the other. for CPU intensive work we'd > probably want to limit the number of concurrent tasks. for I/O intensive work > the concurrency should be higher. > > my above point was rather related to CPU intensive work. e.g. creating a > posting > list while content is indexed. but of course there might be other work that > may > be parallelized more aggressively. > > I guess the actual pool shouldn't care about that. some utility on top > of the pool > should provide that functionality. i.e. execute a number of tasks with a given > level of concurrency. the utility would then dispatch the tasks to the pool > accordingly. > >>> - Timers used in TransactionContext and MultiIndex. This could be >>> turned into a scheduling mechanism that could also be used by the >>> ClusterNode sync. Other classes that use periodic checks in a >>> background thread: DatabaseJournal (ClusterRevisionJanitor), >>> CooperativeFileLock (watch dog). >> Yep. Perhaps we could also reuse some of the scheduling functionality in >> Sling. > > I'm not sure this is needed. the java rt library already comes with > Timer and Task > classes. our needs are very simple and I'm not sure that justifies a > new dependency. Yes, AFAICT Java also has ThreadPool implementations. If not, I urge to still _not_ reinvent the wheel and take something existing even if it would a single dependency. Regards Felix > >>> the more I think about it, the more I like your idea. but we should be >>> careful with a maximum size for a repository wide pool. extensive use >>> of the pool by a module should not lock up another module just because >>> there are no more idle threads. maybe that global pool shouldn't have >>> a maximum size... >> That might make sense. Perhaps we should have some concept of >> sub-pools (that borrow from the main pool) with fixed limits for tasks >> that need them (see above). > > hmm, that doesn't sound flexible and generic. I just thought again how cool > it was if we could deploy jackrabbit into a google app-engine. that however > requires that all background threads are removed. if we have that generic > pool and client code adjusted accordingly it could be as easy as turning > the pool into a direct executor variant ;) well, that's very optimistic but > sounds promising to me... > > regards > marcel >
[jira] Resolved: (JCR-2047) Test failure: org.apache.jackrabbit.test.TestAll
[ https://issues.apache.org/jira/browse/JCR-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2047. --- Resolution: Fixed Fix Version/s: 2.0.0 Two issues likely caused this occasional failures: - NodeTypesInContentTest does not identify itself as a read-only test - NodeTypeCreationTest is actually a test that writes to the repository and needs a different test root in the configuration both will remove the test content in their tearDown method. Fixed in revision: 793571 > Test failure: org.apache.jackrabbit.test.TestAll > > > Key: JCR-2047 > URL: https://issues.apache.org/jira/browse/JCR-2047 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-spi2jcr >Reporter: Michael Dürig > Fix For: 2.0.0 > > Attachments: org.apache.jackrabbit.test.TestAll.txt > > > Subsequent test runs fail unless doing a mvn clean first. > --- > T E S T S > --- > Running org.apache.jackrabbit.spi2jcr.spi.TestAll > Tests run: 50, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.965 sec > Running org.apache.jackrabbit.test.TestAll > Tests run: 1038, Failures: 11, Errors: 0, Skipped: 0, Time elapsed: 44.925 > sec <<< FAILURE! > Running org.apache.jackrabbit.spi2jcr.jcr2spi.TestAll > Tests run: 394, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.416 sec > Results : > Failed tests: > testOrderByAscending(org.apache.jackrabbit.test.api.query.SQLOrderByTest) > testOrderByDescending(org.apache.jackrabbit.test.api.query.SQLOrderByTest) > testOrderByDefault(org.apache.jackrabbit.test.api.query.SQLOrderByTest) > > testDocOrderIndexedNotation(org.apache.jackrabbit.test.api.query.XPathPosIndexTest) > > testDocOrderPositionFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderPositionIndex(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderLastFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderFirstFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > testOrderByAscending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderByDescending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderBy(org.apache.jackrabbit.test.api.query.XPathOrderByTest) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2205) Occasional query test failures in spi2jcr and core
[ https://issues.apache.org/jira/browse/JCR-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730327#action_12730327 ] Jukka Zitting commented on JCR-2205: Yep, duplicate. > Occasional query test failures in spi2jcr and core > -- > > Key: JCR-2205 > URL: https://issues.apache.org/jira/browse/JCR-2205 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-spi2jcr, query >Reporter: Jukka Zitting > > Every now and then I see the following tests failing in jackabbit-spi2jcr: > Failed tests: > testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testDescendantLeaf(org.apache.jackrabbit.test.api.query.SQLPathTest) > testDescendantSelfTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testChildAxisRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testChildAxisTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testChildAxisLeaf(org.apache.jackrabbit.test.api.query.SQLPathTest) > > testDocOrderIndexedNotation(org.apache.jackrabbit.test.api.query.XPathPosIndexTest) > > testDocOrderPositionFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderPositionIndex(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderLastFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderFirstFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > testOrderByAscending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderByDescending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderBy(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > All the test failures look like this: > testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > Time elapsed: 0.006 sec <<< FAILURE! > junit.framework.AssertionFailedError: Default workspace at /testdata does not > contain sufficient content. > at junit.framework.Assert.fail(Assert.java:47) > at > org.apache.jackrabbit.test.api.query.SQLPathTest.setUp(SQLPathTest.java:53) > at junit.framework.TestCase.runBare(TestCase.java:125) > 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 > org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:450) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at > org.apache.jackrabbit.test.ConcurrentTestSuite.access$001(ConcurrentTestSuite.java:29) > at > org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67) > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2047) Test failure: org.apache.jackrabbit.test.TestAll
[ https://issues.apache.org/jira/browse/JCR-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2047: -- Component/s: jackrabbit-core Also happens in jackrabbit-core > Test failure: org.apache.jackrabbit.test.TestAll > > > Key: JCR-2047 > URL: https://issues.apache.org/jira/browse/JCR-2047 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-spi2jcr >Reporter: Michael Dürig > Attachments: org.apache.jackrabbit.test.TestAll.txt > > > Subsequent test runs fail unless doing a mvn clean first. > --- > T E S T S > --- > Running org.apache.jackrabbit.spi2jcr.spi.TestAll > Tests run: 50, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.965 sec > Running org.apache.jackrabbit.test.TestAll > Tests run: 1038, Failures: 11, Errors: 0, Skipped: 0, Time elapsed: 44.925 > sec <<< FAILURE! > Running org.apache.jackrabbit.spi2jcr.jcr2spi.TestAll > Tests run: 394, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.416 sec > Results : > Failed tests: > testOrderByAscending(org.apache.jackrabbit.test.api.query.SQLOrderByTest) > testOrderByDescending(org.apache.jackrabbit.test.api.query.SQLOrderByTest) > testOrderByDefault(org.apache.jackrabbit.test.api.query.SQLOrderByTest) > > testDocOrderIndexedNotation(org.apache.jackrabbit.test.api.query.XPathPosIndexTest) > > testDocOrderPositionFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderPositionIndex(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderLastFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderFirstFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > testOrderByAscending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderByDescending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderBy(org.apache.jackrabbit.test.api.query.XPathOrderByTest) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2205) Occasional query test failures in spi2jcr and core
[ https://issues.apache.org/jira/browse/JCR-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2205. --- Resolution: Duplicate I guess that's even a duplicate. > Occasional query test failures in spi2jcr and core > -- > > Key: JCR-2205 > URL: https://issues.apache.org/jira/browse/JCR-2205 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-spi2jcr, query >Reporter: Jukka Zitting > > Every now and then I see the following tests failing in jackabbit-spi2jcr: > Failed tests: > testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testDescendantLeaf(org.apache.jackrabbit.test.api.query.SQLPathTest) > testDescendantSelfTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testChildAxisRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testChildAxisTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > testChildAxisLeaf(org.apache.jackrabbit.test.api.query.SQLPathTest) > > testDocOrderIndexedNotation(org.apache.jackrabbit.test.api.query.XPathPosIndexTest) > > testDocOrderPositionFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderPositionIndex(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderLastFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > > testDocOrderFirstFunction(org.apache.jackrabbit.test.api.query.XPathDocOrderTest) > testOrderByAscending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderByDescending(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > testOrderBy(org.apache.jackrabbit.test.api.query.XPathOrderByTest) > All the test failures look like this: > testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) > Time elapsed: 0.006 sec <<< FAILURE! > junit.framework.AssertionFailedError: Default workspace at /testdata does not > contain sufficient content. > at junit.framework.Assert.fail(Assert.java:47) > at > org.apache.jackrabbit.test.api.query.SQLPathTest.setUp(SQLPathTest.java:53) > at junit.framework.TestCase.runBare(TestCase.java:125) > 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 > org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:450) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at > org.apache.jackrabbit.test.ConcurrentTestSuite.access$001(ConcurrentTestSuite.java:29) > at > org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67) > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)
The article should still works, because it follow Michael's instruction. Just noticed it's quite old: August 15, 2007. I did a try for m2eclipse recently and it give much better experience than it's early version. It has a GUI to manage your pom (You don't need to check the pom model manual any more) and update eclipse dependencies automatically. Import and run goals inside IDE also give better productivity. -- Guo On Mon, Jul 13, 2009 at 12:53 PM, Paco Avila wrote: > > This article is very clear about it: > > http://www.jroller.com/cdaniluk/entry/setting_up_an_eclipse_multi > > I will try this instructions. > On Mon, Jul 13, 2009 at 1:09 PM, Michael Dürig wrote: >>> I've some problems developing with jackrabbit in Eclipse. Where can I >>> find >>> some info about this? >> >> There are many ways to do this, but I'm pretty happy with the >> m2eclipse plugin from http://m2eclipse.sonatype.org/. >> >> The plugin installs cleanly from the update site at >> http://m2eclipse.sonatype.org/update/, and after that I can use File > >> Import... > Maven Projects and point the dialog to the root of my >> checkout. The importer will correctly find and set up all the >> components as separate projects in Eclipse. > > I use a similar approach but without the m2eclipse plugin. Rather I use > Maven from the command line: > > mvn clean install > mvn eclipse:eclipse > > and then import the generated eclipse project files with Eclipse. > > This approach works generally quite well. > > Michael > > -- Kind regards, Du, Guo __ Phone : +353-86-176 6186 Email : onl...@duguo.com __ http://duguo.com - Career Life Balance
[jira] Updated: (JCR-2085) test case (TCK) maintenance for JCR 2.0
[ https://issues.apache.org/jira/browse/JCR-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-2085: Attachment: apicoverage.html API coverage as of July 13: 488/514 = ~94% > test case (TCK) maintenance for JCR 2.0 > --- > > Key: JCR-2085 > URL: https://issues.apache.org/jira/browse/JCR-2085 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-jcr-tests >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 2.0.0 > > Attachments: apicoverage.html, apicoverage.html, apicoverage.html, > apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, > apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, > apicoverage.html, jcrtests-binary.patch, jcrtests-versioning-2.patch, > jcrtests-versioning.patch > > > Umbrella issue for changes/additions to JUnit test cases, setup and config. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)
I've some problems developing with jackrabbit in Eclipse. Where can I find some info about this? There are many ways to do this, but I'm pretty happy with the m2eclipse plugin from http://m2eclipse.sonatype.org/. The plugin installs cleanly from the update site at http://m2eclipse.sonatype.org/update/, and after that I can use File > Import... > Maven Projects and point the dialog to the root of my checkout. The importer will correctly find and set up all the components as separate projects in Eclipse. I use a similar approach but without the m2eclipse plugin. Rather I use Maven from the command line: mvn clean install mvn eclipse:eclipse and then import the generated eclipse project files with Eclipse. This approach works generally quite well. Michael
Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)
Hi, On Mon, Jul 13, 2009 at 1:03 PM, Paco Avila wrote: > I've some problems developing with jackrabbit in Eclipse. Where can I find > some info about this? There are many ways to do this, but I'm pretty happy with the m2eclipse plugin from http://m2eclipse.sonatype.org/. The plugin installs cleanly from the update site at http://m2eclipse.sonatype.org/update/, and after that I can use File > Import... > Maven Projects and point the dialog to the root of my checkout. The importer will correctly find and set up all the components as separate projects in Eclipse. It helps if you've done a normal Maven build before importing the projects, as then all the generated sources will also be available to Eclipse. BR, Jukka Zitting
[jira] Commented: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730304#action_12730304 ] Paco Avila commented on JCR-1972: - In 1.x branch, the class org.apache.jackrabbit.core.NodeImpl.java is this: public synchronized NodeImpl addNode(Name nodeName, Name nodeTypeName, UUID uuid) So, it already accept an UUID parameter for new node creation. > Preserving UUID and document version history on repository migration > > > Key: JCR-1972 > URL: https://issues.apache.org/jira/browse/JCR-1972 > Project: Jackrabbit Content Repository > Issue Type: Wish > Components: jackrabbit-core >Affects Versions: core 1.4.8 >Reporter: Paco Avila > Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch > > > I have been working I an migration utility for OpenKM and I performed some > changes in jackrabit-core to enable version import, preserving > the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to > preserve UUID in the migration process. > This migration process is needed because there are changes in repository node > definition, and Jackrabbit can't deal with this actually. > I've attache a PDF with the changes needed in Jackrabbit-core. It works and > there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is JCR-1972 going to be included?
This article is very clear about it: http://www.jroller.com/cdaniluk/entry/setting_up_an_eclipse_multi I will try this instructions. On Mon, Jul 13, 2009 at 1:03 PM, Paco Avila wrote: > I've some problems developing with jackrabbit in Eclipse. Where can I find > some info about this? The "problem" is due maven2 modules and Eclipse > project mapping. I have spend some time searching in Google with little > luck. > > > On Fri, Jul 10, 2009 at 4:23 PM, Jukka Zitting wrote: > >> Hi, >> >> On Fri, Jul 10, 2009 at 4:10 PM, Paco Avila wrote: >> > I will try to send the patch in a couple of days. >> >> Thanks! There's no pressing need for the 1.6 release, so I don't mind >> waiting a bit longer before cutting the release candidate. >> >> BR, >> >> Jukka Zitting >> > > > > -- > Paco Avila > GIT Consultors > tel: +34 971 498310 > fax: +34 971496189 > e-mail: pav...@git.es > http://www.git.es > -- Paco Avila GIT Consultors tel: +34 971 498310 fax: +34 971496189 e-mail: pav...@git.es http://www.git.es
[jira] Updated: (JCR-1736) Expose BootstrapConfig in Servlets
[ https://issues.apache.org/jira/browse/JCR-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1736: --- Resolution: Fixed Fix Version/s: 1.6.0 Status: Resolved (was: Patch Available) I applied the patch to trunk in revision 793559 and to the 1.x branch in revision 793561. > Expose BootstrapConfig in Servlets > -- > > Key: JCR-1736 > URL: https://issues.apache.org/jira/browse/JCR-1736 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-webapp >Affects Versions: 1.4 >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Minor > Fix For: 1.6.0 > > Attachments: bootstrapconfig.r695761.patch > > > the RepostitoryStartup and RepositroyAccess servlets use a bootstrap config > object for initialization. in order to generate diagnostics reports it would > be very useful to be able to access them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is JCR-1972 going to be included?
I've some problems developing with jackrabbit in Eclipse. Where can I find some info about this? The "problem" is due maven2 modules and Eclipse project mapping. I have spend some time searching in Google with little luck. On Fri, Jul 10, 2009 at 4:23 PM, Jukka Zitting wrote: > Hi, > > On Fri, Jul 10, 2009 at 4:10 PM, Paco Avila wrote: > > I will try to send the patch in a couple of days. > > Thanks! There's no pressing need for the 1.6 release, so I don't mind > waiting a bit longer before cutting the release candidate. > > BR, > > Jukka Zitting > -- Paco Avila GIT Consultors tel: +34 971 498310 fax: +34 971496189 e-mail: pav...@git.es http://www.git.es
[jira] Resolved: (JCR-2201) Implement QueryResult.getSelectorNames()
[ https://issues.apache.org/jira/browse/JCR-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2201. --- Resolution: Fixed Fix Version/s: 2.0.0 Implemented in revision: 793507 > Implement QueryResult.getSelectorNames() > > > Key: JCR-2201 > URL: https://issues.apache.org/jira/browse/JCR-2201 > Project: Jackrabbit Content Repository > Issue Type: Sub-task >Reporter: Jukka Zitting > Fix For: 2.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2200) Implement Query.getBindVariableNames()
[ https://issues.apache.org/jira/browse/JCR-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2200. --- Resolution: Fixed Fix Version/s: 2.0.0 Implemented in revision: 793484 > Implement Query.getBindVariableNames() > -- > > Key: JCR-2200 > URL: https://issues.apache.org/jira/browse/JCR-2200 > Project: Jackrabbit Content Repository > Issue Type: Sub-task >Reporter: Jukka Zitting >Assignee: Marcel Reutegger > Fix For: 2.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: node type nt:file
Tobias Bocanegra wrote: hi, no, the jcr:content node is not created automatically. ... But it maybe in some repositories, so make sure to handle that case as well :-) BR, Julian
Re: Per-repository thread pool in Jackrabbit
Hi, 2009/7/12 Jukka Zitting : > Hi, > > 2009/7/8 Marcel Reutegger : >> - paralleled execution of some work. this is primarily to make use of >> multi-core processors. execution should be distributed over and >> executed by N threads which is a factor of the available processors. > > If I recall correctly we debated this already earlier. My point was > that limiting the number of tasks to the number of available > processors may not be a good approach as the tasks may be IO-bound or > block for other reasons, in which case having more task threads would > give you better throughput. But I recall being proven wrong, did we > have some benchmark for that? Do you remember where this discussion > was? I don't remember either... But let's just start a new one. I think this very much depends on the work that needs to be distributed. there is no prove that one way is better than the other. for CPU intensive work we'd probably want to limit the number of concurrent tasks. for I/O intensive work the concurrency should be higher. my above point was rather related to CPU intensive work. e.g. creating a posting list while content is indexed. but of course there might be other work that may be parallelized more aggressively. I guess the actual pool shouldn't care about that. some utility on top of the pool should provide that functionality. i.e. execute a number of tasks with a given level of concurrency. the utility would then dispatch the tasks to the pool accordingly. >> - Timers used in TransactionContext and MultiIndex. This could be >> turned into a scheduling mechanism that could also be used by the >> ClusterNode sync. Other classes that use periodic checks in a >> background thread: DatabaseJournal (ClusterRevisionJanitor), >> CooperativeFileLock (watch dog). > > Yep. Perhaps we could also reuse some of the scheduling functionality in > Sling. I'm not sure this is needed. the java rt library already comes with Timer and Task classes. our needs are very simple and I'm not sure that justifies a new dependency. >> the more I think about it, the more I like your idea. but we should be >> careful with a maximum size for a repository wide pool. extensive use >> of the pool by a module should not lock up another module just because >> there are no more idle threads. maybe that global pool shouldn't have >> a maximum size... > > That might make sense. Perhaps we should have some concept of > sub-pools (that borrow from the main pool) with fixed limits for tasks > that need them (see above). hmm, that doesn't sound flexible and generic. I just thought again how cool it was if we could deploy jackrabbit into a google app-engine. that however requires that all background threads are removed. if we have that generic pool and client code adjusted accordingly it could be as easy as turning the pool into a direct executor variant ;) well, that's very optimistic but sounds promising to me... regards marcel
