Re: [VOTE] Release jackrabbit-classloader 1.4.1
Felix Meschberger wrote: > Please vote on releasing these packages as jackrabbit-classloader 1.4.1. > The vote is on for the next 72 hours and passes if a majority of at > least three +1 votes are cast. The votes from Jackrabbit PMC members are > binding. > [X] +1 Release the packages as jackrabbit-classloader 1.4.1 checked signatures, checksums, build, notice and license files. regards marcel
Re: [VOTE] Release jackrabbit-classloader 1.4.1
Hi, On Tue, Sep 23, 2008 at 8:47 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > a20e9ade53c608ce27bc215aa15366c5 jackrabbit-classloader-1.4.1-src.jar +1 Release the packages as jackrabbit-classloader 1.4.1 BR, Jukka Zitting
Re: [VOTE] Release jackrabbit-classloader 1.4.1
+1 Release the packages as jackrabbit-classloader 1.4.1 regards, toby On 9/23/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > I have posted a candidate for the jackrabbit-classloader 1.4.1 release at > > http://people.apache.org/~fmeschbe/jackrabbit-classloader-1.4.1/ > > See the included RELEASE-NOTES.txt file (also included at the end of > this message) for details on release contents and latest changes. The > release candidate is a jar archive of the sources in > http://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-classloader-1.4.1. > The MD5 checksum of the release package is: > > a20e9ade53c608ce27bc215aa15366c5 jackrabbit-classloader-1.4.1-src.jar > > Please vote on releasing these packages as jackrabbit-classloader 1.4.1. > The vote is on for the next 72 hours and passes if a majority of at > least three +1 votes are cast. The votes from Jackrabbit PMC members are > binding. > > [ ] +1 Release the packages as jackrabbit-classloader 1.4.1 > [ ] -1 Do not release the packages because... > > As before, I have also included a pre-compiled binary and a staged > Maven repository produced from the packaged source. If this vote > passes, I will make these artifacts available to users along with the > official source release. > > PS. See http://www.nabble.com/Release-auditing-guidelines-p8481069.html > for release auditing guidelines Jukka wrote last year. > > Regards > Felix > > > > Release Notes -- Apache Jackrabbit Repository Classloader -- Version 1.4.1 > > Introduction > > > This is the 1.4.1 patch release of the jackrabbit-classloader component of > Apache Jackrabbit, a fully conforming implementation of the Content > Repository for Java Technology API (JCR). > > This release contains fixes to a number of issues. See below for the full > list of changes in this release. > > See the Apache Jackrabbit website at http://jackrabbit.apache.org/ for > more information. > > Release Contents > > > Unlike previous Jackrabbit releases that contained a full set of components, > this patch release only contains the jackrabbit-classloader component. The > component is distributed both as a source archive and a pre-compiled binary. > > * Source archive (jackrabbit-classloader-1.4.1-src.jar) > > The source archive contains the full source code of this release > in a "jackrabbit-classloader-1.4.1" directory. Use the following > commands (or the equivalent in your environment) to build the > component with Maven 2 and Java 1.4 or higher: > > $ jar xf jackrabbit-classloader-1.4.1-src.jar > $ cd jackrabbit-classloader-1.4.1 > $ mvn install > > * Pre-compiled binary (jackrabbit-classloader-1.4.1.jar) > > Jackrabbit Repositorly Classloader Library of the Apache Jackrabbit > content repository implementation. > > See the included README.txt file for more information. > > Each release file is accompanied by SHA1 and MD5 checksums and a PGP > signature. The public key used for the signatures can be found > in the KEYS file. > > Changes in this release > --- > > All the changes in this release are listed below. The issue identifier and > title is listed for each change and known issue. You can look up individual > issues for more details in the Jackrabbit issue tracker at > http://issues.apache.org/jira/browse/JCR > > Bug: > [JCR-1749] JCRUrlConnection relies on nt:file/nt:resource >
[jira] Commented: (JCR-1104) JSR 283 support
[ https://issues.apache.org/jira/browse/JCR-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633672#action_12633672 ] Julian Reschke commented on JCR-1104: - added o.a.j.api.jsr283.Node (containing shareable node functionality) with revision 698122. > JSR 283 support > --- > > Key: JCR-1104 > URL: https://issues.apache.org/jira/browse/JCR-1104 > Project: Jackrabbit > Issue Type: New Feature > Components: JCR 2.0 >Reporter: Stefan Guggisberg >Priority: Minor > Attachments: sharednodesapi.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1755) ClassCastException when registering custom node by XML file
ClassCastException when registering custom node by XML file
---
Key: JCR-1755
URL: https://issues.apache.org/jira/browse/JCR-1755
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
Ubuntu 8.10, MySql 5
Repository is deployed as a shared J2EE resource (JNDI).
Reporter: Jakub Wozniakowski
Priority: Critical
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
{code:title=JcrCustomNodeRegister.java|borderStyle=solid}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{code}
we receive such surprise:
{code:title=stack}
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
{code}
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> {code:title=JcrCustomNodeRegister.java|borderStyle=solid}
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> {code}
> we receive such surprise:
> {code:title=stack}
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> {code}
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
{code:java}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{code}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
{code:title=JcrCustomNodeRegister.java|borderStyle=solid}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{code}
we receive such surprise:
{code:title=stack}
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
{code}
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> {code:java}
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> {code}
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
{code}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{code}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
{code:java}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{code}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> {code}
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> {code}
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
{quote}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{quote}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
{code}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{code}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> {quote}
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> {quote}
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
{quote}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{quote}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
{{code}}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{{code}}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> {{code}}
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> {{code}}
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
{{
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
}}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
>
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
>
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Wozniakowski updated JCR-1755:
Description:
When trying to register node type from XML file using following code:
{{
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
}}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
was:
When trying to register node type from XML file using following code:
{{code}}
JackrabbitNodeTypeManager nodeTypeManager =
(JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
for(Resource resource : nodeDefinitions){
System.out.println("** registering node:"+resource);
nodeTypeManager.registerNodeTypes(resource.getInputStream(),
JackrabbitNodeTypeManager.TEXT_XML);
}
{{code}}
we receive such surprise:
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at
org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
at
org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
at
org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
at
pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
at
pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
...
Registering nodes by .cnd files works fine.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> {{
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> }}
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633688#action_12633688
]
Alexander Klimetschek commented on JCR-1755:
Looks like the classical "container or JVM provides different XML
implementation (Xerces version)" than expected, ie. from what is provided in
Jackrabbit's lib.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hudson build became unstable: Jackrabbit-o cm » Jackrabbit Object Content Mapping #134
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-ocm/org.apache.jackrabbit$jackrabbit-ocm/134/changes
[jira] Commented: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633694#action_12633694
]
Jakub Wozniakowski commented on JCR-1755:
-
Using Sun Java 1.5.0.15
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633691#action_12633691
]
Alexander Klimetschek commented on JCR-1755:
Oh, and Jackrabbit uses/requires xerces version 2.8.1
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633702#action_12633702
]
Jukka Zitting commented on JCR-1755:
Doesn't look like a XML library version issue to me. The failing code in
DOMWalker expects the parent of the currently processed XML node to be an
element, but in your case it looks like it's the top-level XML document.
We probably in any case need to fix that in DOMWalker, but I believe you can
work around this issue by modifying your node type definition files. If my
guess is right, your XML file looks like this:
...
Try wrapping the content in a element, like this:
...
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633719#action_12633719
]
Jakub Wozniakowski commented on JCR-1755:
-
Confirmed.
Surrounding node definitions by is successfull
workaround.
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Priority: Critical
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hudson build is back to stable: Jackrabbit- ocm » Jackrabbit Object Content Mapping #135
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-ocm/org.apache.jackrabbit$jackrabbit-ocm/135/changes
[jira] Updated: (JCR-1678) NullPointerException in constructor of JcrDavException
[ https://issues.apache.org/jira/browse/JCR-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1678: Component/s: (was: jackrabbit-webdav) jackrabbit-jcr-server wrong component -> adjust > NullPointerException in constructor of JcrDavException > -- > > Key: JCR-1678 > URL: https://issues.apache.org/jira/browse/JCR-1678 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-jcr-server >Affects Versions: 1.4 >Reporter: Thomas Weber >Assignee: angela > Fix For: 1.5 > > Attachments: patch > > > within DavSessionProviderImpl.attachSession() a > org.apache.jackrabbit.rmi.client.RemoteRepositoryException is thrown, catched > as RepositoryException and passed into the > ctor of JcrDavException > the lookup for the class in the static HashMap codeMap for the class fails > and a NPE is thrown > suggested fix: > The static lookup by the javax.jcr.*Exception classed must be fixed to > include derived exception classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1607) Add a NamespaceHelper in jcr-commons
[ https://issues.apache.org/jira/browse/JCR-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1607: Component/s: jackrabbit-jcr-server add missing component > Add a NamespaceHelper in jcr-commons > > > Key: JCR-1607 > URL: https://issues.apache.org/jira/browse/JCR-1607 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core, jackrabbit-jcr-commons, > jackrabbit-jcr-server, namespace >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > > We have a number of code snippets in jackrabbit-core and many JCR clients > that do something like the following: > * get the prefix/URI for a given namespace URI/prefix without throwing an > exception if the namespace is not found (return null instead) > * get a Map containing all current namespace prefix->URI mappings > * get the prefixed name for a given URI + local name pair in a given session > (without a dependency to the SPI) > * safely register a given namespace (don't throw if the namespace is already > registered, automatically select an unused prefix if needed, etc.) > I'd like to introduce a NamespaceHelper class in jcr-commons to cover such > common code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1756) Include OCM in the main Jackrabbit build when using Java 5
Include OCM in the main Jackrabbit build when using Java 5 -- Key: JCR-1756 URL: https://issues.apache.org/jira/browse/JCR-1756 Project: Jackrabbit Issue Type: Improvement Components: maven Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 1.5 Currently the OCM component are separate from the rest of Jackrabbit build due to the fact that they need Java 5 to compile. I'd like to add a java5 profile to the main Jackrabbit build that contains the OCM components and is automatically activated when building with Java 5 or higher. This would simplify build instructions and allow us to remove the extra Jackrabbit-ocm Hudson build that we currently use to build the OCM component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1756) Include OCM in the main Jackrabbit build when using Java 5
[ https://issues.apache.org/jira/browse/JCR-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1756: --- Attachment: JCR-1756.patch Proposed patch. > Include OCM in the main Jackrabbit build when using Java 5 > -- > > Key: JCR-1756 > URL: https://issues.apache.org/jira/browse/JCR-1756 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1756.patch > > > Currently the OCM component are separate from the rest of Jackrabbit build > due to the fact that they need Java 5 to compile. I'd like to add a java5 > profile to the main Jackrabbit build that contains the OCM components and is > automatically activated when building with Java 5 or higher. > This would simplify build instructions and allow us to remove the extra > Jackrabbit-ocm Hudson build that we currently use to build the OCM component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1757) OCM: translate-project goal not found
OCM: translate-project goal not found - Key: JCR-1757 URL: https://issues.apache.org/jira/browse/JCR-1757 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 1.5 The jackrabbit-ocm POM doesn't specify the required version of the Retrotranslator plugin it uses. In some cases this causes the build to use an older version of the plugin that doesn't come with the translate-plugin goal. The goal is included in the latest version (1.0-alpha-4) of the plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1731) Session.checkPermission("/", "add_node") throws PathNotFoundException instead of AccessControlException
[
https://issues.apache.org/jira/browse/JCR-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting reassigned JCR-1731:
--
Assignee: Jukka Zitting
> Session.checkPermission("/", "add_node") throws PathNotFoundException instead
> of AccessControlException
> ---
>
> Key: JCR-1731
> URL: https://issues.apache.org/jira/browse/JCR-1731
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core, security
>Affects Versions: core 1.4.5
>Reporter: Tobias Bocanegra
>Assignee: Jukka Zitting
> Fix For: core 1.4.6
>
>
> When invoking Session.checkPermission("/", "add_node"), a
> PathNotFoundException is thrown:
> Exception in thread "main" javax.jcr.PathNotFoundException: no such ancestor
> path of degree 1
> at
> org.apache.jackrabbit.spi.commons.name.PathFactoryImpl$PathImpl.getAncestor(PathFactoryImpl.java:443)
> at
> org.apache.jackrabbit.core.SessionImpl.checkPermission(SessionImpl.java:710)
> at Test.main(Test.java:35)
> i assume that getAncestor(1) used to return null in an earlier version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1757) OCM: translate-project goal not found
[ https://issues.apache.org/jira/browse/JCR-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1757. Resolution: Fixed Fixed in revision 698186. > OCM: translate-project goal not found > - > > Key: JCR-1757 > URL: https://issues.apache.org/jira/browse/JCR-1757 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > > The jackrabbit-ocm POM doesn't specify the required version of the > Retrotranslator plugin it uses. In some cases this causes the build to use an > older version of the plugin that doesn't come with the translate-plugin goal. > The goal is included in the latest version (1.0-alpha-4) of the plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1645) Add support for Map of referenced beans
[
https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633745#action_12633745
]
Vincent Giguère commented on JCR-1645:
--
Hi,
Everything seems to be fine.
However, I was wondering if you would have a better idea on how to implement
the BeanReferenceMapConverter. I find that my solution is a bit of a hack.
When persisting a map of reference, we must save the key in the map and the
UUID of the referenced node. But, since there are no implementation of
javax.jcr.Value that offer the possibility to store 2 strings (the key and the
UUID), I was left with encoding the 2 inside a String:
value="{color:red} MAPKEY{color}:*keyInTheMap{color:red}
MAPVALUE:{color}adjklq3e-rcq45f-4g3579-4fsd-345fsd"
Is there a better way of storing 2 strings as a value in the node?
If no, are you comfortable with this approach?
> Add support for Map of referenced beans
> ---
>
> Key: JCR-1645
> URL: https://issues.apache.org/jira/browse/JCR-1645
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-ocm
>Reporter: Vincent Giguère
>Assignee: Christophe Lombart
> Fix For: 1.5
>
> Attachments: BeanReferenceMapConverterImpl.java,
> BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java,
> MapReferenceValueEncoderTest.java
>
>
> OCM should support the mapping of maps of referenced beans.
> @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class)
> private java.util.Map aMap;
> BeanReferenceCollectionConverterImpl (mainly the method doGetCollection)
> needs to be updated to support the interface ManageableMap interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1645) Add support for Map of referenced beans
[
https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633745#action_12633745
]
vgiguere edited comment on JCR-1645 at 9/23/08 7:25 AM:
---
Hi,
Everything seems to be fine.
However, I was wondering if you would have a better idea on how to implement
the BeanReferenceMapConverter. I find that my solution is a bit of a hack.
When persisting a map of reference, we must save the key in the map and the
UUID of the referenced node. But, since there are no implementation of
javax.jcr.Value that offer the possibility to store 2 strings (the key and the
UUID), I was left with encoding the 2 inside a String:
value="MAPKEY:*keyInTheMapMAPVALUE:adjklq3e-rcq45f-4g3579-4fsd-345fsd"
Is there a better way of storing 2 strings as a value in the node?
If no, are you comfortable with this approach?
was (Author: vgiguere):
Hi,
Everything seems to be fine.
However, I was wondering if you would have a better idea on how to implement
the BeanReferenceMapConverter. I find that my solution is a bit of a hack.
When persisting a map of reference, we must save the key in the map and the
UUID of the referenced node. But, since there are no implementation of
javax.jcr.Value that offer the possibility to store 2 strings (the key and the
UUID), I was left with encoding the 2 inside a String:
value="MAPKEY:*keyInTheMapMAPVALUE:{color}adjklq3e-rcq45f-4g3579-4fsd-345fsd"
Is there a better way of storing 2 strings as a value in the node?
If no, are you comfortable with this approach?
> Add support for Map of referenced beans
> ---
>
> Key: JCR-1645
> URL: https://issues.apache.org/jira/browse/JCR-1645
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-ocm
>Reporter: Vincent Giguère
>Assignee: Christophe Lombart
> Fix For: 1.5
>
> Attachments: BeanReferenceMapConverterImpl.java,
> BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java,
> MapReferenceValueEncoderTest.java
>
>
> OCM should support the mapping of maps of referenced beans.
> @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class)
> private java.util.Map aMap;
> BeanReferenceCollectionConverterImpl (mainly the method doGetCollection)
> needs to be updated to support the interface ManageableMap interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1645) Add support for Map of referenced beans
[
https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633745#action_12633745
]
vgiguere edited comment on JCR-1645 at 9/23/08 7:24 AM:
---
Hi,
Everything seems to be fine.
However, I was wondering if you would have a better idea on how to implement
the BeanReferenceMapConverter. I find that my solution is a bit of a hack.
When persisting a map of reference, we must save the key in the map and the
UUID of the referenced node. But, since there are no implementation of
javax.jcr.Value that offer the possibility to store 2 strings (the key and the
UUID), I was left with encoding the 2 inside a String:
value="MAPKEY:*keyInTheMapMAPVALUE:{color}adjklq3e-rcq45f-4g3579-4fsd-345fsd"
Is there a better way of storing 2 strings as a value in the node?
If no, are you comfortable with this approach?
was (Author: vgiguere):
Hi,
Everything seems to be fine.
However, I was wondering if you would have a better idea on how to implement
the BeanReferenceMapConverter. I find that my solution is a bit of a hack.
When persisting a map of reference, we must save the key in the map and the
UUID of the referenced node. But, since there are no implementation of
javax.jcr.Value that offer the possibility to store 2 strings (the key and the
UUID), I was left with encoding the 2 inside a String:
value="{color:red} MAPKEY{color}:*keyInTheMap{color:red}
MAPVALUE:{color}adjklq3e-rcq45f-4g3579-4fsd-345fsd"
Is there a better way of storing 2 strings as a value in the node?
If no, are you comfortable with this approach?
> Add support for Map of referenced beans
> ---
>
> Key: JCR-1645
> URL: https://issues.apache.org/jira/browse/JCR-1645
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-ocm
>Reporter: Vincent Giguère
>Assignee: Christophe Lombart
> Fix For: 1.5
>
> Attachments: BeanReferenceMapConverterImpl.java,
> BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java,
> MapReferenceValueEncoderTest.java
>
>
> OCM should support the mapping of maps of referenced beans.
> @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class)
> private java.util.Map aMap;
> BeanReferenceCollectionConverterImpl (mainly the method doGetCollection)
> needs to be updated to support the interface ManageableMap interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1645) Add support for Map of referenced beans
[ https://issues.apache.org/jira/browse/JCR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633751#action_12633751 ] Christophe Lombart commented on JCR-1645: - I'm agree with you but I don't see another solution based on a multi value property. Another solution is to use subnodes instead of a multivalue prop. Those subnodes can match to each element in the map. in each subnode, we can have a prop for the key (or use the subnode name) and another property for the reference value It is also a bit of hack due to the fact that is not possible to store a map of prop in a JCR node. > Add support for Map of referenced beans > --- > > Key: JCR-1645 > URL: https://issues.apache.org/jira/browse/JCR-1645 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-ocm >Reporter: Vincent Giguère >Assignee: Christophe Lombart > Fix For: 1.5 > > Attachments: BeanReferenceMapConverterImpl.java, > BeanReferenceMapConverterImplTest.java, MapReferenceValueEncoder.java, > MapReferenceValueEncoderTest.java > > > OCM should support the mapping of maps of referenced beans. > @Collection(collectionConverter= BeanReferenceCollectionConverterImpl.class) > private java.util.Map aMap; > BeanReferenceCollectionConverterImpl (mainly the method doGetCollection) > needs to be updated to support the interface ManageableMap interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1731) Session.checkPermission("/", "add_node") throws PathNotFoundException instead of AccessControlException
[
https://issues.apache.org/jira/browse/JCR-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-1731.
Resolution: Fixed
Fixed in revision 698201.
> Session.checkPermission("/", "add_node") throws PathNotFoundException instead
> of AccessControlException
> ---
>
> Key: JCR-1731
> URL: https://issues.apache.org/jira/browse/JCR-1731
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core, security
>Affects Versions: core 1.4.5
>Reporter: Tobias Bocanegra
>Assignee: Jukka Zitting
> Fix For: core 1.4.6
>
>
> When invoking Session.checkPermission("/", "add_node"), a
> PathNotFoundException is thrown:
> Exception in thread "main" javax.jcr.PathNotFoundException: no such ancestor
> path of degree 1
> at
> org.apache.jackrabbit.spi.commons.name.PathFactoryImpl$PathImpl.getAncestor(PathFactoryImpl.java:443)
> at
> org.apache.jackrabbit.core.SessionImpl.checkPermission(SessionImpl.java:710)
> at Test.main(Test.java:35)
> i assume that getAncestor(1) used to return null in an earlier version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1743) Session.checkPermission: add_node and set_property evaluation are not handled differently
[ https://issues.apache.org/jira/browse/JCR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting reassigned JCR-1743: -- Assignee: Jukka Zitting > Session.checkPermission: add_node and set_property evaluation are not handled > differently > - > > Key: JCR-1743 > URL: https://issues.apache.org/jira/browse/JCR-1743 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: core 1.4.5 >Reporter: Tobias Bocanegra >Assignee: Jukka Zitting > Fix For: core 1.4.6 > > > if the property does not exist yet, Session.checkPermission invokes an > AccessManager.checkPermission(... WRITE) for both cases. i.e. the access > manager has no means for handle a "add_node" differently from a > "set_property" > suggest to create a fake property id for the case where the property does not > exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1758) Improvement to org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl to map super types effectively
Improvement to org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl to map super types effectively --- Key: JCR-1758 URL: https://issues.apache.org/jira/browse/JCR-1758 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Environment: Any Java Version. Reporter: Boni Gopalan Priority: Minor Fix For: 1.5 Improvement to org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's implementation of public Value getValue(ValueFactory valueFactory, Object propValue) , used equality check of class names to decide whether Object propValue is worthy of any attempt to map to an apropriate property. Since the purpose of the class is to provide a 'best effort' attempt to map an Object of type java.lang.Object it will be better to use 'instanceof'. This approach will convert the specific class as well as any inherited objects. For example using instanceof will let us map a BufferedInputStream, and any other sub classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1743) Session.checkPermission: add_node and set_property evaluation are not handled differently
[ https://issues.apache.org/jira/browse/JCR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1743: --- Attachment: JCR-1743.patch Proposed patch that creates a new PropertyId for the non-existing property and uses that in the AccessManager.checkPermission call. While I was at it, I also added safeguards against paths like /path/to/property/property or /path/to/new-property-that-has-the-same-name-as-an-existing-node. The trouble with this patch is that it may break existing AccessManager implementations that expect checkPermission calls for new properties to be WRITE requests for the parent node. Perhaps we should add a marker interface or something similar that an AccessManager that does need this functionality must implement. This way we could keep full backwards compatibility at the expense of some extra trouble. Note that all this will only affect the 1.4 branch. > Session.checkPermission: add_node and set_property evaluation are not handled > differently > - > > Key: JCR-1743 > URL: https://issues.apache.org/jira/browse/JCR-1743 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: core 1.4.5 >Reporter: Tobias Bocanegra >Assignee: Jukka Zitting > Fix For: core 1.4.6 > > Attachments: JCR-1743.patch > > > if the property does not exist yet, Session.checkPermission invokes an > AccessManager.checkPermission(... WRITE) for both cases. i.e. the access > manager has no means for handle a "add_node" differently from a > "set_property" > suggest to create a fake property id for the case where the property does not > exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1743) Session.checkPermission: add_node and set_property evaluation are not handled differently
[ https://issues.apache.org/jira/browse/JCR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1743: --- Component/s: security jackrabbit-core Issue Type: Improvement (was: Bug) This is more an improvement than a bug fix, as the previous behaviour was clearly intentional. > Session.checkPermission: add_node and set_property evaluation are not handled > differently > - > > Key: JCR-1743 > URL: https://issues.apache.org/jira/browse/JCR-1743 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core, security >Affects Versions: core 1.4.5 >Reporter: Tobias Bocanegra >Assignee: Jukka Zitting > Fix For: core 1.4.6 > > Attachments: JCR-1743.patch > > > if the property does not exist yet, Session.checkPermission invokes an > AccessManager.checkPermission(... WRITE) for both cases. i.e. the access > manager has no means for handle a "add_node" differently from a > "set_property" > suggest to create a fake property id for the case where the property does not > exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-1216:
Attachment: softReferencePatch.txt
This patch uses SoftReference instead of WeakReference, so leaks are detected a
bit later. This patch passes the unit tests on my machine. Still it's not very
nice, as I don't know what kind of ItemStateListener are registered in
StateChangeDispatcher. Is there always a hard reference to required listeners?
> Unreferenced sessions should get garbage collected
> --
>
> Key: JCR-1216
> URL: https://issues.apache.org/jira/browse/JCR-1216
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Attachments: softReferencePatch.txt, userSessionPatch.txt,
> weakReferencePatch.txt
>
>
> If an application opens many sessions and doesn't close them, they are never
> garbage collected. After some time, the virtual machine will run out of
> memory. This code will run out of memory after a few thousand logins:
> Repository rep = new TransientRepository();
> for (int i = 0; ; i++) {
> rep.login(new SimpleCredentials("", new char[0]));
> }
> Using a finalizer to close SessionImpl doesn't work, because it seems there
> are references from the (hard referenced part of the cache) to the
> SessionImpl objects. Maybe it is possible to remove those references, or
> change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1743) Session.checkPermission: add_node and set_property evaluation are not handled differently
[ https://issues.apache.org/jira/browse/JCR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1743: --- Attachment: JCR-1743-alternative.patch Attached an alternative patch that tries to solve the backwards compatibility issue by catching ItemNotFoundExceptions thrown by AccessManager implementations that always expect the target item to exist. In such cases we fall back to the previous behaviour of asking for WRITE permission on the parent node. > Session.checkPermission: add_node and set_property evaluation are not handled > differently > - > > Key: JCR-1743 > URL: https://issues.apache.org/jira/browse/JCR-1743 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core, security >Affects Versions: core 1.4.5 >Reporter: Tobias Bocanegra >Assignee: Jukka Zitting > Fix For: core 1.4.6 > > Attachments: JCR-1743-alternative.patch, JCR-1743.patch > > > if the property does not exist yet, Session.checkPermission invokes an > AccessManager.checkPermission(... WRITE) for both cases. i.e. the access > manager has no means for handle a "add_node" differently from a > "set_property" > suggest to create a fake property id for the case where the property does not > exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1758) Improvement to UndefinedTypeConverterImpl to map super types effectively
[ https://issues.apache.org/jira/browse/JCR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1758: --- Affects Version/s: (was: 1.5) Summary: Improvement to UndefinedTypeConverterImpl to map super types effectively (was: Improvement to org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl to map super types effectively) > Improvement to UndefinedTypeConverterImpl to map super types effectively > > > Key: JCR-1758 > URL: https://issues.apache.org/jira/browse/JCR-1758 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm > Environment: Any Java Version. >Reporter: Boni Gopalan >Priority: Minor > Fix For: 1.5 > > Original Estimate: 1h > Remaining Estimate: 1h > > Improvement to > org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's > implementation of > public Value getValue(ValueFactory valueFactory, Object propValue) , used > equality check of class names to decide whether Object propValue is worthy of > any attempt to map to an apropriate property. Since the purpose of the class > is to provide a 'best effort' attempt to map an Object of type > java.lang.Object it will be better to use 'instanceof'. This approach will > convert the specific class as well as any inherited objects. For example > using instanceof will let us map a BufferedInputStream, and any other sub > classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1758) Improvement to UndefinedTypeConverterImpl to map super types effectively
[ https://issues.apache.org/jira/browse/JCR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boni Gopalan updated JCR-1758: -- Attachment: UndefinedTypeConverterImpl.java Patch for the Issue reported. Modified getValue() method to use instanceof at the place of Class.equals() Ran and passed all the tests in jackrabbit-ocm. > Improvement to UndefinedTypeConverterImpl to map super types effectively > > > Key: JCR-1758 > URL: https://issues.apache.org/jira/browse/JCR-1758 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm > Environment: Any Java Version. >Reporter: Boni Gopalan >Priority: Minor > Fix For: 1.5 > > Attachments: UndefinedTypeConverterImpl.java > > Original Estimate: 1h > Remaining Estimate: 1h > > Improvement to > org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's > implementation of > public Value getValue(ValueFactory valueFactory, Object propValue) , used > equality check of class names to decide whether Object propValue is worthy of > any attempt to map to an apropriate property. Since the purpose of the class > is to provide a 'best effort' attempt to map an Object of type > java.lang.Object it will be better to use 'instanceof'. This approach will > convert the specific class as well as any inherited objects. For example > using instanceof will let us map a BufferedInputStream, and any other sub > classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1755) ClassCastException when registering custom node by XML file
[
https://issues.apache.org/jira/browse/JCR-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-1755.
Resolution: Fixed
Fix Version/s: core 1.4.6
Assignee: Jukka Zitting
Fixed the issue in revision 698209 and merged the fix to the 1.4 branch in
revision 698210. Thanks for reporting this!
> ClassCastException when registering custom node by XML file
> ---
>
> Key: JCR-1755
> URL: https://issues.apache.org/jira/browse/JCR-1755
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: core 1.4.5
> Environment: Spring 2.5, Spring Modules 0.9, Firefox 3, Tomcat 6,
> Ubuntu 8.10, MySql 5
> Repository is deployed as a shared J2EE resource (JNDI).
>Reporter: Jakub Wozniakowski
>Assignee: Jukka Zitting
>Priority: Critical
> Fix For: core 1.4.6
>
>
> When trying to register node type from XML file using following code:
> JackrabbitNodeTypeManager nodeTypeManager =
> (JackrabbitNodeTypeManager)workspace.getNodeTypeManager();
> for(Resource resource : nodeDefinitions){
> System.out.println("** registering node:"+resource);
>
> nodeTypeManager.registerNodeTypes(resource.getInputStream(),
> JackrabbitNodeTypeManager.TEXT_XML);
> }
> we receive such surprise:
> Caused by: java.lang.ClassCastException:
> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
> at
> org.apache.jackrabbit.core.util.DOMWalker.iterateElements(DOMWalker.java:215)
> at
> org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader.getNodeTypeDefs(NodeTypeReader.java:121)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:257)
> at
> org.apache.jackrabbit.core.nodetype.NodeTypeManagerImpl.registerNodeTypes(NodeTypeManagerImpl.java:499)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.registerNodes(JcrCustomNodeRegister.java:41)
> at
> pl.codeservice.jcr.JcrCustomNodeRegister.init(JcrCustomNodeRegister.java:27)
> ...
> Registering nodes by .cnd files works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1751) Update slf4j
[ https://issues.apache.org/jira/browse/JCR-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1751: --- Component/s: maven Fix Version/s: 1.5 Assignee: Jukka Zitting I'm wondering if a better solution would be *not* to use jcl-over-slf4j at all in Jackrabbit, i.e. leave it up to the client application to exclude the transitive commons-logging dependency with jcl-over-slf4j they want. > Update slf4j > > > Key: JCR-1751 > URL: https://issues.apache.org/jira/browse/JCR-1751 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Reporter: Stephane Landelle >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Please update slf4j from 1.3.0 to 1.5.2. > jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent > version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, > which is quite a pain... > No impact observed. > Best regards, > Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1754) The jackrabbit-ocm DTD 1.5 is missing and has to be publish
[ https://issues.apache.org/jira/browse/JCR-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633784#action_12633784 ] Jukka Zitting commented on JCR-1754: I don't recall if I already gave the instructions, but here they are again. :-) To publish static files to our website, just commit them to the jackrabbit/site folder in svn, from where they will automatically be deployed to the public web site. See http://jackrabbit.apache.org/website.html for the details. > The jackrabbit-ocm DTD 1.5 is missing and has to be publish > > > Key: JCR-1754 > URL: https://issues.apache.org/jira/browse/JCR-1754 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm, jackrabbit-site >Affects Versions: 1.5 >Reporter: Christophe Lombart > > The jackrabbit-ocm DTD 1.5 is missing and it should be made available for > reference on the Jackrabbit web site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-1631) Replace commons-logging dependency with SLF4J
[ https://issues.apache.org/jira/browse/JCR-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting reopened JCR-1631: As noted in JCR-1751, it might actually be a better idea *not* to exclude the commons-logging dependency at this level. Instead, we should let the client application decide what to do with the transitive logging dependencies. > Replace commons-logging dependency with SLF4J > - > > Key: JCR-1631 > URL: https://issues.apache.org/jira/browse/JCR-1631 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-text-extractors >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 1.5 > > > The poi dependency in jackrabbit-text-extractors brings in a transitive > dependency to commons-logging. Since we use SLF4J for all logging, we should > exclude the commons-logging dependency and replace it with jcl104-over-slf4j. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1631) Replace commons-logging dependency with SLF4J
[ https://issues.apache.org/jira/browse/JCR-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1631: --- Attachment: JCR-1631-reconsider.patch Attached a proposed patch that reverts the previous changes, and moves the commons-logging exclusion to the higher level projects jackrabbit-jca and jackrabbit-webapp. > Replace commons-logging dependency with SLF4J > - > > Key: JCR-1631 > URL: https://issues.apache.org/jira/browse/JCR-1631 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-text-extractors >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1631-reconsider.patch > > > The poi dependency in jackrabbit-text-extractors brings in a transitive > dependency to commons-logging. Since we use SLF4J for all logging, we should > exclude the commons-logging dependency and replace it with jcl104-over-slf4j. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1751) Update slf4j
[ https://issues.apache.org/jira/browse/JCR-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633796#action_12633796 ] Stephane Landelle commented on JCR-1751: I agree, jackrabbit shouldn't in any way depend on jcl104-over-slf4j with a compile scope. Currently, only jackrabbit-webapp and jackrabbit-text-extractor depend on jcl104-over-slf4j (both with compile scope). Concerning jackrabbit-webapp, scope should be runtime, not compile as it is now. Concerning jackrabbit-text-extractor, I don't understand why it depends on jcl104-over-slf4j in the first place. Should it be remove? Should scope be changed to test? Sincerely, Stephane Landelle 2008/9/23 Jukka Zitting (JIRA) <[EMAIL PROTECTED]> > Update slf4j > > > Key: JCR-1751 > URL: https://issues.apache.org/jira/browse/JCR-1751 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Reporter: Stephane Landelle >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Please update slf4j from 1.3.0 to 1.5.2. > jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent > version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, > which is quite a pain... > No impact observed. > Best regards, > Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1751) Update slf4j
[ https://issues.apache.org/jira/browse/JCR-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1751. Resolution: Fixed Updated the SLF4J dependencies to 1.5.3 in revision 698222. I reopened the JCR-1631 issue that introduced the jcl104-over-slf4j dependency to text-extractors. The rationale was to replace the transitive commons-logging dependency of Apache POI with SLF4J. > Update slf4j > > > Key: JCR-1751 > URL: https://issues.apache.org/jira/browse/JCR-1751 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Reporter: Stephane Landelle >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Please update slf4j from 1.3.0 to 1.5.2. > jcl104-over-slf4j has been renamed as jcl-over-slf4j, so if one uses a recent > version, he has to exclude jcl104-over-slf4j for every jackrabbit dependency, > which is quite a pain... > No impact observed. > Best regards, > Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1753) Allow means force a Repository to synchronize with the cluster
[ https://issues.apache.org/jira/browse/JCR-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1753: --- Affects Version/s: (was: core 1.4.5) Fix Version/s: 1.5 Assignee: Jukka Zitting Summary: Allow means force a Repository to synchronize with the cluster (was: Allow means force a Repository to synchronize with the data store) Hmm, there's a somewhat releated long discussion ([1] and [2]) about JackrabbitRepository.shutdown() that we had earlier this year. This method is not nearly as intrusive as the shutdown() method, but there might be valid reasons why it shouldn't be exposed to just any client. [1] http://markmail.org/message/fqyypq5x6bma4ike [2] http://markmail.org/message/dsqyv3rafo4j5xea > Allow means force a Repository to synchronize with the cluster > -- > > Key: JCR-1753 > URL: https://issues.apache.org/jira/browse/JCR-1753 > Project: Jackrabbit > Issue Type: New Feature > Components: clustering, jackrabbit-api, jackrabbit-core >Reporter: Micah Whitacre >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1753.tar.gz > > > Based on the thread on the user mailing list I'm logging this to propose > adding a sync() method to force cluster synchronization using the > JackrabbitRepository extension API. > The purpose of the method is such that in a distributed clustered environment > sometime cluster synchronization does or has not occurred such that certain > repositories are in a stale state. This method would provide a means to > force a repository to update pull in possible changes made by other > Jackrabbit repositories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1750) Creating QValue from stream: stream not closed
[ https://issues.apache.org/jira/browse/JCR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1750. Resolution: Fixed Fix Version/s: 1.5 Assignee: Jukka Zitting Patch applied in revision 698246. Thanks! > Creating QValue from stream: stream not closed > -- > > Key: JCR-1750 > URL: https://issues.apache.org/jira/browse/JCR-1750 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-spi-commons >Reporter: Michael Dürig >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1750.patch > > > QValueFactoryImpl.create(InputStream) does not close the input stream as > mandated by the contract. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1759) Simplify the usage of OCM annotations
Simplify the usage of OCM annotations - Key: JCR-1759 URL: https://issues.apache.org/jira/browse/JCR-1759 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart If we are using more reflections during the OCM init phase (class descriptor loading), some OCM annotation settings are not necessary : @Node(isAbtract=true) : used to specify an abstract classes @Node(extend=) : used to specify the ancestor class @Node(isInterface= ...) : used to specify the entity as an interface @implement : used to specify the associated interfaces If this refactoring is done, we can set them as deprecated. The performances will not suffer because this is done only once during the application startup (when the ObjectContentManager is initialized). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1760) Review the OCM API and annotations to be more compliant with JPA
Review the OCM API and annotations to be more compliant with JPA Key: JCR-1760 URL: https://issues.apache.org/jira/browse/JCR-1760 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Christophe Lombart It should be possible to start smoothly the JPA support. Of course, all JPA features are not necessary in the JCR world. For example, the annotations @Table and @Column are not very useful for OCM :-). Nevertheless, using almost the same API and a subset of the JPA annotations could be a great help for people who knows the JPA specification. Here is a list of changes that we can do quickly : - Rename the ObjecContentManager into EntityManager and review some method names. - Rename the OCM annotations : @Node => @Entity @Field => @Basic @Bean => @OneToOne @Collection => @OneToMany. Furthermore, @Collection is not a good name because it also supporting Maps :-) I would like to wait for the JPA query because the upcoming JPA spec will add more flexibility in this area. After, we can review in more details the JPA specification and see if there is a real interest to be more conform to this specification. What do you think about that ? Please, add your comments. thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633868#action_12633868 ] Micah Whitacre commented on JCR-1462: - I'm not sure I have permissions to reopen this bug but was advised to do so. This bug seems to have introduced the requirement that all repository.xml files specify a DOCTYPE. If you don't have a doctype specified you start seeing SAX Parse exceptions like the following: org.xml.sax.SAXParseException: Document root element "Repository", must match DOCTYPE root "null". at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:236) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:172) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:382) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:316) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.rootElementSpecified(XMLDTDValidator.java:1652) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:1931) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:795) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:1157) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292) at org.apache.jackrabbit.core.config.ConfigurationParser.parseXML(ConfigurationParser.java:215) at org.apache.jackrabbit.core.config.RepositoryConfigurationParser.parseRepositoryConfig(RepositoryConfigurationParser.java:214) at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:144) at org.apache.jackrabbit.core.config.RepositoryConfig.create(RepositoryConfig.java:118) > repository.xml: throw an exception on error > --- > > Key: JCR-1462 > URL: https://issues.apache.org/jira/browse/JCR-1462 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.5 > > Attachments: configPatch.txt > > > Currently, unsupported parameters in repository.xml and workspace.xml are > ignored. > To find problems earlier, such problems should result in an exception, > and starting such a repository should not be possible. > The same should happen for unsupported values. > For currently unavailable options > (such as text extraction filter classes if the class is not in the classpath), > at least a warning should be written to the error log, or an error should be > thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1758) Improvement to UndefinedTypeConverterImpl to map super types effectively
[ https://issues.apache.org/jira/browse/JCR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1758: --- Assignee: Christophe Lombart > Improvement to UndefinedTypeConverterImpl to map super types effectively > > > Key: JCR-1758 > URL: https://issues.apache.org/jira/browse/JCR-1758 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm > Environment: Any Java Version. >Reporter: Boni Gopalan >Assignee: Christophe Lombart >Priority: Minor > Fix For: 1.5 > > Attachments: UndefinedTypeConverterImpl.java > > Original Estimate: 1h > Remaining Estimate: 1h > > Improvement to > org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's > implementation of > public Value getValue(ValueFactory valueFactory, Object propValue) , used > equality check of class names to decide whether Object propValue is worthy of > any attempt to map to an apropriate property. Since the purpose of the class > is to provide a 'best effort' attempt to map an Object of type > java.lang.Object it will be better to use 'instanceof'. This approach will > convert the specific class as well as any inherited objects. For example > using instanceof will let us map a BufferedInputStream, and any other sub > classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1758) Improvement to UndefinedTypeConverterImpl to map super types effectively
[ https://issues.apache.org/jira/browse/JCR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1758. - Resolution: Fixed the patch has been applied. Unit tests are working here. Thanks for the improvement. Let me know if something is wrong. > Improvement to UndefinedTypeConverterImpl to map super types effectively > > > Key: JCR-1758 > URL: https://issues.apache.org/jira/browse/JCR-1758 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm > Environment: Any Java Version. >Reporter: Boni Gopalan >Assignee: Christophe Lombart >Priority: Minor > Fix For: 1.5 > > Attachments: UndefinedTypeConverterImpl.java > > Original Estimate: 1h > Remaining Estimate: 1h > > Improvement to > org.apache.jackrabbit.ocm.manager.atomictypeconverter.impl.UndefinedTypeConverterImpl's > implementation of > public Value getValue(ValueFactory valueFactory, Object propValue) , used > equality check of class names to decide whether Object propValue is worthy of > any attempt to map to an apropriate property. Since the purpose of the class > is to provide a 'best effort' attempt to map an Object of type > java.lang.Object it will be better to use 'instanceof'. This approach will > convert the specific class as well as any inherited objects. For example > using instanceof will let us map a BufferedInputStream, and any other sub > classes of InputStream to a Binary Property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Item.getPath() returns wrong values on shared nodes
Hi,
currently I am working on the integration of WebDAV binding extensions
into |org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet|, using
the shareable node feature of jsr-283.
The implementation of the BIND method was straightforward and worked as
expected, but I noticed that sometimes DELETE removed the wrong binding.
It turned out that |org.apache.jackrabbit.core.NodeImpl.removeShare()|
did not remove the node itself, but instead another node from the same
shared set. Apparently the methods |ItemImpl.getPath()| and
|ItemImpl.getPrimaryPath()| have unexpected results in these cases.
The following testcase illustrates the issue if included into the test
class |org.apache.jackrabbit.core.ShareableNodeTest|:
/**
* Verify that shared nodes return correct paths.
*/
public void testPath() throws Exception {
Node a1 = testRootNode.addNode("a1");
Node a2 = a1.addNode("a2");
Node b1 = a1.addNode("b1");
b1.addMixin("mix:shareable");
testRootNode.save();
//now we have a shareable node N with path a1/b1
Session session = testRootNode.getSession();
Workspace workspace = session.getWorkspace();
String path = a2.getPath() + "/b2";
workspace.clone(workspace.getName(), b1.getPath(), path, false);
//now we have another shareable node N' in the same shared set as N
with path a1/a2/b2
//using the path a1/a2/b2, we should get the node N' here
Item item = session.getItem(path);
String p = item.getPath();
assertFalse("unexpectedly got the path from another node from the
same shared set ", p.equals(b1.getPath()));
}
Regards,
Manfred
--
Manfred Baedke
bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782
--
Manfred Baedke
bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782
[jira] Reopened: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting reopened JCR-1462: Reopened based on the last comment. I'm not sure I see how much we are actually gaining by enabling DTD validation. Even any valid XHTML document would pass that test without Jackrabbit being any wiser. Validation would make much more sense if the DTD was specified by the configuration parser instead of the document being parsed. > repository.xml: throw an exception on error > --- > > Key: JCR-1462 > URL: https://issues.apache.org/jira/browse/JCR-1462 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.5 > > Attachments: configPatch.txt > > > Currently, unsupported parameters in repository.xml and workspace.xml are > ignored. > To find problems earlier, such problems should result in an exception, > and starting such a repository should not be possible. > The same should happen for unsupported values. > For currently unavailable options > (such as text extraction filter classes if the class is not in the classpath), > at least a warning should be written to the error log, or an error should be > thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-664) Property.setValue(Node) explicitly checks for NodeImpl
[
https://issues.apache.org/jira/browse/JCR-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633888#action_12633888
]
Jukka Zitting commented on JCR-664:
---
I suggest to resolve this as Won't Fix until we have a good use case.
> Property.setValue(Node) explicitly checks for NodeImpl
> --
>
> Key: JCR-664
> URL: https://issues.apache.org/jira/browse/JCR-664
> Project: Jackrabbit
> Issue Type: Wish
> Components: jackrabbit-core
> Environment: that's neither a bug nor is it a major issue
>Reporter: Tobias Bocanegra
>Priority: Minor
>
> The implementation of Propert.setValue(Node) explicitly checks if the
> argument is a NodeImpl:
> if (target instanceof NodeImpl) {
>[...]
> } else {
>String msg = "incompatible Node object: " + target;
>log.debug(msg);
>throw new RepositoryException(msg);
> }
> This is not very convenient for applications that decorate the jcr objects.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1759) Simplify the usage of OCM annotations
[ https://issues.apache.org/jira/browse/JCR-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1759: --- Assignee: Christophe Lombart > Simplify the usage of OCM annotations > - > > Key: JCR-1759 > URL: https://issues.apache.org/jira/browse/JCR-1759 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm >Affects Versions: 1.5 >Reporter: Christophe Lombart >Assignee: Christophe Lombart > > If we are using more reflections during the OCM init phase (class descriptor > loading), some OCM annotation settings are not necessary : > @Node(isAbtract=true) : used to specify an abstract classes > @Node(extend=) : used to specify the ancestor class > @Node(isInterface= ...) : used to specify the entity as an interface > @implement : used to specify the associated interfaces > If this refactoring is done, we can set them as deprecated. > The performances will not suffer because this is done only once during the > application startup (when the ObjectContentManager is initialized). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1328) Session.itemExists implementation wrong
[ https://issues.apache.org/jira/browse/JCR-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633899#action_12633899 ] Jukka Zitting commented on JCR-1328: In spi-commons there's already a MalformedPathException class that extends NameException (and through it RepositoryException). Adding another exception with the same name would be confusing and removing the class from spi-commons would be a backwards compatibility issue. And because of the NameException superclass, we can't even play tricks by letting one similarly named exception extend the other. So, can we come up with some other name for this exception? PathSyntaxException? > Session.itemExists implementation wrong > --- > > Key: JCR-1328 > URL: https://issues.apache.org/jira/browse/JCR-1328 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Felix Meschberger >Priority: Minor > Attachments: JCR-1328.patch > > > IMHO the implementation of the Session.itemExists(String) method is wrong > when called with a malformed path such as "/a/b/c/*" (note the trailing > star). According to the spec, the method must return "false" for a malformed > path like this. > In reality, the method throws a RepositoryException which is allowed to be > thrown by the spec "if an error occurrs" (whatever that means). But catching > this exception means, we cannot handle it: Is it a connection issue or a > general repository problem ? If so, I cannot do anything about it. It is > really a path problem, I can do something about it. But how do I know > (without rebuilding internals) ? > See also SLING-152 for more info. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
jackrabbit-core 1.4.6 release timeline
What is the approximate timeline for the jackrabbit-core 1.4.6 release? Thanks.
Re: jackrabbit-core 1.4.6 release timeline
Hi, On Wed, Sep 24, 2008 at 12:31 AM, Brian Whipple <[EMAIL PROTECTED]> wrote: > What is the approximate timeline for the jackrabbit-core 1.4.6 release? There is one open issue (JCR-1743) with a proposed patch, and I plan to roll the release candidate as soon as that issue is resolved. The release should be official by next week. BR, Jukka Zitting
[jira] Resolved: (JCR-1538) [patch] add toString for NodeImpl and PropertyImpl
[ https://issues.apache.org/jira/browse/JCR-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1538. Resolution: Fixed Assignee: Jukka Zitting Completed in revision 698402. All ItemImpl descendants now have toString() methods that return a string like " " using safeGetJCRPath for the path part. Also, I replaced all calls to safeGetJCRPath() with the toString() method in diagnostics output. The result is more readable, for example: "failed to add property " + name + " to " + safeGetJCRPath() vs. "failed to add property " + name + " to " + this > [patch] add toString for NodeImpl and PropertyImpl > -- > > Key: JCR-1538 > URL: https://issues.apache.org/jira/browse/JCR-1538 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: core 1.4.2 >Reporter: Dave Brosius >Assignee: Jukka Zitting >Priority: Trivial > Fix For: 1.5 > > Attachments: node_and_property_toString.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > add toString for NodeImpl and PropertyImpl with new format. see how it is > liked, before adding more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to register Repository?
I don't know how to register Repository. I want to write the RepositoryFactory using jsr 170 by myself. -- View this message in context: http://www.nabble.com/How-to-register-Repository--tp19640431p19640431.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] Reopened: (JCR-1721) make collection element names configureable
[ https://issues.apache.org/jira/browse/JCR-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reopened JCR-1721: - We have also to support the jcrElementName with the XML mapping fille. > make collection element names configureable > --- > > Key: JCR-1721 > URL: https://issues.apache.org/jira/browse/JCR-1721 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-ocm >Reporter: Oliver Lietz >Assignee: Christophe Lombart >Priority: Minor > Fix For: 1.5 > > Attachments: jcrElementName.diff, jcrElementName.diff > > > - add jcrElementName to CollectionDescriptor and Collection annotation > - make COLLECTION_ELEMENT_NAME protected instead of private -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to use javax.jcr to get Repository
Just have workspace and username password. -- View this message in context: http://www.nabble.com/How-to-use-javax.jcr-to-get-Repository-tp19642519p19642519.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: How to use javax.jcr to get Repository
Hi, On Wed, Sep 24, 2008 at 8:02 AM, xing007008 <[EMAIL PROTECTED]> wrote: > Just have workspace and username password. With nothing but javax.jcr interfaces? You can't, that's explicitly outside the scope of the spec. BR, Jukka Zitting
