[jira] [Updated] (JCR-4354) VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
[
https://issues.apache.org/jira/browse/JCR-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4354:
Fix Version/s: 2.17.6
> VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
>
>
> Key: JCR-4354
> URL: https://issues.apache.org/jira/browse/JCR-4354
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
>Reporter: Woonsan Ko
>Priority: Major
> Labels: PatchAvailable
> Fix For: 2.17.6
>
>
> I think it would be nice to have a VFS (commons-vfs) based {{FileSystem}}
> which then can be used by {{BundleFsPersistenceManager}}.
> For example, I have worked with a Jackrabbit based WCMS product which
> recommends using one of {{BundleDbPersistenceManager}} components for both
> workspaces and version, which makes it easier for clustering.
> One typical problem is that the version storage in DBMS keeps increasing, so
> as a result we've recommended cleaning up older version items periodically.
> (You may google "cms version cleaner" for more info.)
> In this case, if they were able to configure a VFS based {{FileSystem}} and
> the generic {{PersistenceManager}}, {{BundleFsPersistenceManager}}, for the
> versions, their DB size would keep small enough, and they may keep the
> version items almost infinitely. Actually versioning are used relatively less
> than other normal functionalities such as content retrieval and searching,
> only when authoring users publish a document in our case. So, keeping version
> data separately from database wouldn't be a problem, as long as it supports
> easier clustering (through WebDAV or SFTP in this option).
> Another possible use case is that some people may use VFS based solution for
> both workspaces and version, backed by a clustered WebDAV server or SFTP
> server. They can use VFS-based DataStore provided by JCR-3975 as well. This
> would increase architectural options around Jackrabbit ecosystem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4354) VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
[
https://issues.apache.org/jira/browse/JCR-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4354:
Labels: PatchAvailable (was: )
> VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
>
>
> Key: JCR-4354
> URL: https://issues.apache.org/jira/browse/JCR-4354
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
>Reporter: Woonsan Ko
>Priority: Major
> Labels: PatchAvailable
> Fix For: 2.17.6
>
>
> I think it would be nice to have a VFS (commons-vfs) based {{FileSystem}}
> which then can be used by {{BundleFsPersistenceManager}}.
> For example, I have worked with a Jackrabbit based WCMS product which
> recommends using one of {{BundleDbPersistenceManager}} components for both
> workspaces and version, which makes it easier for clustering.
> One typical problem is that the version storage in DBMS keeps increasing, so
> as a result we've recommended cleaning up older version items periodically.
> (You may google "cms version cleaner" for more info.)
> In this case, if they were able to configure a VFS based {{FileSystem}} and
> the generic {{PersistenceManager}}, {{BundleFsPersistenceManager}}, for the
> versions, their DB size would keep small enough, and they may keep the
> version items almost infinitely. Actually versioning are used relatively less
> than other normal functionalities such as content retrieval and searching,
> only when authoring users publish a document in our case. So, keeping version
> data separately from database wouldn't be a problem, as long as it supports
> easier clustering (through WebDAV or SFTP in this option).
> Another possible use case is that some people may use VFS based solution for
> both workspaces and version, backed by a clustered WebDAV server or SFTP
> server. They can use VFS-based DataStore provided by JCR-3975 as well. This
> would increase architectural options around Jackrabbit ecosystem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4354) VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
[
https://issues.apache.org/jira/browse/JCR-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-4354:
Fix Version/s: 2.18
> VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
>
>
> Key: JCR-4354
> URL: https://issues.apache.org/jira/browse/JCR-4354
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
>Reporter: Woonsan Ko
>Priority: Major
> Labels: PatchAvailable
> Fix For: 2.18, 2.17.6
>
>
> I think it would be nice to have a VFS (commons-vfs) based {{FileSystem}}
> which then can be used by {{BundleFsPersistenceManager}}.
> For example, I have worked with a Jackrabbit based WCMS product which
> recommends using one of {{BundleDbPersistenceManager}} components for both
> workspaces and version, which makes it easier for clustering.
> One typical problem is that the version storage in DBMS keeps increasing, so
> as a result we've recommended cleaning up older version items periodically.
> (You may google "cms version cleaner" for more info.)
> In this case, if they were able to configure a VFS based {{FileSystem}} and
> the generic {{PersistenceManager}}, {{BundleFsPersistenceManager}}, for the
> versions, their DB size would keep small enough, and they may keep the
> version items almost infinitely. Actually versioning are used relatively less
> than other normal functionalities such as content retrieval and searching,
> only when authoring users publish a document in our case. So, keeping version
> data separately from database wouldn't be a problem, as long as it supports
> easier clustering (through WebDAV or SFTP in this option).
> Another possible use case is that some people may use VFS based solution for
> both workspaces and version, backed by a clustered WebDAV server or SFTP
> server. They can use VFS-based DataStore provided by JCR-3975 as well. This
> would increase architectural options around Jackrabbit ecosystem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
javax.jcr.version.VersionException: Unable to perform operation. Node is checked-in. at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:141)
I have written a piece of java code to update the contents of the jack rabbit
repository
System.out.println("node.getName()"+node.getName());
if( node.getName().equals("1486135308708")) {
InputStream inputStream =
new FileInputStream("D:/1103_LVA_Temp01_SEV.pdf");
if (node.isCheckedOut()) {
Binary localBinary =
localSession.getValueFactory().createBinary(inputStream);
node.getNode("jcr:content").setProperty("jcr:data",
localBinary);
localSession.save();
}
}
Getting below exception
2018-08-08 15:13:14,401 [main] DEBUG CopyJCRFiles - Unable to perform
operation. Node is checked-in.
javax.jcr.version.VersionException: Unable to perform operation. Node is
checked-in.
at
org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:141)
at
org.apache.jackrabbit.rmi.server.ServerNode.setProperty(ServerNode.java:289)
at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at org.apache.jackrabbit.rmi.server.ServerNode_Stub.setProperty(Unknown
Source)
at
org.apache.jackrabbit.rmi.client.ClientNode.setProperty(ClientNode.java:128)
I tried by checkin out the version manager same issue is observed
--
Sent from: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-Dev-f523400.html
Re: Decide if a composite node store setup expose multiple checkpoint mbeans
Hi, sorry for getting back to this a bit late There was an off-list discussion among some core oak commiters which concluded that: * checkpoint bean should only be exposed by global node store (opened OAK-7699 [0] for this) * we should formalize responsibilities of a node store implementation instead of discovering issues after the fact (opened OAK-7700 [1] for this) [0]: https://issues.apache.org/jira/browse/OAK-7699 [1]: https://issues.apache.org/jira/browse/OAK-7700 Thanks, Vikas
