[cmis] api and general structure, client implementation
hi all, i think we are making great progress on the server side of the cmis implementation and it is great to see both the ws and the atompub binding progress so quickly. since i think it should also be a goal of this implementation to make our code as re-uable as possible, it is great that it does not have any specific proprietary jackrabbit dependencies but really just jcr dependencies. on top of that i think it would also be great to expose the entire cmis model as a separate api. i think dominique already submitted an issue around specifying an api, so both the ws and the atompub binding can use that. https://issues.apache.org/jira/browse/JCRCMIS-7 i would like to take that a step further and also propose that we have a cmis client. i think this is something that is really important and help everybody developing something around cmis a great deal. so. i would propose that we have an svn subproject structure that is something like this. jcr-cmis/ server/ client/ api/ does that make sense? regards, david -- Visit: http://dev.day.com/
[jira] Updated: (JCR-1932) Session.getAttributes( ) call always returns an empty array
[ https://issues.apache.org/jira/browse/JCR-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] alessandro cosenza updated JCR-1932: Summary: Session.getAttributes( ) call always returns an empty array (was: bug in JCR API Session.getAttributes( ) call) Session.getAttributes( ) call always returns an empty array --- Key: JCR-1932 URL: https://issues.apache.org/jira/browse/JCR-1932 Project: Jackrabbit Issue Type: Bug Components: JCR API Reporter: alessandro cosenza Attachments: bug.txt Repository repository = new RMIRemoteRepository(//localhost:1099/jackrabbit.repository); SimpleCredentials c = new SimpleCredentials(alex,ok.toCharArray()); c.setAttribute(anAttribute, aValue); Session s = repository.login(c, aWorkspace); String[]attr=s.getAttributeNames(); array attr is empty. according to docs it should contains attributes from the SimpleCredentials object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1892) Unique ID for org.apache.jackrabbit.value.BinaryValue
[ https://issues.apache.org/jira/browse/JCR-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662918#action_12662918 ] Thomas Mueller commented on JCR-1892: - What about The identifier is opaque, meaning it can have any format and size, however it is at normally about 50 characters and at most 255 characters long. The string only contains Unicode code points from 32 to 127 (including). For some databases, the VARCHAR limit is 255. Unicode code points 32 to 127 are the same in ASCII, and I don't like to exclude ':' and '/' to support URLs; and I don't like to exclude base64 encoding. If you already have a DataIdentifier for something, then it's highly likely that the corresponding record also exists in the DataStore One use case is fast data migration (from one repository to another). In that case the record usually doesn't exist yet. I don't see any harm in getRecordIfStored(). Unique ID for org.apache.jackrabbit.value.BinaryValue - Key: JCR-1892 URL: https://issues.apache.org/jira/browse/JCR-1892 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Thomas Mueller Assignee: Thomas Mueller Attachments: JackrabbitValue-api.patch, JackrabbitValue-core.patch BinaryValue should have a method get the unique identifier (if one is available). That way an application may not have to read the stream if that value is already processed. When the DataStore is used, a unique identifier is available, so probably this feature is quite simple to implement. See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html (but please don't reply to this thread from now on - instead add comments to this issue). Another feature is getFileName() to get the file name if it is stored in the file system. This method may need a security mechanism, for example getFileName(Session s) so that the system can check it. In any case the file should not be modified, but maybe knowing the file name is already too dangerous in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Website] Prominent links to articles
Hi all, there are a lot of good both introductionary and detailed articles about JCR and Jackrabbit on the web. We link them on the wiki [1], but this requires to non-obvious clicks from the jackrabbit homepage (wiki - jcr links) amongst dozens of others. Therefore I would like to create a new Articles page on the website, that should be part of the Apache Jackrabbit section in the top-right of the navigation sidebar. This page would basically do the same as the JcrLinks wiki page, but reduced to a smaller set and cleaned up - for the rest we can directly link to the wiki page. In addition, I would link to that page from the Getting Started page [2] (See here for some good articles explaining the concepts). That page should also link to all the pages it mentions and lead to First hops as a logically next step for anyone that wants to code with Jackrabbit. Finally I would improve the home page and include prominent links to those pages (Look at Getting Started, If you are new to JCR and Jackrabbit, here are some good introductions and tutorials). I think currently a new visitor has no clue what to explore first on the homepage. And all the articles already give a good documentation (which we ...ahem... lack a bit). WDYT? [1] http://wiki.apache.org/jackrabbit/JcrLinks [2] http://jackrabbit.apache.org/getting-started-with-apache-jackrabbit.html Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: [Website] Prominent links to articles
Hi, On Mon, Jan 12, 2009 at 1:15 PM, Alexander Klimetschek aklim...@day.com wrote: WDYT? +1 BR, Jukka Zitting
[jira] Commented: (JCR-1931) SharedFieldCache$StringIndex memory leak causing OOM's
[ https://issues.apache.org/jira/browse/JCR-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662960#action_12662960 ] Marcel Reutegger commented on JCR-1931: --- Comments: - can you please create a patch that only includes relevant changes? it seems there are several changes in the patch that are just line breaks at different positions. - StringIndex#sparse should be final, it is only set in the constructor - comment in StringIndex#isSparse still mentions 10% Other than that, the patch looks OK. SharedFieldCache$StringIndex memory leak causing OOM's --- Key: JCR-1931 URL: https://issues.apache.org/jira/browse/JCR-1931 Project: Jackrabbit Issue Type: Bug Components: query Affects Versions: 1.5.0 Reporter: Ard Schrijvers Assignee: Ard Schrijvers Priority: Critical Fix For: 1.5.1 Attachments: JCR-1931.patch, OrderByOOMTest.java SharedFieldCache$StringIndex is not working properly. It is meant to cache the docnumbers in lucene along with the term to sort on. The issue is twofold. I have a solution for the second one, the first one is not really solvable from jr pov, because lucene index readers are already heavily caching Terms. Explanation of the problem: For *each* unique property where is sorted on, a new lucene ScoreDocComparator is created (see SharedFieldComparator newComparator). This new comparator creates *per* lucene indexreader SharedFieldCache.StringIndex which is stored in a WeakHashMap with as key, the indexreader . As this indexreader almost *never* can be garbage collected (only if it is merged and thus unused after), the SharedFieldCache.StringIndex are there to be the rest of the jvm life (which is sometime short, as can be seen from the simple unittest attached). Obviously, this results pretty fast in OOM. 1) issue one: The cached terms[] in SharedFieldCache.StringIndex can become huge when you sort on a common property (date) which is present in a lot of nodes. It you sort on large properties, like 'title' this SharedFieldCache.StringIndex will quickly use hundreds of Mb for a couple of hundred of thousand of nodes with a title. This issue is already a lucene issue, as lucene already caches the terms. OTOH, I really doubt whether we should index long string values as UNTOKENIZED in lucene at all. A half working solution might be a two-step solution, where the first sort is on the first 10 chars, and only if the comparator returns 0, take the entire string to sort on 2) issue two: The cached terms[] in SharedFieldCache.StringIndex is frequently sparse, consuming an incredible amount of memory for string arrays containing mainly null values. For example (see attached unit test): - add 1.000.000 nodes - do a query and sort on a non existing property - you'll loose 1.000.000 * 4 bytes ~ 4 Mb of memory - sort on another non existing prop : another 4 Mb is lost - do it 100 times -- 400 Mb is lost, and can't be reclaimed I'll attach a solution which works really fine for me, still having the almost unavoidable memory absorption, but makes it much smaller. The solution is, that if 10% of the String array is filled, i consider the array already sparse, and move to a HashMap solution. Performance does not decrease much (and in case of large sparsity increases because less memory consumption -- less gc, etc). Perhaps it does not seem to be a common issue (certainly the unit test) but our production environments memory snapshots indicate most memory being held by the SharedFieldCache$StringIndex (and the lucene Terms, which is harder to avoid) I'd like to see this in the 1.5.1 if others are ok with 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-1932) Session.getAttributes( ) call always returns an empty array
[ https://issues.apache.org/jira/browse/JCR-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662964#action_12662964 ] Alexander Klimetschek commented on JCR-1932: Looking at the SessionImpl code, I see that the member attributes, which is read by getAttributeNames() and getAttribute(String) is never written to. The solution would be to change the RepositoryImpl.login(Credentials, String) method to pass on the attributes array through to createSession() - createSessionInstance() - XASessionImpl constructor - SessionImpl constructor. Session.getAttributes( ) call always returns an empty array --- Key: JCR-1932 URL: https://issues.apache.org/jira/browse/JCR-1932 Project: Jackrabbit Issue Type: Bug Components: JCR API Reporter: alessandro cosenza Attachments: bug.txt Repository repository = new RMIRemoteRepository(//localhost:1099/jackrabbit.repository); SimpleCredentials c = new SimpleCredentials(alex,ok.toCharArray()); c.setAttribute(anAttribute, aValue); Session s = repository.login(c, aWorkspace); String[]attr=s.getAttributeNames(); array attr is empty. according to docs it should contains attributes from the SimpleCredentials object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1664) JNDI Referencable Issues
[ https://issues.apache.org/jira/browse/JCR-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662986#action_12662986 ] Jukka Zitting commented on JCR-1664: I just noticed that revision 683268 that contained changes relevant to this issue was incorrectly labelled with JCR-1644 instead of JCR-1664, and that I therefore missed merging it to the 1.4 branch for the 1.4.6 release. 1.4.6 still works with the previous 681031 changes merged, but it's a bit more difficult to subclass BindableRepository. We can include the missing 683268 changes in a jackrabbit-core 1.4.7 release if there's enough demand. JNDI Referencable Issues Key: JCR-1664 URL: https://issues.apache.org/jira/browse/JCR-1664 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.5 Environment: linux glassfish jndi spring Reporter: Nicholas Stuart Assignee: Jukka Zitting Fix For: core 1.4.6 Attachments: JCR-1664.patch, JCR-1664.patch, out.patch I'm questioning the use of Referencable in the BindableResource and BindableResourceFactory classes for the JNDI lookup process. Reason for this is because Referencable needs the Addrs to be in the EXACT order in order for it to be considered the same. (see http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/Reference.html#equals(java.lang.Object) ) In order for me to get the JNDI reference to be found correctly I had to change the BindableResource.getReference method to swap the order the StringReferences were added to match up what was being passed in by glassfish. This seems EXTREMELY fragile to me as I don't know what order, say JBoss, would pass the StringRefences in in the Reference object for the Factory method. Also, another problem is that getReference is binding the class name to BindableRepository class implementation and not javax.jcr.Repository. This again causes them not to match if you follow the example on the wiki on setting up the JNDI reference and use javax.jcr.Repository as the type. This can either be fixed by changing the JNDI reference to use the BindableRepository class or the change the BindableRepository class to set that to the Repository interface. Not sure which would be considered 'better' I have a patch that fixes the first issue (at least for glassfish), but not the second. Again, this seems like a really 'breakable' setup right now and not sure what would be better to make sure this is avoided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1823) Repository.login throws IllegalStateException
[
https://issues.apache.org/jira/browse/JCR-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662990#action_12662990
]
Grégory Joseph commented on JCR-1823:
-
I might be wrong, but I seem to remember this is the exception i got with
JCR-1778, which might thus be irrelevant now ?
Repository.login throws IllegalStateException
-
Key: JCR-1823
URL: https://issues.apache.org/jira/browse/JCR-1823
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Felix Meschberger
Assignee: Jukka Zitting
Fix For: 1.5.1
Attachments: JCR-1823.patch
Calling any login method on Repository instance, which has been shut down
throws an IllegalStateException, which is caused by the
RepositoryImpl.sanityCheck method.
This exception is unexpected by callers of the login method, which is
specified to throw one of LoginException, NoSuchWorkspaceException and
RepositoryException. In particular the spec says, that a RepositoryException
is thrown if another error occurs.
So I suggest to modify the RepositoryImpl.login(Credentials, String) as
follows (patch against trunk):
Index:
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
===
---
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
(revision 706543)
+++
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
(working copy)
@@ -1358,6 +1358,8 @@
} catch (AccessDeniedException ade) {
// authenticated subject is not authorized for the specified
workspace
throw new LoginException(Workspace access denied, ade);
+} catch (RuntimeException re) {
+throw new RepositoryException(re.getMessage(), re);
} finally {
shutdownLock.readLock().release();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1933) Session.isLive() and logout() throw exceptions
Session.isLive() and logout() throw exceptions -- Key: JCR-1933 URL: https://issues.apache.org/jira/browse/JCR-1933 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-rmi Affects Versions: 1.5.0 Reporter: Marcel Reutegger Priority: Minor The two methods will throw an exception in case the remote session is not available anymore. For most other methods an exception is OK in that case, but I think for the methods isLive() and logout() (both do not declare any exception) a client expects a different behavior. I propose we change it as follows: - Session.isLive(): return false if remote session is not available anymore - Session.logout(): write a log message, but do not throw a runtime exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1931) SharedFieldCache$StringIndex memory leak causing OOM's
[ https://issues.apache.org/jira/browse/JCR-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663010#action_12663010 ] Jukka Zitting commented on JCR-1931: Seems OK to me too. Ard, can you commit this with Marcel's suggetions? I'll then merge it to 1.5 for inclusion in 1.5.1. SharedFieldCache$StringIndex memory leak causing OOM's --- Key: JCR-1931 URL: https://issues.apache.org/jira/browse/JCR-1931 Project: Jackrabbit Issue Type: Bug Components: query Affects Versions: 1.5.0 Reporter: Ard Schrijvers Assignee: Ard Schrijvers Priority: Critical Fix For: 1.5.1 Attachments: JCR-1931.patch, OrderByOOMTest.java SharedFieldCache$StringIndex is not working properly. It is meant to cache the docnumbers in lucene along with the term to sort on. The issue is twofold. I have a solution for the second one, the first one is not really solvable from jr pov, because lucene index readers are already heavily caching Terms. Explanation of the problem: For *each* unique property where is sorted on, a new lucene ScoreDocComparator is created (see SharedFieldComparator newComparator). This new comparator creates *per* lucene indexreader SharedFieldCache.StringIndex which is stored in a WeakHashMap with as key, the indexreader . As this indexreader almost *never* can be garbage collected (only if it is merged and thus unused after), the SharedFieldCache.StringIndex are there to be the rest of the jvm life (which is sometime short, as can be seen from the simple unittest attached). Obviously, this results pretty fast in OOM. 1) issue one: The cached terms[] in SharedFieldCache.StringIndex can become huge when you sort on a common property (date) which is present in a lot of nodes. It you sort on large properties, like 'title' this SharedFieldCache.StringIndex will quickly use hundreds of Mb for a couple of hundred of thousand of nodes with a title. This issue is already a lucene issue, as lucene already caches the terms. OTOH, I really doubt whether we should index long string values as UNTOKENIZED in lucene at all. A half working solution might be a two-step solution, where the first sort is on the first 10 chars, and only if the comparator returns 0, take the entire string to sort on 2) issue two: The cached terms[] in SharedFieldCache.StringIndex is frequently sparse, consuming an incredible amount of memory for string arrays containing mainly null values. For example (see attached unit test): - add 1.000.000 nodes - do a query and sort on a non existing property - you'll loose 1.000.000 * 4 bytes ~ 4 Mb of memory - sort on another non existing prop : another 4 Mb is lost - do it 100 times -- 400 Mb is lost, and can't be reclaimed I'll attach a solution which works really fine for me, still having the almost unavoidable memory absorption, but makes it much smaller. The solution is, that if 10% of the String array is filled, i consider the array already sparse, and move to a HashMap solution. Performance does not decrease much (and in case of large sparsity increases because less memory consumption -- less gc, etc). Perhaps it does not seem to be a common issue (certainly the unit test) but our production environments memory snapshots indicate most memory being held by the SharedFieldCache$StringIndex (and the lucene Terms, which is harder to avoid) I'd like to see this in the 1.5.1 if others are ok with it -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JCRSITE project created
Hi, I created a new JCRSITE [1] project in Jira for tracking changes to the Jackrabbit web site, the Jackrabbit parent POM (as discussed for the JCR Commons subproject), and other resources for which we don't have a more specific issue tracker. Like the JCRCMIS project, JCRSITE has wiki markup enabled for comments and issue descriptions. [1] https://issues.apache.org/jira/browse/JCRSITE BR, Jukka Zitting
Setting up a new parent POM (Was: [VOTE] Create the JCR Commons subproject)
Hi, On Wed, Jan 7, 2009 at 8:03 AM, Felix Meschberger fmesc...@gmail.com wrote: I think the parent project is truly Jackrabbit global. As such it does not belong to the Commons subproject. That's a good point, and I agree that we should go that way. I'll be setting up the new parent POM (as described in JCRSITE-1) in a separate svn subtree rooted at .../asf/jackrabbit/parent. BR, Jukka Zitting
Re: JCRSITE project created
On Mon, Jan 12, 2009 at 6:40 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: I created a new JCRSITE [1] project in Jira for tracking changes to the Jackrabbit web site, the Jackrabbit parent POM (as discussed for the JCR Commons subproject), and other resources for which we don't have a more specific issue tracker. Cool, I just added a website task for my earlier proposal [1]. But it seems I (and probably other committers as well) don't have the rights to assign issues - although I can edit, comment, attach files, resolve issue etc. Regards, Alex [1] https://issues.apache.org/jira/browse/JCRSITE-2 -- Alexander Klimetschek alexander.klimetsc...@day.com
[jira] Commented: (JCR-1933) Session.isLive() and logout() throw exceptions
[ https://issues.apache.org/jira/browse/JCR-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663029#action_12663029 ] Alexander Klimetschek commented on JCR-1933: - Session.isLive(): return false if remote session is not available anymore - Session.logout(): write a log message, but do not throw a runtime exception. +1 Session.isLive() and logout() throw exceptions -- Key: JCR-1933 URL: https://issues.apache.org/jira/browse/JCR-1933 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-rmi Affects Versions: 1.5.0 Reporter: Marcel Reutegger Priority: Minor The two methods will throw an exception in case the remote session is not available anymore. For most other methods an exception is OK in that case, but I think for the methods isLive() and logout() (both do not declare any exception) a client expects a different behavior. I propose we change it as follows: - Session.isLive(): return false if remote session is not available anymore - Session.logout(): write a log message, but do not throw a runtime exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCRSITE project created
Hi, On Mon, Jan 12, 2009 at 7:09 PM, Alexander Klimetschek aklim...@day.com wrote: But it seems I (and probably other committers as well) don't have the rights to assign issues - although I can edit, comment, attach files, resolve issue etc. Should be fixed now. BR, Jukka Zitting
[jira] Resolved: (JCRSITE-1) Create new project-level Jackrabbit parent POM
[
https://issues.apache.org/jira/browse/JCRSITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCRSITE-1.
-
Resolution: Fixed
I think I have the new parent POM in a pretty good shape now in
https://svn.apache.org/repos/asf/jackrabbit/parent/trunk/. Resolving as Fixed.
Create new project-level Jackrabbit parent POM
--
Key: JCRSITE-1
URL: https://issues.apache.org/jira/browse/JCRSITE-1
Project: Jackrabbit Site
Issue Type: Task
Components: parent
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Fix For: parent 2.0
The current {{org.apache.jackrabbit:jackrabbit-parent}} POM contains
dependency management and other settings that are related to specific
Jackrabbit components. Since we are now moving many components to the new JCR
Commons subproject we should have a more generic project-level parent POM
that only specifies global configuration like project members, mailing lists,
and perhaps some generic settings of the Jackrabbit build environment.
I plan to identify this parent POM as {{org.apache.jackrabbit:parent}} as I'd
like to reserve the jackrabbit- artifactId prefix for the component that
are part of the core Jackrabbit repository build.
I'd like to start the versioning of this parent POM at 2.0 as an upgrade from
the jackrabbit-parent 1.x POMs we now have, and create 2.x versions until
upgrading to 3.0 for some major change like a TLP reorganization or switch to
the next major Maven version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRSITE-4) Implementation Architecture Documentation
[ https://issues.apache.org/jira/browse/JCRSITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-1 to JCRSITE-4: --- Component/s: (was: docs) site Description: (was: Create Generic Documentation that decribes the Architecture and Operations of Jackrabbit. Target Audience: Jackrabbit Developers Jackrabbit Users TOC: Architecure Overview (JSR-170 vs Jackrabbit Implementation) Basic Jackrabbit Operations - Startup, initialize, configuration - Authenticate, login, acquire a session - Read and Introspect, Nodetypes, Permissions - Create, Update Delete, working with transient Items - NodetypeValidate Save, PerstianceHandlers, Stores - NamespaceRegistry and Session Namespaces - Queries, Querylanguages, Indexes ...) Environment: (was: Documentation) Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRSITE-4 (was: JCR-1) Project: Jackrabbit Site (was: Jackrabbit) Implementation Architecture Documentation - Key: JCRSITE-4 URL: https://issues.apache.org/jira/browse/JCRSITE-4 Project: Jackrabbit Site Issue Type: Task Components: site Reporter: David Nuescheler Assignee: David Nuescheler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRSITE-5) Update First Hops Documentation
[ https://issues.apache.org/jira/browse/JCRSITE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-941 to JCRSITE-5: - Fix Version/s: (was: none) Component/s: (was: docs) site Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRSITE-5 (was: JCR-941) Project: Jackrabbit Site (was: Jackrabbit) Update First Hops Documentation - Key: JCRSITE-5 URL: https://issues.apache.org/jira/browse/JCRSITE-5 Project: Jackrabbit Site Issue Type: Improvement Components: site Environment: None - just the Apache Jackrabbit website Reporter: Porter Woodward Assignee: Jukka Zitting The First Hops portion of the Apache Jackrabbit site is out of date. http://jackrabbit.apache.org/doc/firststeps.html It still references Jackrabbit 1.0 - and the project is onto release 1.3; it also references several dependencies - and the downloads page is no longer clear as to which jar files would be required to get a basic repository application up and running. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRSITE-6) Update / Fix Documentation for CND Notation
[ https://issues.apache.org/jira/browse/JCRSITE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-1194 to JCRSITE-6: -- Component/s: (was: docs) site Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRSITE-6 (was: JCR-1194) Project: Jackrabbit Site (was: Jackrabbit) Update / Fix Documentation for CND Notation --- Key: JCRSITE-6 URL: https://issues.apache.org/jira/browse/JCRSITE-6 Project: Jackrabbit Site Issue Type: Improvement Components: site Reporter: Felix Gonschorek Priority: Minor I started to learn Jackrabbit / JCA, but there was a documentation bug that took me long to figure out. This is related to the CND documentation under http://jackrabbit.apache.org/doc/nodetype/cnd.html I could not import my namespace and NodeType definition, until i a) created the namespace in my repository (it's obvious i need to do this, but i thought, the namespace declaration on top of the cnd file would do this) b) i declare the namespace nt in addition to my own namespace. i could not import anything but an empty node type, until i did this eg. not just: --- myns=http://www.mynamespace.com/myns; --- i needed to declare: --- myns=http://www.mynamespace.com/myns; nt = 'http://www.jcp.org/jcr/nt/1.0' --- before anything works. otherwise i got a strange exception (could not parse node type definition at [??) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRSITE-3) Simple standalone sample apps
[ https://issues.apache.org/jira/browse/JCRSITE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCRSITE-3: Description: It would be great to have really simple standalone sample apps for the most important features. The sample apps should have a main method each, write to System.out, and be in the test source tree or in a new 'examples' tree, in jackrabbit-core (and / or in another project). Then for each of those sample apps there should be a test that redirects System.out to a ByteArrayOutputStream, calls the main method, checks if the output is correct. Like that the sample apps don't get out of sync. Simple standalone sample apps - Key: JCRSITE-3 URL: https://issues.apache.org/jira/browse/JCRSITE-3 Project: Jackrabbit Site Issue Type: New Feature Components: site Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor It would be great to have really simple standalone sample apps for the most important features. The sample apps should have a main method each, write to System.out, and be in the test source tree or in a new 'examples' tree, in jackrabbit-core (and / or in another project). Then for each of those sample apps there should be a test that redirects System.out to a ByteArrayOutputStream, calls the main method, checks if the output is correct. Like that the sample apps don't get out of sync. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRSITE-4) Implementation Architecture Documentation
[ https://issues.apache.org/jira/browse/JCRSITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCRSITE-4: Description: Create Generic Documentation that decribes the Architecture and Operations of Jackrabbit. Target Audience: Jackrabbit Developers Jackrabbit Users TOC: Architecure Overview (JSR-170 vs Jackrabbit Implementation) Basic Jackrabbit Operations - Startup, initialize, configuration - Authenticate, login, acquire a session - Read and Introspect, Nodetypes, Permissions - Create, Update Delete, working with transient Items - NodetypeValidate Save, PerstianceHandlers, Stores - NamespaceRegistry and Session Namespaces - Queries, Querylanguages, Indexes ... Implementation Architecture Documentation - Key: JCRSITE-4 URL: https://issues.apache.org/jira/browse/JCRSITE-4 Project: Jackrabbit Site Issue Type: Task Components: site Reporter: David Nuescheler Assignee: David Nuescheler Create Generic Documentation that decribes the Architecture and Operations of Jackrabbit. Target Audience: Jackrabbit Developers Jackrabbit Users TOC: Architecure Overview (JSR-170 vs Jackrabbit Implementation) Basic Jackrabbit Operations - Startup, initialize, configuration - Authenticate, login, acquire a session - Read and Introspect, Nodetypes, Permissions - Create, Update Delete, working with transient Items - NodetypeValidate Save, PerstianceHandlers, Stores - NamespaceRegistry and Session Namespaces - Queries, Querylanguages, Indexes ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCRSITE project created
Hi, On Mon, Jan 12, 2009 at 6:40 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: I created a new JCRSITE [1] project in Jira for tracking changes to the Jackrabbit web site, the Jackrabbit parent POM (as discussed for the JCR Commons subproject), and other resources for which we don't have a more specific issue tracker. As you probably noticed, I also migrated all open Jackrabbit docs issues to JCRSITE. BR, Jukka Zitting
[jira] Assigned: (JCRSITE-2) Add articles/tutorials page
[ https://issues.apache.org/jira/browse/JCRSITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek reassigned JCRSITE-2: --- Assignee: Alexander Klimetschek Add articles/tutorials page --- Key: JCRSITE-2 URL: https://issues.apache.org/jira/browse/JCRSITE-2 Project: Jackrabbit Site Issue Type: Improvement Components: site Reporter: Alexander Klimetschek Assignee: Alexander Klimetschek Add articles page (copy from JcrLinks in the wiki), improve getting started page, change homepage to link to them See mailing list: http://markmail.org/message/allouxx4sbib35la -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1778) BindableRepositoryFactory doesn't handle repository shutdown
[ https://issues.apache.org/jira/browse/JCR-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663117#action_12663117 ] Grégory Joseph commented on JCR-1778: - Seems to as this is (if only by accident) related to JCR-1823 BindableRepositoryFactory doesn't handle repository shutdown Key: JCR-1778 URL: https://issues.apache.org/jira/browse/JCR-1778 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Jukka Zitting Priority: Minor The BindableRepositoryFactory class keeps a cached reference to a repository even after the repository has been shut down. This causes the following code snippet to fail with an IllegalStateException: Hashtable environment = new Hashtable(); environment.put( Context.INITIAL_CONTEXT_FACTORY, DummyInitialContextFactory.class.getName()); environment.put(Context.PROVIDER_URL, http://jackrabbit.apache.org/;); Context context = new InitialContext(environment); JackrabbitRepository repository; String xml = src/test/repository/repository.xml; String dir = target/repository; String key = repository; // Create first repository RegistryHelper.registerRepository(context, key, xml, dir, true); repository = (JackrabbitRepository) context.lookup(key); repository.login().logout(); repository.shutdown(); // Create second repository with the same configuration RegistryHelper.registerRepository(context, key, xml, dir, true); repository = (JackrabbitRepository) context.lookup(key); repository.login().logout(); // throws an IllegalStateException! repository.shutdown(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-1) Copy the JCR-RMI component to the new JCR Commons subproject
Copy the JCR-RMI component to the new JCR Commons subproject Key: JCRRMI-1 URL: https://issues.apache.org/jira/browse/JCRRMI-1 Project: Jackrabbit JCR-RMI Issue Type: Task Reporter: Jukka Zitting Assignee: Jukka Zitting JCR-RMI is one of the components to be included in the new JCR Commons subproject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
org.apache.jcr for the JCR Commons subproject
Hi, I'd like to start using org.apache.jcr as the package root and Maven groupId of the components in the new JCR Commons subproject to clarify the distinction between Jackrabbit, the content repository and the generic JCR tools we'll have in JCR Commons. Doing so will require changes to all client code that wants to upgrade to the latest version, but will also give us a chance to clean up our APIs and we're in any case labeling the first JCR Commons releases as 2.0. BR, Jukka Zitting
[jira] Moved: (JCRRMI-4) RMI: Allow custom socket factories
[ https://issues.apache.org/jira/browse/JCRRMI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-781 to JCRRMI-4: Component/s: (was: jackrabbit-jcr-rmi) Description: (was: The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.) Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRRMI-4 (was: JCR-781) Project: Jackrabbit JCR-RMI (was: Jackrabbit) RMI: Allow custom socket factories -- Key: JCRRMI-4 URL: https://issues.apache.org/jira/browse/JCRRMI-4 Project: Jackrabbit JCR-RMI Issue Type: New Feature Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRRMI-2) ClientObservationManager causes null pointer
[ https://issues.apache.org/jira/browse/JCRRMI-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-1643 to JCRRMI-2: - Component/s: (was: jackrabbit-jcr-rmi) Affects Version/s: (was: rmi 1.4.1) Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRRMI-2 (was: JCR-1643) Project: Jackrabbit JCR-RMI (was: Jackrabbit) ClientObservationManager causes null pointer Key: JCRRMI-2 URL: https://issues.apache.org/jira/browse/JCRRMI-2 Project: Jackrabbit JCR-RMI Issue Type: Bug Environment: Using a simple rmi connection to connect to a jackrabbit server running on tomcat on linux. Reporter: Brett Conoly This is listed as major because it prevents rmi users from accessing registered events...safely There is a mailing list thread with the subject null pointer in client observation manager for reference. Using: ObservationManager manager = session.getWorkspace().getObservationManager(); EventListenerIterator events = manager.getRegisteredEventListeners(); causes an unexplained null pointer within the ClientObservationManager if getRegisteredEventListeners() is called before an EventListener is registered with the related ObservationManager. This was tested with org.apache.jackrabbit.core.observation.ObservationManagerImpl and it passed without any issues. No other implementations of the ObservationManager were tested. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRRMI-6) Streamline the JCR-RMI network interfaces
[ https://issues.apache.org/jira/browse/JCRRMI-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-300 to JCRRMI-6: Component/s: (was: jackrabbit-jcr-rmi) Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRRMI-6 (was: JCR-300) Project: Jackrabbit JCR-RMI (was: Jackrabbit) Streamline the JCR-RMI network interfaces - Key: JCRRMI-6 URL: https://issues.apache.org/jira/browse/JCRRMI-6 Project: Jackrabbit JCR-RMI Issue Type: Improvement Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor The JCR-RMI network layer makes an excessive amount of remote method calls in some use cases. Use caching and other mechanisms to improve performance in such cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRRMI-3) Session.isLive() and logout() throw exceptions
[ https://issues.apache.org/jira/browse/JCRRMI-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting moved JCR-1933 to JCRRMI-3: - Component/s: (was: jackrabbit-jcr-rmi) Affects Version/s: (was: 1.5.0) Workflow: no-reopen-closed, patch-avail (was: jira) Key: JCRRMI-3 (was: JCR-1933) Project: Jackrabbit JCR-RMI (was: Jackrabbit) Session.isLive() and logout() throw exceptions -- Key: JCRRMI-3 URL: https://issues.apache.org/jira/browse/JCRRMI-3 Project: Jackrabbit JCR-RMI Issue Type: Bug Reporter: Marcel Reutegger Priority: Minor The two methods will throw an exception in case the remote session is not available anymore. For most other methods an exception is OK in that case, but I think for the methods isLive() and logout() (both do not declare any exception) a client expects a different behavior. I propose we change it as follows: - Session.isLive(): return false if remote session is not available anymore - Session.logout(): write a log message, but do not throw a runtime exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRRMI-4) RMI: Allow custom socket factories
[ https://issues.apache.org/jira/browse/JCRRMI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCRRMI-4: --- Description: The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory. RMI: Allow custom socket factories -- Key: JCRRMI-4 URL: https://issues.apache.org/jira/browse/JCRRMI-4 Project: Jackrabbit JCR-RMI Issue Type: New Feature Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Migrating JCR-RMI to the JCR Commons subproject
Hi, I started setting up the new JCR Commons subproject by using the JCR-RMI component as the first example. Here are the steps I've taken so far: 1) Create the JCRRMI project in Jira. 2) Migrate all open jackrabbit-jcr-rmi issues from JCR to JCRRMI. 3) Create the repos/asf/jackrabbit/commons/jcr-rmi directory in svn. 4) Copy trunk/jackrabbit-jcr-rmi to commons/jcr-rmi/trunk 5) Modify the JCR-RMI POM to work outside the main Jackrabbit build. Here's what I still plan to do over the next few weeks/months: 6) Rename the org.apache.jackrabbit.rmi package to org.apache.jcr.rmi. 7) Prepare and release JCR-RMI 2.0. 8) Replace old jackrabbit-jcr-rmi with an external dependency to the new 2.0 release of JCR-RMI. 9) Remove the jackrabbit-jcr-rmi component from the JCR project in Jira. Feel free to comment or question any of these steps, I may well be overlooking something or otherwise going in the wrong direction. If this migration works well for JCR-RMI, we can replicate it with the other JCR Commons components. BR, Jukka Zitting
[jira] Resolved: (JCR-601) Delete workspace support
[ https://issues.apache.org/jira/browse/JCR-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-601. Resolution: Won't Fix this issue (delete workspace support in jackrabbit API) should from my point of view be resolved won't fix. if we add a temporary Workspace interface to the jsr283 package is a different story we may or may not do that depending on the needs. Delete workspace support Key: JCR-601 URL: https://issues.apache.org/jira/browse/JCR-601 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-api Affects Versions: 0.9, 1.0, 1.0.1, 1.1 Reporter: Przemo Pakulski Assignee: angela Priority: Minor JackrabbitWorkspace interface defines method to create new workspace, but there is no method to remove workspace programatically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
