[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:
Labels: (was: PatchAvailable)
> 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
> Components: jackrabbit-vfs-ext
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.18, 2.17.6
>
> Attachments: JCR-4354.diff
>
>
> 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:
Component/s: jackrabbit-vfs-ext
> 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
> Components: jackrabbit-vfs-ext
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Labels: PatchAvailable
> Fix For: 2.18, 2.17.6
>
> Attachments: JCR-4354.diff
>
>
> 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:
Attachment: JCR-4354.diff
> 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
>
> Attachments: JCR-4354.diff
>
>
> 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)
[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
]
Woonsan Ko updated JCR-4354:
Description:
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.
was:
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 for clustering.
One typical problem is that the version storage in DBMS keeps increasing a lot,
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 very rarely, only when
authoring users publish a document in our case. So, keeping versions separately
from database wouldn't be a problem, as long as it's easily clusterable
(through WebDAV or SFTP for instance).
And, another possible use case is that some people may use VFS based
{{FileSystem}} and the generic {{PersistenceManager}} for both workspaces and
version, backed by a clustered WebDAV server or SFTP server. That could help
increase architectural options as well. Also, they can use VFS-based DataStore
provided by JCR-3975.
> 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
>
> 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:
Description:
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 for clustering.
One typical problem is that the version storage in DBMS keeps increasing a lot,
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 very rarely, only when
authoring users publish a document in our case. So, keeping versions separately
from database wouldn't be a problem, as long as it's easily clusterable
(through WebDAV or SFTP for instance).
And, another possible use case is that some people may use VFS based
{{FileSystem}} and the generic {{PersistenceManager}} for both workspaces and
version, backed by a clustered WebDAV server or SFTP server. That could help
increase architectural options as well. Also, they can use VFS-based DataStore
provided by JCR-3975.
was:
I think it would be nice to have a VFS (commons-vfs) based {{Persistence
Manager}}.
For example, I have worked with a Jackrabbit based WCMS product which
recommends using one of {{BundleDbPersistenceManager}} components for both
workspaces and version for clustering.
One typical problem is that the version storage in DBMS keeps increasing a lot,
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 Persistence Manager
for the versions, their DB size would keep small enough, and they may keep the
version items almost infinitely. Actually versioning are used very rarely, only
when authoring users publish a document in our case. So, keeping versions
separately from database wouldn't be a problem, as long as it's easily
clusterable (through WebDAV or SFTP for instance).
And, another possible use case is that some people may use VFS based
PersistenceManager for both workspaces and version, backed by a clustered
WebDAV server or SFTP server. That could help increase architectural options as
well. Also, they can use VFS-based DataStore provided by JCR-3975.
> 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
>
> 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 for clustering.
> One typical problem is that the version storage in DBMS keeps increasing a
> lot, 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 very rarely,
> only when authoring users publish a document in our case. So, keeping
> versions separately from database wouldn't be a problem, as long as it's
> easily clusterable (through WebDAV or SFTP for instance).
> And, another possible use case is that some people may use VFS based
> {{FileSystem}} and the generic {{PersistenceManager}} for both workspaces and
> version, backed by a clustered WebDAV server or SFTP server. That could help
> increase architectural options as well. Also, they can use VFS-based
> DataStore provided by JCR-3975.
--
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:
Summary: VFS (commons-vfs) based FileSystem for VFS backend based
Persistence Manager (was: VFS (commons-vfs) based Persistence Manager)
> 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
>
> I think it would be nice to have a VFS (commons-vfs) based {{Persistence
> Manager}}.
> For example, I have worked with a Jackrabbit based WCMS product which
> recommends using one of {{BundleDbPersistenceManager}} components for both
> workspaces and version for clustering.
> One typical problem is that the version storage in DBMS keeps increasing a
> lot, 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 Persistence Manager
> for the versions, their DB size would keep small enough, and they may keep
> the version items almost infinitely. Actually versioning are used very
> rarely, only when authoring users publish a document in our case. So, keeping
> versions separately from database wouldn't be a problem, as long as it's
> easily clusterable (through WebDAV or SFTP for instance).
> And, another possible use case is that some people may use VFS based
> PersistenceManager for both workspaces and version, backed by a clustered
> WebDAV server or SFTP server. That could help increase architectural options
> as well. Also, they can use VFS-based DataStore provided by JCR-3975.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
