[jira] Updated: (JCR-1026) Add a FileSystem to org.apache.jackrabbit.core.query.lucene.SearchIndex
[ https://issues.apache.org/jira/browse/JCR-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated JCR-1026: --- Component/s: indexing Priority: Major (was: Critical) hardly a critical issue... Add a FileSystem to org.apache.jackrabbit.core.query.lucene.SearchIndex --- Key: JCR-1026 URL: https://issues.apache.org/jira/browse/JCR-1026 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.3 Reporter: Alexander Filipchik Now org.apache.jackrabbit.core.query.lucene.SearchIndex uses local File System. When clustering - it's impossible to move it to database. I think SearchIndex must using org.apache.jackrabbit.core.fs.FileSystem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-926) Global data store for binaries
[ https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513847 ] Thomas Mueller commented on JCR-926: What needs to be done to commit this to Jackrabbit? My patches get bigger and more complicated... Global data store for binaries -- Key: JCR-926 URL: https://issues.apache.org/jira/browse/JCR-926 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Jukka Zitting Attachments: dataStore.patch, DataStore.patch, DataStore2.patch, dataStore3.patch, dataStore4.zip, internalValue.patch, ReadWhileSaveTest.patch There are three main problems with the way Jackrabbit currently handles large binary values: 1) Persisting a large binary value blocks access to the persistence layer for extended amounts of time (see JCR-314) 2) At least two copies of binary streams are made when saving them through the JCR API: one in the transient space, and one when persisting the value 3) Versioining and copy operations on nodes or subtrees that contain large binary values can quickly end up consuming excessive amounts of storage space. To solve these issues (and to get other nice benefits), I propose that we implement a global data store concept in the repository. A data store is an append-only set of binary values that uses short identifiers to identify and access the stored binary values. The data store would trivially fit the requirements of transient space and transaction handling due to the append-only nature. An explicit mark-and-sweep garbage collection process could be added to avoid concerns about storing garbage values. See the recent NGP value record discussion, especially [1], for more background on this idea. [1] http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200705.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-926) Global data store for binaries
[ https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513854 ] Jukka Zitting commented on JCR-926: --- I'm sorry I haven't had the cycles lately to properly review the patches. Would it be possible to split them to smaller semi-independent pieces? For example we could commit the data store implementation independent of the integration to rest of the Jackrabbit core. Global data store for binaries -- Key: JCR-926 URL: https://issues.apache.org/jira/browse/JCR-926 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Jukka Zitting Attachments: dataStore.patch, DataStore.patch, DataStore2.patch, dataStore3.patch, dataStore4.zip, internalValue.patch, ReadWhileSaveTest.patch There are three main problems with the way Jackrabbit currently handles large binary values: 1) Persisting a large binary value blocks access to the persistence layer for extended amounts of time (see JCR-314) 2) At least two copies of binary streams are made when saving them through the JCR API: one in the transient space, and one when persisting the value 3) Versioining and copy operations on nodes or subtrees that contain large binary values can quickly end up consuming excessive amounts of storage space. To solve these issues (and to get other nice benefits), I propose that we implement a global data store concept in the repository. A data store is an append-only set of binary values that uses short identifiers to identify and access the stored binary values. The data store would trivially fit the requirements of transient space and transaction handling due to the append-only nature. An explicit mark-and-sweep garbage collection process could be added to avoid concerns about storing garbage values. See the recent NGP value record discussion, especially [1], for more background on this idea. [1] http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200705.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SystemView Import and UUID
hi, the current implementation needs a valid uuid if the attribute is present. it's discussable if an empty attribute should be treated like a non existing one. feel free to post a jira enhancement issue. regards, toby On 7/18/07, qcfireball [EMAIL PROTECTED] wrote: I am trying to do a SystemView Import, and have a UUID created if the node does not already exist. I use an XSLT to x-form my XML into the proper SystemView, and include a node for jcr:uuid. If this value is empty, the JCR throws an exception. If I remove the jcr:uuid node, the JCR imports the XML without Exception. My problem is that I don't want to maintain 2 XSLT's or have to post process the XML to remove the jcr:uuid node. Is there any way to import XML with the following jcr:uuid node value in the imported XML? sv:property sv:name=jcr:uuid sv:type=String sv:value/ /sv:property -- View this message in context: http://www.nabble.com/SystemView-Import-and-UUID-tf4102939.html#a11667706 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: [jira] Commented: (JCR-926) Global data store for binaries
I'm sorry I haven't had the cycles lately to properly review the patches. Sure, I understand. Would it be possible to split them to smaller semi-independent pieces? For example we could commit the data store implementation independent of the integration to rest of the Jackrabbit core. Sure, just the ..core.data package. Do you need a new patch or can you just commit this subset? The real problem will be the API changes (introducing the DataStore in many constructors and methods). Can I help to integrate those changes? Or change it to make integration easier? Thomas
Re: [jira] Commented: (JCR-926) Global data store for binaries
Hi, On 7/19/07, Thomas Mueller [EMAIL PROTECTED] wrote: Would it be possible to split them to smaller semi-independent pieces? For example we could commit the data store implementation independent of the integration to rest of the Jackrabbit core. Sure, just the ..core.data package. Do you need a new patch or can you just commit this subset? I can take care of it. The real problem will be the API changes (introducing the DataStore in many constructors and methods). Can I help to integrate those changes? Or change it to make integration easier? I'll give the latest patch a look and get back to you on the best way forward. BR, Jukka Zitting
[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513897 ] angela commented on JCR-388: i will attach my patch, where i (hopefully) integrated all comments (see jira). during some quick testing in found a couple of additional things: - compliance class: version-history was missing as well - DAV:predecessor-set missing with checked-out vc-resource - in response to the discussion with julian i disabled the version-control feature for collections. - versions are always non-collection resources - versions never expose any member resources - isCollection() always returns false - the locator for versions has to be build accordingly - collections may never put under DAV version control. - VersionResources are read-only - override addMember, removeMember and all methods related to PROPPATCH. - VersionHistoryResource are read-only except for remove of versions (i'm not sure, whether this is allowed with deltaV. it is optional in JCR). - there were some more comments that were copied from jcr-server without making sense in the new context. - VersionHandler: i change the behaviour in order not to export all jcr properties present with the content-node such as the DefaultHandler does. add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-388: --- Attachment: JCR-388_2007_07_19.patch patch addressing my additional comments. rob/ed, can you check if everything still works as you expect it? unless someone finds a problem i will commit the patch by Tuesday next week. kind regards angela add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: JCR-388_2007_07_19.patch, patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- 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-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513897 ] angela edited comment on JCR-388 at 7/19/07 7:05 AM: - i will attach my patch, where i (hopefully) integrated all comments (see jira). during some quick testing in found a couple of additional things: - compliance class: version-history was missing as well - DAV:predecessor-set missing with checked-out vc-resource - in response to the discussion with julian i disabled the version-control feature for collections. - versions are always non-collection resources - versions never expose any member resources - isCollection() always returns false - the locator for versions has to be build accordingly - collections may never put under DAV version control. - VersionResources are read-only - override addMember, removeMember and all methods related to PROPPATCH. - VersionHistoryResource are read-only except for remove of versions (i'm not sure, whether this is allowed with deltaV. it is optional in JCR). - VersionHistoryResource did only specify version-history resource type. it should also include 'collection'. - there were some more comments that were copied from jcr-server without making sense in the new context. - VersionHandler: i change the behaviour in order not to export all jcr properties present with the content-node such as the DefaultHandler does. was: i will attach my patch, where i (hopefully) integrated all comments (see jira). during some quick testing in found a couple of additional things: - compliance class: version-history was missing as well - DAV:predecessor-set missing with checked-out vc-resource - in response to the discussion with julian i disabled the version-control feature for collections. - versions are always non-collection resources - versions never expose any member resources - isCollection() always returns false - the locator for versions has to be build accordingly - collections may never put under DAV version control. - VersionResources are read-only - override addMember, removeMember and all methods related to PROPPATCH. - VersionHistoryResource are read-only except for remove of versions (i'm not sure, whether this is allowed with deltaV. it is optional in JCR). - there were some more comments that were copied from jcr-server without making sense in the new context. - VersionHandler: i change the behaviour in order not to export all jcr properties present with the content-node such as the DefaultHandler does. add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: JCR-388_2007_07_19.patch, patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Junit testing with Jackrabbit using AbstractDependencyInjectionSpringContextTests
I'm am in the process of setting up Junit testing for my Jackrabbit based CMS web application using JSF and Spring. I finally got my test to see the config files I need, but now I get the following error message. It seems like the JcrTemplate isn't opening up a new JCR session so that I can access the repository. Everything works fine when the application is deployed...just not for my Junit test. Since I don't get any errors about being able to initialize any of my Dependency Injected beans...i would assume everything is initialized properly. Does anyone know what i'm missing? Do I need to set something in the AbstractDependencyInjectionSpringContextTests class to initialize the repository? javax.jcr.RepositoryException: this session has been closed at org.apache.jackrabbit.core.SessionImpl.sanityCheck (SessionImpl.java:353) at org.apache.jackrabbit.core.ItemImpl.sanityCheck(It emImpl.java:153) at org.apache.jackrabbit.core.NodeImpl.getUUID(NodeIm pl.java:2803) at org.bmpcoe.cwe5.service.impl.NodeServiceImpl.getNo deByPath(NodeServiceImpl.java:165) at org.bmpcoe.cwe5.service.NodeServiceTests.testGetAl lFiles(NodeServiceTests.java:41) at org.springframework.test.ConditionalTestCase.runBa re(ConditionalTestCase.java:69) at org.eclipse.ant.internal.ui.antsupport.EclipseDefa ultExecutor.executeTargets(EclipseDefaultExecutor. java:32) at org.eclipse.ant.internal.ui.antsupport.InternalAnt Runner.run(InternalAntRunner.java:423) at org.eclipse.ant.internal.ui.antsupport.InternalAnt Runner.main(InternalAntRunner.java:137) -- View this message in context: http://www.nabble.com/Junit-testing-with-Jackrabbit-using-AbstractDependencyInjectionSpringContextTests-tf4111862.html#a11691587 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
RE: Release schedule for 1.3.1 and onward
Would somebody please be kind enough to answer my question below. We have to do some planning upgrades and this information would help greatly! Much appreciated Amir -Original Message- From: Amir Mistric [mailto:[EMAIL PROTECTED] Sent: Monday, July 16, 2007 11:24 AM To: dev@jackrabbit.apache.org Subject: Release schedule for 1.3.1 and onward Is there a document or a link outlining when will next versions of JR be released? In particular 1.3.1? JIRA would be a nice place to put this info in but it is not there currently... Thanks Amir
[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513950 ] Ed Burnette commented on JCR-388: - I did a smoke test on it and it seems to work for me. add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: JCR-388_2007_07_19.patch, patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Junit testing with Jackrabbit using AbstractDependencyInjectionSpringContextTests
bilobag wrote: javax.jcr.RepositoryException: this session has been closed Could you please provide the source code of a very simple TestCase that fails for you? It seems like the session is closed to early (well obviously ;) but without the source it's very difficult to tell what's going wrong. Cheers, Christoph
Re: Junit testing with Jackrabbit using AbstractDependencyInjectionSpringContextTests
Yes, here is the source for my test class and the applicationContext.xml.
Please let me know what you think. I would expect the jcrTemplate to open a
repository session like it does when I run the web app, but it seems like
its not. Please let me know if there is something extra that I need to do
to get my test case to work with a Jackrabbit repository. Thanks.
source:
public class NodeServiceTests extends
AbstractDependencyInjectionSpringContextTests {
protected static final Log log =
LogFactory.getLog(NodeServiceTests.class);
private NodeService nodeService;
public void setNodeService(NodeService nodeService) {
this.nodeService = nodeService;
}
private NodeService getNodeService() {
return this.nodeService;
}
public NodeServiceTests() {
super();
setAutowireMode(AUTOWIRE_BY_NAME);
}
protected String[] getConfigLocations() {
return new String[] {
classpath:WEB-INF/applicationContext.xml};
}
public void testGetAllFiles() throws IllegalAccessException,
RepositoryException, InvocationTargetException {
log.debug(in testGetAllFiles()***);
NodeDto fileNode = getNodeService().getNodeByPath(/app
root/workspace3/folder0);
Collection allFiles =
getNodeService().getAllFiles(fileNode.getUuid());
Iterator fileIter = allFiles.iterator();
int x=0;
while(fileIter.hasNext()) {
log.debug(fileNodeType + x++ + = +
fileIter.next());
}
log.debug(end testGetAllFiles() );
assertNotNull(allFiles);
}
}
applicationContext.xml:
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:aop=http://www.springframework.org/schema/aop;
xmlns:tx=http://www.springframework.org/schema/tx;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd;
bean id=repository
class=org.springmodules.jcr.jackrabbit.RepositoryFactoryBean
!-- normal factory beans params --
property name=configuration
value=/WEB-INF/app-repository.xml /
/bean
!-- JNDI configuration --
!-- bean id=repository
class=org.springframework.jndi.JndiObjectFactoryBean
property name=jndiName
value=java:comp/env/jcr/myRepository/
/bean --
!-- SessionFactory --
bean id=jcrSessionFactory
class=org.app.webapp.util.AppJackrabbitSessionFactory
property name=repository ref=repository /
property name=credentials
bean class=javax.jcr.SimpleCredentials
constructor-arg index=0 value=bogus /
!-- create the credentials using a bean
factory --
constructor-arg index=1
bean factory-bean=password
factory-method=toCharArray /
/constructor-arg
/bean
/property
!--
property name=forceNamespacesRegistration
value=true/
property name=keepNewNamespaces value=false/
--
property name=skipExistingNamespaces value=true /
property name=contentType value=text/x-jcr-cnd /
property name=nodeDefinitions
list
value/WEB-INF/appNodeTypes.cnd/value
/list
/property
/bean
!-- create the password to return it as a char[] --
bean id=password class=java.lang.String
constructor-arg index=0 value= /
/bean
bean id=jcrTemplate class=org.springmodules.jcr.JcrTemplate
property name=sessionFactory ref=jcrSessionFactory /
property name=allowCreate value=true /
/bean
bean id=jcrTransactionManager
class=org.springmodules.jcr.jackrabbit.LocalTransactionManager
property name=sessionFactory ref=jcrSessionFactory /
/bean
bean id=txProxyTemplate abstract=true
Re: Junit testing with Jackrabbit using AbstractDependencyInjectionSpringContextTests
Ok, i think my issue is that I have the
org.springmodules.jcr.support.OpenSessionInViewFilter configured in my
web.xml which is supposed to keep my repository session open. My dao mainly
just uses the jcrTemplate methods to access the repository. I believe the
template opens and closes the session. Does anyone know of a way to keep it
open during my entire test case?
bilobag wrote:
Yes, here is the source for my test class and the applicationContext.xml.
Please let me know what you think. I would expect the jcrTemplate to open
a repository session like it does when I run the web app, but it seems
like its not. Please let me know if there is something extra that I need
to do to get my test case to work with a Jackrabbit repository. Thanks.
source:
public class NodeServiceTests extends
AbstractDependencyInjectionSpringContextTests {
protected static final Log log =
LogFactory.getLog(NodeServiceTests.class);
private NodeService nodeService;
public void setNodeService(NodeService nodeService) {
this.nodeService = nodeService;
}
private NodeService getNodeService() {
return this.nodeService;
}
public NodeServiceTests() {
super();
setAutowireMode(AUTOWIRE_BY_NAME);
}
protected String[] getConfigLocations() {
return new String[] {
classpath:WEB-INF/applicationContext.xml};
}
public void testGetAllFiles() throws IllegalAccessException,
RepositoryException, InvocationTargetException {
log.debug(in testGetAllFiles()***);
NodeDto fileNode = getNodeService().getNodeByPath(/app
root/workspace3/folder0);
Collection allFiles =
getNodeService().getAllFiles(fileNode.getUuid());
Iterator fileIter = allFiles.iterator();
int x=0;
while(fileIter.hasNext()) {
log.debug(fileNodeType + x++ + = +
fileIter.next());
}
log.debug(end testGetAllFiles() );
assertNotNull(allFiles);
}
}
applicationContext.xml:
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:aop=http://www.springframework.org/schema/aop;
xmlns:tx=http://www.springframework.org/schema/tx;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd;
bean id=repository
class=org.springmodules.jcr.jackrabbit.RepositoryFactoryBean
!-- normal factory beans params --
property name=configuration
value=/WEB-INF/app-repository.xml /
/bean
!-- JNDI configuration --
!-- bean id=repository
class=org.springframework.jndi.JndiObjectFactoryBean
property name=jndiName
value=java:comp/env/jcr/myRepository/
/bean --
!-- SessionFactory --
bean id=jcrSessionFactory
class=org.app.webapp.util.AppJackrabbitSessionFactory
property name=repository ref=repository /
property name=credentials
bean class=javax.jcr.SimpleCredentials
constructor-arg index=0 value=bogus /
!-- create the credentials using a bean
factory --
constructor-arg index=1
bean factory-bean=password
factory-method=toCharArray /
/constructor-arg
/bean
/property
!--
property name=forceNamespacesRegistration
value=true/
property name=keepNewNamespaces value=false/
--
property name=skipExistingNamespaces value=true /
property name=contentType value=text/x-jcr-cnd /
property name=nodeDefinitions
list
value/WEB-INF/appNodeTypes.cnd/value
/list
/property
/bean
!-- create the password to return it as a char[] --
bean id=password class=java.lang.String
constructor-arg index=0 value= /
/bean
bean id=jcrTemplate class=org.springmodules.jcr.JcrTemplate
property name=sessionFactory
Re: Junit testing with Jackrabbit using AbstractDependencyInjectionSpringContextTests
bilobag wrote:
Ok, i think my issue is that I have the
org.springmodules.jcr.support.OpenSessionInViewFilter configured in my
web.xml which is supposed to keep my repository session open. My dao mainly
just uses the jcrTemplate methods to access the repository. I believe the
template opens and closes the session. Does anyone know of a way to keep it
open during my entire test case?
I just copied some code from OpenSessionInViewFilter to put together a quick and
dirty solution. I'm using transactions and therefore have a threadbound session
available anyway. There might be a cleaner solution but this one should work for
now.
Cheers,
Christoph
ps: Just post such questions to the user list next time. Most developers read
both lists anyway.
===
package com.subshell.sophora.server.persistence.jcr;
import javax.jcr.Node;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.jackrabbit.JcrConstants;
import org.springframework.test.AbstractDependencyInjectionSpringContextTests;
import
org.springframework.transaction.support.TransactionSynchronizationManager;
import org.springmodules.jcr.JcrTemplate;
import org.springmodules.jcr.SessionFactory;
import org.springmodules.jcr.SessionFactoryUtils;
public class NodeServiceTests extends
AbstractDependencyInjectionSpringContextTests {
protected static final Log log =
LogFactory.getLog(NodeServiceTests.class);
protected JcrTemplate jcrTemplate;
private SessionFactory sf;
private Session session;
public JcrTemplate getJcrTemplate() {
return jcrTemplate;
}
public void setJcrTemplate(JcrTemplate jcrTemplate) {
this.jcrTemplate = jcrTemplate;
}
public NodeServiceTests() {
super();
setAutowireMode(AUTOWIRE_BY_NAME);
}
@Override
protected String[] getConfigLocations() {
return new String[] {
classpath:WEB-INF/applicationContext.xml };
}
@Override
protected void onSetUp() throws Exception {
super.onSetUp();
sf = jcrTemplate.getSessionFactory();
session = SessionFactoryUtils.getSession(sf, true);
TransactionSynchronizationManager.bindResource(sf,
sf.getSessionHolder(session));
}
@Override
protected void onTearDown() throws Exception {
TransactionSynchronizationManager.unbindResource(sf);
SessionFactoryUtils.releaseSession(session, sf);
super.onTearDown();
}
public void testGetAllFiles() throws RepositoryException {
Node addNode = jcrTemplate.getRootNode().addNode(test);
addNode.addMixin(JcrConstants.MIX_REFERENCEABLE);
String uuid = addNode.getUUID();
Node nodeByUUID = jcrTemplate.getNodeByUUID(uuid);
assertEquals(JcrConstants.MIX_REFERENCEABLE,
nodeByUUID.getMixinNodeTypes()[0].getName());
}
}
