[jira] Created: (JCR-360) restore sometime throws error about missing tmp files
restore sometime throws error about missing tmp files - Key: JCR-360 URL: http://issues.apache.org/jira/browse/JCR-360 Project: Jackrabbit Type: Bug Components: versioning Versions: 0.9 Environment: r387153 Reporter: Tobias Bocanegra Fix For: 1.1 Caused by: javax.jcr.RepositoryException: file backing binary value not found: /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory): /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory) at org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.java:454) at org.apache.jackrabbit.core.state.util.Serializer.serialize(Serializer.java:197) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-361) restore sometime throws error about missing tmp files
restore sometime throws error about missing tmp files - Key: JCR-361 URL: http://issues.apache.org/jira/browse/JCR-361 Project: Jackrabbit Type: Bug Components: versioning Versions: 0.9 Environment: r387153 Reporter: Tobias Bocanegra Fix For: 1.1 Caused by: javax.jcr.RepositoryException: file backing binary value not found: /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory): /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory) at org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.java:454) at org.apache.jackrabbit.core.state.util.Serializer.serialize(Serializer.java:197) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: binary values problem
hi giotta, 1) The ReferentialIntegrityException which should not be thrown and this one is already filed here: http://issues.apache.org/jira/browse/JCR-272 2) Somehow restore is not rolled-back when an exception occurs (sth that should not happen with jca). i created a new issue for this: http://issues.apache.org/jira/browse/JCR-362 regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Created: (JCR-362) restore sometime throws error about missing tmp files
restore sometime throws error about missing tmp files - Key: JCR-362 URL: http://issues.apache.org/jira/browse/JCR-362 Project: Jackrabbit Type: Bug Components: versioning Versions: 0.9 Environment: r387153 Reporter: Tobias Bocanegra Fix For: 1.1 Caused by: javax.jcr.RepositoryException: file backing binary value not found: /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory): /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory) at org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.java:454) at org.apache.jackrabbit.core.state.util.Serializer.serialize(Serializer.java:197) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restore version problem
hi aleksandar,
i created a new issue for this: http://issues.apache.org/jira/browse/JCR-362
regards, toby
On 3/19/06, Aleksandar Pecanov [EMAIL PROTECTED] wrote:
Trying to restore a certain version often (not always) results in:
Caused by: javax.jcr.RepositoryException: /: unable to update item.:
Error saving property state:
48e469d1-51ee-4991-b4e7-fed40bb3e049/{http://www.jcp.org/jcr/1.0}data:
Error saving property state:
48e469d1-51ee-4991-b4e7-fed40bb3e049/{http://www.jcp.org/jcr/1.0}data
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1198)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:806)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:3507)
at org.apache.jackrabbit.core.NodeImpl.restore(NodeImpl.java:2853)
at
com.islands.document.AbstractElementary.replaceWithVersion(AbstractElementary.java:513)
... 31 more
Caused by: org.apache.jackrabbit.core.state.ItemStateException: Error
saving property state:
48e469d1-51ee-4991-b4e7-fed40bb3e049/{http://www.jcp.org/jcr/1.0}data
at
com.islands.storage.database.GenericPersistanceManager.store(GenericPersistanceManager.java:292)
at
org.apache.jackrabbit.core.state.AbstractPersistenceManager.store(AbstractPersistenceManager.java:69)
at
com.islands.storage.database.GenericPersistanceManager.store(GenericPersistanceManager.java:90)
at
com.islands.storage.IslandsPersistanceManager.store(IslandsPersistanceManager.java:144)
at org.apache.jackrabbit.core.state.SharedItemStateManager
$Update.end(SharedItemStateManager.java:570)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:693)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:316)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:323)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:292)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:258)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1190)
... 35 more
Caused by: javax.jcr.RepositoryException: file backing binary value not
found: /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or
directory): /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file
or directory)
at
org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.java:454)
at
org.apache.jackrabbit.core.state.util.Serializer.serialize(Serializer.java:197)
at
com.islands.storage.database.GenericPersistanceManager.store(GenericPersistanceManager.java:283)
... 45 more
Caused by:
java.io.FileNotFoundException: /server/apache-tomcat-5.5.15/temp/bin4435.tmp
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.java:452)
... 47 more
... which is related to transient storage.
Is this a know bug, or is it related to something else?
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
[jira] Deleted: (JCR-361) restore sometime throws error about missing tmp files
[ http://issues.apache.org/jira/browse/JCR-361?page=all ] Tobias Bocanegra deleted JCR-361: - restore sometime throws error about missing tmp files - Key: JCR-361 URL: http://issues.apache.org/jira/browse/JCR-361 Project: Jackrabbit Type: Bug Environment: r387153 Reporter: Tobias Bocanegra Caused by: javax.jcr.RepositoryException: file backing binary value not found: /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory): /server/apache-tomcat-5.5.15/temp/bin4435.tmp (No such file or directory) at org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.java:454) at org.apache.jackrabbit.core.state.util.Serializer.serialize(Serializer.java:197) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: about document history
hi sam, do you know if any work is going on concerning storing deltas instead of total copies? no, currently not. the difficulty hereby is, that the versionstorage must be 'browsable' like normal content, i.e. the version nodes inside the versionstorage must reflect the complete state of the node, from the time it was versioned. currently,this is simply done, by using a 'normal' persistence manager, and dynamically mapping the nodes in the workspace. so an eventual delta can only happen on the persistence layer, or by ciompletely replace the version manager. will it be possible in the future to change a running environment from storing copies to storing deltas?` if implemented, yes. will there be a solution for changing all versions stored as copies in the past to saved deltas? yes. basically doing an export/import. i'm interrested, what is the usecase for your questions. i.e. what is your estimate on how many versions of documents (in total) you will have, and how much space is used by them? are there tousands of 1mb documents, having hunders of versions ( 100gb), or what is the scale? regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: about document history
hi paco, the versions are store inside the repository, using a seperate persistence manager. virtually, they will reside under /jcr:system/jcr:versionStorage as specified by jsr170. whenever you checkin a node, all it's content is copied to that location. there is no delta stored (yet). regards, toby On 3/17/06, Paco Avila [EMAIL PROTECTED] wrote: Hi, I've seen that Jackrabbit saves the document changes so, I can restrive a especific document version. How are this versions stored? As deltas or is the whole document stored earch time? In my application I need to know the space occupied by any document, includind its history, can I? Thanks in advance. -- Paco Avila GIT Consultors -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Access Manager custom implementation
I need completely different set of constants: read properties,write properties, browse children,add child,delete child most of them can be mapped: read properties - PropertyId, READ write properties - PropertyId, WRITE browse children - NodeId, READ add child - NodeId, WRITE delete child - NodeId, REMOVE regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Access Manager custom implementation
Well, I know that. So there is no way to provide custom set of privileges for the node, which would match JSR 170 standard. From the other side, is it possible to extend JackRabbit somehow without modification of the source code? currently not. the respective permissions must be identified first, e.g. BrowseProperties and then also added to all the spots where this is relevant. In this case, probably in NodeImpl.getProperties(). regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Transaction isolation level support
hi przemo,
transactions should be read-repeatable. error on line 9 is ok, if the
same node was modified by another transaction before. can you please
file a jira issue? thanks.
regards, toby
On 3/10/06, Przemyslaw Pakulski [EMAIL PROTECTED] wrote:
Hi,
We are introducing transactions to our system, and run some concurrency
tests. We read in jsr170 spec that transactions should be completely
isolated from each other.
Considering following simple block of code :
folder = getFolder(session);
CrxUserTransaction ut = new CrxUserTransaction(session);
0 ut.begin();
1 folder.checkout();
2 Node child = folder.addNode(child);
3 child.addMixin(mix:versionable); 4 child.setProperty(id, id);
5 child.setProperty(iteration, i);
6 folder.save();
7 child.checkin();
8 folder.checkin();
9 ut.commit();
We noticed different exceptions in different lines, executing this block
concurrently :
- line 1 - InvalidItemStateException : the item does not exist anymore,
- line 6 - InvalidItemStateException : item cannot be saved because it
has been modified externally,
- line 9 - XAException caused by StaleItemStateExcpetion :
{http://www.jcp.org/jcr/1.0}isCheckedOut has been modified externally
Certainly we don't share session between threads, we use dedicated
session for each thread.
So, it looks like transactions can see changes made by other
transactions, what means jackrabbit doesn't support SERIALIZABLE and
even REPETABLE_READ isolation level, but only READ_COMMITTED level.
Can anybody explain what really isolation level is supported by
jackrabbit implementation currently ?
Regards
Przemo Pakulski
www.cognifide.com
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
[jira] Reopened: (JCR-335) Deadlock caused by versioning operations within transaction
[ http://issues.apache.org/jira/browse/JCR-335?page=all ] Tobias Bocanegra reopened JCR-335: -- reopening in behalf of przemo Deadlock caused by versioning operations within transaction --- Key: JCR-335 URL: http://issues.apache.org/jira/browse/JCR-335 Project: Jackrabbit Type: Bug Components: versioning Versions: 0.9 Environment: r383887 Reporter: Tobias Bocanegra Assignee: Dominique Pfister Fix For: 1.0 Attachments: threaddump-385412.txt Deadlock occurs, while running a very simple test, which is just trying to checkout/checkin node within transaction concurrently from 2 threads. Find enclosed thread dump, log and simple Java program. I'm using UserTransaction implementation from jackrabbit test suite. Regards Przemo Pakulski www.cognifide.com Full thread dump Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode): Thread-5 prio=5 tid=0x03054c48 nid=0x180c in Object.wait() [355f000..355fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:429) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1137) at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:110) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:456) at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:651) at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:150) at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:128) - locked 0x11565ac8 (a org.apache.jackrabbit.core.TransactionContext) at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:300) at com.oyster.mom.contentserver.jcr.transaction.JackrabbitUserTransaction.commit(JackrabbitUserTransaction.java:102) at com.oyster.mom.contentserver.jcr.transaction.JrTestDeadlock.run(JrTestDeadlock.java:97) Thread-4 prio=5 tid=0x0303b348 nid=0x9d0 in Object.wait() [351f000..351fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:429) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1137) at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:110) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:456) at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:651) at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:150) at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:128) - locked 0x1156f558 (a org.apache.jackrabbit.core.TransactionContext) at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:300) at com.oyster.mom.contentserver.jcr.transaction.JackrabbitUserTransaction.commit(JackrabbitUserTransaction.java:102) at com.oyster.mom.contentserver.jcr.transaction.JrTestDeadlock.run(JrTestDeadlock.java:97) IndexMerger daemon prio=5 tid=0x030388b8 nid=0x1858 in Object.wait() [34df000..34dfd8c] at java.lang.Object.wait(Native Method) - waiting on 0x114fd280 (a org.apache.commons.collections.buffer.BlockingBuffer) at java.lang.Object.wait(Object.java:429) at org.apache.commons.collections.buffer.BlockingBuffer.remove(BlockingBuffer.java:107) - locked 0x114fd280 (a org.apache.commons.collections.buffer.BlockingBuffer) at org.apache.jackrabbit.core.query.lucene.IndexMerger.run(IndexMerger.java:235) Thread-2 daemon prio=5 tid=0x0303a230 nid=0xe4c in Object.wait() [349f000..349fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x114fd2e0 (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:429) - locked 0x114fd2e0 (a java.util.TaskQueue
Re: [VOTE] Request graduation from Incubator as Apache Jackrabbit TLP
+1 regards, toby On 3/9/06, Roy T. Fielding [EMAIL PROTECTED] wrote: With my Incubator PMC/Mentor hat on, I believe that the Jackrabbit podling has accomplished all of the tasks and created the community necessary to stand on its own as an Apache top-level project (TLP). I am therefore calling a vote of the Jackrabbit committers to determine if the project as a whole agrees. Please send your +1 if you think we should request graduation now, -1 if you think we should wait, or something in between if you want to abstain. Anyone can vote, but only committer votes are binding. This vote will end on Saturday, 11 March 2006 at 5pm PST, or earlier if all committers have voted. If it passes, I will submit the request for graduation to the Incubator PMC and to the ASF Board on the same day. Roy -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Difference between nodetypes structure.
hi helio, the first implementation is necessary, since a nt:file is defined to have a jcr:content child node. the nt:file does not define the jcr:data or jcr:mimeType properties. have a look at those relevant nodetypes again: [nt:hierarchyNode] - jcr:created (date) mandatory autocreated protected initialize [nt:file] nt:hierarchyNode + jcr:content (nt:base) primary mandatory [nt:resource] mix:referenceable - jcr:encoding (string) - jcr:mimeType (string) mandatory - jcr:data (binary) primary mandatory - jcr:lastModified (date) mandatory ignor regards, toby On 3/9/06, hsp [EMAIL PROTECTED] wrote: Hi; I would to know what is the difference between the following implementation code: Node fileNode = parentnode.addNode(file.getName(), nt:file); Node resNode = fileNode.addNode(jcr:content, nt:resource); resNode.setProperty(jcr:mimeType, mimeType); resNode.setProperty(jcr:encoding, ); resNode.setProperty(jcr:data, new FileInputStream(file)); and the another: Node fileNode = parentnode.addNode(file.getName(), nt:file); fileNode.setProperty(jcr:mimeType, mimeType); fileNode.setProperty(jcr:encoding, ); fileNode.setProperty(jcr:data, new FileInputStream(file)); What is the consequences, considerations. Is it wrong? Is the first implementation necessary? What is the best pratice for? Thanks Helio -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: svn commit: r383856 - in /incubator/jackrabbit/trunk/jackrabbit/src: main/java/org/apache/jackrabbit/core/nodetype/compact/ test/java/org/apache/jackrabbit/core/nodetype/compact/
you are curret, but when the definition contains a supertype twice, it
will be dropped during registration, and the equals will fail
aswell...but i guess this happens anyways.
ok. i will revert the change.
regards, toby
On 3/7/06, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 3/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Modified:
incubator/jackrabbit/trunk/jackrabbit/src/main/java/org/apache/jackrabbit/core/nodetype/compact/CompactNodeTypeDefReader.java
[...]
@@ -269,7 +270,7 @@
* @throws ParseException
*/
private void doSuperTypes(NodeTypeDef ntd) throws ParseException {
-ArrayList supertypes = new ArrayList();
+HashSet supertypes = new HashSet();
if (!currentTokenEquals(Lexer.EXTENDS)) {
return;
}
This reverts my commit (r383708) that temporarily works around a
problem with supertype ordering (JCR-333). Because of this the
CompactNodeTypeDefTest fails due to supertype ordering at least on
Linux JDK 1.4.2_10.
I suggest we keep my change (use a List instead of a Set) until
JCR-333 is resolved to avoid random problems caused by the undefined
ordering of HashSets.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
[jira] Created: (JCR-335) Deadlock caused by versioning operations within transaction
Deadlock caused by versioning operations within transaction --- Key: JCR-335 URL: http://issues.apache.org/jira/browse/JCR-335 Project: Jackrabbit Type: Bug Components: versioning Versions: 0.9 Environment: r383887 Reporter: Tobias Bocanegra Fix For: 1.1 Deadlock occurs, while running a very simple test, which is just trying to checkout/checkin node within transaction concurrently from 2 threads. Find enclosed thread dump, log and simple Java program. I'm using UserTransaction implementation from jackrabbit test suite. Regards Przemo Pakulski www.cognifide.com Full thread dump Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode): Thread-5 prio=5 tid=0x03054c48 nid=0x180c in Object.wait() [355f000..355fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:429) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1137) at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:110) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:456) at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:651) at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:150) at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:128) - locked 0x11565ac8 (a org.apache.jackrabbit.core.TransactionContext) at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:300) at com.oyster.mom.contentserver.jcr.transaction.JackrabbitUserTransaction.commit(JackrabbitUserTransaction.java:102) at com.oyster.mom.contentserver.jcr.transaction.JrTestDeadlock.run(JrTestDeadlock.java:97) Thread-4 prio=5 tid=0x0303b348 nid=0x9d0 in Object.wait() [351f000..351fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:429) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x1148ef20 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1137) at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:110) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:456) at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:651) at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:150) at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:128) - locked 0x1156f558 (a org.apache.jackrabbit.core.TransactionContext) at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:300) at com.oyster.mom.contentserver.jcr.transaction.JackrabbitUserTransaction.commit(JackrabbitUserTransaction.java:102) at com.oyster.mom.contentserver.jcr.transaction.JrTestDeadlock.run(JrTestDeadlock.java:97) IndexMerger daemon prio=5 tid=0x030388b8 nid=0x1858 in Object.wait() [34df000..34dfd8c] at java.lang.Object.wait(Native Method) - waiting on 0x114fd280 (a org.apache.commons.collections.buffer.BlockingBuffer) at java.lang.Object.wait(Object.java:429) at org.apache.commons.collections.buffer.BlockingBuffer.remove(BlockingBuffer.java:107) - locked 0x114fd280 (a org.apache.commons.collections.buffer.BlockingBuffer) at org.apache.jackrabbit.core.query.lucene.IndexMerger.run(IndexMerger.java:235) Thread-2 daemon prio=5 tid=0x0303a230 nid=0xe4c in Object.wait() [349f000..349fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x114fd2e0 (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:429) - locked 0x114fd2e0 (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:382) Thread-1 daemon prio=5 tid=0x0301b7a0 nid=0x1a00 in Object.wait() [345f000..345fd8c] at java.lang.Object.wait(Native Method) - waiting on 0x114f9058 (a java.util.TaskQueue) at java.lang.Object.wait(Object.java:429) at java.util.TimerThread.mainLoop
Re: Deadlock caused by versioning operations within transaction
();
Node folder = getFolder(session);
folder.checkout();
folder.checkin();
success = true;
log.info(SUCCESS id: + id + , i= + i);
}
catch (Exception e) {
log.warn(FAIL: + id + , i= + i, e);
}
finally {
try {
if (success) {
ut.commit();
}
else {
ut.rollback();
}
}
catch (Exception e) {
log.fatal(e);
}
}
}
session.logout();
}
catch (RepositoryException e) {
e.printStackTrace();
}
}
}
13:46 ERROR JrTestDeadlock.run(JrTestDeadlock.java:76) - START id:0, i=0
13:46 ERROR JrTestDeadlock.run(JrTestDeadlock.java:76) - START id:1, i=0
13:46 INFO JrTestDeadlock.run(JrTestDeadlock.java:89) - SUCCESS id:0, i=0
13:46 INFO JrTestDeadlock.run(JrTestDeadlock.java:89) - SUCCESS id:1, i=0
13:46 ERROR
org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:156)
- org.apache.jackrabbit.core.state.StaleItemStateException:
233e656f-79f8-414d-9e37-3fce865b492d/{http://www.jcp.org/jcr/1.0}isCheckedOut
has been modified externally
13:46 FATAL JrTestDeadlock.run(JrTestDeadlock.java:104) -
javax.transaction.RollbackException: Transaction rolled back: XA_ERR=104
13:46 ERROR JrTestDeadlock.run(JrTestDeadlock.java:76) - START id:1, i=1
13:46 WARN JrTestDeadlock.run(JrTestDeadlock.java:92) - FAIL:1, i=1
ax.jcr.InvalidItemStateException: f83a830b-abbf-4ab2-8625-b9e2c4802316: the
item does not exist anymore
at
org.apache.jackrabbit.core.version.XAVersion.sanityCheck(XAVersion.java:81)
at
org.apache.jackrabbit.core.version.XAVersion.getInternalVersion(XAVersion.java:70)
at
org.apache.jackrabbit.core.version.AbstractVersion.getUUID(AbstractVersion.java:107)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2759)
at JrTestDeadlock.run(JrTestDeadlock.java:85)
13:46 ERROR JrTestDeadlock.run(JrTestDeadlock.java:76) - START id:1, i=2
13:46 INFO JrTestDeadlock.run(JrTestDeadlock.java:89) - SUCCESS id:1, i=2
13:51 WARN
org.apache.jackrabbit.core.TransactionContext.run(TransactionContext.java:239)
- Transaction rolled back because timeout expired.
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: Concurrent locking operations fail
(JrTestConcurrentLocks.java:100) - FAIL:2, i=4 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:88) - START id:1, i=9 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:88) - START id:2, i=5 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:100) - FAIL:2, i=5 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:88) - START id:2, i=6 15:46:18 WARN JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:103) - ERROR:1, i=9 javax.jcr.InvalidItemStateException: /folder: the node cannot be saved because it has been modified externally. at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:908) at org.apache.jackrabbit.core.ItemImpl.persistTransientItems(ItemImpl.java:682) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1173) at org.apache.jackrabbit.core.NodeImpl.lock(NodeImpl.java:3744) at JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:94) 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:100) - FAIL:2, i=6 15:46:18 WARN org.apache.jackrabbit.core.lock.LockManagerImpl$LockInfo.loggingOut(LockManagerImpl.java:892) - Unable to unlock session-scoped lock on node '7c198c7b-76c8-47c8-96a8-d9dfefd4b387-W': Unable to unlock node. Node has pending changes: /folder 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:88) - START id:2, i=7 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:100) - FAIL:2, i=7 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:88) - START id:2, i=8 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:100) - FAIL:2, i=8 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:88) - START id:2, i=9 15:46:18 INFO JrTestConcurrentLocks.run(JrTestConcurrentLocks.java:100) - FAIL:2, i=9 -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: session lifecycle
hi stephan JCR sessions in jackrabbit are rather heavy objects. there are several caches for Paths, ItemStates, Items, etc...some of them are shared among sessions, but some not. i would do some sort of session pooling/sharing/reuse but you need to keep in mind the following points: 1) sessions hold local state information, such as transiently modified items, namespace mappings, etc. so they *cannot* be shared among clients that do write operations. 2) sessions are *not* 100% thread safe. so any read operation must be synchronized. hope this helps, regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: proble registering NodeType's with CND file
) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.jackrabbit.name.UnknownPrefixException: mix at org.apache.jackrabbit.name.QName.fromJCRName(QName.java:597) at org.apache.jackrabbit.core.nodetype.compact.CompactNodeTypeDefReader.toQName (CompactNodeTypeDefReader.java:636) ... 52 more -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: security only for nodes with mix:referenceable?
no. every node has a nodeid. but only the Node.getUUID() works for those that are referenceable. regards, toby On 3/3/06, Torgeir Veimo [EMAIL PROTECTED] wrote: Since the access manager takes a NodeId as parameter in it's permission check methods, is the assumption that only nodes with nodetype mix:referenceable can be under access control correct? -- Torgeir Veimo [EMAIL PROTECTED] -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Jcr-Server Contrib: JSR170 dependency in WebDAV library
i totaly agree. i would prefer to remove the getRepositorySession() completely. returning an object is a sign of poor design. regards, toby On 3/2/06, Angela Schreiber [EMAIL PROTECTED] wrote: hi it has been mentioned in an earlier thread, that the webdav library (contrib/jcr-server/webdav) is designed for generic usage. nevertheless there are currently the following dependencies to jsr170: 1) DavSession.getRepositorySession() [javax.jcr.Session] - dependency in return value 2) DavResourceLocator.getJcrPath() [String] - naming issue 3) DavLocatorFactory: javadoc refering to 2) - javadoc issue actually, i'd prefer to get rid of those dependencies. while 2) and 3) whould only be a matter or renaming, 1) could be solved by returning a generic object or removing the method altogether. what is the feeling about such a change? regards angela -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Copy versioned nodes
hi thomas, versions are not automatically copied.and you are correct, this is not defined by the spec, because the idea is, that by copying your create a new instance of a node, not a backup. so, you need to do it yourself. the problem is, that versions cannot be copied, since the entire version storage is read-only. so what you need to do is to restore all versions of the original node, copy them over to your new node, and check them in, one-by-one. regards, toby On 3/2/06, Thomas Heute [EMAIL PROTECTED] wrote: Hello, I am trying to copy versionable nodes using workspace.copy([...]) with the 0.9 version of JackRabbit From what i experienced, only the latest revision seems to get copied. This is unfortunately not defined by the spec. What i would need is to copy all the versions or a version with a certain tag. Could you please confirm that i need to do the copy by myself ? Or should we change the way it is implemented in jackRabbit ? (Or did i miss something since i am fairly new with JSR 170/JackRabbit. Thanks in advance and thanks for the good work, Thomas. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Commented: (JCR-329) NodeReferencesId.equals() is not symetric
[ http://issues.apache.org/jira/browse/JCR-329?page=comments#action_12368121 ] Tobias Bocanegra commented on JCR-329: -- i would perfer: NodeReferencesId NodeReferences.getId() ; NodeId NodeReferences.getTargetId(); and NodeReferencedId _not_ extending from NodeId NodeReferencesId.equals() is not symetric - Key: JCR-329 URL: http://issues.apache.org/jira/browse/JCR-329 Project: Jackrabbit Type: Improvement Versions: 0.9 Reporter: Marcel Reutegger Assignee: Stefan Guggisberg Priority: Minor Fix For: 1.0 Attachments: NodeReferencesId.patch NodeReferencesId.equals() is not symetric when equality is tested against a NodeId. Code example: UUID uuid = UUID.randomUUID(); NodeId id = new NodeId(uuid); NodeReferencesId refId = new NodeReferencesId(uuid); id.equals(refId); // will return true refId.equals(id); // will return false NodeReferencesId should be decouled from the ItemId hierarchy. The class NodeReferences already does not extend from NodeState which makes perfectly sense. So, the same should apply to the identifier of NodeReferences. The attached patch to NodeReferencesId also requires minor changes to some of the persistence managers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JCR-RMI NodeType/Property problem
hi
the reference property must be set using the node directly:
contact.setProperty(JCRContact.PROP_REFERENCE, node);
regards, toby
On 2/24/06, Ashley Martens [EMAIL PROTECTED] wrote:
I have an issue with JCR-RMI.
I have a custom nodetype:
pl = 'http://powerlender.com/ns'
[pl:contact] nt:base
/* Properties */
- pl:contactDate (string) = '' mandatory
- pl:contactBy(string) = '' mandatory
- pl:contactType (long) = '0' mandatory
- pl:ref (reference)
When I create a node of this type and assign values to the properties under
an embedded Jackrabbit instance it works fine. However, when I run the same
code through JCR-RMI I get an error.
Code:
Node contact = contacts.addNode(test-attachment,
JCRContact.NT_CONTACT);
contact.setProperty(JCRContact.PROP_CONTACT_BY, PL);
contact.setProperty(JCRContact.PROP_CONTACT_DATE,
2005-12-26);
contact.setProperty(JCRContact.PROP_CONTACT_TYPE, 1);
contact.setProperty(JCRContact.PROP_REFERENCE,
node.getUUID()); -- Error occurs here
Error from JCR-RMI client.
javax.jcr.nodetype.ConstraintViolationException: no matching property
definition found for {http://powerlender.com/ns}ref
at
org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:103)
at
org.apache.jackrabbit.rmi.server.ServerNode.setProperty(ServerNode.java:249)
Error from JCR-RMI server:
javax.jcr.nodetype.ConstraintViolationException: no matching property
definition found for {http://powerlender.com/ns}ref
at
org.apache.jackrabbit.core.nodetype.EffectiveNodeType.getApplicablePropertyDef(EffectiveNodeType.java:797)
at
org.apache.jackrabbit.core.NodeImpl.getApplicablePropertyDefinition(NodeImpl.java:887)
at
org.apache.jackrabbit.core.NodeImpl.getOrCreateProperty(NodeImpl.java:433)
at
org.apache.jackrabbit.core.NodeImpl.getOrCreateProperty(NodeImpl.java:403)
at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:2014)
at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:2042)
at
org.apache.jackrabbit.rmi.server.ServerNode.setProperty(ServerNode.java:247)
When I looked in the EffectiveNodeType class I noticed that the error occurs
when the class cannot find the property definition, but when I look in the
custom_nodetypes.xml file in my repository the nodetype and the property
definition look good.
- nodeType hasOrderableChildNodes=false isMixin=false name=pl:contact
primaryItemName=
- supertypes
supertypent:base/supertype
/supertypes
- propertyDefinition autoCreated=false mandatory=true multiple=false
name=pl:contactDate onParentVersion=COPY protected=false
requiredType=String
- defaultValues
defaultValue /
/defaultValues
/propertyDefinition
- propertyDefinition autoCreated=false mandatory=true multiple=false
name=pl:contactBy onParentVersion=COPY protected=false
requiredType=String
- defaultValues
defaultValue /
/defaultValues
/propertyDefinition
- propertyDefinition autoCreated=false mandatory=true multiple=false
name=pl:contactType onParentVersion=COPY protected=false
requiredType=Long
- defaultValues
defaultValue0/defaultValue
/defaultValues
/propertyDefinition
propertyDefinition autoCreated=false mandatory=false multiple=false
name=pl:ref onParentVersion=COPY protected=false
requiredType=Reference /
/nodeType
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: binary value - contentLength
have a look at: Property.getLength() regards, toby On 2/22/06, Torgeir Veimo [EMAIL PROTECTED] wrote: In order to get the size (content length) of a binary value, do I have to store it when the content is saved to the repository, or is there a method I've overlooked somewhere? -- Torgeir Veimo [EMAIL PROTECTED] -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: setProperty ItemNotFoundException
hi carlos,
i would be good, if you could figure out some test-case or test-code
that reproduces the behaviour you've seen. if the itegrity of the
repository is corrupted, there must be a bug somewhere else. i don't
think covering the exception does any good to this :-)
regards, toby
On 2/22/06, Carlos Villegas [EMAIL PROTECTED] wrote:
Hi,
I'm new to this list, and JIRA is very slow...
I having a trouble in which sometimes Node.setProperty throws an
ItemNotFoundException. It seems the node is corrupted, that property was
set previously and something went wrong. Now it throws ItemNotFound. I
try to trace the exception, and found that the id exists, so it seems
the property is defined somewhere but it gives the error when it tries
to retrieve the item state. So I tried to delete the node and recreate
it but it gives me the same error, I can't delete it.
Well, to make the deletion work, I did the following on
NodeImpl.onRemove()
// remove properties
// use temp set to avoid ConcurrentModificationException
HashSet tmp = new HashSet(thisState.getPropertyNames());
for (Iterator iter = tmp.iterator(); iter.hasNext();) {
QName propName = (QName) iter.next();
// remove the property entry
thisState.removePropertyName(propName);
// remove property
PropertyId propId = new PropertyId(thisState.getNodeId(),
propName);
try {
itemMgr.getItem(propId).setRemoved();
} catch (ItemNotFoundException ne) {
// ignore it?
}
}
Note the try/catch statement.
This works, I can now delete the node and recreate it. But I don't know
if this is correct or if it leaves garbage in the persistence storage.
Also I don't know how the node got to that state. But I need to do some
recovery.
Any thoughts?
Carlos
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: best practice - node view count
hi torgeir, there is a descriptor that provides you with this information: RepositoryImpl . . // names of well-known repository properties public static final String STATS_NODE_COUNT_PROPERTY = jcr.repository.stats.nodes.count; public static final String STATS_PROP_COUNT_PROPERTY = jcr.repository.stats.properties.count; . . so just call: repository.getDescriptor(jcr.repository.stats.nodes.count); regards, toby On 2/21/06, Torgeir Veimo [EMAIL PROTECTED] wrote: Has anyone implemented view counting for nodes in a jcr setup? I'd assume it would hurt performance to store view count as a node property. -- Torgeir Veimo [EMAIL PROTECTED] -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Created: (JCR-325) docview roundtripping does not work with multivalue non-string properties
docview roundtripping does not work with multivalue non-string properties
-
Key: JCR-325
URL: http://issues.apache.org/jira/browse/JCR-325
Project: Jackrabbit
Type: Bug
Components: core
Versions: 0.9
Environment: jackrabbit r379292
Reporter: Tobias Bocanegra
when exporting a multivalue property with docview, the property values are
serialized to a space delimited list in the xml attributes:
for example:
?xml version=1.0 encoding=UTF-8?
.
.
testNode
jcr:primaryType=refTest
refs=b5c12524-5446-4c1a-b024-77f623680271
7b4d4e6f-9515-47d8-a77c-b4beeaf469bc
/
the refTest nodetype was:
[refTest]
- refs (reference) multiple
importing this docview fails with: javax.jcr.ValueFormatException: not a valid
UUID format
this is due to the fact, that the space delimited list is not exploded anymore.
actually this code is commented:
org.apache.jackrabbit.core.xml.DocViewImportHandler, lines 191 - 200:
/*
// @todo should attribute value be interpreted as LIST type
(i.e. multi-valued property)?
String[] strings = Text.explode(attrValue, ' ', true);
propValues = new Value[strings.length];
for (int j = 0; j strings.length; j++) {
// decode encoded blanks in value
strings[j] = Text.replace(strings[j], _x0020_, );
propValues[j] = InternalValue.create(strings[j]);
}
*/
i haven't tested, but i assume this also fails for all other non-string
property types.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-317) replace UUID strings by UUID classes in NodeId, etc..
[ http://issues.apache.org/jira/browse/JCR-317?page=comments#action_12366619 ] Tobias Bocanegra commented on JCR-317: -- - replaced all usages of 'String uuid' by 'NodeId' - replaced the uuids in the child node entries by NodeId - replaced parentUUID of the item state by 'NodeId' - contructors of the ItemState now take ItemIds - added NodeState.getNodeId() - added PropertyState.getPropertyId() replace UUID strings by UUID classes in NodeId, etc.. - Key: JCR-317 URL: http://issues.apache.org/jira/browse/JCR-317 Project: Jackrabbit Type: Improvement Versions: 0.9 Environment: r376692 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Fix For: 1.0 Currently the UUIDs of the nodes are stored as Strings in the ItemIds and ItemStates and cause alot of overhead throughout jackrabbit. they should be replaced by a fast implementation of a UUID class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-317) replace UUID strings by UUID classes in NodeId, etc..
[ http://issues.apache.org/jira/browse/JCR-317?page=all ] Tobias Bocanegra resolved JCR-317: -- Resolution: Fixed fixed in revision 378221 replace UUID strings by UUID classes in NodeId, etc.. - Key: JCR-317 URL: http://issues.apache.org/jira/browse/JCR-317 Project: Jackrabbit Type: Improvement Versions: 0.9 Environment: r376692 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Fix For: 1.0 Currently the UUIDs of the nodes are stored as Strings in the ItemIds and ItemStates and cause alot of overhead throughout jackrabbit. they should be replaced by a fast implementation of a UUID class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
JCR-317....
hi all, i just commited a rather large set of modified files. this fixed a lot of object creations when internally converting uuid strings to NodeIds and vice-versa. this fix should speedup jackrabbit by factor 2. the downside of this change is that some of the signatures of ItemId, NodeId, PropertyId, ItemState, NodeState, PropertyState changed. the ones that built their own persistence managers probably need to adapt this. sorry for any inconvenience caused. regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: use of java 1.4 assert
yeah +1 regards, tobi On 2/16/06, Felix Meschberger [EMAIL PROTECTED] wrote: what's the general feeling about this? +1 Regards Felix -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Closed: (JCR-308) Nodes having OPV=Ignore are removed on restore
[ http://issues.apache.org/jira/browse/JCR-308?page=all ] Tobias Bocanegra closed JCR-308: Nodes having OPV=Ignore are removed on restore -- Key: JCR-308 URL: http://issues.apache.org/jira/browse/JCR-308 Project: Jackrabbit Type: Bug Components: versioning Environment: jackrabbit r370795 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra JCR1.0 Specification mentions: 8.2.11.5 IGNORE Child Node On checkin of N, no state information about C will be stored in VN. On restore of VN, the child node C of the current N will remain and not be removed. Property On checkin of N, no state information about P will be stored in VN. On restore of VN, the property P of the current N will remain and not be removed. but the current implementation removed the ignore child. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-308) Nodes having OPV=Ignore are removed on restore
[ http://issues.apache.org/jira/browse/JCR-308?page=all ] Tobias Bocanegra reassigned JCR-308: Assign To: Tobias Bocanegra Nodes having OPV=Ignore are removed on restore -- Key: JCR-308 URL: http://issues.apache.org/jira/browse/JCR-308 Project: Jackrabbit Type: Bug Components: versioning Environment: jackrabbit r370795 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra JCR1.0 Specification mentions: 8.2.11.5 IGNORE Child Node On checkin of N, no state information about C will be stored in VN. On restore of VN, the child node C of the current N will remain and not be removed. Property On checkin of N, no state information about P will be stored in VN. On restore of VN, the property P of the current N will remain and not be removed. but the current implementation removed the ignore child. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Version references
i don't understand... if you have a reference property R1 that points to a node N1 and you check-in the node of that property, it is copied to the version storage, let's name it R1.1 calling N1.getReferences() only returns the R1 but not R1.1. you can't modify the R1.1 anyways, so you don't need to alter it before deleting N1. regards, toby On 2/1/06, Martin Perez [EMAIL PROTECTED] wrote: Sorry, Do you mean that I have to search on the version storage? Do you have a sample query. I'm a little lost since the last changes index changes. I know to look on normal storage we should use /jcr:root but what about looking on the version storage? Martin On 2/1/06, Tobias Bocanegra [EMAIL PROTECTED] wrote: hi martin, this is one speciality about the version storage - the references 'into the normal space' do not work. otherwise you would never be able to delete any node, that has a versioned reference pointing on it, since you can't modify a version. the other way around, it should work (eg: the jcr:baseVersion property). regards, toby On 1/31/06, Martin Perez [EMAIL PROTECTED] wrote: Hello. I have a node A that have many property references R1 on N1,R2 on N2,R3 on N3, When A is deleted, I get the references using A.getReferences() and I change those reference values to a default value so R1 = D, R2 = D, R3 = D, ... The problem is that the method getReferences() does not returns references that come from version nodes. So now, I'm getting several ItemNotFoundExceptions. How could I remove those references? Do I have to search the references manually? And in that case, how can I search only on the version storage? Thanks! Martin -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com --- -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Behavior of CompactNodeTypeDefReader in contribution nt-ns-util
hi michael,
you are right. this extra declaration is not needed (but does not do
any harm neither). i will fix this. thanks for reporting this.
regads, toby
On 2/1/06, Michael Singer [EMAIL PROTECTED] wrote:
Hi list,
I wrote a simple program which uses the nt-ns-util contribution to
register custom node types written in CND language.
I defined the following (very simple) custom node types:
test = 'http://foo.bar/test'
[test:firstnodetype]
+ test:secondnodetype mandatory
test = 'http://foo.bar/test'
[test:secondnodetype] test:firstnodetype
+ test:thirdnodetype
test = 'http://foo.bar/test'
[test:thirdnodetype] test:secondnodetype
- test:catalog (string) 'URI', 'URN', 'DOI', 'ISBN', 'ISSN'
- test:entry (string) m
In the resulting custom_nodetypes.xml each of the custom nodes has a
supertype of nt:base but I didn't explicitely define a supertype of
nt:base for [test:secondnodetype] and [test:thirdnodetype].
I think this behavior is wrong since the method getDeclaredSupertypes()
of class NodeType always returns nt:base plus the explicitely declared
Supertype (which it e.g. does not for nt:folder).
I changed the code to avoid the creation of nt:base supertypes if not
explicitely declared (if no supertype is declared nt:base still gets
created). This patch will do the change:
Index:
Z:/_DATA/workspace/nt-ns-util/src/main/java/org/apache/jackrabbit/core/nodetype/compact/CompactNodeTypeDefReader.java
===
---
Z:/_DATA/workspace/nt-ns-util/src/main/java/org/apache/jackrabbit/core/nodetype/compact/CompactNodeTypeDefReader.java
(revision 374032)
+++
Z:/_DATA/workspace/nt-ns-util/src/main/java/org/apache/jackrabbit/core/nodetype/compact/CompactNodeTypeDefReader.java
(working copy)
@@ -206,7 +206,7 @@
// add nt:base to superclasses if not mixin
if (!ntd.isMixin()) {
HashSet superTypes = new
HashSet(Arrays.asList(ntd.getSupertypes()));
-if (!superTypes.contains(QName.NT_BASE)) {
+if (superTypes.size() == 0) {
superTypes.add(QName.NT_BASE);
ntd.setSupertypes((QName[]) superTypes.toArray(new
QName[superTypes.size()]));
}
Can someone tell me if I am missing something?
--
kind regards
Michael
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
[jira] Created: (JCR-312) CompactNodeTypeDefReader adds nt:base as declared supertype even if already extending
CompactNodeTypeDefReader adds nt:base as declared supertype even if already extending - Key: JCR-312 URL: http://issues.apache.org/jira/browse/JCR-312 Project: Jackrabbit Type: Bug Environment: nt-ns-util r374055 Reporter: Tobias Bocanegra (reported to the list by michael singer) I wrote a simple program which uses the nt-ns-util contribution to register custom node types written in CND language. I defined the following (very simple) custom node types: test = 'http://foo.bar/test' [test:firstnodetype] + test:secondnodetype mandatory test = 'http://foo.bar/test' [test:secondnodetype] test:firstnodetype + test:thirdnodetype test = 'http://foo.bar/test' [test:thirdnodetype] test:secondnodetype - test:catalog (string) 'URI', 'URN', 'DOI', 'ISBN', 'ISSN' - test:entry (string) m In the resulting custom_nodetypes.xml each of the custom nodes has a supertype of nt:base but I didn't explicitely define a supertype of nt:base for [test:secondnodetype] and [test:thirdnodetype]. I think this behavior is wrong since the method getDeclaredSupertypes() of class NodeType always returns nt:base plus the explicitely declared Supertype (which it e.g. does not for nt:folder). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-312) CompactNodeTypeDefReader adds nt:base as declared supertype even if already extending
[ http://issues.apache.org/jira/browse/JCR-312?page=all ] Tobias Bocanegra reassigned JCR-312: Assign To: Tobias Bocanegra CompactNodeTypeDefReader adds nt:base as declared supertype even if already extending - Key: JCR-312 URL: http://issues.apache.org/jira/browse/JCR-312 Project: Jackrabbit Type: Bug Environment: nt-ns-util r374055 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra (reported to the list by michael singer) I wrote a simple program which uses the nt-ns-util contribution to register custom node types written in CND language. I defined the following (very simple) custom node types: test = 'http://foo.bar/test' [test:firstnodetype] + test:secondnodetype mandatory test = 'http://foo.bar/test' [test:secondnodetype] test:firstnodetype + test:thirdnodetype test = 'http://foo.bar/test' [test:thirdnodetype] test:secondnodetype - test:catalog (string) 'URI', 'URN', 'DOI', 'ISBN', 'ISSN' - test:entry (string) m In the resulting custom_nodetypes.xml each of the custom nodes has a supertype of nt:base but I didn't explicitely define a supertype of nt:base for [test:secondnodetype] and [test:thirdnodetype]. I think this behavior is wrong since the method getDeclaredSupertypes() of class NodeType always returns nt:base plus the explicitely declared Supertype (which it e.g. does not for nt:folder). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-312) CompactNodeTypeDefReader adds nt:base as declared supertype even if already extending
[ http://issues.apache.org/jira/browse/JCR-312?page=all ] Tobias Bocanegra resolved JCR-312: -- Fix Version: 0.9 Resolution: Fixed fixed . Date: Wed Feb 1 05:54:23 2006 New Revision: 374065 Modified: incubator/jackrabbit/trunk/contrib/nt-ns-util/src/main/java/org/apache/jackrabbit/core/nodetype/compact/CompactNodeTypeDefReader.java please note: CND that defined nodetypes that just extended from mixintypes, but did not extend from nt:base and are not mixin types themselfes, cannot be registered anymore. they need to be extended from nt:base explicitely. eg: [my:Profile] mix:referenceable does not work anymore, since it just extends from a mixin type but not from a primary type: [my:Profile] mix:referenceable, nt:base CompactNodeTypeDefReader adds nt:base as declared supertype even if already extending - Key: JCR-312 URL: http://issues.apache.org/jira/browse/JCR-312 Project: Jackrabbit Type: Bug Environment: nt-ns-util r374055 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Fix For: 0.9 (reported to the list by michael singer) I wrote a simple program which uses the nt-ns-util contribution to register custom node types written in CND language. I defined the following (very simple) custom node types: test = 'http://foo.bar/test' [test:firstnodetype] + test:secondnodetype mandatory test = 'http://foo.bar/test' [test:secondnodetype] test:firstnodetype + test:thirdnodetype test = 'http://foo.bar/test' [test:thirdnodetype] test:secondnodetype - test:catalog (string) 'URI', 'URN', 'DOI', 'ISBN', 'ISSN' - test:entry (string) m In the resulting custom_nodetypes.xml each of the custom nodes has a supertype of nt:base but I didn't explicitely define a supertype of nt:base for [test:secondnodetype] and [test:thirdnodetype]. I think this behavior is wrong since the method getDeclaredSupertypes() of class NodeType always returns nt:base plus the explicitely declared Supertype (which it e.g. does not for nt:folder). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from o.a.j.core to o.a.j.api
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364545 ] Tobias Bocanegra commented on JCR-309: -- if find NodeTypeManagerImpl.registerNodeTypes(InputStream) very useless. since clients would need to fake XML in order to create the node types. i suggest to elaborate NodeType stuff for 2.0 and then expose this api. Extract the public API interfaces from o.a.j.core to o.a.j.api -- Key: JCR-309 URL: http://issues.apache.org/jira/browse/JCR-309 Project: Jackrabbit Type: Task Components: API Reporter: Jukka Zitting Fix For: 1.0 Attachments: jackrabbit-api.patch To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package. At least the following interfaces should be moved along with any supporting implementation-independent classes: * PersistenceManager * FileSystem * AccessManager * QueryHandler * TextFilter Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces. Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from o.a.j.core to o.a.j.api
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364607 ] Tobias Bocanegra commented on JCR-309: -- ok. lets add the register nodetype. but i would prefer an 'org.xml.sax.InputSource' instead of the input stream. and maybe an additional content type: public NodeType[] NodeTypeManagerImpl.registerNodeTypes(InputSource in, String contentType); contentType is either: text/xml or text/cnd the advantage of the inputsource is: it has a systemId that can be used to resolve entities (eg: relatvie DVDs), and also for better error reporting. Extract the public API interfaces from o.a.j.core to o.a.j.api -- Key: JCR-309 URL: http://issues.apache.org/jira/browse/JCR-309 Project: Jackrabbit Type: Task Components: API Reporter: Jukka Zitting Fix For: 1.0 Attachments: jackrabbit-api.patch To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package. At least the following interfaces should be moved along with any supporting implementation-independent classes: * PersistenceManager * FileSystem * AccessManager * QueryHandler * TextFilter Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces. Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lack of performance and possible optimization
hi sirene, if you have no further structure information (which is not very typical), you would invent some hierarchy eg, you create a random id, and make every level max 256 nodes wides. for example a node with the id: 0x0123456789abcdef you could be stored at: /01/23/45/6789abcdef. it usually does not make sense to divide further, since with 4 levels, you would already have 2^32 leaves, which is enough for your example. you can then access the node by a simple: Node node = (Node) Session.getItem(/01/23/45/6789abcdef); If you don't need to control the way your 'id' is generated, you can also create referenceable nodes, and use it's UUID as id. your suggestion of how to access the node is probably the least favorable. you don't leverage any of the builtin mechanisms of the repository: neither path, nor uuid, nor search. maybe if you explain what type of content you want to store, we might be able to help you with modeling the nodetypes and figure out an appropriate content layout. regards, toby On 1/28/06, sirène vip [EMAIL PROTECTED] wrote: Hello, I have a question about opitmisation and performance. Supposing that I have 1'000'000 nodes to store in my tree under the root node, where each node has system-generated unique ID. Then in a later phase, I want to unstore one node with a specfic ID. What I'm doing currently is iterating over these nodes and for each node, getting its ID and comparing it the ID of the node to be unstored. I was wondering about the performance of such a solution and what other alternatives exist in order to optimize it. Thank you. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Commented: (JCR-309) Extract the public API interfaces from o.a.j.core to o.a.j.api
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364096 ] Tobias Bocanegra commented on JCR-309: -- well, some of those groups are rather interfaces that provide a backend service, and are not usefull for the 'client'. so i would devide: Client Interface: - NodeType stuff Service Provider Interface - PersistenceManager - FileSystem - AccessManager - QueryHandler - TextFilter Extract the public API interfaces from o.a.j.core to o.a.j.api -- Key: JCR-309 URL: http://issues.apache.org/jira/browse/JCR-309 Project: Jackrabbit Type: Task Components: API Reporter: Jukka Zitting Fix For: 1.0 To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package. At least the following interfaces should be moved along with any supporting implementation-independent classes: * PersistenceManager * FileSystem * AccessManager * QueryHandler * TextFilter Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces. Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: For restoring a node, a IGNOREed child node throws ConstrainViolationException
hi roland,
thanks for finding this. i created a jira issue for this bug:
http://issues.apache.org/jira/browse/JCR-308
regards, toby
On 1/22/06, Roland Kofler [EMAIL PROTECTED] wrote:
A version IGNORED child node should remain in the node tree if you
revert to a previous version. This is stated in the subchapter 8.2.11.5
of JCR170.
I've found that jackrabbit removes the IGNORED child node after a
revert, wich is wrong.
Neverthenless I have to say: You are great!
Roland
doing this:
public void revertToVersion(Node jcrNode, NodeHolder nodeHolder) {
try {
jcrNode.restore((Version)
(nodeHolder.getJcrNode().getParent()), false);
} catch (RepositoryException e) {
throw new IllegalStateException(e);
}
}
on that:
!-- PAGE --
!-- page definition --
nodeType hasOrderableChildNodes=true isMixin=false
name=s1NT:page primaryItemName=
supertypes
supertypent:base/supertype
supertypemix:referenceable/supertype
supertypemix:versionable/supertype
supertypemix:lockable/supertype
/supertypes
...
!-- similarity results root child node --
childNodeDefinition autoCreated=true
defaultPrimaryType=s1NT:similarityRoot mandatory=true
name=s1:similarityRoot
onParentVersion=IGNORE protected=false sameNameSiblings=false
/childNodeDefinition
/nodeType
...
leads to:
java.lang.IllegalStateException:
javax.jcr.nodetype.ConstraintViolationException: /s1:pages/s1:page:
mandatory child node {http://www.systemone.at/jcr}similarityRoot does
not exist
...
at
org.apache.jackrabbit.core.ItemImpl.validateTransientItems(ItemImpl.java:557)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1131)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:3502)
at org.apache.jackrabbit.core.NodeImpl.restore(NodeImpl.java:2848)
at
at.systemone.wiki.node.PageNodeWorker.revertToVersion(PageNodeWorker.java:21)
... 18 more
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: Value based AccessManager?
hi mike, one solution is to give a system session to the access manager that is separate from the one actually accessing the workspace (user session). during the save operation of the user session, this system session still has the 'old' view on the workspace and can be used to determine the authorization. regards, toby On 1/20/06, Daglian, Michael (IT) [EMAIL PROTECTED] wrote: Hello everyone, I am having a bit of trouble determining how to use the AccessManager interface to provide authorization rather than authentication. We have a Jackrabbit-external authorization service based upon certain attributes of the repository data (the path and declaring node type of the modified item as well as property values - we don't authorize to the individual property level). I can work around the access manager configuration not including a session instance (albeit a less than ideal solution). However, an issue arises when attempting to authorize removal operations. Jackrabbit appears only to invoke the access manager to check for removal permissions upon save (i.e. in the validateTransientItems method of ItemImpl). However, access to property values (or even the removed item) at this point isn't possible since the item has been removed from the session (even it's state is not very accessible as it's in the attic of the TransientItemStateManager). Has anyone else ventured down this path and come up with a clean solution? Apologies if this has been addressed in earlier discussions but a search of the archives did not yield anything. Regards, -- Mike NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Commented: (JCR-306) repositoryConfig should use setter for its internal components
[ http://issues.apache.org/jira/browse/JCR-306?page=comments#action_12363253 ] Tobias Bocanegra commented on JCR-306: -- i strongly oppose to apply the suggested patch. stefan is right - the internals of jackrabbit rely on the fact that the config classes are immutable. we should not break this. i suggest to create some sort of ConfigBuilder which has all the relevant getter and setter methods, and a 'create()' method that creates the immutable config objects. repositoryConfig should use setter for its internal components -- Key: JCR-306 URL: http://issues.apache.org/jira/browse/JCR-306 Project: Jackrabbit Type: Improvement Components: config Reporter: Costin Leau Assignee: Jukka Zitting Fix For: 0.9 Attachments: RepositoryConfig.patch From the mailing list (not archived at the moment): --- Jukka's reply --- I refactored the config classes last year but didn't change the way the config instances are being used by Jackrabbit. In general I think that a IoC approach (use setters to configure the Jackrabbit components) would be better than passing config objects around and letting the components to instantiate any subcomponents based on the configuration. This is why I didn't really want to make the config constructors public, otherwise we'd easily up with backwards compatibility issues if we were to change the way configuration is handled. --- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: EJB-Access to Repository
make sure, the log4j.jar is not present in the WEB-INF/lib of your
webapp. i assume there is a clash in the classloader hierarchy.
On 1/11/06, Humer Günther [EMAIL PROTECTED] wrote:
I developed a Session-Bean which creates a Repository with
RepositoryConfig.create.
public void startRepository() throws Exception {
Repository rep;
String repHome = jackrep;
String repConfig = repository.xml;
InputStream stream = getStream(repConfig);
RepositoryConfig config = RepositoryConfig.create(stream, repHome);
rep = RepositoryImpl.create(config);
}
The EAR contains the Bean and Jackrabbit-lib and the dependencies.
I am using JBoss 4.0.3SP1 as the ApplicationServer
When I call the Method I get a ClassCastException [1], which seems to come
from log4j.
I inspected the log4j of JBoss and Jackrabbit, they're both 1.2.8...
Any suggestions??
If I execute the Method locally (without running the Bean on Jboss, it
succeeds.
[1]
15:11:40,838 INFO [STDOUT] log4j:ERROR A
org.jboss.logging.util.OnlyOnceErrorHandler object is not assignable to a
org.apache.log4j.spi.ErrorHandler variable.
15:11:40,838 INFO [STDOUT] log4j:ERROR The class
org.apache.log4j.spi.ErrorHandler was loaded by
15:11:40,838 INFO [STDOUT] log4j:ERROR [EMAIL PROTECTED]
url=file:/D:/Program
Files/jboss/jboss-4.0.3SP1/server/default/tmp/deploy/tmp10849dms.ear
,addedOrder=58}] whereas object of type
15:11:40,838 INFO [STDOUT] log4j:ERROR
org.jboss.logging.util.OnlyOnceErrorHandler was loaded by [EMAIL PROTECTED]
15:11:40,978 INFO [STDOUT] log4j:ERROR Could not create an Appender.
Reported error follows.
15:11:40,978 INFO [STDOUT] java.lang.ClassCastException:
org.jboss.logging.appender.DailyRollingFileAppender
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:165)
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:140)
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:153)
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:415)
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:384)
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:783)
15:11:40,978 INFO [STDOUT] at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:666)
15:11:40,978 INFO
...
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: XML schema to node types
i committed the patch at revision: 367525
regards, toby
On 1/10/06, Peeter Piegaze [EMAIL PROTECTED] wrote:
Hi Mike,
You are right about that bug.
I have intermittent access to a useful computer right now (travelling)
and can't commit stuff (for some mysterious reason) but I have
arranged to have a patch applied by another committer which should fix
tthe specific problem. As for the more general issue of dealing with
the default namespace I will take a look at that when I get a chance.
Of course your are free to fix stuff yourself and send patches to me
or another commiter.
Actually could you clarify exactly what the default namespace issue is
again? I am not quite sure I see what you mean (though I am sure you
are right :-)
Sorry I can't be of more help at the moment,
Cheers,
Peet
On 1/10/06, Michael Daglian [EMAIL PROTECTED] wrote:
Hello Peeter,
Apologies if I am misusing the schema converter code you committed but I
am a bit confused as to how to make use of the NamespaceExtractor class.
As demonstrated in your test-case for the SchemaConverter I am
attempting to use an extractor to get the additional namespaces out a
schema file. However, this does not appear possible due to the use of
getURI for the mapping property:
if (mapping.getURI(prefix) != null){...
The NamespaceMapping class throws an exception if the prefix is unmapped
and thus the empty NamespaceMapping created using the default structure
always generates this exception, which only gets caught and logged.
On another note, it seems unclear how to best handle the default
namespace using the NamespaceMapping class. When using the reader and
explicitly mapping the namespace to be (i.e
NamespaceMapping.setMapping(, );), this works fine. But when
outputting it writes the default namespace in a manner that the reader
cannot read. Is there a recommended way of handling this case? Thanks!
Best Regards,
-- Mike
On 12/20/05, Peeter Piegaze [EMAIL PROTECTED] wrote:
Hi Nicolas,
Regarding your interest in XML schema to JCR node type conversion: I
have committed the XSD to JCR node type converter into
contribs/nt-ns-util
Cheers
Peeter
On 10/31/05, Nicolas Belisle [EMAIL PROTECTED] wrote:
Great news !
I'm looking forward to this.
Many thanks,
Nick
Hi Nicholas, Actually, I wrote something that does this. I haven't
gotten
around to completely finishing it yet, but I will take your mail as a
motivator to do just that. Then I will commit to contribs. Cheers,
Peeter
On 10/31/05, Nicolas Belisle [EMAIL PROTECTED] wrote:
Hi, I'm currently investigating ways to convert XML schemas to
Jackrabbit node types declaration. This way, most metadata formats
(Dublin Core, MARC21, etc.) could be integrated easily in a
Jackrabbit
repository. Anyone has done something in that direction and would
like
to its share ideas ? Any other comments on this ? I would
certainly
contribute the result back to Jackrabbit.Regards, Nick
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: Analyzing the Jackrabbit architecture
hi jukka, i just thought again about your NodeId, PropertyId, ItemId refactoring suggestions. in your article you state: [...] Looking at the virtual core.B package we find that only the NodeId, PropertyId, and ItemId classes depend on the state package: [...] i think, it is vice versa. the classes in the state package depend on the *Id classes. those classes are used widely in jackrabbit as identifying objects for the actual items or item states. internally, the path is used seldomly for that purpose. thinking about a possible jackrabbit API, the *Id classes certainly should be a part of it. For example the o.a.j.core.security.AccessManager, which could be seen as part of the 'API' or 'SPI', makes use of those, an so do the persistence managers. as for the API (and/or a possible jcr-283 extension) we could get rid of the very loosly defined UUID of type String and probably introduce the NodeId, PropertyId, ItemId and make it part of the jcr API. i would love to have: Session.getNode(NodeId id) and Node.getId() so if i would need to move the *Id classes, i would put them to org.apache.jackrabbit.* and make them part of the (yet non-existent :-) API. regards, toby On 1/9/06, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 1/9/06, Tobias Bocanegra [EMAIL PROTECTED] wrote: - Split the main core package into subpackages that certainly makes sense, but by what semantics? Good question, I didn't really focus on that very much. It seems that at least the hierarchy and namespace stuff could quite easily be moved to a separate package (or two) as a somewhat coherent set of classes. - Move the nodetype.virtual package to a higher level we could put those into the oaj.core.virtual package. btw: there are plans to remove the virtual states completely and add a more sophisticated approach. OK, then I think we could leave it as is for now. - Move the state subpackages to a separate package as far as i can tell, most of the state subpackages are implementation of persistencemanagers. so i suggest to create a oaj.core.persistencemgr package. Sounds good. The persistence manager concept is a pretty visible one, so moving the PersistenceManager interface and the implementation packages to a dedicated package could clarify things. Currently there are troublesome dependencies from PersistenceManager to the Id classes in o.a.j.core and from the SharedItemStateManager to PersistenceManager. Moving the Id classes to o.a.j.core.state and the item state managers to a new package would clean these up quite nicely, making this part of the dependency structure linear: statemgr - persistencemgr - state. - Make a separate package for the item state managers that would be: oaj.core.statemgr ? Sounds good. PS. I was contacted by Neeraj Sangal from Lattix and he's also taking a look at Jackrabbit architecture. I'll report back when I get more feedback from him. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftmanship, JCR consulting, and Java development -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Analyzing the Jackrabbit architecture
that looks cool. thanks for taking the time. some comments to your suggestions: - Split the main core package into subpackages that certainly makes sense, but by what semantics? - Move the nodetype.virtual package to a higher level we could put those into the oaj.core.virtual package. btw: there are plans to remove the virtual states completely and add a more sophisticated approach. - Move the state subpackages to a separate package as far as i can tell, most of the state subpackages are implementation of persistencemanagers. so i suggest to create a oaj.core.persistencemgr package. - Make a separate package for the item state managers that would be: oaj.core.statemgr ? - Move the NodeId, PropertyId, and ItemId classes to the state package totally makes sense. regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: OnParentVersion attribute
My question is how can I know what was the version of subnodes when new version of node (parent) was created? shortly: you don't (as defined by jsr170) it is the job of the application to retrieve the suitable version, if you need to restore the version again. regards, toby ps: imo, the baseversion reference should be versioned aswell, not just the ref to the history. -- Thanks, Marek -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Exception with WebDAV
well it seems, that you did not recompile all your jars... this looks like a linking problem. the IOUtil is in jcr-server-server, but the DavConstants (where the modificationDateFormat field is in) is in jcr-server-webdav. regards, toby On 12/17/05, Martin Perez [EMAIL PROTECTED] wrote: This happened to me also sometime ago. I just updated today the webdav module, server, rmi, etc., i.e., all, from SVN repository. I have created a repository within the server and when I try to browse it using http://localhost:8080/jlibrary/repository/test I get the following: java.lang.NoSuchFieldError: modificationDateFormat org.apache.jackrabbit.server.io.IOUtil.getLastModified(IOUtil.java:65) org.apache.jackrabbit.server.io.ExportContextImpl.setModificationTime( ExportContextImpl.java:120) org.apache.jackrabbit.server.io.DirListingExportHandler.exportContent( DirListingExportHandler.java:189) org.apache.jackrabbit.server.io.DefaultIOManager.exportContent( DefaultIOManager.java:138) org.apache.jackrabbit.webdav.simple.DavResourceImpl.spool( DavResourceImpl.java:210) org.apache.jackrabbit.server.AbstractWebdavServlet.spoolResource( AbstractWebdavServlet.java:378) org.apache.jackrabbit.server.AbstractWebdavServlet.doGet( AbstractWebdavServlet.java:344) org.apache.jackrabbit.j2ee.SimpleWebdavServlet.execute( SimpleWebdavServlet.java:191) org.apache.jackrabbit.server.AbstractWebdavServlet.service( AbstractWebdavServlet.java:170) javax.servlet.http.HttpServlet.service( HttpServlet.java:802) This happens with any workspace, including default. Any ideas? Regards, Martin -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Commented: (JCR-291) jcr-server-webapp: RMI Registration unstable
[ http://issues.apache.org/jira/browse/JCR-291?page=comments#action_12360196 ] Tobias Bocanegra commented on JCR-291: -- looks good. thanks. jcr-server-webapp: RMI Registration unstable Key: JCR-291 URL: http://issues.apache.org/jira/browse/JCR-291 Project: Jackrabbit Type: Improvement Environment: SVN Rev. 355696 Reporter: Felix Meschberger Priority: Minor Attachments: RMIRegistry_fm_051211.diff Registration of the repository to a RMI registry in RepositoryStartupServlet.registerRMI uses web application parameters inconsistently and may not always succeed registering the repository. Today, the registerRMI uses these parameters for registration to RMI: rmi-host : The name of the host on which the registry is running rmi-port : The port on which the registry is running rmi-uri : An RMI URI to use for registration repository-name : The name to bind the repository to The problem is, that rmi-port is used to try to create the registry to make sure a registry is running on the local host. The rmi-uri is used to register the repository using the static Naming.bind method. If the rmi-uri is not configured, the URI is created from rmi-host, rmi-port and repository-name. This may now create a bunch of problems: If the rmi-port and rmi-uri configurations do not match, registration fails, if rmi-host does not resolve to an IP address to which the registry is bound, registration fails. I encounter this issue, when trying to register the repository to an RMI registry using default rmi-port configuration (rmi-host and rmi-uri not configured) when running the web app in Jetty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Addition to Download Page
Is that what you are talking about Mr/Ms solprovider? It is Mr. solprovider. I have been writing on the web as solprovider since 1995, and own solprovider.com, which has an Apache Lenya section. ...seems, that 10 years of 'web experience' is not enough to build jackrabbit :-)) regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Maven downloads wrong version of commons-collections
you will find all dependencies in your local maven repository directory. that's usually your home directory/.maven/repository I could not find a repository directory under Maven or Jackrabbit (other than jackrabbit\applications\test\repository, which does not contain JARs.) it's a directory named '.maven' in your home directory. ls -al ~/.maven should disclose it I still do not know of a method to add a directory of JARs to the CLASSPATH without naming each individually. (I have been searching for years. I think Sun just likes long CLASSPATHs.) for a in lib/*.jar; do CLASSPATH=$CLASSPATH:$a done regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Properties versus child node definition
read the javadoc On 12/2/05, Simon Gash [EMAIL PROTECTED] wrote: Hi Stefan Thanks for that. What's confusing me is that in JackRabbits propertyDefinitionImpl class there are two properties one is setDeclaringNodeType and one is name. The name actually takes a QName which in my mind is a type. What are these properties for and how should I be using them? Thanks Simon -Original Message- From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: 02 December 2005 09:44 To: jackrabbit-dev@incubator.apache.org Subject: Re: Properties versus child node definition hi simon jackrabbit supports multiple inheritance for node types. create a node type that declares the email properties and add it as a supertype to other node types. alternatively you could create a mixin node type that declares the email properties. you could then add the mixin to individual nodes. cheers stefan On 12/2/05, Simon Gash [EMAIL PROTECTED] wrote: Can properties be inherited by separate node definitions? I'm considering something like an e-mail address where I can represent it as a String property with its own validation constraint. I would like then to be able to add it to other node types whenever I want to use an e-mail address. I guess the other way of doing this would be to use a child node definition but that seems a bit over the top for a simple e-mail address, also I might have multiple e-mail addresses per node type (home, work ...). What's the best way of doing this? Thanks Simon Come visit us at: Content Management Europe Exhibition. 29th November - 1st December 2005, Olympia Grand Hall, London. Stand # 341 GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte Technology Fast 500 EMEA. This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. Email transmission cannot be guaranteed to be secure or error free, as information may be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This email and any files attached to it have been checked with virus detection software before transmission. You should nonetheless carry out your own virus check before opening any attachment. GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software viruses. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: JCR-RMI question
how to you register the repository? take a look at the RepositoryStartupServlet in the jcr-server contrib. make sure to set the useCodeBaseOnly system property: System.setProperty(java.rmi.server.useCodebaseOnly, true); before binding the remote repository. regards, toby On 11/28/05, Peter Darton [EMAIL PROTECTED] wrote: Has anyone here been using the JCR-RMI package? Is this a good place to ask questions about it (it seems to have no dedicated mailing list of its own)? I am trying to run a number of JCRs (implemented using Jackrabbit) on a server machine and make that service available through RMI. I've written a simple command-line application (Main.java) that starts one or more Jackrabbit repositories and then registers them with the RMI naming service. I originally assumed it would be fairly simple, as I've just been pasting bits of code together from examples in the documentation (i.e. nothing clever), so I'd rather expected it just to work, but it isn't working. The problem is that I get the following exception reported: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.lang.ClassNotFoundException: org.apache.jackrabbit.rmi.server.ServerRepository_Stub at sun.rmi.server.UnicastServerRef.oldDispatch(Unknown Source) ... trace cut for brevity ... at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source) at java.rmi.Naming.rebind(Naming.java:160) at jackrabbitdaemon.Main.startRmiRepository(Main.java:69) at jackrabbitdaemon.Main.main(Main.java:179) trace continues to list underlying exception, and the exception that caused that - see attached fullProgramOutput.txt for the whole lot The exception is being thrown after I've started the Jackrabbit repository, right at the point where I attempt to (re)bind the RMI-JCR's RemoteRepository object to the RMI name //drnick:1099/configAuthor (drnick is my hostname). I originally suspected it was caused by a lack of a security policy (one web page told me that failure to set a policy will cause RMI to refuse to load external classes), so I passed in the arguments -Djava.security.manager and -Djava.security.policy=securityPolicy.txt (which is being loaded, as removing the permission causes Jackrabbit to fail to start with a security error). However that failed to fix it. I've also tried passing in the same arguments to RMID (rmid.exe -J-Djava.security.manager -J-Djava.security.policy=securityPolicy.txt -J-Dsun.rmi.activation.execPolicy=none -port 1099), but that's had no effect either. I suspect I'm missing something that'll be obvious that everyone who knows RMI (which I'm rather new to), at least I hope it's nothing too complicated... Can anyone tell me what I'm doing wrong here? Many thanks, Peter _ This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: eventconsumer exceptions
hi costin, it seems, that the exception is thrown in your event listener. maybe you add more error handling to it. regards, toby On 11/24/05, Costin Leau [EMAIL PROTECTED] wrote: Hello, I'm trying to use EventListener but I keep getting these messages - sometimes 3, sometimes one and sometimes none. [java] 2005-11-24 17:05:30,489 [ObservationManager] WARN org.apache.jackrabbit.core.observation.ObservationManagerFactory - EventConsumer threw exception: java.lang.IllegalStateException: not in itialized [java] 2005-11-24 17:05:30,489 [ObservationManager] WARN org.apache.jackrabbit.core.observation.ObservationManagerFactory - EventConsumer threw exception: java.lang.IllegalStateException: not in itialized [java] 2005-11-24 17:05:30,489 [ObservationManager] WARN org.apache.jackrabbit.core.observation.ObservationManagerFactory - EventConsumer threw exception: java.lang.IllegalStateException: not in itialized I have no idea what causes this messages. I assumed this has something to do with events being asynchronous. I've added a Thread.sleep but I still get one (I do get to log the others): [mkdir] Created dir: C:\work\study\springmodules-0.2\workspace\springmodules\samples\jcr\.classes\repo [java] constructor called [java] received events: [java] Event[path=/sample node/sample property|type=4|userID=bogus] [java] Event[path=/sample node/jcr:primaryType|type=4|userID=bogus] [java] Event[path=/sample node|type=1|userID=bogus] [java] received events: [java] Event[path=/sample node/sample property|type=4|userID=bogus] [java] Event[path=/sample node/jcr:primaryType|type=4|userID=bogus] [java] Event[path=/sample node|type=1|userID=bogus] [java] 2005-11-24 17:14:02,335 [ObservationManager] WARN org.apache.jackrabbit.core.observation.ObservationManagerFactory - EventConsumer threw exception: java.lang.IllegalStateException: not in itialized What exactly I am doing wrong here. I can provide the source code however the code is very simple - I get a session and just attach a listener (which simply logs) to it. Nothing special. -- Best regards, Costin Leau mailto:[EMAIL PROTECTED] -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Re[2]: eventconsumer exceptions
|userID=bogus] [java] Event[path=/sample node|type=1|userID=bogus] [java] received events: [java] Event[path=/sample node/sample property|type=4|userID=bogus] [java] Event[path=/sample node/jcr:primaryType|type=4|userID=bogus] [java] Event[path=/sample node|type=1|userID=bogus] [java] 2005-11-24 17:14:02,335 [ObservationManager] WARN org.apache.jackrabbit.core.observation.ObservationManagerFactory - EventConsumer threw exception: java.lang.IllegalStateException: not in itialized What exactly I am doing wrong here. I can provide the source code however the code is very simple - I get a session and just attach a listener (which simply logs) to it. Nothing special. -- Best regards, Costinmailto:[EMAIL PROTECTED] -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Atom node types
i have peeters code, and i will provide it shortly On 11/23/05, David Nuescheler [EMAIL PROTECTED] wrote: hi jukka, looks great. sorry for the delay. with respect to the compact node type definition i just quickly made peeters draft available here: http://www.day.com/o.file/Compact%20Node%20Type%20Definition.doc?get=c4a27b78b1e464a44f7f63e34aeb9f3c i think that it would be interesting to have some code that converts nodetype definitions to and from the compact notation. [peeter, didn't you start to do something like that at one point? did that already make it into some experimental contrib? ] regards, david -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Atom node types
peeter, can you tell me what happend to the short notation, like: [ex:NodeType] ex:ParentType1, ex:ParentType2 orderable mixin - ex:property (STRING) primary mandatory = 'default1', 'default2' 'constraint1', 'constraint2' + ex:node (ex:reqType1, ex:reqType2) = ex:defaultType ? On 11/23/05, David Nuescheler [EMAIL PROTECTED] wrote: hi jukka, looks great. sorry for the delay. with respect to the compact node type definition i just quickly made peeters draft available here: http://www.day.com/o.file/Compact%20Node%20Type%20Definition.doc?get=c4a27b78b1e464a44f7f63e34aeb9f3c i think that it would be interesting to have some code that converts nodetype definitions to and from the compact notation. [peeter, didn't you start to do something like that at one point? did that already make it into some experimental contrib? ] regards, david -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Atom node types
and where did the namespace declaration go ?
we had this:
cnd ::= { ns_decl | node_type_def };
ns_decl ::= '' prefix '=' uri '';
node_type_def ::= see document
for example:
nt='http://www.jcp.org/jcr/nt/1.0'
[nt:unstructured]
- *
+ *
(extending nt:base was implizit for non-mixin types)
On 11/23/05, David Nuescheler [EMAIL PROTECTED] wrote:
hi jukka,
looks great. sorry for the delay.
with respect to the compact node type definition
i just quickly made peeters draft available here:
http://www.day.com/o.file/Compact%20Node%20Type%20Definition.doc?get=c4a27b78b1e464a44f7f63e34aeb9f3c
i think that it would be interesting to have some code that
converts nodetype definitions to and from the compact notation.
[peeter, didn't you start to do something like that at one point?
did that already make it into some experimental contrib? ]
regards,
david
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: vetoing property change?
hi roland, simple answer: you can't. the observation is triggered asynchronously. synchronous, vetoable observation will be part of the discussion for jsr283. what is the need for this? for simple constaints, you can use the constraints in the property definition. regards, toby On 11/21/05, Roland Kofler [EMAIL PROTECTED] wrote: We tried to vetoing a propery change by throwing an exception in the callback. Doesn't work. how do you veto in Jackrabbit? thanks Roland -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: removing reference properties
can you provide a code example that lead to this exception? regards, toby On 11/19/05, Aleksandar Pecanov [EMAIL PROTECTED] wrote: I get a very nasty exception when saving reference properties. However, the node with the property containing the reference is saved correctly, but the refference is missing. Is this a known bug in jackrabbit, or is something else wrong? Here is the exception: Caused by: java.lang.NullPointerException at org.apache.jackrabbit.core.version.VersionManagerImpl.internalSetItemReferences(VersionManagerImpl.java:761) at org.apache.jackrabbit.core.version.VersionManagerImpl.setItemReferences(VersionManagerImpl.java:739) at org.apache.jackrabbit.core.version.VersionManagerImpl.setNodeReferences(VersionManagerImpl.java:718) at org.apache.jackrabbit.core.version.VersionItemStateProvider.setNodeReferences(VersionItemStateProvider.java:166) at org.apache.jackrabbit.core.state.SharedItemStateManager.store(SharedItemStateManager.java:554) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:344) at org.apache.jackrabbit.core.state.TransactionalItemStateManager.update(TransactionalItemStateManager.java:276) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:306) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:260) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1153) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:765) -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Removing a version
hi nicolas,
this is probably a bug in jackrabbit. thank you for reporting it. can
you please file a jira issue
(http://issues.apache.org/jira/browse/JCR) for this? thanks.
regards, toby
On 11/18/05, Nicolas Belisle [EMAIL PROTECTED] wrote:
Hi,
I'm trying to remove a version of a Node, but the
VersionHistory.removeVersion() method throws :
javax.jcr.ReferentialIntegrityException: Unable to remove version. At
least once referenced..
Secton 8.2.2.10 (Removal of Versions) of the specification indicates that
the version graph should be automatically repaired upon removal. Then,
VersionHistory.removeVersion() should take care of references. In fact, a
user cannot alter the references (jcr:predecessors and jcr:successors),
since they are protected properties.
Here's the example :
Node root1 = session.getRootNode() ;
Node test1 = root1.addNode(test) ;
test1.addMixin(mix:versionable);
test1.setProperty(test, 1);
session.save();
test1.checkin();
test1.checkout();
test1.setProperty(test, 2);
session.save();
test1.checkin();
test1.checkout();
test1.setProperty(test, 3);
session.save();
test1.checkin();
VersionHistory vh = test1.getVersionHistory();
for (VersionIterator vi = vh.getAllVersions(); vi.hasNext(); ) {
Version currenVersion = vi.nextVersion();
String versionName = currenVersion.getName();
if (!versionName.equals(jcr:rootVersion)) {
String propertyValue =
currenVersion.getNode(jcr:frozenNode).getProperty(test).getString();
System.out.println(Removing version : + versionName +
with value: + propertyValue);
vh.removeVersion(versionName);
}
}
Something I do wrong ?
Many thanks,
Nicolas
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: adding two time the same label for history...
imo, your code is behaving correclty. regards, toby On 11/14/05, Tomasz Dabrowski [EMAIL PROTECTED] wrote: yeah :-) but your adding the label to the same version? this one would throw an exception: node.getVersionHistory().addVersionLabel(1.0, foo, false); node.getVersionHistory().addVersionLabel(1.1, foo, false); as you can see I'm adding label to the current base version. this is from method body addLabel.. String versionName = node.getBaseVersion().getName(); node.getVersionHistory().addVersionLabel(versionName, label, false); these are steps to call this method (I don't modify node in time (don't increase current version), just follow bellow sequence) Node myRoot = session.getRootNode().getNode(myRoot); addLabel(myRoot, MY_LABEL); // this should throw exception addLabel(myRoot, MY_LABEL); -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: adding two time the same label for history...
can you provide your code example? On 11/9/05, Tomasz Dabrowski [EMAIL PROTECTED] wrote: In JSR-170 javadocs there is written for VersionHistory.addLabel(java.lang.String versionName, java.lang.String label, boolean moveLabel): VersionException - if an attempt is made to add an existing label to a version history and moveLabel is false or if the specifed version does not exist in this version history or if the specified version is the root version (jcr:rootVersion). I wrote simple prototype trying to add two time the same label for the same history. My moveLabel was set to FALSE so I should get exception VersionException. Unfortunately I didn't. Does anybody have similar problem? Thanks in advance, Tomek -- Tomasz Dabrowski email: [EMAIL PROTECTED] www: www.cognifide.com -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Observation manager
You want me to provide getObservationManager().addEventListener ? but with what arguments? are you sure you select the correct events to listen to if you want to listen to all events do: wsp.getObservationManager().addEventListener(listener, Event.NODE_ADDED | Event.NODE_REMOVED | Event.PROPERTY_ADDED | Event.PROPERTY_REMOVED, /, true, null, null, false); There is nothing to it. After that I use session.getWorkspace(),getObser...getEventListenerIterator, and it's empty. please note, that the event listener is bound to the session you retrieve the workspace from. once you close/logout the session, the listener is removed. regards, toby On 11/4/05, Aleksandar Pecanov [EMAIL PROTECTED] wrote: I have a little bit of problem. Maybe I'm misusing something. When adding an event listener to the observation manager, no exceptions are throwen, everything seems fine. But no events are delivered to the event listeners and when I get the event listener iterator from the manager, it's empty. Does observation work in jackrabbit? Thank you -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Observation manager
You want me to provide getObservationManager().addEventListener ? but with what arguments? are you sure you select the correct events to listen to if you want to listen to all events do: wsp.getObservationManager().addEventListener(listener, Event.NODE_ADDED | Event.NODE_REMOVED | Event.PROPERTY_ADDED | Event.PROPERTY_REMOVED, /, true, null, null, false); There is nothing to it. After that I use session.getWorkspace(),getObser...getEventListenerIterator, and it's empty. please note, that the event listener is bound to the session you retrieve the workspace from. once you close/logout the session, the listener is removed. Quote from JCR spec: Additionally, if noLocal is true, then events generated by the session through which the listener was registered are ignored. Otherwise, they are not ignored. It seems that if the last parameter is true, the session is ignored. Combined with the above statement, it means that no events will be sent, which does not make much sense, does it? The event listener is bound (or should be) to Workspace, according to spec. well it's a bit more complicated. the listener is bound to the workspace, but the workspace object is bound to the session that logged on that workspace. so, if you do a Repository.login(), a new Workspace and a new Session object is created. if you do a session.logout, both are discarded. and so are the eventlisteners. the 'noLocal' flag referrs to the session that registers the listener (via it's local workspace object). regards, toby ps: please reply to jackrabbit-dev@incubator.apache.org insted to me personally, so all list members can profit from this discussion. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Observation manager
can you provide your code example? On 11/4/05, Aleksandar Pecanov [EMAIL PROTECTED] wrote: I have a little bit of problem. Maybe I'm misusing something. When adding an event listener to the observation manager, no exceptions are throwen, everything seems fine. But no events are delivered to the event listeners and when I get the event listener iterator from the manager, it's empty. Does observation work in jackrabbit? Thank you -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Version node
1. Is it possible to add extra properties in a version node ? For example, when I check in a version, I want to specify extra properties like : user=myuser, comment=This new version blalbla ... no you can't. but the suggestion from miro is good 2. How the version number is managed ? Eg. can the developer decide to increment the major version number when the node is checkin ? ... no you can't. the version numbers are always incremented by .1, and a new .1 is created upon a branch. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Version node
Isn't this because of the underlying svn usage? no, we did not implement a svn-server into jackrabbit, yet :-) -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Node labeling
hi, Could you tell me if there is some way of labeling node version see VersionHistory.addVersionLabel(...) and version of its subterr at once? what is 'subterr' ? regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: shutting down repository obtained from jndi via spring
The addShutdownHook is still there, but also the static blocks meant for pre-loading the classes. On my machine working with the latest SVN trunk the .lock files are correctly deleted. hm, i have the latest svn trunk as well, and the lock file is not being removed. i don't see any static blocks in RepositoryImpl though. if it's just about the .lock file, http://issues.apache.org/jira/browse/JCR-233 suggests a solution with exclusive file locking. imo, this would be the best option (although some FS might not support filelocks. encoutered this on some linux NFS).
Re: Questestion regarding: ...... svn commit: r291132 - /incubator/jackrabbit/trunk/contrib/jcr-server/webdav/project.xml
angela is right. the webdav server should only depend on commons. the
commons jar is built (and installed) in the modules/commons
subproject.
On 9/23/05, Angela Schreiber [EMAIL PROTECTED] wrote:
hi jukka
are your sure, this is correct? i was forced to remove any
dependency to the jackrabbit-general part in the jcr-server...
and i'm not so happy, that you reintroduced it now.
didn't tobi create a commons-module that allow contributions
to retrieve the commons-jar only? i thought that was for
this exact purpose. i'm i misleaded?
thanks
angela
[EMAIL PROTECTED] wrote:
Author: jukka
Date: Fri Sep 23 07:49:30 2005
New Revision: 291132
URL: http://svn.apache.org/viewcvs?rev=291132view=rev
Log:
jcr-server/webdav: Switch dependencies back to non-splitted Jackrabbit.
Modified:
incubator/jackrabbit/trunk/contrib/jcr-server/webdav/project.xml
Modified: incubator/jackrabbit/trunk/contrib/jcr-server/webdav/project.xml
URL:
http://svn.apache.org/viewcvs/incubator/jackrabbit/trunk/contrib/jcr-server/webdav/project.xml?rev=291132r1=291131r2=291132view=diff
==
--- incubator/jackrabbit/trunk/contrib/jcr-server/webdav/project.xml
(original)
+++ incubator/jackrabbit/trunk/contrib/jcr-server/webdav/project.xml Fri
Sep 23 07:49:30 2005
@@ -31,12 +31,7 @@
dependencies
dependency
groupIdjackrabbit/groupId
-artifactIdjackrabbit-api/artifactId
-version${jackrabbit.build.version.jackrabbit}/version
-/dependency
-dependency
-groupIdjackrabbit/groupId
-artifactIdjackrabbit-commons/artifactId
+artifactIdjackrabbit/artifactId
version${jackrabbit.build.version.jackrabbit}/version
/dependency
dependency
--
toby
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
jackrabbit-commons.jar
hi, i added a 'modules/commons' directory with a simple project.xml that extends from the jackrabbit/project.xml. the jar:jar (jar:install) postGoal also builds (installs) the jar of the jackrabbit-commons. i found this the easiest way to generate the jar file, since one of the maven best practices is, that one project.xml should only generate one artifact. -- toby - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: custom AccessManager
I am writing my custom AccessManager and encountering some questions. In my design, permission policy statement is stored in properties of accessed node. I want to get them by ItemManager rather than by JSR-170 ...,It seems better. But I need to redesign ItemManager. Maybe need a new getItem() method without AccessManager check for avoid infinite loop of access check... Could any member redesign AMContext,ItemManager and SessionImpl for this reason? I thought this is useful for others. well, that would be too invasive. you need to find another mechanism to prevent infinite look, either work with java security (i.e. use AccessController.doPrivileged(PrivilegedAction)) or put the acm in the thread-local, or read the permissions of your nodes in a separately, using a system session. cheers, tobi -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: [VOTE] Revert the great split
it seems, that the majority wants to switch back to the old structure. before moving the files, i suggest to think about the repackaging as suggested by roy. commons will go to: org.apache.jackrabbit.util.* core will go to: org.apache.jackrabbit.jcr.* api would go to: org.apache.jackrabbit.* but is currently empty. i'm not happy with the api packaging, but i can't come up with a better solution. please note, that the refactoring will break all existing configurations, since the class names (eg of the persistence managers) are referenced in the xmls. maybe we could provide a backward compatibility mapping in the config reader which logs a deprecation warning. on the other hand, 1.0 is not released yet, and we should not respect backward compatibility too much. -- tobi On 9/8/05, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, As suggested by Tobias, I'd like to start a vote on whether to revert the great split proposed and implemented as issue JCR-157 (http://issues.apache.org/jira/browse/JCR-157). I'm ready to undo the restructuring, but I'd like a clear consensus before doing that. So please vote on whether we should revert the split. [ ] +1 Revert the JCR-157 changes [ ] 0 Happy with either project structure [ ] -1 Do not revert the JCR-157 changes The vote is open until the end of this week. I'll close the vote and take actions accordingly on Monday the 12th. BR, Jukka Zitting -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: [RESULT] [VOTE] Revert the great split
:-) oops, i think i wasn't clear enough. roy actually convinced me, that the current project structure only causes problems. so i change my vote to: '0'. cheers, tobi On 9/12/05, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, The vote result is mixed with one +1, two 0, and one -1 committer votes and three +1 non-committer votes. Committers: +1 Jukka Zitting 0 Stefan Guggisberg 0 Edgar Poce -1 Tobias Bocanegra Non-committers: +1 Manu [EMAIL PROTECTED] +1 Joseph Ottinger +1 Felix Meschberger The -1 vote is a veto and thus I will not make the proposed changes until more consensus is gained. I'll follow up on Tobias's repackaging proposal in hope of finding a compromise that everyone is happy with. BR, Jukka Zitting -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Rethinking the great split
Me too -- I've tried several times to recover a decent website build
from the split directories and I am ready to give up. Since nobody
else has built the site since the split was made, I think it is a
dead end that is hampering progress.
well, i still believe that the split is good, especially,
if we want to develop the jackrabbit api in future. could everything
be put into one sole codebase of course, but it will be more
difficult to find cyclic dependencies, etc. if the project grows bigger.
from my experience with larger, multi-module projects, it is
crucial to separate the build processes of the individual modules.
having a set of good maven goals solves a lot of the multiproject
problems. i must admit, that i did not invest a lot of time
adjusting the maven files, i though that there are other
developers with more maven experience than i have.
but if it is the common wish, i will adjust the files so that:
- a comprehensive site, including the 'modules', 'contribs' external
docs, etc is built.
- add a mechanism for handling the transitive dependencies
(imo, maven 2 is not ready, yet)
We seem to have no end of bad names. None of {api,commons,core}
are meaningful. api is just a placeholder for javax.jcr.
no. api will contain the jackrabbit API with methods that are
currently not available in jcr (nodetypes, QName, etc). and this
will be the base for the future jcr 2.0. it is a pity that few
efforts were made in creating such an api, since the split.
btw, i thought, org.apache.jackrabbit is a placeholder for javax.jcr :-)
commons should be o.a.j.util.
ok,
core should be o.a.j.jcr.
i disagree. o.a.j.core is totally ok.
I'd like to have some kind of grouping/distinction of things
like rmi and webdav that act as network client interfaces.
Would org.apache.jackrabbit.via.rmi be okay?
ok for me.
cheers, tobi
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: jcr-server clean broken
yes, i will. On 8/26/05, Brian Moseley [EMAIL PROTECTED] wrote: cleaning jcr-server is broken. running clean within one of the jcr-server subprojects invokes multiproject:clean, which doesn't actually do anything. i'm all for jcr-server being built with multiproject, but i don't know enough about multiproject to make sure it fully works. can somebody take a look at it? thanks! -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: jcr-server clean broken
now it should work again. cheers, tobi On 8/27/05, Tobias Bocanegra [EMAIL PROTECTED] wrote: yes, i will. On 8/26/05, Brian Moseley [EMAIL PROTECTED] wrote: cleaning jcr-server is broken. running clean within one of the jcr-server subprojects invokes multiproject:clean, which doesn't actually do anything. i'm all for jcr-server being built with multiproject, but i don't know enough about multiproject to make sure it fully works. can somebody take a look at it? thanks! -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com --- -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: ClassCastException when getting Repository from InitialContext (Sorry if this is a repost)
hi Digby, the problem is, that the classloader that creates the repository uses another jcr-1.0.jar than the classloader that looks up the repository. make sure that the jcr-1.0.jar is located in the $CATALINA_HOME/shared/lib. then all classloaders should use this one. cheers, tobi On 8/25/05, lists [EMAIL PROTECTED] wrote: Hi, Another query: I've set up Jackrabbit to run in Tomcat 5.5 and have set up the resource in server.xml and context.xml. All looks good. I can get the BindableRepository back from the context, but I can't cast it to a javax.jcr.Repository. The weird thing is, if I cast to an object, I can see that is is a BindableRepository, I can see that one of the interfaces it implements is Repository, i.e. InitialContext context = new InitialContext(); Context environment = (Context) context.lookup(java:comp/env); Object repository = (Object) environment.lookup(jcr/repository); out.println(repository.getClass().getGenericInterfaces()[0]); gives interface javax.jcr.Repository But out.println(repository instanceof javax.jcr.Repository); gives false And the cast causes a ClassCastException. Can anyone shed any light on this? Is it something to do with the BindableRepository having default access? Many thanks, Digby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: remote access with a client
this is probably due to a bug in jdk and spaces in the codebase. see: http://forum.java.sun.com/thread.jspa?threadID=282485messageID=1110739 workaround: set useCodebaseOnly system property System.setProperty(java.rmi.server.useCodebaseOnly, true); RemoteAdapterFactory factory = new ServerAdapterFactory(); RemoteRepository remote = factory.getRemoteRepository(repository); cheers, tobi On 8/23/05, Andries Demont [EMAIL PROTECTED] wrote: hi all I deployed the jack-rabbit server on the tomcat 5.5 server. The client i use looks like this: String name = //laptop-steven:2005/jackrabbit.repository; ClientRepositoryFactory crf = new ClientRepositoryFactory(); Repository repository = crf.getRepository(name); RemoteAdapterFactory factory = new ServerAdapterFactory(); RemoteRepository remote = factory.getRemoteRepository(repository); Naming.bind(name, remote);// Make the RMI binding using java.rmi.Naming RemoteSession session = remote.login(new SimpleCredentials (userid, .toCharArray()), null); I tried a lot of urls, but none of them worked. I'm still a beginner in distibuted software, so I think this isn't a difficult problem. Can anybody help me? This is the stacktrace of the code above: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.net.MalformedURLException: no protocol: Software at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at java.rmi.Naming.lookup(Unknown Source) at org.apache.jackrabbit.rmi.client.ClientRepositoryFactory.getRepository (ClientRepositoryFactory.java:99) at Remote_Test.main(Remote_Test.java:36) caused by: java.net.MalformedURLException: no protocol: Software at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at java.net.URL.init(Unknown Source) at sun.rmi.server.LoaderHandler.pathToURLs(Unknown Source) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader.loadClass(Unknown Source) at sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source) at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) at java.io.ObjectInputStream.readClassDesc(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: Rethinking the great split
hi jukka,
* Managing the current Jackrabbit build environment is relatively hard
even with the multiproject plugin being used.
* There is no longer a single Jackrabbit jar with an associated set of
dependencies, leading to more complex documentation and deployment issues.
* There is no obvious way to avoid navigational issues across the
component sites generated by the current multiproject setup.
* The unit test, checkstyle, and other reports are split over the
component projects
* The component structure points the way towards an even more fragmented
project structure with separate component projects for example for
individual persistence managers (see the recent build problems thread)
i totally agree, that multiproject support is not solved very
sophisticated in maven (at least in 1.0, i don't know about 2.0). for
our own product, we use maven, but only to manage the build process.
none of mavens site generation, unittest, etc. are used. we get the
best overview of our modules / (sub)projects using eclipse or idea.
Even though I greatly appreciate the benefits of the restructuring
(especially the commons library that I'm already using in a few other
projects) I've come to feel that the problems outweight the benefits.
So, I'd like to propose to partially undo the changes related to
JCR-157. Instead of the full api, commons, and core subprojects, I'd
propose using package naming and design conventions to manage these
components. We could have o.a.j.{api,commons,core} packages within a
top-level ./src/main/java source directory. Additional component
packages (like o.a.j.rmi) could be used if major contrib projects were
to be fully integrated with Jackrabbit. The design constraints (like no
Jackrabbit dependencies in commons) could be enforced either manually or
with some custom Checkstyle checks. The separate api and commons jar
files could still be generated by a Maven postGoal rule. This change
would solve above problems while still providing at least some of the
original benefits.
well, i can't see another nice way of doing this. so maybe a common
source directory would be the easiest solution. however, we should
also check the new features of maven 2.0 in respect of multiproject
capabilities:
http://maven.apache.org/maven2/about.html#features
[...]
- Superior dependency management including automatic updating, dependency
closures (also known as transitive dependencies)
- Able to easily work with multiple projects at a time
[...]
i will give it a try and see if maven 2.0 would offer the needs we are
looking for.
cheers, tobi
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: Rethinking the great split
hi,
i´m curently on vacation and have limited internet access, so lets
dicuss this issue next week.
cheers, tobi
On 7/27/05, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
After a few weeks of working with the post JCR-157 Jackrabbit structure,
I've started thinking about partially reverting the restructuring. The
main reasons for this are:
* Managing the current Jackrabbit build environment is relatively hard
even with the multiproject plugin being used.
* There is no longer a single Jackrabbit jar with an associated set of
dependencies, leading to more complex documentation and deployment issues.
* There is no obvious way to avoid navigational issues across the
component sites generated by the current multiproject setup.
* The unit test, checkstyle, and other reports are split over the
component projects
* The component structure points the way towards an even more fragmented
project structure with separate component projects for example for
individual persistence managers (see the recent build problems thread)
Even though I greatly appreciate the benefits of the restructuring
(especially the commons library that I'm already using in a few other
projects) I've come to feel that the problems outweight the benefits.
So, I'd like to propose to partially undo the changes related to
JCR-157. Instead of the full api, commons, and core subprojects, I'd
propose using package naming and design conventions to manage these
components. We could have o.a.j.{api,commons,core} packages within a
top-level ./src/main/java source directory. Additional component
packages (like o.a.j.rmi) could be used if major contrib projects were
to be fully integrated with Jackrabbit. The design constraints (like no
Jackrabbit dependencies in commons) could be enforced either manually or
with some custom Checkstyle checks. The separate api and commons jar
files could still be generated by a Maven postGoal rule. This change
would solve above problems while still providing at least some of the
original benefits.
Comments?
BR,
Jukka Zitting
--
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---
Re: jcr-server webapp PROPFIND/PROPPATCH support
hi rob, the default configuration of the import/export catalogs are in a manner, that provide a more or less 'normal' fileserver. MKCOL creates folders, PUT creates files. it is completely up to you to alter the command chains for your purpose. cheers, tobi On 7/20/05, Rob Owen [EMAIL PROTECTED] wrote: To make the WebDAV view (/repository or SimpleWebdavServlet) in the jcr-server webapp more general, it seems that PROPFIND should return all (or at least all user-defined) properties found on the node. At the moment it only returns pseudo-properties (essential WebDAV properties) that are created from node metadata. If there are user defined properties on these nodes then they should be returned in a PROPFIND request. I'm not sure how these would be identified, but might be something like any properties not defined in some namespaces (eg. nt, jcr, rep). At the moment, these properties will not exist as they cannot be set on the nodetypes created using this servlet (see below). In order to support PROPPATCH, DAVResourceImpl was modified, but discovered it creates nt:folder nodes for WebDAV collections and nt:file nodes for WebDAV non-collection resources. These nodetypes do not allow additional properties to be set and so this in itself prevents PROPPATCH from working. Would the recommended route be to change the nodetypes created (eg. to nt:unstructured or something else) in order to be able to set arbitrary properties on the JCR nodes and thereby provide the ability to fully support WebDAV's PROPPATCH? Full support for PROPFIND/PROPPATCH is required for some existing WebDAV applications to use jackrabbit as the content repository. Any suggestions on the best route would be much appreciated. Thanks, Rob. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
