Re: Clustering w/ distributed cache
Hi, Do you have experience with memcached for Java? http://www.thimbleware.com/projects/jmemcached >From what I read it is a client-server solution, you would have to serialize / deserialize objects, which would slow down things a lot (compared to having the cache in the Java heap memory). Regards, Thomas On Mon, Feb 16, 2009 at 9:02 PM, defeng wrote: > > I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and NFS > for datastore. Everything works well, but since the Jackrabbit uses a > Cluster-wide lock, many times, other JCR clients need to wait for a long > time to acquire the Global lock. > > To solve this issue, I want to use a distributed cache(memcached) in > SharedISM. To disable cache in SessionISM and LocalISM (I did not use XA ). > So there is no necessary to sync any data in cache. In addition, I donot > need to register Namespace or Nodetype at runtime. The only thing is to > sync > local search index in the Looping of ClusterNode. (I did not use > AccessManager in Jackrabbit) > > When updating an item, a distributed lock is acquired. It is used to ensure > the data consistence between persisten manager and distributed cache > (2-phase commit). > > Is the proposal feasible? Any comment is highly appreciated! > -- > View this message in context: > http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22044598.html > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. > >
Hudson build is back to stable: Jac krabbit-trunk » Jackrabbit Core #363
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/363/changes
Re: Hudson build is back to stable: Jackrabbit-trunk » Jackrabbit Core #363
Hi, I just re-run the Hudson build after the ISMLocking failures yesterday. No changes were made meanwhile, so the failure looks like a random problem. Let's keep an eye out for similar issues in the future. BR, Jukka Zitting
Re: Jackrabbit 1.5.3 release plan
Hi, On Mon, Feb 16, 2009 at 11:54 AM, Marcel Reutegger wrote: > On Mon, Feb 16, 2009 at 09:14, Marcel Reutegger > wrote: >> I'll have a look at the patch today and provide feedback. > > this feature also requires changes to jackrabbit-spi-commons. that's > where the query parsers are located. IIUC, the plan is to just release > a jackrabbit-core 1.5.3, right? We'll release everything in the 1.5 branch, but only those components that have been changed have their version numbers updated to 1.5.3 and binary artifacts uploaded to the central Maven repository. > I think we should rather defer this to the 1.6 release, otherwise we > introduce dependencies between patch releases of the 1.5 branch. that > is, a jackrabbit-core 1.5.3 would require a jackrabbit-spi-commons > 1.5.3. Hmm, agreed. Jackrabbit 1.6 is a better place for that. Dan, I hope you'll be OK with a custom build for now until Jackrabbit 1.6 is out? BR, Jukka Zitting
[jira] Created: (JCR-1981) Test class in the main source tree
Test class in the main source tree -- Key: JCR-1981 URL: https://issues.apache.org/jira/browse/JCR-1981 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Reporter: Thomas Mueller org.apache.jackrabbit.core.TestRepository is in the main source folder (src/main/java) instead of the test folder (src/test/java). The build of jackrabbit-core is successful even if I move the class to the test folder, so it looks like it was just a mistake. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1981) Test class in the main source tree
[ https://issues.apache.org/jira/browse/JCR-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1981. - Resolution: Fixed Committed in revision 745041 > Test class in the main source tree > -- > > Key: JCR-1981 > URL: https://issues.apache.org/jira/browse/JCR-1981 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Reporter: Thomas Mueller > > org.apache.jackrabbit.core.TestRepository is in the main source folder > (src/main/java) instead of the test folder (src/test/java). > The build of jackrabbit-core is successful even if I move the class > to the test folder, so it looks like it was just a mistake. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1982) Exception root cause is swallowed in various places
Exception root cause is swallowed in various places --- Key: JCR-1982 URL: https://issues.apache.org/jira/browse/JCR-1982 Project: Jackrabbit Content Repository Issue Type: Bug Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor When re-throwing an exception, the root cause is swallowed in some places in Jackrabbit, mainly when converting to an IOException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1981) Test class in the main source tree
[ https://issues.apache.org/jira/browse/JCR-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1981: --- Priority: Minor (was: Major) Issue Type: Improvement (was: Bug) I introduced the TestRepository class in JCR-368 to make it easier for people to submit new test cases that they could easily run both within and outside the main Jackrabbit test suite. As such it explicitly belongs to src/main/java. However, I haven't seen anyone really use the class and I'm not sure how well it even works anymore. So perhaps we should simply drop the entire class. Anyway, I changed this to an improvement issue, as the class being in src/main/java was not a mistake. > Test class in the main source tree > -- > > Key: JCR-1981 > URL: https://issues.apache.org/jira/browse/JCR-1981 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Thomas Mueller >Priority: Minor > > org.apache.jackrabbit.core.TestRepository is in the main source folder > (src/main/java) instead of the test folder (src/test/java). > The build of jackrabbit-core is successful even if I move the class > to the test folder, so it looks like it was just a mistake. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1982) Exception root cause is swallowed in various places
[ https://issues.apache.org/jira/browse/JCR-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1982. - Resolution: Fixed Committed in revision 745051 (when creating a BLOB object), revision 745053 (on configuration error), revision 745056 (on namespace index error), revision 745060 (on nodetype I/O error). > Exception root cause is swallowed in various places > --- > > Key: JCR-1982 > URL: https://issues.apache.org/jira/browse/JCR-1982 > Project: Jackrabbit Content Repository > Issue Type: Bug >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > > When re-throwing an exception, the root cause is swallowed in some places in > Jackrabbit, mainly when converting to an IOException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r745051 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/value: BLOBInResource.java BLOBValue.java
Hi, On Tue, Feb 17, 2009 at 2:35 PM, wrote: > -throw new IOException(fsResource.getPath() > +IOException e2 = new IOException(fsResource.getPath() > + ": Error while creating value: " + fse.toString()); > +e2.initCause(fse); > +throw e2; There's a nice utility class in Commons IO 1.4 for this purpose. See IOExceptionWithCause [1]. [1] http://commons.apache.org/io/api-release/org/apache/commons/io/IOExceptionWithCause.html BR, Jukka Zitting
Re: svn commit: r745051 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/value: BLOBInResource.java BLOBValue.java
Hi Jukka, Hm... Sorry, I should have waited with committing the changes... I didn't knew about this class. I will use it in the future (but leave the code right now). Regards, Thomas On Tue, Feb 17, 2009 at 2:46 PM, Jukka Zitting wrote: > Hi, > > On Tue, Feb 17, 2009 at 2:35 PM, wrote: > > -throw new IOException(fsResource.getPath() > > +IOException e2 = new IOException(fsResource.getPath() > > + ": Error while creating value: " + fse.toString()); > > +e2.initCause(fse); > > +throw e2; > > There's a nice utility class in Commons IO 1.4 for this purpose. See > IOExceptionWithCause [1]. > > [1] > http://commons.apache.org/io/api-release/org/apache/commons/io/IOExceptionWithCause.html > > BR, > > Jukka Zitting >
Re: svn commit: r745051 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/value: BLOBInResource.java BLOBValue.java
Hi, On Tue, Feb 17, 2009 at 2:55 PM, Thomas Müller wrote: > Hm... Sorry, I should have waited with committing the changes... I didn't > knew about this class. I will use it in the future (but leave the code right > now). Yeah, that's fine. Just wanted to point it out for future use. BR, Jukka Zitting
Build failed in Hudson: Jackrabbit-trunk-java14 #83
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/83/changes
Changes:
[thomasm] JCR-1982 Exception root cause is swallowed on nodetype I/O error
[thomasm] JCR-1982 Exception root cause is swallowed when on namespace index
error
[thomasm] JCR-1982 Exception root cause is swallowed on configuration error
[thomasm] JCR-1982 Exception root cause is swallowed when creating a BLOB object
[thomasm] JCR-1981 Test class in the main source tree
--
[...truncated 242 lines...]
[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:
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
[INFO] [jar:jar {execution: default}]
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar:
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
[INFO] [install:install]
[INFO] Installing
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
to
/export/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT.jar
[INFO] Installing
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
to
/export/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
[INFO] Installing
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
to
/export/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
[INFO] [maven-one-plugin:install-maven-one-repository {execution: default}]
[INFO] Installing
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
to
/export/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-spi-1.6-SNAPSHOT.jar
[INFO] Installing
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
to
/export/home/hudson/.maven/repository/org.apache.jackrabbit/java-sources/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
[INFO] Installing
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
to
/export/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
[INFO]
[INFO] Building Jackrabbit SPI Commons
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target
(included: [**], excluded: [])
[INFO] [javacc:jjtree-javacc {execution: sql}]
Java Compiler Compiler Version 4.0 (Tree Builder)
(type "jjtree" with no arguments for help)
Reading from file
/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/src/main/javacc/sql/JCRSQL.jjt
. . .
File
"/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/Node.java"
does not exist. Will create one.
File
"/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/SimpleNode.java"
does not exist. Will create one.
File
"/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/ASTQuery.java"
does not exist. Will create one.
File
"/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/ASTSelectList.java"
does not exist. Will create one.
File
"/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/ASTFromClause.java"
does not exist. Will create one.
File
"/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/targe
Re: Build failed in Hudson: Jackrabbit-trunk-java14 #83
Hi,
I used a Java 1.5 constructor... I will fix it.
Regards,
Thomas
On Tue, Feb 17, 2009 at 4:19 PM, Apache Hudson Server <
hud...@hudson.zones.apache.org> wrote:
> See
> http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/83/changes
>
> Changes:
>
> [thomasm] JCR-1982 Exception root cause is swallowed on nodetype I/O error
>
> [thomasm] JCR-1982 Exception root cause is swallowed when on namespace
> index error
>
> [thomasm] JCR-1982 Exception root cause is swallowed on configuration error
>
> [thomasm] JCR-1982 Exception root cause is swallowed when creating a BLOB
> object
>
> [thomasm] JCR-1981 Test class in the main source tree
>
> --
> [...truncated 242 lines...]
> [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:
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
> [INFO] [jar:jar {execution: default}]
> [INFO] [jar:test-jar {execution: default}]
> [INFO] Building jar:
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
> [INFO] [install:install]
> [INFO] Installing
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
> to
> /export/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT.jar
> [INFO] Installing
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
> to
> /export/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
> [INFO] Installing
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
> to
> /export/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
> [INFO] [maven-one-plugin:install-maven-one-repository {execution: default}]
> [INFO] Installing
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
> to
> /export/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-spi-1.6-SNAPSHOT.jar
> [INFO] Installing
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
> to
> /export/home/hudson/.maven/repository/org.apache.jackrabbit/java-sources/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
> [INFO] Installing
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
> to
> /export/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
> [INFO]
>
> [INFO] Building Jackrabbit SPI Commons
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting file set:
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target
> (included: [**], excluded: [])
> [INFO] [javacc:jjtree-javacc {execution: sql}]
> Java Compiler Compiler Version 4.0 (Tree Builder)
> (type "jjtree" with no arguments for help)
> Reading from file
> /zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/src/main/javacc/sql/JCRSQL.jjt
> . . .
> File
> "/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/Node.java"
> does not exist. Will create one.
> File
> "/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/SimpleNode.java"
> does not exist. Will create one.
> File
> "/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/ASTQuery.java"
> does not exist. Will create one.
> File
> "/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-trunk-java14/workspace/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/sql/ASTSelectList.java"
> does not exist. Will create one.
> File
> "/zonestorage/hudson/home/hudson/hudson/jobs/Jackrabbit-tru
[jira] Commented: (JCR-1982) Exception root cause is swallowed in various places
[ https://issues.apache.org/jira/browse/JCR-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674237#action_12674237 ] Thomas Mueller commented on JCR-1982: - Revision 745120 (on namespace index error; was using a Java 1.5 constructor before) > Exception root cause is swallowed in various places > --- > > Key: JCR-1982 > URL: https://issues.apache.org/jira/browse/JCR-1982 > Project: Jackrabbit Content Repository > Issue Type: Bug >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > > When re-throwing an exception, the root cause is swallowed in some places in > Jackrabbit, mainly when converting to an IOException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Clustering w/ distributed cache
Thank for you reply. I used the memcache in other projects before, the performance seems good. Facebook did some enhancement on it. http://github.com/blog/267-facebook-s-memcached-on-github. You are right, we have to serialize/deserialize objects. But that's the price we have to pay for the clustering, is it? In current clustering, one operation (for example, modify a property) will block entire clustering. It's terrible for us. we want to change the cluster-wide lock to item-wide, based on distributed lock with memcached. Another thought is to disable clustering/journal configuration. All cluster nodes use same distributed cache, DB and NFS. Since no local cache again, we only need to use JMS (activemq) to notify Local Search Index udpating. I noticed "Native Clustering" was on the Jackrabbit Roadmap - 3.0. What's the schedule for 3.0? Thomas Müller-2 wrote: > > Hi, > > Do you have experience with memcached for Java? > http://www.thimbleware.com/projects/jmemcached > From what I read it is a client-server solution, you would have to > serialize > / deserialize objects, which would slow down things a lot (compared to > having the cache in the Java heap memory). > > Regards, > Thomas > > > > On Mon, Feb 16, 2009 at 9:02 PM, defeng wrote: > >> >> I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and >> NFS >> for datastore. Everything works well, but since the Jackrabbit uses a >> Cluster-wide lock, many times, other JCR clients need to wait for a long >> time to acquire the Global lock. >> >> To solve this issue, I want to use a distributed cache(memcached) in >> SharedISM. To disable cache in SessionISM and LocalISM (I did not use XA >> ). >> So there is no necessary to sync any data in cache. In addition, I donot >> need to register Namespace or Nodetype at runtime. The only thing is to >> sync >> local search index in the Looping of ClusterNode. (I did not use >> AccessManager in Jackrabbit) >> >> When updating an item, a distributed lock is acquired. It is used to >> ensure >> the data consistence between persisten manager and distributed cache >> (2-phase commit). >> >> Is the proposal feasible? Any comment is highly appreciated! >> -- >> View this message in context: >> http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22044598.html >> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Clustering-w--distributed-cache-tp22044598p22059652.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] Resolved: (JCR-1847) Path methods should throw a specific exception instead of RepositoryEx
[ https://issues.apache.org/jira/browse/JCR-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1847. - Resolution: Won't Fix Assignee: angela won't reach consensus on this. introducing "a helper class had its own exception" just restores the situation we had with "BaseException" and which we finally got rid of. resolving won't fix. > Path methods should throw a specific exception instead of RepositoryEx > -- > > Key: JCR-1847 > URL: https://issues.apache.org/jira/browse/JCR-1847 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi >Reporter: Alexander Klimetschek >Assignee: angela >Priority: Minor > > The o.a.j.spi.Path interface declares most methods to throw a RepositoryEx, > whereas a o.a.j.spi.commons.conversion.NameEx (or another specific exception) > would make more sense, since the RepositoryEx is too generic for what seems > to be a "malformed names/path" nature for all things that happen in a Path > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCR meetup in Amsterdam?
Hi, On Fri, Feb 13, 2009 at 10:55 AM, Jukka Zitting wrote: > On Thu, Feb 12, 2009 at 11:05 AM, Jukka Zitting > wrote: >> The meetup will only happen if we can find enough attendees, >> presentations and sponsors. Please let me know, preferably already by >> the end of this week, if you'd be interested in participating. > > As was pointed out in private, I didn't leave any place for people to > sign up. I just created a wiki page for that, see [1]. You can also > email me in private if you like. > > [1] http://wiki.apache.org/jackrabbit/JcrMeetupMarch2009 Thanks for everyone who's already signed up on the wiki or in private email! However, we're still short of enough interest to make the meetup worth organizing. So please let me know if you're considering attending. If we can't find enough interest, we'll do just a normal BoF session at the ApacheCon. BR, Jukka Zitting
[jira] Commented: (JCR-1847) Path methods should throw a specific exception instead of RepositoryEx
[ https://issues.apache.org/jira/browse/JCR-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674259#action_12674259 ] Thomas Mueller commented on JCR-1847: - I think just RepositoryException with an error codes would be better, as in JDBC (example: http://www.h2database.com/javadoc/org/h2/constant/ErrorCode.html ). Unfortunately RepositoryException doesn't have an error code. Specific exception just bloats everything (methods tend to end with "throws a, b, c, d,...", and there are many catch/throw cases). The JCR 1.0 API already has 18 exception types, which seems like far too many in my view. Even more radical: only use unchecked exceptions (RepositoryException extends RuntimeException). So you don't have to catch / re-throw. Most modern languages (for example Scala) don't have checked exceptions any more. > Path methods should throw a specific exception instead of RepositoryEx > -- > > Key: JCR-1847 > URL: https://issues.apache.org/jira/browse/JCR-1847 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi >Reporter: Alexander Klimetschek >Assignee: angela >Priority: Minor > > The o.a.j.spi.Path interface declares most methods to throw a RepositoryEx, > whereas a o.a.j.spi.commons.conversion.NameEx (or another specific exception) > would make more sense, since the RepositoryEx is too generic for what seems > to be a "malformed names/path" nature for all things that happen in a Path > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Addendum to CCLA of Day Management
Hi Sam, I would like to extend the list of employees covered in the CCLA of Day Management to the following: The "Schedule A" (list of covered employees) addendum Tobias Bocanegra tri...@apache.org Bertrand Delacretaz bdelacre...@apache.org Michael Duerig mdue...@apache.org Roy T. Fielding field...@apache.org Stefan Guggisbergste...@apache.org Alex Klimetschek alex...@apache.org Philipp Koch pk...@apache.org Felix Meschbergerfmesc...@apache.org Thomas Mueller thom...@apache.org David Nuescheler unc...@apache.org Dominique Pfisterdpfis...@apache.org Peeter Piegaze ppieg...@apache.org Marcel Reutegger mreut...@apache.org Angela Schreiber ang...@apache.org Carsten Ziegeler cziege...@apache.org Jukka Zittingju...@apache.org I also faxed this list to (410)-803-2258. please let me know if there is anything else you need. regards, david -- David Nuescheler Chief Technology Officer Day Software AG Barfuesserplatz 6 / Postfach 4001 Basel Switzerland T 41 61 226 98 98 F 41 61 226 98 97
Hudson build is back to normal: Jackrabbit-trunk-java14 #84
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/84/changes
[jira] Updated: (JCR-1983) Provide change log consolidator
[ https://issues.apache.org/jira/browse/JCR-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated JCR-1983: --- Attachment: JCR-1983.patch Suggested implementation > Provide change log consolidator > --- > > Key: JCR-1983 > URL: https://issues.apache.org/jira/browse/JCR-1983 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi-commons >Reporter: Michael Dürig >Priority: Minor > Attachments: JCR-1983.patch > > > spi-commons should provide base implementations for consolidating change logs > (Batch). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1983) Provide change log consolidator
Provide change log consolidator --- Key: JCR-1983 URL: https://issues.apache.org/jira/browse/JCR-1983 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-spi-commons Reporter: Michael Dürig Priority: Minor Attachments: JCR-1983.patch spi-commons should provide base implementations for consolidating change logs (Batch). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1983) Provide change log consolidator
[ https://issues.apache.org/jira/browse/JCR-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674283#action_12674283 ] Michael Dürig commented on JCR-1983: The patch adds an interface o.a.j.spi.commons.batch.ChangeLog. A ChangeLog is a specialized Batch which keeps a list of Operations. The apply method applies these operations to another batch. There are two implementations of the ChangLog interface in the patch: ChangeLogImpl and ConsolidatingChangeLog. ChangeLogImpl implements the default behavior for a ChangeLog. ConsolidatingChangeLog is a specialization of ChangeLogImpl and does some simple consolidation (i.e. addNode followed by deleteNode operations cancel each other). > Provide change log consolidator > --- > > Key: JCR-1983 > URL: https://issues.apache.org/jira/browse/JCR-1983 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi-commons >Reporter: Michael Dürig >Priority: Minor > Attachments: JCR-1983.patch > > > spi-commons should provide base implementations for consolidating change logs > (Batch). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1847) Path methods should throw a specific exception instead of RepositoryEx
[ https://issues.apache.org/jira/browse/JCR-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674340#action_12674340 ] Alexander Klimetschek commented on JCR-1847: > introducing "a helper class had its own exception" just restores the > situation we had with "BaseException" and which we finally got rid of. AFAIK BaseException was used for everything in commons, so it has not the same semantics as a (new) "InvalidPathException". But the longer I look at it, the real issue is that internal code uses the spi Path interface for path related utilites - which seems not right to me - especially if there is no specific exception for a malformed path, what I would consider as a missing feature of that utility API. > Path methods should throw a specific exception instead of RepositoryEx > -- > > Key: JCR-1847 > URL: https://issues.apache.org/jira/browse/JCR-1847 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi >Reporter: Alexander Klimetschek >Assignee: angela >Priority: Minor > > The o.a.j.spi.Path interface declares most methods to throw a RepositoryEx, > whereas a o.a.j.spi.commons.conversion.NameEx (or another specific exception) > would make more sense, since the RepositoryEx is too generic for what seems > to be a "malformed names/path" nature for all things that happen in a Path > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674475#action_12674475 ] James Snyder commented on JCR-1187: --- To get around this issue using the OCM, I had to clear the OCM request cache to get a new stream. I am using the db data store, but I am not sure why this worked given the description of the bug. > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1847) Path methods should throw a specific exception instead of RepositoryEx
[ https://issues.apache.org/jira/browse/JCR-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674501#action_12674501 ] angela commented on JCR-1847: - > AFAIK BaseException was used for everything in commons, so it has not the > same semantics > as a (new) "InvalidPathException". the base exception was used solely inside jackrabbit-core just exactly to deal with invalid (malformed) path, unknown names, invalid names, item-state exceptions etc. and it was caught again within jackrabbit-core and rethrown as RepositoryException (in very exceptional cases a subclass of it) all over the place. > Path methods should throw a specific exception instead of RepositoryEx > -- > > Key: JCR-1847 > URL: https://issues.apache.org/jira/browse/JCR-1847 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-spi >Reporter: Alexander Klimetschek >Assignee: angela >Priority: Minor > > The o.a.j.spi.Path interface declares most methods to throw a RepositoryEx, > whereas a o.a.j.spi.commons.conversion.NameEx (or another specific exception) > would make more sense, since the RepositoryEx is too generic for what seems > to be a "malformed names/path" nature for all things that happen in a Path > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
