[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)
[jira] [Updated] (JCR-4354) VFS (commons-vfs) 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 {{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.
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.
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 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)
[jira] [Updated] (JCR-4354) VFS (commons-vfs) 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 {{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.
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.
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.
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 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.
> 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)
[jira] [Commented] (JCR-4354) VFS (commons-vfs) based Persistence Manager
[
https://issues.apache.org/jira/browse/JCR-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570324#comment-16570324
]
Woonsan Ko commented on JCR-4354:
-
I'd like to provide PR(s) for this improvement some day. Thanks!
> VFS (commons-vfs) 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.
> 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)
[jira] [Updated] (JCR-4354) VFS (commons-vfs) 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 {{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.
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.
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.
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.
> VFS (commons-vfs) 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.
> 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)
[jira] [Created] (JCR-4354) VFS (commons-vfs) based Persistence Manager
Woonsan Ko created JCR-4354:
---
Summary: VFS (commons-vfs) 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
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.
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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-313) Avoid opening VaultPackage to get RegisteredPackage in FSRegistry
[ https://issues.apache.org/jira/browse/JCRVLT-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated JCRVLT-313: Fix Version/s: 3.2.2 > Avoid opening VaultPackage to get RegisteredPackage in FSRegistry > - > > Key: JCRVLT-313 > URL: https://issues.apache.org/jira/browse/JCRVLT-313 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Reporter: Dominik Süß >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.2.2 > > > The current state of the implementation of FSRegistry is built around the > initial buildup from scratch so it was sufficient to open the VaultPackage to > extract the RegisteredPackage data. Implementing consuming application to > visualize the package state showed inefficiencies. As the necessary state is > already cached after registration opening a registered package should doesn't > mandate opening the vaultpackage under the hood. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JCRVLT-314) Optimize buildup & update flow of FSInstallState
[ https://issues.apache.org/jira/browse/JCRVLT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-314. - Resolution: Fixed Fix Version/s: 3.2.2 fixed in r1837508 > Optimize buildup & update flow of FSInstallState > > > Key: JCRVLT-314 > URL: https://issues.apache.org/jira/browse/JCRVLT-314 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Reporter: Dominik Süß >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.2.2 > > > The implementation as is passes a lot of metadata to the setInstallState > method to build up the target State to be persisted. As the save call and > cleanup code is already decoupled from the buildup the state can be already > built in the calling methods which allows to better scale up for further and > potentially optional properties to persist via builder pattern. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JCRVLT-313) Avoid opening VaultPackage to get RegisteredPackage in FSRegistry
[ https://issues.apache.org/jira/browse/JCRVLT-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-313. - Resolution: Fixed fixed in r1837508 > Avoid opening VaultPackage to get RegisteredPackage in FSRegistry > - > > Key: JCRVLT-313 > URL: https://issues.apache.org/jira/browse/JCRVLT-313 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Reporter: Dominik Süß >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.2.2 > > > The current state of the implementation of FSRegistry is built around the > initial buildup from scratch so it was sufficient to open the VaultPackage to > extract the RegisteredPackage data. Implementing consuming application to > visualize the package state showed inefficiencies. As the necessary state is > already cached after registration opening a registered package should doesn't > mandate opening the vaultpackage under the hood. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Jackrabbit Filevault 3.2.0
On Mon, 2018-08-06 at 07:29 +, Tobias Bocanegra wrote: > Please vote on releasing this package as Apache Jackrabbit Filevault > 3.2.0. +1 with [INFO] [INFO] Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T21:33:14+03:00) [INFO] OS name: "linux", version: "4.17.11-1-default", arch: "amd64", family: "unix" [INFO] Java version: 1.8.0_171, vendor: Oracle Corporation, runtime: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre [INFO] Also quickly tested with the Sling IDE tooling, no regressions spotted. Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (JCRVLT-312) Release Filevault 3.2
[ https://issues.apache.org/jira/browse/JCRVLT-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569831#comment-16569831 ] Tobias Bocanegra commented on JCRVLT-312: - RC created: https://repository.apache.org/content/repositories/orgapachejackrabbit-1362/ Vote Thread: https://www.mail-archive.com/dev@jackrabbit.apache.org/msg42125.html > Release Filevault 3.2 > - > > Key: JCRVLT-312 > URL: https://issues.apache.org/jira/browse/JCRVLT-312 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Affects Versions: 3.2 >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Jackrabbit Filevault 3.2.0
> On 6 Aug 2018, at 09:29, Tobias Bocanegra wrote: > > A candidate for the Jackrabbit Filevault 3.2.0 release is available at: ... [X] +1 Release this package as Apache Jackrabbit Filevault 3.2.0 With: [INFO] [INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00) [INFO] OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" [INFO] Java version: 1.8.0_152, vendor: Oracle Corporation [INFO] [INFO] ALL CHECKS OK [INFO] Regards, Toby
[VOTE] Release Apache Jackrabbit Filevault 3.2.0
A candidate for the Jackrabbit Filevault 3.2.0 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/filevault/3.2.0/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/tags/jackrabbit-filevault-3.2.0/ The SHA1 checksum of the archive is 354eb978563fa42db03cd15326a62135a1f28790. The command for running automated checks against this release candidate is: $ sh check-release.sh filevault 3.2.0 354eb978563fa42db03cd15326a62135a1f28790 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachejackrabbit-1362/ Please vote on releasing this package as Apache Jackrabbit Filevault 3.2.0. The vote is open for a minimum of 72 hours during business days and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. The vote fails if not enough votes are cast after 1 week (5 business days). [ ] +1 Release this package as Apache Jackrabbit Filevault 3.2.0 [ ] -1 Do not release this package because... Regards, Toby
[jira] [Resolved] (JCRVLT-300) vlt-rcp: Support proxy
[
https://issues.apache.org/jira/browse/JCRVLT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-300.
-
Resolution: Fixed
fixed in r1837486
> vlt-rcp: Support proxy
> --
>
> Key: JCRVLT-300
> URL: https://issues.apache.org/jira/browse/JCRVLT-300
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.2
>
>
> Currently it is not possible to explicity configure an HTTP proxy (either via
> dedicated parameters or generic system variables). The underlying problem is
> the lack of support in spi2dav tracked in JCR-3211.
> The error message looks like this
> {code}
> 12:52:56 [DEBUG] Opening connection {}->:4502
> 12:52:56 [DEBUG] http-outgoing-0: Shutdown connection
> 12:52:56 [DEBUG] Connection discarded
> 12:52:56 [DEBUG] Connection released: [id: 0][route:
> {}->:4502][total kept alive: 0; route allocated: 0 of 20; total
> allocated: 0 of 20]
> 12:52:56 [DEBUG] Cancelling request execution
> 12:52:56 [ERROR] Error while retrieving src repository
> :4502/crx/server/-/jcr:root/:
> javax.jcr.RepositoryException: java.net.UnknownHostException: :
> System error
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
