Re: SPI: usage of java.util.Properties in interfaces
I think both approaches have their disadvantages. Using a map requires casting to Strings (we currently have to stick with 1.4, I think) and Properties class exposes methods like store and load which are useless (or even dangerous). I propose we change the RepositoryService interface and use the two descriptor methods defined in javax.jcr.Repository: getDescriptorKeys() and getDescriptor(). The implementation then can use whatever collection it prefers. regards marcel Julian Reschke wrote: Angela Schreiber schrieb: ja... we discussed that before. the reason is, that repository descriptors are defined to be key-value String pairs and we wanted to make that clear. Well, I really think that's a bad idea. Please reconsider it (keep in mind that JDK 1.5 will provide typing anyway...). The current design makes it really hard to re-use an existing instance (what if somebody writes to it?) Best regards, Julian
[jira] Commented: (JCR-604) After saving over Webdav the jcr:encoding property is deleted
[ http://issues.apache.org/jira/browse/JCR-604?page=comments#action_12445103 ] angela commented on JCR-604: tja... i guess that resetting the properties upon a PUT that replaces an existing resource is not according to the RFC. so maybe we should look at this. (still its just an assuption, that it was a PUT and not MOVE of a tmp-file). did you set the original encoding manually or was this value retrieved from a contenttype header? what happened to the jcr:mimeType property? i'm not against closing this issue, but i'm curious... and i'd like to understand, whether the behaviour you describe is caused by an misbehaviour of the server. the 'UTF-8' is for sure not correct, but this is a different discussion. regards angela > After saving over Webdav the jcr:encoding property is deleted > - > > Key: JCR-604 > URL: http://issues.apache.org/jira/browse/JCR-604 > Project: Jackrabbit > Issue Type: Bug > Components: webdav >Affects Versions: 1.1 >Reporter: Claus Köll > Assigned To: angela > > If i add a word file to the repository the property jcr:encoding is under the > jcr:content > with a value like UTF-8, > i modify the word file over webdav then the property is deleted. -- 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-604) After saving over Webdav the jcr:encoding property is deleted
[ http://issues.apache.org/jira/browse/JCR-604?page=comments#action_12445106 ] Claus Köll commented on JCR-604: hi angela. i dont know wich mehtod is called if you open the file directly with ms-word and perform a save. if the bahaviour is not ok according to the specification we should leave the issue open until you clarify it i set the original encoding property manually. the value utf-8 is only set from a test method because i didnt check wheter the property is null on reading the node again. the other properties will be not changed. claus > After saving over Webdav the jcr:encoding property is deleted > - > > Key: JCR-604 > URL: http://issues.apache.org/jira/browse/JCR-604 > Project: Jackrabbit > Issue Type: Bug > Components: webdav >Affects Versions: 1.1 >Reporter: Claus Köll > Assigned To: angela > > If i add a word file to the repository the property jcr:encoding is under the > jcr:content > with a value like UTF-8, > i modify the word file over webdav then the property is deleted. -- 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: SPI: usage of java.util.Properties in interfaces
Marcel Reutegger schrieb: I think both approaches have their disadvantages. Using a map requires casting to Strings (we currently have to stick with 1.4, I think) and Properties class exposes methods like store and load which are useless (or even dangerous). Well, SPI already uses generic Collections in one other place, so I really don't buy that one :-) Speaking of which, is there a particular reason why QNodeTypeDefinition.getDependencies returns a Collection, not a Set? I propose we change the RepositoryService interface and use the two descriptor methods defined in javax.jcr.Repository: getDescriptorKeys() and getDescriptor(). The implementation then can use whatever collection it prefers. That would work for me for this case. Best regards, Julian
Re: FW: failed to read custom node type definitions stored in custom_nodetypes.xml
well, weird. can you file a jira issue? regards, toby On 10/27/06, Magnus Grimsell <[EMAIL PROTECTED]> wrote: I'm not sure if this belongs in the dev list but since I didn't get any response on the user list I try here. Please tell me if I'm breaking any mailing list policies. /Magnus > -Original Message- > From: Magnus Grimsell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 25, 2006 3:56 PM > To: users@jackrabbit.apache.org > Subject: failed to read custom node type definitions stored in > custom_nodetypes.xml > > > I execute the following code on an empty repository first > time the server is started: > > JackrabbitNodeTypeManager manager = > > (JackrabbitNodeTypeManager)session.getWorkspace().getNodeTypeM > anager(); > InputStream nodeTypes = > this.getClass().getClassLoader().getResourceAsStream(res); > manager.registerNodeTypes(nodeTypes, > JackrabbitNodeTypeManager.TEXT_X_JCR_CND); > session.save(); > > This seems to work as the tests passes. However when > restarting the server I get the following error: > > Error creating a Connection Factory from class > 'org.apache.jackrabbit.jca.JCAManagedConnectionFactory'. > Reason: javax.resource.ResourceException: Failed to create > session: internal error: failed to read custom node type > definitions stored in custom_nodetypes.xml: > > custom_nodetypes.xml exists but is empty. I use jackrabbit JCA. > > Do I get this error because the repository isn't shut down > correctly? Should I do repository.shutdown() or should that > be handled by the connector? > > Thanks, > Magnus Grimsell > -- -< [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: SPI: usage of java.util.Properties in interfaces
Hi, On 10/27/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote: I propose we change the RepositoryService interface and use the two descriptor methods defined in javax.jcr.Repository: getDescriptorKeys() and getDescriptor(). The implementation then can use whatever collection it prefers. How about remote clients that would prefer to get all the descriptors in one call? BR, Jukka Zitting
Re: SPI: usage of java.util.Properties in interfaces
Jukka Zitting schrieb: Hi, On 10/27/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote: I propose we change the RepositoryService interface and use the two descriptor methods defined in javax.jcr.Repository: getDescriptorKeys() and getDescriptor(). The implementation then can use whatever collection it prefers. How about remote clients that would prefer to get all the descriptors in one call? Good point. Please just make it a Map. Best regards, Julian
Re: SPI: usage of java.util.Properties in interfaces
Julian Reschke wrote: Marcel Reutegger schrieb: I think both approaches have their disadvantages. Using a map requires casting to Strings (we currently have to stick with 1.4, I think) and Properties class exposes methods like store and load which are useless (or even dangerous). Well, SPI already uses generic Collections in one other place, so I really don't buy that one :-) we tried to avoid casting where it was possible with reasonable effort. e.g. introducing a separate interface for a type safe QName collection seems overkill. Speaking of which, is there a particular reason why QNodeTypeDefinition.getDependencies returns a Collection, not a Set? because we didn't see a need for a Set. a collection is IMO sufficient. what is the benefit of a Set over a Collection for a client? regards marcel
Re: SPI: usage of java.util.Properties in interfaces
The most logical difference would be that a Set tells you that the elements stored in it will be unique while a Collection might permit you to introduce duplicates. -Tako On 10/27/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote: Julian Reschke wrote: > Marcel Reutegger schrieb: >> I think both approaches have their disadvantages. Using a map requires >> casting to Strings (we currently have to stick with 1.4, I think) and >> Properties class exposes methods like store and load which are useless >> (or even dangerous). > > Well, SPI already uses generic Collections in one other place, so I > really don't buy that one :-) we tried to avoid casting where it was possible with reasonable effort. e.g. introducing a separate interface for a type safe QName collection seems overkill. > Speaking of which, is there a particular reason why > QNodeTypeDefinition.getDependencies returns a Collection, not a Set? because we didn't see a need for a Set. a collection is IMO sufficient. what is the benefit of a Set over a Collection for a client? regards marcel
Re: SPI: usage of java.util.Properties in interfaces
Marcel Reutegger schrieb: Julian Reschke wrote: Marcel Reutegger schrieb: I think both approaches have their disadvantages. Using a map requires casting to Strings (we currently have to stick with 1.4, I think) and Properties class exposes methods like store and load which are useless (or even dangerous). Well, SPI already uses generic Collections in one other place, so I really don't buy that one :-) we tried to avoid casting where it was possible with reasonable effort. e.g. introducing a separate interface for a type safe QName collection seems overkill. Agreed. Speaking of which, is there a particular reason why QNodeTypeDefinition.getDependencies returns a Collection, not a Set? because we didn't see a need for a Set. a collection is IMO sufficient. what is the benefit of a Set over a Collection for a client? The client can rely on not having duplicates in it, or alternatively, the producer doesn't need to take care not to produce them... Best regards, Julian
[jira] Commented: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12445194 ] Stefan Guggisberg commented on JCR-535: --- > About this issue, can I assume there are no concurrent operations? no. why would you assume that? > > I am deleting all subnodes under root except jcr:system. The issue I see is a > session creating some nodes while I delete them all. I think this could > happen and this should be taken care of. > > Are my assumptions correct? for the former: yes for the latter: no importXML has different sematics than a 'restore' operation. for an import you don't need exclusive access. > > If yes, how could I manage to handle this issue? > > Ignore root node when importing through sysView > --- > > Key: JCR-535 > URL: http://issues.apache.org/jira/browse/JCR-535 > Project: Jackrabbit > Issue Type: Improvement > Components: core >Reporter: Nicolas Toper >Priority: Minor > Attachments: patch-1-Ignore-root-node.txt, > patch-WorkspaceImporter-231006-2.txt, patch-WorkspaceImporter-231006.txt, > patch-WorkspaceImporterTest-231006.txt > > > When importing through a sysView, we should ignore the root node. It is in > the sysView to provide a root XML node, but the importer is going to attach > it to the repository"s root node... Which would create another root node and > often raise exception. This is a know issue > I needed this behavior to change for the backup tool, since I use the > sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I > should update too the SessionImporter so we have a consistant behavior. What > do you think? -- 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-332) Upgrade to Maven 2
[ http://issues.apache.org/jira/browse/JCR-332?page=comments#action_12445204 ] Miro Walker commented on JCR-332: - Has anyone had a chance to try this patch yet? There's a recent comment on JCR-352 suggesting that the work to migrate is ongoing, but I wonder what is left to do? > Upgrade to Maven 2 > -- > > Key: JCR-332 > URL: http://issues.apache.org/jira/browse/JCR-332 > Project: Jackrabbit > Issue Type: New Feature > Components: maven >Affects Versions: 0.9, 1.0, 1.0.1, 1.1 >Reporter: fabrizio giustina > Assigned To: Jukka Zitting > Attachments: jackrabbit-core_single-line-description_pom.xml.patch, > jackrabbit-jcr-rmi_scm.patch, > jackrabbit-jcr-rmi_single-line-description-and-rmic_pom.xml.patch, > jcr-rmi-pom.xml, maven2-test.patch, pom.xml, pom.xml, pom.xml.patch > > > If you are interested in migrating to maven2 (or adding optional maven 2 > build scripts) this is a full maven 2 pom.xml for the main jackrabbit jar. > All the xpath/javacc stuff, previously done in maven.xml, was pretty painfull > to reproduce in maven2... the attached pom exactly reproduces the m1 build by > using the maven2 javacc plugin + a couple of antrun executions. > Test configuration is not yet complete, I think it will be a lot better to > reproduce the previous behaviour (init tests run first) without any > customization (maybe using a single junit test suite with setUp tasks). Also > custom packaging goals added to maven.xml (that can be esily done in m2 by > using the assembly plugin) are not yet reproduced too. > If there is interest, I can also provide poms for the contribution projects > (that will be easy, the only complex pom is the main one). -- 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: SPI: usage of java.util.Properties in interfaces
Jukka Zitting wrote: How about remote clients that would prefer to get all the descriptors in one call? hmm... good point. even though caching the descriptors would be trivial. I've just changed the relevant methods to use a Map instead of the Properties class. regards marcel
Re: SPI: usage of java.util.Properties in interfaces
Julian Reschke wrote: Marcel Reutegger schrieb: because we didn't see a need for a Set. a collection is IMO sufficient. what is the benefit of a Set over a Collection for a client? The client can rely on not having duplicates in it, The client can rely on it anyway because the documentation says so. e.g. even a Set would allow a null value in general but getDependencies() will never return a collection with a null value. IMO the binding contract is the documentation, specifically when dealing with collection classes that are very general. Using a Set would make sense when passing in a collection of objects and the callee doesn't want to accept duplicates. > or alternatively, > the producer doesn't need to take care not to produce them... Using a Collection gives the producer the freedom to choose which implementation he wants to use. if there are just a couple of element an ArrayList is less expensive than a HashSet. regards marcel
[jira] Created: (JCR-608) NullPointerException in indexer when creating versionable node on virgin repository
NullPointerException in indexer when creating versionable node on virgin repository --- Key: JCR-608 URL: http://issues.apache.org/jira/browse/JCR-608 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.1 Reporter: Magnus Grimsell Priority: Minor When creating a versionable node on a virgin repository NodeIndexer throws a NullPointerException. After a restart everything works fine. SEVERE: Synchronous EventConsumer threw exception. java.lang.NullPointerException at org.apache.jackrabbit.core.query.lucene.NodeIndexer.createDoc(NodeIndexer.java:141) at org.apache.jackrabbit.core.query.lucene.NodeIndexer.createDocument(NodeIndexer.java:115) at org.apache.jackrabbit.core.query.lucene.SearchIndex.createDocument(SearchIndex.java:459) at org.apache.jackrabbit.core.query.lucene.SearchIndex$2.next(SearchIndex.java:302) at org.apache.jackrabbit.core.query.lucene.MultiIndex.update(MultiIndex.java:322) at org.apache.jackrabbit.core.query.lucene.SearchIndex.updateNodes(SearchIndex.java:290) at org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:471) at org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:231) at org.apache.jackrabbit.core.observation.ObservationDispatcher.dispatchEvents(ObservationDispatcher.java:201) at org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:430) at org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatch(DelegatingObservationDispatcher.java:123) at org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatchEvents(DelegatingObservationDispatcher.java:99) at org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:430) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:657) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:747) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:325) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:301) at org.apache.jackrabbit.core.version.AbstractVersionManager.createVersionHistory(AbstractVersionManager.java:254) at org.apache.jackrabbit.core.version.VersionManagerImpl$1.run(VersionManagerImpl.java:207) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:579) at org.apache.jackrabbit.core.version.VersionManagerImpl.createVersionHistory(VersionManagerImpl.java:204) at org.apache.jackrabbit.core.version.XAVersionManager.createVersionHistory(XAVersionManager.java:147) at org.apache.jackrabbit.core.ItemImpl.initVersionHistories(ItemImpl.java:771) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1181) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:817) -- 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] Updated: (JCR-608) NullPointerException in indexer when creating versionable node on virgin repository
[ http://issues.apache.org/jira/browse/JCR-608?page=all ] Magnus Grimsell updated JCR-608: Attachment: JackRabbitTest.java Test case to reproduce the bug > NullPointerException in indexer when creating versionable node on virgin > repository > --- > > Key: JCR-608 > URL: http://issues.apache.org/jira/browse/JCR-608 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Magnus Grimsell >Priority: Minor > Attachments: JackRabbitTest.java > > > When creating a versionable node on a virgin repository NodeIndexer throws a > NullPointerException. > After a restart everything works fine. > SEVERE: Synchronous EventConsumer threw exception. > java.lang.NullPointerException > at > org.apache.jackrabbit.core.query.lucene.NodeIndexer.createDoc(NodeIndexer.java:141) > at > org.apache.jackrabbit.core.query.lucene.NodeIndexer.createDocument(NodeIndexer.java:115) > at > org.apache.jackrabbit.core.query.lucene.SearchIndex.createDocument(SearchIndex.java:459) > at > org.apache.jackrabbit.core.query.lucene.SearchIndex$2.next(SearchIndex.java:302) > at > org.apache.jackrabbit.core.query.lucene.MultiIndex.update(MultiIndex.java:322) > at > org.apache.jackrabbit.core.query.lucene.SearchIndex.updateNodes(SearchIndex.java:290) > at > org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:471) > at > org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:231) > at > org.apache.jackrabbit.core.observation.ObservationDispatcher.dispatchEvents(ObservationDispatcher.java:201) > at > org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:430) > at > org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatch(DelegatingObservationDispatcher.java:123) > at > org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatchEvents(DelegatingObservationDispatcher.java:99) > at > org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:430) > at > org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:657) > at > org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:747) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:325) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:301) > at > org.apache.jackrabbit.core.version.AbstractVersionManager.createVersionHistory(AbstractVersionManager.java:254) > at > org.apache.jackrabbit.core.version.VersionManagerImpl$1.run(VersionManagerImpl.java:207) > at > org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:579) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.createVersionHistory(VersionManagerImpl.java:204) > at > org.apache.jackrabbit.core.version.XAVersionManager.createVersionHistory(XAVersionManager.java:147) > at > org.apache.jackrabbit.core.ItemImpl.initVersionHistories(ItemImpl.java:771) > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1181) > at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:817) -- 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-609) Empty custom_nodetypes.xml after restart
Empty custom_nodetypes.xml after restart Key: JCR-609 URL: http://issues.apache.org/jira/browse/JCR-609 Project: Jackrabbit Issue Type: Bug Components: jca Affects Versions: 1.1 Environment: oc4j 10.1.3 Reporter: Magnus Grimsell I run jackrabbit jca on oc4j 10.1.3. First time the server is started I execute the following code on the empty repository : JackrabbitNodeTypeManager manager = (JackrabbitNodeTypeManager)session.getWorkspace().getNodeTypeManager(); InputStream nodeTypes = this.getClass().getClassLoader().getResourceAsStream(res); manager.registerNodeTypes(nodeTypes, JackrabbitNodeTypeManager.TEXT_X_JCR_CND); session.save(); This works fine. I can create nodes of custom type. However when restarting the server I get the following error: Error creating a Connection Factory from class 'org.apache.jackrabbit.jca.JCAManagedConnectionFactory'. Reason: javax.resource.ResourceException: Failed to create session: internal error: failed to read custom node type definitions stored in custom_nodetypes.xml: custom_nodetypes.xml exists but is empty. -- 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: Solaris zone for Jackrabbit
Hi, Cool. This is a great idea. For the nightlies (and tests) I suggest you setup an automatic build tools such as Continuum. Regards Felix On 10/26/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: Hi, I'm planning to request a Solaris zone [1] for the Jackrabbit project. The main uses of the zone would be: * Building nightly Jackrabbit development snapshots * Running nightly unit and integration tests * Generating and hosting various Maven reports I volunteer to be the root user, and any Jackrabbit committer can have an account on the zone. If or when we get the zone, I plan to setup a Subversion folder at .../asf/jackrabbit/zone for maintaining any scripts and configuration files related to the above tasks. Comments and ideas are welcome. I'll proceed to request the zone in a few days. [1] http://www.apache.org/dev/solaris-zones.html BR, Jukka Zitting
