[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path
[
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892577#comment-16892577
]
Felix Meschberger commented on JCR-4460:
You might want to look how it is being used in the Sling JCR WebDAV bundles for
some more insight, [~reschke]
> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path
[
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892531#comment-16892531
]
Felix Meschberger commented on JCR-4460:
{quote}There probably was a good reason for it's introduction
{quote}
I guess so, yes. But I cannot remember. One explanation I would have is usage
inside an OSGi framework where the servlet context path might be injected
differently... But honestly, I do not remember ...
> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin
[ https://issues.apache.org/jira/browse/JCR-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747768#comment-15747768 ] Felix Meschberger commented on JCR-4060: ACK. > unintended export versions due to changed defaults in maven bundle plugin > - > > Key: JCR-4060 > URL: https://issues.apache.org/jira/browse/JCR-4060 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.12.5, 2.13.4 >Reporter: Julian Reschke >Priority: Blocker > Fix For: 2.13.6, 2.14, 2.12.7 > > Attachments: ExportVersionChecker.jar, ExportVersionChecker.java > > > It appears that the maven bundle plugin change for JCR-3937 has caused > default export version numbers to be assigned where before we hadn't any. > For instance, in jackrabbit-api, the package "o.a.j.api" has a > package-info.java setting the version to 2.4, and this is what get's exported. > However, o.a.j.api.query does not have a package-info, and now gets exported > with a version number of 2.13.5, whereas previously it didn't get any version > number. > a) Does anybody know whether this change in behavior of the bundle plugin is > documented anywhere? > b) Do we need to fix something here, or are automatically assigned version > numbers indeed ok? If we need to do something, what is the correct fix? > Freeze the version numbers at the currently assigned version? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin
[ https://issues.apache.org/jira/browse/JCR-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747595#comment-15747595 ] Felix Meschberger commented on JCR-4060: I think the most sensible thing to do would be to create java-package.info files in all the exported packages exporting these packages at the latest bundle release version. This way you don't break existing consumers and make sure that going forward, the export versions should be properly managed as the packages may evolve (well probably not any more, so having a fixed version number is even better). ... and then not having full-blown all-in releases any more also will help, but that is for another day ;-) > unintended export versions due to changed defaults in maven bundle plugin > - > > Key: JCR-4060 > URL: https://issues.apache.org/jira/browse/JCR-4060 > Project: Jackrabbit Content Repository > Issue Type: Bug >Affects Versions: 2.12.5, 2.13.4 >Reporter: Julian Reschke >Priority: Blocker > Fix For: 2.13.6, 2.14, 2.12.7 > > Attachments: ExportVersionChecker.jar, ExportVersionChecker.java > > > It appears that the maven bundle plugin change for JCR-3937 has caused > default export version numbers to be assigned where before we hadn't any. > For instance, in jackrabbit-api, the package "o.a.j.api" has a > package-info.java setting the version to 2.4, and this is what get's exported. > However, o.a.j.api.query does not have a package-info, and now gets exported > with a version number of 2.13.5, whereas previously it didn't get any version > number. > a) Does anybody know whether this change in behavior of the bundle plugin is > documented anywhere? > b) Do we need to fix something here, or are automatically assigned version > numbers indeed ok? If we need to do something, what is the correct fix? > Freeze the version numbers at the currently assigned version? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession
[ https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487313#comment-14487313 ] Felix Meschberger commented on JCR-3870: This is actually not an edge case and has always been there. Export SessionImpl#getItemOrNull in JackrabbitSession - Key: JCR-3870 URL: https://issues.apache.org/jira/browse/JCR-3870 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Affects Versions: 2.10 Reporter: Joel Richard Priority: Critical Labels: performance getItemOrNull should be exported in JackrabbitSession. This would allow to combine itemExists and getItem in Sling which would reduce the rendering time by 8%. See the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession
[ https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484909#comment-14484909 ] Felix Meschberger commented on JCR-3870: I don't think it is worth exporting such a method. The most basic problem is the JCR API requesting the getItem method to throw in case the item does not exist. So the itemExists method has been added to be able to check the existence (or visibility, actually) of the item before trying to access it. So, the actual performance problem boils down to being an implementation problem: The API specification as [~mreutegg] pointed out suggest to check for existence before accessing the item and this is what Sling does. In other word Sling follows the API specification guidance. As such Sling is expecting the implementation to do the best to support the API and the API guidance. Export SessionImpl#getItemOrNull in JackrabbitSession - Key: JCR-3870 URL: https://issues.apache.org/jira/browse/JCR-3870 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Affects Versions: 2.10 Reporter: Joel Richard Priority: Critical Labels: performance getItemOrNull should be exported in JackrabbitSession. This would allow to combine itemExists and getItem in Sling which would reduce the rendering time by 8%. See the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession
[ https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484909#comment-14484909 ] Felix Meschberger edited comment on JCR-3870 at 4/8/15 7:55 AM: I don't think it is worth exporting such a method. The most basic problem is the JCR API requesting the getItem method to throw in case the item does not exist. So the itemExists method has been added to be able to check the existence (or visibility, actually) of the item before trying to access it. So, the actual performance problem boils down to being an implementation problem: The API specification, as [~mreutegg] pointed out, suggests to check for existence before accessing the item and this is what Sling does. In other word Sling follows the API specification guidance. As such Sling is expecting the implementation to do the best to support the API and the API guidance. was (Author: fmeschbe): I don't think it is worth exporting such a method. The most basic problem is the JCR API requesting the getItem method to throw in case the item does not exist. So the itemExists method has been added to be able to check the existence (or visibility, actually) of the item before trying to access it. So, the actual performance problem boils down to being an implementation problem: The API specification as [~mreutegg] pointed out suggest to check for existence before accessing the item and this is what Sling does. In other word Sling follows the API specification guidance. As such Sling is expecting the implementation to do the best to support the API and the API guidance. Export SessionImpl#getItemOrNull in JackrabbitSession - Key: JCR-3870 URL: https://issues.apache.org/jira/browse/JCR-3870 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Affects Versions: 2.10 Reporter: Joel Richard Priority: Critical Labels: performance getItemOrNull should be exported in JackrabbitSession. This would allow to combine itemExists and getItem in Sling which would reduce the rendering time by 8%. See the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession
[ https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485513#comment-14485513 ] Felix Meschberger commented on JCR-3870: bq. there are many other places, where sling is optimized around how the JCR implementation behaves Really ? Off the top of my head I know of the Oak Observer (falling back to regular JCR Observation is not available). Others ? Indeed, at one point in early time, Sling had JCR Session pooling until Jackrabbit Repository.login became drammatically faster than pooled session cleanup. At which time we happily removed Session pooling from Sling. Export SessionImpl#getItemOrNull in JackrabbitSession - Key: JCR-3870 URL: https://issues.apache.org/jira/browse/JCR-3870 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Affects Versions: 2.10 Reporter: Joel Richard Priority: Critical Labels: performance getItemOrNull should be exported in JackrabbitSession. This would allow to combine itemExists and getItem in Sling which would reduce the rendering time by 8%. See the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3802) User Management: API for System Users
[
https://issues.apache.org/jira/browse/JCR-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090775#comment-14090775
]
Felix Meschberger commented on JCR-3802:
Sounds good to me.
The API patch defines the properties of a system user. But what is the use case
for system users from a pure Jackrabbit point of view ? I understand the
support for Sling's SlingRepository.loginService method and I think that makes
sense. Is that enough to justify the introduction of system users in Jackrabbit
?
(Don't get me wrong. I think the idea is perfectly valid and with my Sling hat
on, I welcome it very much.)
And some comments on the POC patch:
* SystemUserImpl.checkValidTree checks for type AuthorizableType.USER to check
whether the tree is of the correct type. Is that correct or should that be
AuthorizableType.SYSTEM_USER ?
* UserValidator prohibits disabling system users. What is the reason ? I would
think we should be able to disable these users just as any other users for some
quick stop-gap security measures.
* UserUtil.isSystemUser is missing from the POC patch
* UserManagerImpl adds use of com.google.common.base.Strings[.isNullOrEmpty].
Is that by intent or should this rather be org.apache.lang.StringUtil ?
User Management: API for System Users
-
Key: JCR-3802
URL: https://issues.apache.org/jira/browse/JCR-3802
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api
Reporter: angela
Attachments: JCR-3802___POC_implementation_for_Oak.patch,
JCR-3802_proposed_API.patch
Apache Sling recently added the ability to define dedicated service users
that allows to replace the troublesome
{{SlingRepository.loginAdministrative}} with {{SlingRepository.loginService}}.
In a default Sling repository backed by a Jackrabbit/Oak content repository
this results in user accounts being created for these service users.
Since these service users are never expected to represent a real subject that
has a userId/password pair or profile information editable by this very
subject, I figured out that it may be useful to cover these service users
with the following API extensions, which would allow us to identify if a
given user account is in fact a service (or system) user.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners
[ https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933083#comment-13933083 ] Felix Meschberger commented on JCR-3745: I like the filter idea, but I think it is strange to have an interface defining a Bean API instead of just have the simple flat bean class. Alternatively the interface would just define getter methods. Add JackrabbitObservationManager with additional methods for registering event listeners Key: JCR-3745 URL: https://issues.apache.org/jira/browse/JCR-3745 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-api Reporter: Michael Dürig Assignee: Michael Dürig I'd like to add an additional method for adding event listeners to the Jackrabbit API: void addEventListener(EventListener listener, int eventTypes, String[] absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean noLocal, boolean noExternal) throws RepositoryException; Compared to the JCR method of the same name, this method takes an array of absPath and additional boolean argument: Only events whose associated parent node is at one of the paths in codeabsPaths/code (or within its subgraph, if codeisDeep/code is codetrue/code) will be received. and Additionally, if codenoExternal/code is codetrue/code, then events from external cluster nodes are ignored. Otherwise, they are not ignored. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners
[ https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933167#comment-13933167 ] Felix Meschberger commented on JCR-3745: [~rombert] I think we can just keep both methods and should be fine. [~mduerig] I seem to understand we agree on the setter methods for interfaces: How about defining JackrabbitEventListener as a final class ? (NB: Actually it just occurrs to me why setters on interfaces are a really bad idea: This basically defines a mutable object and so the filter used for registration cannot be used by the ObservationManager essentially causing the latter to clone (or otherwise copy) the settings for internal use. Slightly better would be a builder interface with setters and the actual interface with getters -- still two objects, though ...) Add JackrabbitObservationManager with additional methods for registering event listeners Key: JCR-3745 URL: https://issues.apache.org/jira/browse/JCR-3745 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-api Reporter: Michael Dürig Assignee: Michael Dürig Attachments: JCR-3745.patch I'd like to add an additional method for adding event listeners to the Jackrabbit API: void addEventListener(EventListener listener, int eventTypes, String[] absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean noLocal, boolean noExternal) throws RepositoryException; Compared to the JCR method of the same name, this method takes an array of absPath and additional boolean argument: Only events whose associated parent node is at one of the paths in codeabsPaths/code (or within its subgraph, if codeisDeep/code is codetrue/code) will be received. and Additionally, if codenoExternal/code is codetrue/code, then events from external cluster nodes are ignored. Otherwise, they are not ignored. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners
[ https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933197#comment-13933197 ] Felix Meschberger commented on JCR-3745: bq. Class yes, final why? What's the use of extending it ? The ObservationManager is the consumer of the instance and it can only support what it can support and thus is exposed in this base class. If we later see, that extension makes sense we can still make it non-final. But making a non-final class final is essentially killing backwards compatibility. Add JackrabbitObservationManager with additional methods for registering event listeners Key: JCR-3745 URL: https://issues.apache.org/jira/browse/JCR-3745 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-api Reporter: Michael Dürig Assignee: Michael Dürig Attachments: JCR-3745.patch I'd like to add an additional method for adding event listeners to the Jackrabbit API: void addEventListener(EventListener listener, int eventTypes, String[] absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean noLocal, boolean noExternal) throws RepositoryException; Compared to the JCR method of the same name, this method takes an array of absPath and additional boolean argument: Only events whose associated parent node is at one of the paths in codeabsPaths/code (or within its subgraph, if codeisDeep/code is codetrue/code) will be received. and Additionally, if codenoExternal/code is codetrue/code, then events from external cluster nodes are ignored. Otherwise, they are not ignored. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837643#comment-13837643 ] Felix Meschberger commented on JCR-3705: +1 for a new jackrabbit-data component Extract data store API and implementations from jackrabbit-core --- Key: JCR-3705 URL: https://issues.apache.org/jira/browse/JCR-3705 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would currently require a direct dependency to jackrabbit-core, which is troublesome for various reasons. Since the DataStore interface and its implementations are mostly independent of the rest of Jackrabbit internals, it should be possible to avoid that dependency by moving the data store bits to some other component. One alternative would be to place them in jackrabbit-jcr-commons, another to create a separate new jackrabbit-data component for this purpose. WDYT? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JCR-3293) AbstractLoginModule: get rid of trust_credentials_attribute
[
https://issues.apache.org/jira/browse/JCR-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815935#comment-13815935
]
Felix Meschberger commented on JCR-3293:
Codewise, something like this, I think:
{code}
Subject s = getAndPopulateTheSubject();
Session session = Subject.doAs(s, new PrivilegedExceptionAction() {
public Session run() throws RepositoryException {
return repository.login();
}
});
{code}
(plus proper exception handling and unwrapping, of course)
AbstractLoginModule: get rid of trust_credentials_attribute
---
Key: JCR-3293
URL: https://issues.apache.org/jira/browse/JCR-3293
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.4
Reporter: angela
based on JCR-2355 we added a very simplistic way to indicate to the login
module that the given credentials have
been preauthenticated. as already stated in the original issue this poses a
major security issue as it leaves the
repository access untrusted.
i would like to raise those security concern again and would therefore like
to get rid of that hack in the long run.
the suggested procedure:
- deprecate the attribute (immediately)
- log a warning if it is used (immediately)
- document how to fix code that is currently relying on that attribute
- remove support altogether for the next major release
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (JCRVLT-18) Set default autosave threshold based on repository implementation
[ https://issues.apache.org/jira/browse/JCRVLT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800429#comment-13800429 ] Felix Meschberger commented on JCRVLT-18: - [~tmueller] I think for package installation, stability is more important than performance. The main drawback of autosave (which is why I really don't like it) is that it is not atomic and may leave partially installed packages behind which are hard to cleanup. I would suggest to remove auto save alltogether and rather instruct users to use smaller packages. Set default autosave threshold based on repository implementation - Key: JCRVLT-18 URL: https://issues.apache.org/jira/browse/JCRVLT-18 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Tobias Bocanegra Priority: Minor with jackrabbit 2.0 we had a limitation of the size of the transient space as it is held in memory. in order to support large packages, the AutoSave threshold is set to 1024 nodes. with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. however, the bigger the transient size, the higher the chance for collisions during installation of large packages, so saving in chunks yields to a more robust installation behavior. suggestions: - autosave threshold of 0 should mean 'auto' - autosave threshold of -1 should mean 'never' - packages can provide their desired autosave threshold via properties -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641519#comment-13641519
]
Felix Meschberger commented on JCR-3534:
Well, this message is an access token.
If that would be the case, this would be bad design. The message data must not
be a general access token.
A key-value list would be nice
This sounds like YAGNI -- I doubt we are going to use it. And if so, we can
still adapt. There is just one place in the code involved which knows how to
talk to itself
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641019#comment-13641019
]
Felix Meschberger commented on JCR-3534:
To simplify development/support, the message should readable, for example
JSON or an URL. Example (shortened)
This sounds like the old mantra in the XML-days: Everything had to be XML, bla,
bla, bla. Please just keep this simple and don't overexagerate. Having a string
of colon separated values (if the value is structured in some way) is more that
enough. Otherwise you incurr the price of parsing JSON ... Not worth it IMHO.
Having expiry and encrypting the identifier would prevent further damage in
case the BinaryReferenceMessage leaks.
What is the problem with this message leaking as opposed to the actual data
leaking which would be transported over the same channel completely unencrypted
? Again, this sounds like over-engineering to me.
We should leave data protection to the transport layer (e.g. SSL) and just care
to make sure that a data reference cannot be made up by an attacker (in the
sense of try to find out whether a document exists).
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634889#comment-13634889
]
Felix Meschberger commented on JCR-3534:
Re. signed message or HMAC
I agree with Jukka: The user id cannot be part of this transaction because
there is no reason to assume that to be the same. Even if the name is the
same the actual entity represented by the name need not be the same. This is
essentially the same issue that NFS is faced with the numeric user and group
IDs.
But: we also need a way to inject that value through some public API such as
the ValueFactory or some other means. Assuming RMI or Davex is not the going
to work because we have two separate systems where the data is extracted
through the JackrabbitValue.getContentIdentifier() (or some new API) method,
serialized in a custom way and then reinjected through some new API (or the
ValueFactory if that can differentiate between a message binary and a real
binary !).
Re. Future Proof
Angela is quite right: It is essential, that whatever mechanism we implement
for Jackrabbit 2 should also be available for Oak.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634905#comment-13634905
]
Felix Meschberger commented on JCR-3534:
Re. ValueFactory#createValue(String, PropertyType.BINARY)
Some thought on this: The implementation must make sure to (a) properly
identify the hashed/signed/whatever value as being an identifier (no false
positives or negatives!) and (b) reject identifiers for which there is no data
store entry.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634974#comment-13634974
]
Felix Meschberger commented on JCR-3534:
createValue(Binary)
If we have a custom Binary implementation, we could also fail early when trying
to create that instance: If the content Id cannot be resolved to a valid entry,
the Binary object cannot be created and thus there is no need to call
createValue(Binary) at all.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13604991#comment-13604991
]
Felix Meschberger commented on JCR-3534:
This does not solve my problems at all: I have two separate systems (separate
JVMs and no clustering but shared data store) involved. So a Binary object
from one system cannot be used on the other system without serializing and
deserializing it.
My proposal uses the data store identity as the serialization mechanism and
uses the new JackrabbitSesssion.getValueByContentIdentity as the
deserialization mechanism.
Another option would be to have such a method on a new JackrabbitValueFactory
class. But since we have a content identifier and want to get at content, we
need some level of access control. So we need that access control in the
JackrabbitValueFactory which would be the only method in the
JackrabbitValueFactory which employs access control to create a value
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605061#comment-13605061
]
Felix Meschberger commented on JCR-3534:
suggested getValueByContentId() method wouldn't work with Oak
So JackrabbitValue.getContentIdentifier will not be supported in Oak, either ?
I'd adjust the deployment configuration if you want to make those
repositories share data more intimately.
How if clustering is not an option ?
Consider for example, I have an author box and a publish box. For various
reasons both share the same Data Store. The straight forward approach to send
binaries from the author box to the publish box would be to extract the binary
from the Data Store on the author box and push it back in to the Data Store on
the publish box, just for the Data Store to realize the binary is actually the
same. On the reading side we can retrieve an identifier
(JackrabbitValue.getContentIdentifier). I just need a way to reuse the binary
data referred to by that content Identifier on the publish side.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605083#comment-13605083
]
Felix Meschberger commented on JCR-3534:
but is the overhead high enough to justify the leak in the abstraction
well, copying lots of 20MB binaries ? instead of lots of 50 character strings ?
Do the math ;-)
The abstraction already leaked with the JackrabbitValue.getContentIdentitiy
method (ok, that would be the broken window ;-) ).
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3534) Add JackrabbitSession.getValueByContentId method
Felix Meschberger created JCR-3534:
--
Summary: Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Reporter: Felix Meschberger
we have a couple of use cases, where we would like to leverage the global data
store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use the
same DataStore (for the sake of this discussion assume we have the problems of
concurrent access and garbage collection under control). When sending content
from one instance to the other instance we don't want to send potentially large
binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether the
such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-3534:
---
Attachment: JCR-3534.patch
Proposed patch adding the new API.
To access the DataStore item by its ID I converted one method from
InternalValue from package private to public since the
InternvalValue.create(DataStore, String) method cannot be used: The
getContentIdentifier method does not return the store prefix required by the
create(DataStore, String) method. Also the create method does not validate the
existence of a data store entry for the provided identifier.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-3534:
---
Component/s: jackrabbit-core
jackrabbit-api
Affects Version/s: 2.6
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3489) enhance get/set Property value access, expanding the supported types set
[
https://issues.apache.org/jira/browse/JCR-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536861#comment-13536861
]
Felix Meschberger commented on JCR-3489:
Speaking of Sling: Our solution based on the Adaptable interface with the
ValueMap is only a secondary benefit of the Resource API we did to abstract the
complex JCR API with checked exceptions into a simpler, easier to use API which
also allows for much simpler and easier extension by other implementations.
I seriously doubt our Sling implementation will be changed to use this new
functionality because our implementation exists and is proven and is embedded
in a larger context (Adaptable with AdapterFactory).
enhance get/set Property value access, expanding the supported types set
Key: JCR-3489
URL: https://issues.apache.org/jira/browse/JCR-3489
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Affects Versions: 2.5.2
Reporter: Simone Tripodi
Priority: Minor
Fix For: 2.6
Attachments: JCR-3489.patch
The idea is having a small EDSL that simplifies the access to {{Property}}
value, so rather than coding the following:
{code}
Property property = ...;
boolean oldValue = property.getBoolean();
boolean newValue = !oldValue;
property.setValue(newValue);
{code}
it could be simplified specifying wich type the users are interested on:
{code}
PropertyAccessors propertiesAccessor = ...;
boolean oldValue = propertiesAccessor.get(property).to(boolean.class);
boolean newValue = !oldValue;
propertiesAccessor.set(newValue).to(property);
{code}
where {{PropertiesAccessor}} is the delegated to handle right types handling.
By default it supports default {{Property}} value types, but it could be
extended.
It could happen also that users would like to support a larger set of types,
maybe performing conversions to/from default {{Property}} types, so rather
than inserting the custom code in the app when required, they could use the
{{PropertiesAccessor}}; they first need to register the Accessor
implementation to (un)bind the type:
{code}
propertiesAccessor.handle(URI.class).with(new PropertyAccessorURI() {
@Override
public void set(URI value, Property target) throws
ValueFormatException, RepositoryException {
// ...
}
@Override
public URI get(Property property) throws ValueFormatException,
RepositoryException {
// TODO ...
return null;
}
});
{code}
so they can use the accessor via the {{PropertiesAccessor}}:
{code}
URI oldValue = propertiesAccessor.get(property).to(URI.class);
URI newValue = URI.create(http://jackrabbit.apache.org/;);
propertiesAccessor.set(newValue).to(property);
{code}
Patch coming soon!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3465) JcrUtils.getOrCreateByPath() creates a whole subtree instead of a single branch
[ https://issues.apache.org/jira/browse/JCR-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506318#comment-13506318 ] Felix Meschberger commented on JCR-3465: +1 to fixing. AFAICT from reading the JavaDoc support for a/b/../../c/d../../e/f is not implied. In fact I even consider this an unexpected side effect. JcrUtils.getOrCreateByPath() creates a whole subtree instead of a single branch --- Key: JCR-3465 URL: https://issues.apache.org/jira/browse/JCR-3465 Project: Jackrabbit Content Repository Issue Type: Bug Reporter: Michael Dürig Priority: Minor Given a leaf node n, JcrUtils.getOrCreateByPath(n, a/b/../../c/d/../../e/f, false, null, null, true); will result in paths a/b, c/d and e/f being added to n where I'd only expect the path e/f. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-245) Add import for org.h2 in oak-mk bundle
[
https://issues.apache.org/jira/browse/OAK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435797#comment-13435797
]
Felix Meschberger commented on OAK-245:
---
I don't consider this a bug. Let's say it doesn't work well with OSGi.
Ok, lets land in on doesn't cope well with dynamic module systems. See also
http://blog.meschberger.ch/2010/12/classforname-probably-not.html and BJ
Hargrave's findings on this.
Add import for org.h2 in oak-mk bundle
--
Key: OAK-245
URL: https://issues.apache.org/jira/browse/OAK-245
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Chetan Mehrotra
Labels: osgi
Attachments: import-h2.patch, OAK-245-load-driver.patch
The oak-mk bundle depends on H2 database. It internally uses
Class.forName('org.h2.Driver) to load the H2 driver. Due to usage of
Class.forName Bnd is not able to add org.h2 package to Import-Package list.
So it should have an explicit entry in the maven-bundle-plugin config as
shown below
{code:xml}
Import-Package
org.h2;resolution:=optional,
*
/Import-Package
{code}
Without this MicroKernalService loading would fail with a CNFE
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-245) Add import for org.h2 in oak-mk bundle
[
https://issues.apache.org/jira/browse/OAK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435106#comment-13435106
]
Felix Meschberger commented on OAK-245:
---
bq. Class.forName('org.h2.Driver)
Does it do forName without a class loader ? This would constitute a bug in
itself.
Add import for org.h2 in oak-mk bundle
--
Key: OAK-245
URL: https://issues.apache.org/jira/browse/OAK-245
Project: Jackrabbit Oak
Issue Type: Bug
Components: mk
Reporter: Chetan Mehrotra
Labels: osgi
Attachments: import-h2.patch
The oak-mk bundle depends on H2 database. It internally uses
Class.forName('org.h2.Driver) to load the H2 driver. Due to usage of
Class.forName Bnd is not able to add org.h2 package to Import-Package list.
So it should have an explicit entry in the maven-bundle-plugin config as
shown below
{code:xml}
Import-Package
org.h2;resolution:=optional,
*
/Import-Package
{code}
Without this MicroKernalService loading would fail with a CNFE
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-225) Sling I18N queries not supported by Oak
[
https://issues.apache.org/jira/browse/OAK-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13431687#comment-13431687
]
Felix Meschberger commented on OAK-225:
---
bq. it would be relatively easy to change the query in Sling
You are of course welcome to raise an issue in Sling proposing a different
Query, which (a) requires no to minial code changes and (b) works on both
Jackrabit 2 and Oak. Thanks ;-)
Sling I18N queries not supported by Oak
---
Key: OAK-225
URL: https://issues.apache.org/jira/browse/OAK-225
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 0.3
Reporter: Jukka Zitting
Priority: Minor
Labels: sling, xpath
The Sling I18N component issues XPath queries like the following:
{code:none}
//element(*,mix:language)[fn:lower-case(@jcr:language)='en']//element(*,sling:Message)[@sling:message]/(@sling:key|@sling:message)
{code}
Such queries currently fail with the following exception:
{code:none}
javax.jcr.query.InvalidQueryException: java.text.ParseException: Query:
//element(*,mix:language)[fn:lower-(*)case(@jcr:language)='en']//element(*,sling:Message)[@sling:message]/(@sling:key|@sling:message);
expected: (
at
org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:115)
at
org.apache.jackrabbit.oak.jcr.query.QueryImpl.execute(QueryImpl.java:85)
at
org.apache.sling.jcr.resource.JcrResourceUtil.query(JcrResourceUtil.java:52)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.queryResources(JcrResourceProvider.java:262)
... 54 more
Caused by: java.text.ParseException: Query:
//element(*,mix:language)[fn:lower-(*)case(@jcr:language)='en']//element(*,sling:Message)[@sling:message]/(@sling:key|@sling:message);
expected: (
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.getSyntaxError(XPathToSQL2Converter.java:704)
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.read(XPathToSQL2Converter.java:410)
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.parseExpression(XPathToSQL2Converter.java:336)
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.parseCondition(XPathToSQL2Converter.java:279)
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.parseAnd(XPathToSQL2Converter.java:252)
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.parseConstraint(XPathToSQL2Converter.java:244)
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.convert(XPathToSQL2Converter.java:153)
at
org.apache.jackrabbit.oak.query.QueryEngineImpl.parseQuery(QueryEngineImpl.java:86)
at
org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:99)
at
org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:39)
at
org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:110)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3350) Easy-to-use utility class for adding ACEs to nodes
[ https://issues.apache.org/jira/browse/JCR-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403828#comment-13403828 ] Felix Meschberger commented on JCR-3350: Some comments: * I would wrap the RepositoryException inside a generic RuntimeException. This makes handling unduly hard and inside a Jackrabbit class, it is probably appropriate to have RepositoryExceptions thrown. But those should be documented * Is it required to check for the existence of the item first ? In other words, would setting the ACL fail if the item would not exist ? What if the item is a property ? * I would get rid of the autoSave flag and just document this method does not save or rollback at all. Easy-to-use utility class for adding ACEs to nodes -- Key: JCR-3350 URL: https://issues.apache.org/jira/browse/JCR-3350 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Reporter: Jeff Young Assignee: angela Labels: newbie, patch Attachments: AccessControlUtils.java, JCR-3350_-_Easy-to-use_utility_class_for_adding_ACEs_to_nodes.patch There should be any easy (one-line) method for adding an ACE to a node in a repo supporting resource-based ACLs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-153) Split the CommitHook interface
[
https://issues.apache.org/jira/browse/OAK-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402151#comment-13402151
]
Felix Meschberger commented on OAK-153:
---
.bq The lifecycle of such hooks is up to the deployment
Ok, this essentially means the split prevents bracketing. Maybe this should
just be documented.
Split the CommitHook interface
--
Key: OAK-153
URL: https://issues.apache.org/jira/browse/OAK-153
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Jukka Zitting
Assignee: Jukka Zitting
The {{CommitHook}} interface has two methods, {{beforeCommit()}} and
{{afterCommit()}}, since the symmetry originally seemed like a good idea.
However, in practice these methods are not really so symmetric after all.
For example, unlike {{afterCommit()}} the {{beforeCommit()}} method may end
up being called multiple times for a given changeset if it needs to be
repeatedly rebased or otherwise revised before it can be committed. There
isn't even any guarantee that a particular changeset on which
{{beforeCommit()}} has been called ever gets committed. And on the other hand
there are good reasons to avoid calling {{afterCommit()}} on each and every
commit that has been made. Instead it could be called only every now and then
to cover larger sets of changes.
Thus I'd like to split the {{CommitHook}} interface to two parts that I'd
tentatively call {{CommitEditor}} and {{Observer}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-153) Split the CommitHook interface
[
https://issues.apache.org/jira/browse/OAK-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401406#comment-13401406
]
Felix Meschberger commented on OAK-153:
---
What is the intended lifecycle of these hooks ? Created on call or created on
Repository/Oak/MK start ? What if a class implements both interfaces ?
Background: I could imagine an implementation where beforeCommit and
afterCommit cooperate in that the final afterCommit might be interested in
stuff done for beforeCommit. Depending on how the classes are instantiated this
might be simple or not.
Split the CommitHook interface
--
Key: OAK-153
URL: https://issues.apache.org/jira/browse/OAK-153
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Jukka Zitting
Assignee: Jukka Zitting
The {{CommitHook}} interface has two methods, {{beforeCommit()}} and
{{afterCommit()}}, since the symmetry originally seemed like a good idea.
However, in practice these methods are not really so symmetric after all.
For example, unlike {{afterCommit()}} the {{beforeCommit()}} method may end
up being called multiple times for a given changeset if it needs to be
repeatedly rebased or otherwise revised before it can be committed. There
isn't even any guarantee that a particular changeset on which
{{beforeCommit()}} has been called ever gets committed. And on the other hand
there are good reasons to avoid calling {{afterCommit()}} on each and every
commit that has been made. Instead it could be called only every now and then
to cover larger sets of changes.
Thus I'd like to split the {{CommitHook}} interface to two parts that I'd
tentatively call {{CommitEditor}} and {{Observer}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-67) Initial OSGi Bundle Setup
[ https://issues.apache.org/jira/browse/OAK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260289#comment-13260289 ] Felix Meschberger commented on OAK-67: -- I am ok with just exportin .api. But what about .util ? I would really find it easily informative to have packages intended for internal use only clearly marked with a kind-of-tag in the package. For example o.a.j.mk.util may be seen as internal or external ... but o.a.j.mk.internal.util will never be mistaken to be external. Initial OSGi Bundle Setup - Key: OAK-67 URL: https://issues.apache.org/jira/browse/OAK-67 Project: Jackrabbit Oak Issue Type: Improvement Components: core Affects Versions: 0.1 Reporter: Felix Meschberger Fix For: 0.2 Attachments: OAK-67.patch Since the plan for the 0.2 release intents to add initial OSGi budling functionality, we need to track this addition. Will come up with a patch and change proposal for such bundling. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-2919) Security of token base authentication
[ https://issues.apache.org/jira/browse/JCR-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13113396#comment-13113396 ] Felix Meschberger commented on JCR-2919: System.getProperty(NodeIdFactory.SEQUENTIAL_NODE_ID) Are you kidding ? Are we really configuring this through system properties ? Security of token base authentication - Key: JCR-2919 URL: https://issues.apache.org/jira/browse/JCR-2919 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core, security Affects Versions: 2.3.0 Reporter: Michael Dürig Assignee: angela Fix For: 2.3.0 Token based authentication as implemented with JCR-2851 seems to exhibit a security issue: the token returned by the server consists of the identifier of a (newly created) node in the repository. An attacker who is able to guess (or acquire by other means i.e. via log files) that identifier will be granted access to the repository. Worse yet, JCR-2857 introduces sequential node ids. Guessing is a piece of cake in such a setup. I think we should decouple authentication secrets from node ids. A simple solution would be to store the secret in a token attribute and delegate generation of the secret to a dedicated handler. Such a handler can then use a secure random generator, private/public key encryption or whatever other method that is deemed appropriate to generate the authentication secret. Initial discussion see: http://markmail.org/thread/aspetgvmj2qud25a -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004463#comment-13004463 ] Felix Meschberger commented on JCR-2910: So please add a new issue: remove User.isAdmin(). +1 The isAdmin method makes no sense: What is the semantics a user being admin anyway ? Sounds like some wrong (or old outdated) solution which can now be better handled with real access control and user management. Personally, I believe isAdmin() is a good concept, because it's simple and easy to understand. There is a good reason why all operating systems support it. That's not really true. Core Unix, which is a methusalem in computer counting, has the concept of the single root user and many things check for uid==0. But over time better systems have been developed and nowadays unix also sports a privilege system which allows assigning rights for regular system administration tasks to regular users. Ok internally it still reverts to using root (probably) but this is an implementation detail. This is why I don't like the isAdmin() method, neither on the [Jackrbabbit]Session nor on the User. Rather start defining real-world usable permissions, which is nowadays possible and can be used. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003902#comment-13003902 ] Felix Meschberger commented on JCR-2910: I am not sure about such a method. This sounds like a utility method making it into the API which smells wrong. Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003926#comment-13003926 ] Felix Meschberger commented on JCR-2910: What about JackrabbitSession.getUser()? Perfect. In addition this is orthogonal to Session.getUserID() Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2911) Fine-grained access control for managing node types
[ https://issues.apache.org/jira/browse/JCR-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004396#comment-13004396 ] Felix Meschberger commented on JCR-2911: Shouldn't node type definition authorization be defined by access control on the node type definition storage (/jcr:system/jcr:nodeTypes) ? Fine-grained access control for managing node types --- Key: JCR-2911 URL: https://issues.apache.org/jira/browse/JCR-2911 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core, nodetype Affects Versions: 2.2.4, 2.3.0 Reporter: Omid Milani Priority: Minor Labels: accessManager, nodetype, security Fix For: 2.3.0 Attachments: accessManager_nodeTypes.patch Original Estimate: 5m Remaining Estimate: 5m Extend AccessManager interface to include authorization for register/unregister of node types so it can be defined that a certain user can define and modify some node types but not the others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2809) Lock expires almost immediately
[
https://issues.apache.org/jira/browse/JCR-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930956#action_12930956
]
Felix Meschberger commented on JCR-2809:
And why not keep the timeout as ms internally to prevent the repeated
multiplication by 1000 ?
Lock expires almost immediately
---
Key: JCR-2809
URL: https://issues.apache.org/jira/browse/JCR-2809
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: locks
Affects Versions: 2.1.2
Reporter: Dominique Pfister
When a timeoutHint other than Long.MAX_VALUE is given to the
javax.jcr.lock.LockManager API:
lock(String absPath, boolean isDeep, boolean isSessionScoped, long
timeoutHint, String ownerInfo)
a timeoutTime in seconds will be computed as follows
(o.a.j.core.lock.LockInfo#updateTimeoutTime):
long now = (System.currentTimeMillis() + 999) / 1000; // round up
this.timeoutTime = now + timeoutHint;
the TimeoutHandler in o.a.j.core.lock.LockManagerImpl running every second
will then check whether the timeout has expired
(o.a.j.core.lock.LockInfo#isExpired):
public boolean isExpired() {
return timeoutTime != Long.MAX_VALUE
timeoutTime * 1000 System.currentTimeMillis();
}
Obviously, the latter condition is true from the very beginning. Replacing
'' with '' or '=' should do the trick.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2802) Deprecate all non-bundle persistence managers
[ https://issues.apache.org/jira/browse/JCR-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12928029#action_12928029 ] Felix Meschberger commented on JCR-2802: +1 Deprecate all non-bundle persistence managers - Key: JCR-2802 URL: https://issues.apache.org/jira/browse/JCR-2802 Project: Jackrabbit Content Repository Issue Type: Improvement Components: config, jackrabbit-core Reporter: Jukka Zitting Fix For: 2.2.0 Bundle persistence has been the recommended default since Jackrabbit 1.3, and there is little reason for anyone to be using non-bundle persistence anymore. Thus I'd like to deprecate all non-bundle PMs in Jackrabbit 2.2 and target for their removal in Jackrabbit 3.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2754) jcr:nodeTypeManagement necessary for addNode(name, type)?
[ https://issues.apache.org/jira/browse/JCR-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12913961#action_12913961 ] Felix Meschberger commented on JCR-2754: Here is some salt to my argument that Node.addNode(String, String) does _not_ change the primary node type of a node: The two-argument addNode method is defined to be the same as the single-argument addNode with the additional explicit specification of the primary node type of the node to be created. This is not really a change in the type but an initial setting. jcr:nodeTypeManagement necessary for addNode(name, type)? - Key: JCR-2754 URL: https://issues.apache.org/jira/browse/JCR-2754 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core, security Affects Versions: 2.0.0, 2.1.0, 2.1.1 Reporter: Jukka Zitting Priority: Minor Our current implementation of addNode(name, type) requires the jcr:nodeTypeManagement permission, that's defined by JSR 283 as the privilege to add and remove mixin node types and change the primary node type of a node. In a private discussion this implementation was questioned, based on the argument that the spec seems to only refer to changing the primary type, not specifying it during creation. Personally I don't care too much either way, and since the only harm done by the current implementation seems to be some confusion, I'd rather not change the implementation to prevent backwards compatibility issues. Anyway, I'm filing this issue to solicit feedback from the community. If the consensus is that addNode(name, type) shouldn't need the jcr:nodeTypeManagement permission, then we should clarify the spec in JSR 333 and make this change in Jackrabbit 3.0. Otherwise we'll just resolve this issue as Won't Fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2692) Split jcr-commons in two
[ https://issues.apache.org/jira/browse/JCR-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12894848#action_12894848 ] Felix Meschberger commented on JCR-2692: +1 to splitting +1 to moving the tests out of jackrabbit-core (of course ;-) ) I would suggest to rethink the naming, though. How about jcr-util for the developper/user oriented part jcr-core-supportfor the part used by jackrabbit-core (and presumably others implementing JCR API) Split jcr-commons in two - Key: JCR-2692 URL: https://issues.apache.org/jira/browse/JCR-2692 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Affects Versions: 2.2.0 Reporter: Michael Dürig As discussed in JCR-2688, the jcr commons module should be split: * jcr-impl-commons - utility classes/interfaces for help *implementing* JCR * jcr-api-commons - utility classes/interfaces for help *using* JCR The rational is that it contains utility classes for jackrabbit-core on one hand and utility classes for JCR API consumers on the other hand. Currently there is no clean way to add unit tests for JCR API utility classes since this would introduce a circular dependency on jackrabbit-core. Such unit tests currently live in the jackrabbit-core module in the o.a.j.core.integration package. Along with the split these tests should be considered to be moved to the jcr-api-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2688) Provide utility for handling large number of child nodes/properties
[ https://issues.apache.org/jira/browse/JCR-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12894054#action_12894054 ] Felix Meschberger commented on JCR-2688: (6) would probably be best and also solve the mistakes others have done by going (3), (1) the second best and everything else is just not a good idea ;-) BTW IMHO the excuse 'I don't like it since we have enough modules already' is just FUD. The problem is not the number of modules. The problem really is the unclear separation between modules. What you do with (2) or (3) is add to this incertainty. So please, don't go the (2) or (3) route (what others have done already IMHO is equally wrong and should probably be fixed). Provide utility for handling large number of child nodes/properties --- Key: JCR-2688 URL: https://issues.apache.org/jira/browse/JCR-2688 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Affects Versions: 2.2.0 Reporter: Michael Dürig Assignee: Michael Dürig Attachments: JCR-2688.patch Jackrabbit does not cope well with 'flat' hierarchies. That is with hierarchies where a node has many child nodes and/or properties. The current recommendation for such situations is to manually add intermediate nodes. It would be nice to have an utility which adds/removes intermediate nodes as needed and expose a 'flat' view to users. Such an utility should: - expose a large number of nodes/properties as sequence - parametrize the order of how nodes/properties appear in the sequence - provide methods to lookup/add/remove nodes/properties by key - organize the node/properties in the underlying JCR hierarchy in a way which is both efficient for above operations and easily understandable to users looking at the hierarchy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2640) Internal repository context
[ https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873578#action_12873578 ] Felix Meschberger commented on JCR-2640: About public methods: having *every* method public is not a good idea of course Sure, having each method public is just as bad has designing by the priniciple of preventing public mehtods at all cost ;-) Method qualifier must be driven by the architecture and this may result in public, protected, private or package private methods. My approach is to always use the most restrictive qualifier in the first place and only make a method protected or public if really required. I believe that nobody is too adversely affected by the extra RepositoryContext It will certainly not make the code less complex; but we have reached a complexitiy level, where this increment in complexity is almost neglectible ;-) Internal repository context --- Key: JCR-2640 URL: https://issues.apache.org/jira/browse/JCR-2640 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: repository-context-v1.patch, repository-context.png As discussed in JCR-890, the current approach of using protected or package-private getters on key classes like RepositoryImpl to access other internal components and resources is a bit troublesome. The attached patch (repository-context-v1.patch) introduces a RepositoryContext object that can be used to get rid of such getters. This first version replaces the getNamespaceRegistry(), getNodeTypeRegistry(), getVersionManager() and getRootNodeId() methods from RepositoryImpl. The idea behind this component context idea is to separate the JCR API implementation classes from the task of keeping track of the internal implementation components. This way none of the instances returned by JCR API methods would have methods through which Jackrabbit internals can be directly accessed. See the attached UML diagram for how this layered access would work. Assuming people think this is a good idea, I'd like to extend this mechanism to cover also the rest of the internal Repository components like the data store and the security managers, etc. I'm also thinking about using a similar context objects for tracking internal components associated with workspaces (WorkspaceInfo, SharedItemStateManager, etc.) and sessions (LocalItemStateManager, etc.). PS. Yes, we'd get much of the same functionality (and more) from OSGi or an IoC container. For now I'm hoping to keep things simple without extra external dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2640) Internal repository context
[ https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12872216#action_12872216 ] Felix Meschberger commented on JCR-2640: The point is to avoid public getters of internal components in RepositoryImpl. I think this is not enough of an argument. If we go modularized and we have properly exported API and poperly shielded implementation classes (as is possible e.g. with OSGi Export-Package specs) we don't have to worry about public methods of implementation classes which are used by the public by means of API. The only way for the user to access such publich methods is by using Reflection... But by using Reflection you can do anything you want, and non-public methods are not protected from being used at all. Thus I agree with Tobias, that defining an interface is sufficient. I also agree with Thomas, that trying to prevent publich methods to help modularize stuff is completely wrong and makes things way too complex and in the end probably prevents proper modularization. Increased modularity comes with increased complexity. Unneeded complexity will make our lives harder, not easier. I'm afraid we bloat the code unnecessarily. To a certain extent yes. But modularization is about separation of concerns, is about hiding implementation from the users. If we don't go that route, we can just as well keep the *Impl casts ;-) Internal repository context --- Key: JCR-2640 URL: https://issues.apache.org/jira/browse/JCR-2640 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: repository-context-v1.patch, repository-context.png As discussed in JCR-890, the current approach of using protected or package-private getters on key classes like RepositoryImpl to access other internal components and resources is a bit troublesome. The attached patch (repository-context-v1.patch) introduces a RepositoryContext object that can be used to get rid of such getters. This first version replaces the getNamespaceRegistry(), getNodeTypeRegistry(), getVersionManager() and getRootNodeId() methods from RepositoryImpl. The idea behind this component context idea is to separate the JCR API implementation classes from the task of keeping track of the internal implementation components. This way none of the instances returned by JCR API methods would have methods through which Jackrabbit internals can be directly accessed. See the attached UML diagram for how this layered access would work. Assuming people think this is a good idea, I'd like to extend this mechanism to cover also the rest of the internal Repository components like the data store and the security managers, etc. I'm also thinking about using a similar context objects for tracking internal components associated with workspaces (WorkspaceInfo, SharedItemStateManager, etc.) and sessions (LocalItemStateManager, etc.). PS. Yes, we'd get much of the same functionality (and more) from OSGi or an IoC container. For now I'm hoping to keep things simple without extra external dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2640) Internal repository context
[ https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12871151#action_12871151 ] Felix Meschberger commented on JCR-2640: I do not understand the problem either ? To me the problem is rather mixture of internal API with implementation in the same package, which should be solved. I have no issue with an implementation object calling and using another implementation object. What functionality can be solved by OSGi and IoC in this context ? Internal repository context --- Key: JCR-2640 URL: https://issues.apache.org/jira/browse/JCR-2640 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: repository-context-v1.patch, repository-context.png As discussed in JCR-890, the current approach of using protected or package-private getters on key classes like RepositoryImpl to access other internal components and resources is a bit troublesome. The attached patch (repository-context-v1.patch) introduces a RepositoryContext object that can be used to get rid of such getters. This first version replaces the getNamespaceRegistry(), getNodeTypeRegistry(), getVersionManager() and getRootNodeId() methods from RepositoryImpl. The idea behind this component context idea is to separate the JCR API implementation classes from the task of keeping track of the internal implementation components. This way none of the instances returned by JCR API methods would have methods through which Jackrabbit internals can be directly accessed. See the attached UML diagram for how this layered access would work. Assuming people think this is a good idea, I'd like to extend this mechanism to cover also the rest of the internal Repository components like the data store and the security managers, etc. I'm also thinking about using a similar context objects for tracking internal components associated with workspaces (WorkspaceInfo, SharedItemStateManager, etc.) and sessions (LocalItemStateManager, etc.). PS. Yes, we'd get much of the same functionality (and more) from OSGi or an IoC container. For now I'm hoping to keep things simple without extra external dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRRMI-27) JSR-283: Support AccessControlManager
[ https://issues.apache.org/jira/browse/JCRRMI-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847375#action_12847375 ] Felix Meschberger commented on JCRRMI-27: - Implemented remote AccessControlManager along with AccessControlList, AccessControlPolicy, AccessControlEntry, Privilege, Principal, and Group support. Some methods are not implemented, mostly methods to update access control. Privilege equals and hashCode methods are implemented based on the Privilege name (getting the name is the only round-trip to the server here). Committed in Rev. 925218 This current implementation passes almost all ConformanceTests run during the build. The failing tests all involve unimplemented access control update methods. Failing test record: Running org.apache.jackrabbit.rmi.ConformanceTest Tests run: 1895, Failures: 0, Errors: 21, Skipped: 0, Time elapsed: 93.757 sec FAILURE! Results : Tests in error: testSetIllegalPolicy(org.apache.jackrabbit.test.api.security.AccessControlPolicyTest) testGetAccessControlEntries(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntry(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAggregatePrivilege(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAggregatedPrivilegesSeparately(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAbstractPrivilege(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddPrivilegesPresentInEntries(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryAndSetPolicy(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryIsTransient(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryInvalidPrincipal(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryEmptyPrivilegeArray(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryInvalidPrivilege(org.apache.jackrabbit.test.api.security.AccessControlListTest) testRemoveAccessControlEntry(org.apache.jackrabbit.test.api.security.AccessControlListTest) testRemoveAddedAccessControlEntry(org.apache.jackrabbit.test.api.security.AccessControlListTest) testRemoveAccessControlEntryAndSetPolicy(org.apache.jackrabbit.test.api.security.AccessControlListTest) testRemoveAccessControlEntryIsTransient(org.apache.jackrabbit.test.api.security.AccessControlListTest) testRemoveIllegalAccessControlEntry(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryTwice(org.apache.jackrabbit.test.api.security.AccessControlListTest) testAddAccessControlEntryAgain(org.apache.jackrabbit.test.api.security.AccessControlListTest) testExtendPrivileges(org.apache.jackrabbit.test.api.security.AccessControlListTest) testSetInvalidPolicy(org.apache.jackrabbit.test.api.security.RSessionAccessControlPolicyTest) Tests run: 1895, Failures: 0, Errors: 21, Skipped: 0 JSR-283: Support AccessControlManager - Key: JCRRMI-27 URL: https://issues.apache.org/jira/browse/JCRRMI-27 Project: Jackrabbit JCR-RMI Issue Type: Sub-task Reporter: Felix Meschberger Assignee: Felix Meschberger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRRMI-27) JSR-283: Support AccessControlManager
[ https://issues.apache.org/jira/browse/JCRRMI-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847380#action_12847380 ] Felix Meschberger commented on JCRRMI-27: - Listing the known test failures in the POM (Rev. 925223) allows for the build to succeed without errors. JSR-283: Support AccessControlManager - Key: JCRRMI-27 URL: https://issues.apache.org/jira/browse/JCRRMI-27 Project: Jackrabbit JCR-RMI Issue Type: Sub-task Reporter: Felix Meschberger Assignee: Felix Meschberger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2450) UserManager inconsistency
[ https://issues.apache.org/jira/browse/JCR-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844007#action_12844007 ] Felix Meschberger commented on JCR-2450: I just stumbled upon a strange thing in the UserManager API: This has a method autosave(boolean) which can be used to ensure changes to the User/Group base through the UserManager API are persisted. If autosave is false (check UserManager.isAutoSave()), the session producing the UserManager must be saved -- Session.save() -- to persist any changes. Could it be that your application misses persisting the changes ? UserManager inconsistency - Key: JCR-2450 URL: https://issues.apache.org/jira/browse/JCR-2450 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core, security Affects Versions: 1.6.0, 2.0-beta4 Environment: Ubuntu 9.04 64bit, Tomcat 6.0.20, Jackrabbit 1.6 and 2.0-beta4 Reporter: Michael Stämpfli Priority: Blocker Attachments: jackrabbit-test.zip I used the default class UserManagerImpl to add a user to my jackrabbit (1.6) environment. My application can successfully login to the repository with this user. As soon as I restart Tomcat, the login fails. I did some research and found out why. Obviously the user manager cannot find the user, I registered previously, anymore. Using WebDAV I made a connection to the security workspace. When I create a new user, a new node for this user is created in /jcr:root/rep:security/rep:authorizables/rep:users/admin. As soon as I restart Tomcat and login to the security workspace again (using WebDAV), I see that the user node moved to the root node. As a consequence the user cannot login to the repository because the user manager cannot find the user node anymore. In jackrabbit 2.0-beta4 I get a similar bug and I assume, that the root cause is the same as above. I log into the repository using the administrator account, which is created automatically with the class UserManagerImpl. When I restart Tomcat and try to login to the repository I get the error: javax.jcr.ItemNotFoundException: failed to build path of 55411ff4-d6c7-410a-a16e-5531e1c7afae: cafebabe-cafe-babe-cafe-babecafebabe has no child entry for 55411ff4-d6c7-410a-a16e-5531e1c7afae -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2563) Add UserManager.createGroup(String groupID) method
Add UserManager.createGroup(String groupID) method
--
Key: JCR-2563
URL: https://issues.apache.org/jira/browse/JCR-2563
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.0.0
Reporter: Felix Meschberger
As discussed on the dev list [1] I think it would be useful (and consistent
inside the API) to have a UserManager.createGroup(String groupID) method.
The specification of the method would be:
/**
* Creates a Group for the given groupID must not be codenull/code.
* br
* Same as {...@link #createGroup(Principal,String)} where the specified
groupID
* is the name of a simple codePrincipal/code implementation and the
* intermediate path is codenull/code.
*
* @param groupID The id of the new group, must not be codenull/code.
* @return The new codeGroup/code.
* @throws AuthorizableExistsException in case the given groupID is already
* in use or another {...@link Authorizable} with the same
* {...@link Authorizable#getID() ID} exists.
* @throws RepositoryException If another error occurs.
*/
Group createGroup(String groupID) throws AuthorizableExistsException,
RepositoryException;
[1] http://markmail.org/message/rjofzg4t3kiht7xv
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2563) Add UserManager.createGroup(String groupID) method
[
https://issues.apache.org/jira/browse/JCR-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated JCR-2563:
---
Attachment: JCR-2563.patch
Patch providing the the createGroup(String) method:
* UserManager API extension
* UserManagerImpl implementation in jackrabbit-core
* Unit-Tests ensuring proper work
- ensure group with exact ID is created
- ensure groupd cannot be created (with expected Exception) if a User or
Group with that ID already exists
Add UserManager.createGroup(String groupID) method
--
Key: JCR-2563
URL: https://issues.apache.org/jira/browse/JCR-2563
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.0.0
Reporter: Felix Meschberger
Attachments: JCR-2563.patch
As discussed on the dev list [1] I think it would be useful (and consistent
inside the API) to have a UserManager.createGroup(String groupID) method.
The specification of the method would be:
/**
* Creates a Group for the given groupID must not be codenull/code.
* br
* Same as {...@link #createGroup(Principal,String)} where the specified
groupID
* is the name of a simple codePrincipal/code implementation and the
* intermediate path is codenull/code.
*
* @param groupID The id of the new group, must not be codenull/code.
* @return The new codeGroup/code.
* @throws AuthorizableExistsException in case the given groupID is
already
* in use or another {...@link Authorizable} with the same
* {...@link Authorizable#getID() ID} exists.
* @throws RepositoryException If another error occurs.
*/
Group createGroup(String groupID) throws AuthorizableExistsException,
RepositoryException;
[1] http://markmail.org/message/rjofzg4t3kiht7xv
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2482) Reduce number of compiler warning by adding @Override and generics where appropriate
[ https://issues.apache.org/jira/browse/JCR-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828985#action_12828985 ] Felix Meschberger commented on JCR-2482: There is probably more to it, than just some syntax. For the @Override it helps the compiler ensure correct extension. It is much simpler fixing issues occurring at compile time than to write tests and try to find issues at test/run time. Second it helps identifying overwritten methods when looking at the source without an IDE, e.g. by just skimming SVN with a browser. For final: It serves AFAICT two purposes. One it helps preventing overwriting values inadvertedly, thus going into the find bugs at compile time category as the @Override annotation. The other use it might help compilers and vms optimizie the variable (though this may be of less importance nowadays with advanced compilers and modern VMs). So, I think it is a good thing to have them. Reduce number of compiler warning by adding @Override and generics where appropriate - Key: JCR-2482 URL: https://issues.apache.org/jira/browse/JCR-2482 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr2spi Affects Versions: 2.1.0 Reporter: Michael Dürig Assignee: Michael Dürig Fix For: 2.1.0 Add @Override and generics where possible to reduce the number of warnings issued by the compiler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2362) Drop the jackrabbit-jcr-client component
[ https://issues.apache.org/jira/browse/JCR-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799147#action_12799147 ] Felix Meschberger commented on JCR-2362: Providing a simple single client JAR might be helpful to the uninitiated. But this should only contain a single method of accessing a remote repository. Nothing fancy, but something to get started quickly. Of course, this jar file can be an OSGi bundle probably not exporting anything- yet registering a service to access the repository. For more customized setups and multiple access protocols, we should really leave it to the downstream developers. But, I would discourage any classloader hacking stuff or some multi-mechanism, big, fat JAR approach. Drop the jackrabbit-jcr-client component Key: JCR-2362 URL: https://issues.apache.org/jira/browse/JCR-2362 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-client Reporter: Jukka Zitting The new GenericRepositoryFactory class and JcrUtils.getRepository methods introduced in JCR-2360 implement an improved version of the jackrabbit-jcr-client functionality. Thus I propose that we drop the jackrabbit-jcr-client component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2439) More utility methods in JcrUtils
[ https://issues.apache.org/jira/browse/JCR-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790702#action_12790702 ] Felix Meschberger commented on JCR-2439: String toString(Item item) Couldn't we just implement NodeImpl.toString and PropertyImpl.toString ? addXXX looks reasonable setXXX sounds useful, but I the set prefix sounds a bit strange yet my alternative -- getOrAddXXX -- is probably not better ... More utility methods in JcrUtils Key: JCR-2439 URL: https://issues.apache.org/jira/browse/JCR-2439 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Reporter: Jukka Zitting Priority: Minor I'd like to add at least the following utility methods to JcrUtils: For logging: // Utility method to simplify log messages and debug prints: // Node - name [type] // Property - @name = value(s) String toString(Item item) For making sure that a node exists: // Returns the identified child node. If the child does not already exist, // it is added using the default node type from the parent. Node setNode(Node parent, String name) // Same as above, but ensures that isNodeType(type) is true for the // returned node, using addNode(name, type) or setPrimaryType(type) // if needed. Node setNode(Node parent, String name, String type) For adding (or setting, see above) nt:folder nodes: // Adds a new nt:folder node with the given name Node addFolder(Node parent, String name) // Ensures that an nt:folder node with the given name exists Node setFolder(Node parent, String name) For adding (or setting) nt:file nodes: // Adds a new nt:file/nt:resource structure // If the mime type contains a charset parameter, then the jcr:encoding property is also set Node addFile(Node parent, String name, String mime, InputStream data) Node addFile(Node parent, String name, String mime, Calendar date, InputStream data) // Ensures that an nt:file/nt:resource structure exists with the given data. // Note that the type of a potential existing jcr:content node is not modified Node setFile(Node parent, String name, String mime, InputStream data) Node setFile(Node parent, String name, String mime, Calendar date, InputStream data) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2412) JackrabbitRepositoryStub in jackrabbit-core library class contains o.a.j.test reference
JackrabbitRepositoryStub in jackrabbit-core library class contains o.a.j.test reference --- Key: JCR-2412 URL: https://issues.apache.org/jira/browse/JCR-2412 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.0-beta3 Reporter: Felix Meschberger The JackrabbitRepositoryStub added as part of JCR-2055 contains a reference to the org.apache.jackrabbit.test package. This is IMHO a very bad dependency for a production library and should be removed. (I stumbled upon it while trying to create an OSGi bundle for an embedded Jackrabbit Repository based on 2.0-beta3, so I can work around this. Nevertheless, it is IMHO bad practice and not a very good idea) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2412) JackrabbitRepositoryStub in jackrabbit-core library class contains o.a.j.test reference
[ https://issues.apache.org/jira/browse/JCR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12783072#action_12783072 ] Felix Meschberger commented on JCR-2412: When defining the bundle, I get an Import-Package statement for this package - as I said, I can work around this. The problem is, that the JackrabbitRepositoryStub class uses three classes form the test package and from the POV of OSGi, this constitutes an required dependency to said package. Of course I can exclude the import of that package assuming this class will never be used in a production system. But then: why including it in a production library in the first place ? JackrabbitRepositoryStub in jackrabbit-core library class contains o.a.j.test reference --- Key: JCR-2412 URL: https://issues.apache.org/jira/browse/JCR-2412 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.0-beta3 Reporter: Felix Meschberger The JackrabbitRepositoryStub added as part of JCR-2055 contains a reference to the org.apache.jackrabbit.test package. This is IMHO a very bad dependency for a production library and should be removed. (I stumbled upon it while trying to create an OSGi bundle for an embedded Jackrabbit Repository based on 2.0-beta3, so I can work around this. Nevertheless, it is IMHO bad practice and not a very good idea) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2412) JackrabbitRepositoryStub in jackrabbit-core library class contains o.a.j.test reference
[ https://issues.apache.org/jira/browse/JCR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved JCR-2412. Resolution: Won't Fix I read the explanation. Still I think test dependencies have absolutely no place in a production library whatsoever and however optional the dependency may be. But since I seem to be biting on granite and the workaround I did (which is actually preventing the import being generated for the package) does work I will close this issue. JackrabbitRepositoryStub in jackrabbit-core library class contains o.a.j.test reference --- Key: JCR-2412 URL: https://issues.apache.org/jira/browse/JCR-2412 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.0-beta3 Reporter: Felix Meschberger The JackrabbitRepositoryStub added as part of JCR-2055 contains a reference to the org.apache.jackrabbit.test package. This is IMHO a very bad dependency for a production library and should be removed. (I stumbled upon it while trying to create an OSGi bundle for an embedded Jackrabbit Repository based on 2.0-beta3, so I can work around this. Nevertheless, it is IMHO bad practice and not a very good idea) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2360) JcrUtils.getRepository(...) for simple repository access
[ https://issues.apache.org/jira/browse/JCR-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12769958#action_12769958 ] Felix Meschberger commented on JCR-2360: How come I think of the OSGi ServiceRegistry would be faboulous helper for this kind of extensibility ... ;-) JcrUtils.getRepository(...) for simple repository access Key: JCR-2360 URL: https://issues.apache.org/jira/browse/JCR-2360 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 2.0-beta1 Attachments: JCR-2360.patch As discussed on the mailing list, it would be nice to have a trivially simple way (one line of code) to connect to a repository. The RepositoryFactory interface in JCR 2.0 defines a way for clients to get a repository reference without a direct implementation dependency, but a client still needs extra code to handle the Service Provider lookup and the iteration through all the available repository factories. To simplify client code I'd like to introduce a JcrUtils.getRepository(MapString, String) method that takes care of the tasks mentioned above: MapString, String parameters = ...; // repository settings Repository repository = JcrUtils.getRepository(parameters); As a further simplification, I'd also like to introduce a JcrUtils.getRepository(String) method that builds the parameter map based on a given repository URI. Repository repository = JcrUtils.getRepository(file:///path/to/repository); Repository repository = JcrUtils.getRepository(http://localhost:8080/server;); The set of supported URI types is still to be defined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2358) Prefer JAAS configuration if present
[ https://issues.apache.org/jira/browse/JCR-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766544#action_12766544 ] Felix Meschberger commented on JCR-2358: I concurr with Jukka, that we should not revert the behaviour. It should be an explicit decision to use external JAAS as opposed to internal configuration. Maybe we could even add an option to the login module configuration, which says use JAAS. If this use JAAS option is not set and configuration missing, this would be a configuration error. If this use JAAS options is set, JAAS is used and any existing configuration in repository.xml would be ignored. And if in this case the JAAS configuration cannot be loaded, this would again be a configuration error. Prefer JAAS configuration if present Key: JCR-2358 URL: https://issues.apache.org/jira/browse/JCR-2358 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.6.0 Reporter: Marcel Reutegger Priority: Minor Contrary to JavaDoc the AuthContextProvider prefers the local configuration in repository.xml. When the class was first introduced in 1.5, the implementation did what was documented, but then JCR-1977 was reported. I think we shouldn't have fixed it that way. Prefering JAAS over the local configuration makes sense IMO and works well if Configuration.getAppConfigurationEntry() is correctly implemented and behaves as specified/expected. I suggest we revert to the 1.5 preference sequence and introduce a parameter that instructs the AuthContextProvider to ignore the JAAS configuration (as a workaround for the buggy application servers). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2355) Support easy pre-authenticated login
[ https://issues.apache.org/jira/browse/JCR-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766020#action_12766020 ] Felix Meschberger commented on JCR-2355: I agree that the security might be hampered with when this is used unknowningly. Still, it must explicitly be enabled on a repository configuration level and the default is, that it is not enabled. I am perfectly ok to raise the requirements for the attribute above the basic presence. For example, we could say, the attribute must be set to a session which has certain access rights. This would limit the use of this functionality to code, which already has access to the repository at a certain level. On another you raised your veto. Do you stand by this veto ? In this case, since you are a member of the PMC, I would have to remove the code again. Support easy pre-authenticated login Key: JCR-2355 URL: https://issues.apache.org/jira/browse/JCR-2355 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.0-alpha11 Reporter: Felix Meschberger Fix For: 2.0-alpha12 Attachments: JCR-2355.patch Some applications authenticate users themselves and just need to access the repository on behalf of these pre-authenticated users. Examples of such pre-authentications include SSO solutions or web applications using a web-based authentication protocol not easily implementable in a JAAS LoginModule, for example OpenID or similar. In such situations a password may not be provided in SimpleCredentials and thus regular login with user name and password is not possible. Therefore I propose the enhancement of the AbstractLoginModule to allow for setting a specific attribute in the SimpleCredentials attribute map. If this attribute is set, authentication and login succeeds and a session for the user named in the SimpleCredentials is created. As a starter we might just check for the presence of the attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2355) Support easy pre-authenticated login
[ https://issues.apache.org/jira/browse/JCR-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766047#action_12766047 ] Felix Meschberger commented on JCR-2355: Thanks for reverting your veto. So We keep this change committed. Support easy pre-authenticated login Key: JCR-2355 URL: https://issues.apache.org/jira/browse/JCR-2355 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.0-alpha11 Reporter: Felix Meschberger Fix For: 2.0-alpha12 Attachments: JCR-2355.patch Some applications authenticate users themselves and just need to access the repository on behalf of these pre-authenticated users. Examples of such pre-authentications include SSO solutions or web applications using a web-based authentication protocol not easily implementable in a JAAS LoginModule, for example OpenID or similar. In such situations a password may not be provided in SimpleCredentials and thus regular login with user name and password is not possible. Therefore I propose the enhancement of the AbstractLoginModule to allow for setting a specific attribute in the SimpleCredentials attribute map. If this attribute is set, authentication and login succeeds and a session for the user named in the SimpleCredentials is created. As a starter we might just check for the presence of the attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2355) Support easy pre-authenticated login
Support easy pre-authenticated login Key: JCR-2355 URL: https://issues.apache.org/jira/browse/JCR-2355 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.0-alpha11 Reporter: Felix Meschberger Fix For: 2.0-alpha12 Some applications authenticate users themselves and just need to access the repository on behalf of these pre-authenticated users. Examples of such pre-authentications include SSO solutions or web applications using a web-based authentication protocol not easily implementable in a JAAS LoginModule, for example OpenID or similar. In such situations a password may not be provided in SimpleCredentials and thus regular login with user name and password is not possible. Therefore I propose the enhancement of the AbstractLoginModule to allow for setting a specific attribute in the SimpleCredentials attribute map. If this attribute is set, authentication and login succeeds and a session for the user named in the SimpleCredentials is created. As a starter we might just check for the presence of the attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2355) Support easy pre-authenticated login
[ https://issues.apache.org/jira/browse/JCR-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-2355: --- Attachment: JCR-2355.patch Patch extending the AbstractLoginModule with support for pre-authentication. This patch adds the following: * Support for a configuration parameter declaring a SimpleCredentials attribute for pre-authentication * Add an isPreAuthenticated(Credentials) method used by the login() method The isPreAuthenticated method is protected and can be overwritten by AbstractLoginModule implementations to either switch pre authentication off completely or to apply different and more elaborate checks on the credentials. Support easy pre-authenticated login Key: JCR-2355 URL: https://issues.apache.org/jira/browse/JCR-2355 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.0-alpha11 Reporter: Felix Meschberger Fix For: 2.0-alpha12 Attachments: JCR-2355.patch Some applications authenticate users themselves and just need to access the repository on behalf of these pre-authenticated users. Examples of such pre-authentications include SSO solutions or web applications using a web-based authentication protocol not easily implementable in a JAAS LoginModule, for example OpenID or similar. In such situations a password may not be provided in SimpleCredentials and thus regular login with user name and password is not possible. Therefore I propose the enhancement of the AbstractLoginModule to allow for setting a specific attribute in the SimpleCredentials attribute map. If this attribute is set, authentication and login succeeds and a session for the user named in the SimpleCredentials is created. As a starter we might just check for the presence of the attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2355) Support easy pre-authenticated login
[ https://issues.apache.org/jira/browse/JCR-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved JCR-2355. Resolution: Fixed After having received the ok from Angela, I commit this patch in Rev. 825125. Support easy pre-authenticated login Key: JCR-2355 URL: https://issues.apache.org/jira/browse/JCR-2355 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.0-alpha11 Reporter: Felix Meschberger Fix For: 2.0-alpha12 Attachments: JCR-2355.patch Some applications authenticate users themselves and just need to access the repository on behalf of these pre-authenticated users. Examples of such pre-authentications include SSO solutions or web applications using a web-based authentication protocol not easily implementable in a JAAS LoginModule, for example OpenID or similar. In such situations a password may not be provided in SimpleCredentials and thus regular login with user name and password is not possible. Therefore I propose the enhancement of the AbstractLoginModule to allow for setting a specific attribute in the SimpleCredentials attribute map. If this attribute is set, authentication and login succeeds and a session for the user named in the SimpleCredentials is created. As a starter we might just check for the presence of the attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2334) Tika-based type detection in jcr-server
[ https://issues.apache.org/jira/browse/JCR-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761133#action_12761133 ] Felix Meschberger commented on JCR-2334: I'm not sure, whether replacing the MimeResolver interface with directly using Tika is a good idea. In fact in the Apache Sling WebDAV bundle, I made use of the ability to inject a custom MimeResolver to be able to use Sling's mime type resolver. So, I would actually favor a solution which would provide a Tika-based Mime Resolver. Tika-based type detection in jcr-server --- Key: JCR-2334 URL: https://issues.apache.org/jira/browse/JCR-2334 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-server Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: JCR-2334.patch, JCR-2334.patch As discussed on dev@, I'd like to make the jackrabbit-jcr-server component use Apache Tika for automatic media type detection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed JCRSITE-19. Finally removed the commons/jcr-api structure again in Rev. 804232. This closes the story of this issue. Day Software is currently preparing the JCR API OSGi bundle. Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened JCRSITE-19: -- After considering the remarks by Marcel and discussing this inside Day Software, we (Day Software) decided to release the JCR library as a bundle ourselves. See also http://markmail.org/message/6nezgjnfkbxavaq6. Therefore this issue is actually void and is to be closed wontfix Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved JCRSITE-19. -- Resolution: Won't Fix Fix Version/s: (was: jcr api wrapper 1.0.0.000) As indicated ... Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742229#action_12742229 ] Felix Meschberger commented on JCRSITE-19: -- In Rev. 803366 I committed the maven project along with license file information (in appended-resources) as well as a README.txt and a RELEASE-NOTES.txt file for the release Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: jcr api wrapper 1.0.0.000 Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved JCRSITE-19. -- Resolution: Fixed A first release attempt failed because I was missing the LICENSE and NOTICE files for the source distro. These have been added in Rev. 803380 and so lets resolve this issue and try again ;-) Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: jcr api wrapper 1.0.0.000 Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742264#action_12742264 ] Felix Meschberger commented on JCRSITE-19: -- Is it possible to create a bundle that includes the jcr jar file as is? Technically, yes ... What do others think ? Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: jcr api wrapper 1.0.0.000 Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742267#action_12742267 ] Felix Meschberger commented on JCRSITE-19: -- This would require a new version number or a new artifact id ;-) But yes, this would be an option. Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: jcr api wrapper 1.0.0.000 Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2254) Create OSGi wrapper for JCR API 1.0.1 library
Create OSGi wrapper for JCR API 1.0.1 library - Key: JCR-2254 URL: https://issues.apache.org/jira/browse/JCR-2254 Project: Jackrabbit Content Repository Issue Type: New Feature Components: JCR API Reporter: Felix Meschberger Assignee: Felix Meschberger To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1 (talking of 1.0.1, actually) the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2254) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCR-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-2254: --- Description: To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. was: To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1 (talking of 1.0.1, actually) the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. Summary: Create OSGi wrapper for JCR API 1.0 library (was: Create OSGi wrapper for JCR API 1.0.1 library) Angela just told me that the 1.0.1 library never has been officially released due to compatibility issues. Thus lets do the 1.0 bundle... Create OSGi wrapper for JCR API 1.0 library --- Key: JCR-2254 URL: https://issues.apache.org/jira/browse/JCR-2254 Project: Jackrabbit Content Repository Issue Type: New Feature Components: JCR API Reporter: Felix Meschberger Assignee: Felix Meschberger To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2254) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCR-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-2254: --- Attachment: jcr-api-project.tgz Proposed project descriptor and license files Create OSGi wrapper for JCR API 1.0 library --- Key: JCR-2254 URL: https://issues.apache.org/jira/browse/JCR-2254 Project: Jackrabbit Content Repository Issue Type: New Feature Components: JCR API Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2254) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCR-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741858#action_12741858 ] Felix Meschberger commented on JCR-2254: Thanks for the feedback. Add README, LICENSE, and NOTICE files at the top level of the project ok Use src/main/appended-resources for the LICENSE and NOTICE customizations. thanks for the hint. didn't find exactly this information ;-) The apache parent POM we're using already enables the GPG plugin, so there's no need to define it again in the project POM. Same applies to the RAT plugin. It's already enabled by the Jackrabbit parent POM version 3. Sure, this is a copy-paste relict ;-) will apply the changes before importing into svn. Create OSGi wrapper for JCR API 1.0 library --- Key: JCR-2254 URL: https://issues.apache.org/jira/browse/JCR-2254 Project: Jackrabbit Content Repository Issue Type: New Feature Components: JCR API Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2254) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCR-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741870#action_12741870 ] Felix Meschberger commented on JCR-2254: library version Current the setup is similar to what we do in the Apache Felix wrappers: append a wrapper build counter to the original wrapped library version. So the initial release of this wrapper will be something like jcr-api-1.0.0.000. If ever we would have to re-release the wrapper the build counter would be increased thus giving something like jcr-api-1.0.0.002. Of course the export version of the javax.jcr API packages is fixed at 1.0 and will not change as long as we wrap the 1.0 version of the API. Create OSGi wrapper for JCR API 1.0 library --- Key: JCR-2254 URL: https://issues.apache.org/jira/browse/JCR-2254 Project: Jackrabbit Content Repository Issue Type: New Feature Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRSITE-19) Create OSGi wrapper for JCR API 1.0 library
[ https://issues.apache.org/jira/browse/JCRSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCRSITE-19: - Component/s: wrapper Fix Version/s: jcr api wrapper 1.0.0.000 Create OSGi wrapper for JCR API 1.0 library --- Key: JCRSITE-19 URL: https://issues.apache.org/jira/browse/JCRSITE-19 Project: Jackrabbit Site Issue Type: New Feature Components: wrapper Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: jcr api wrapper 1.0.0.000 Attachments: jcr-api-project.tgz To use the JCR API in OSGi frameworks it would make perfect sense to have separate OSGi bundles providing the API. For JCR 2.0 the library will come as an OSGi bundle. For JCR 1.0 the library is not an OSGi bundle and needs to be wrapped. For this, Jackrabbit should provide a simple wrapper bundle around the JCR library and export the respective API. This wrapper project would be part of the jackrabbit/commons proper and mainly be a service of Jackrabbit to the OSGi users out there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2117) JSR 283: adopt CND syntax changes
[ https://issues.apache.org/jira/browse/JCR-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709919#action_12709919 ] Felix Meschberger commented on JCR-2117: Great. Thanks for the confirmation. JSR 283: adopt CND syntax changes - Key: JCR-2117 URL: https://issues.apache.org/jira/browse/JCR-2117 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core, nodetype Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Fix For: 2.0.0 the CND syntax has changed from Public Review Draft to Public Final Draft. old and new syntax are incompatible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRRMI-21) RMI: Unable to register NodeTypes
[ https://issues.apache.org/jira/browse/JCRRMI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700105#action_12700105 ] Felix Meschberger commented on JCRRMI-21: - I think you might want to use the org.apache.jackrabbit.rmi.jackrabbit.JackrabbitClientAdapterFactory instead of the plain ClientAdapterFactory in the requestRepository method. RMI: Unable to register NodeTypes - Key: JCRRMI-21 URL: https://issues.apache.org/jira/browse/JCRRMI-21 Project: Jackrabbit JCR-RMI Issue Type: Bug Environment: WindowsXP Reporter: Sergey Sachkov Attachments: JackRabbitTest.java Unable to register nodetype via RMI. When trying examples shown in Jackrabbit RMI section: JackrabbitNodeTypeManager ntTypeMgr = (JackrabbitNodeTypeManager) ws.getNodeTypeManager(); getting ClassCastException: java.lang.ClassCastException: org.apache.jackrabbit.rmi.client.ClientNodeTypeManager at JackRabbitTest.testRMINodeTypeRegister(JackRabbitTest.java:39) at JackRabbitTest.main(JackRabbitTest.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) java.lang.ClassCastException: org.apache.jackrabbit.rmi.client.ClientNodeTypeManager -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1878) Use Apache Tika for text extraction
[ https://issues.apache.org/jira/browse/JCR-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699633#action_12699633 ] Felix Meschberger commented on JCR-1878: I think using tika would be great. But I agree: this increase makes me shiver ... Use Apache Tika for text extraction --- Key: JCR-1878 URL: https://issues.apache.org/jira/browse/JCR-1878 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-text-extractors Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 1.6.0 Once Apache Tika is released with a resolution to TIKA-175 (making Tika available to Java 1.4 projects), we should replace our direct parser library dependencies with Tika parsers. Ideally we'd just use the Tika AutoDetectParser that'll automatically detect the type of a binary and parse it accordingly, solving JCR-728. I guess we should keep some level of backwards compatibility with existing textFilterClasses=... configurations, perhaps by keeping the existing TextExtractor classes as wrappers around respective Tika parsers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRRMI-13) Enhancement to get RMI through firewalls
[
https://issues.apache.org/jira/browse/JCRRMI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696417#action_12696417
]
Felix Meschberger commented on JCRRMI-13:
-
thx for the clarification.
Enhancement to get RMI through firewalls
Key: JCRRMI-13
URL: https://issues.apache.org/jira/browse/JCRRMI-13
Project: Jackrabbit JCR-RMI
Issue Type: Improvement
Environment: RHEL Linux 5.0
Reporter: Tony Richardson
Assignee: Jukka Zitting
Fix For: 2.0
It is difficult to get RMI through a firewall with the current implementation
of org.apache.jackrabbit.rmi.server.ServerObject. As it selects a random port
for RMI execution. This issue can be resolved by adding a system property and
modifying the default constructor as shown below.
private static Integer bindPort =
Integer.getInteger(org.apache.jackrabbit.rmi.port, new Integer(0));
/**
* Creates a basic server adapter that uses the given factory
* to create new adapters.
*
* @param factory remote adapter factory
* @throws RemoteException on RMI errors
*/
protected ServerObject(RemoteAdapterFactory factory)
throws RemoteException {
super(bindPort.intValue());
this.factory = factory;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRRMI-13) Enhancement to get RMI through firewalls
[
https://issues.apache.org/jira/browse/JCRRMI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696192#action_12696192
]
Felix Meschberger commented on JCRRMI-13:
-
System properties make me shiver in modular application environments such as
servlet containers or OSGi framework.
Do we really need support for the system property ?
Can we also have the portnumber as an argument to a new constructor instead of
just a setter (setter is still good, of course) ?
Enhancement to get RMI through firewalls
Key: JCRRMI-13
URL: https://issues.apache.org/jira/browse/JCRRMI-13
Project: Jackrabbit JCR-RMI
Issue Type: Improvement
Environment: RHEL Linux 5.0
Reporter: Tony Richardson
Assignee: Jukka Zitting
Fix For: 2.0
It is difficult to get RMI through a firewall with the current implementation
of org.apache.jackrabbit.rmi.server.ServerObject. As it selects a random port
for RMI execution. This issue can be resolved by adding a system property and
modifying the default constructor as shown below.
private static Integer bindPort =
Integer.getInteger(org.apache.jackrabbit.rmi.port, new Integer(0));
/**
* Creates a basic server adapter that uses the given factory
* to create new adapters.
*
* @param factory remote adapter factory
* @throws RemoteException on RMI errors
*/
protected ServerObject(RemoteAdapterFactory factory)
throws RemoteException {
super(bindPort.intValue());
this.factory = factory;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRRMI-3) Session.isLive() and logout() throw exceptions
[ https://issues.apache.org/jira/browse/JCRRMI-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663324#action_12663324 ] Felix Meschberger commented on JCRRMI-3: +1 with remark: The exception thrown is a RuntimeException, which would be nice to have documented in JavaDoc, but which should declared in a throws clause on the signature. Session.isLive() and logout() throw exceptions -- Key: JCRRMI-3 URL: https://issues.apache.org/jira/browse/JCRRMI-3 Project: Jackrabbit JCR-RMI Issue Type: Bug Reporter: Marcel Reutegger Priority: Minor The two methods will throw an exception in case the remote session is not available anymore. For most other methods an exception is OK in that case, but I think for the methods isLive() and logout() (both do not declare any exception) a client expects a different behavior. I propose we change it as follows: - Session.isLive(): return false if remote session is not available anymore - Session.logout(): write a log message, but do not throw a runtime exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCRSITE-1) Create new project-level Jackrabbit parent POM
[
https://issues.apache.org/jira/browse/JCRSITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663327#action_12663327
]
Felix Meschberger commented on JCRSITE-1:
-
Re Parent POM versioning: Since this global parent POM will probably change
seldom, we will not need to branch it or otherwise apply fine-grained version
control. As such a single increasing number like 2 or 3 would probably do (as
is done in other projects, too).
In addition, I suggest we also immediately release this POM, such that our
projects may refer to a released version parent pom.
Create new project-level Jackrabbit parent POM
--
Key: JCRSITE-1
URL: https://issues.apache.org/jira/browse/JCRSITE-1
Project: Jackrabbit Site
Issue Type: Task
Components: parent
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Fix For: parent 2.0
The current {{org.apache.jackrabbit:jackrabbit-parent}} POM contains
dependency management and other settings that are related to specific
Jackrabbit components. Since we are now moving many components to the new JCR
Commons subproject we should have a more generic project-level parent POM
that only specifies global configuration like project members, mailing lists,
and perhaps some generic settings of the Jackrabbit build environment.
I plan to identify this parent POM as {{org.apache.jackrabbit:parent}} as I'd
like to reserve the jackrabbit- artifactId prefix for the component that
are part of the core Jackrabbit repository build.
I'd like to start the versioning of this parent POM at 2.0 as an upgrade from
the jackrabbit-parent 1.x POMs we now have, and create 2.x versions until
upgrading to 3.0 for some major change like a TLP reorganization or switch to
the next major Maven version.
--
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: (JCRRMI-3) Session.isLive() and logout() throw exceptions
[ https://issues.apache.org/jira/browse/JCRRMI-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663324#action_12663324 ] fmeschbe edited comment on JCRRMI-3 at 1/13/09 5:11 AM: - +1 with remark: The exception thrown is a RuntimeException, which would be nice to have documented in JavaDoc, but which should declared in a throws clause on the signature. So the current behaviour is not technically wrong, just not nice ;-) was (Author: fmeschbe): +1 with remark: The exception thrown is a RuntimeException, which would be nice to have documented in JavaDoc, but which should declared in a throws clause on the signature. Session.isLive() and logout() throw exceptions -- Key: JCRRMI-3 URL: https://issues.apache.org/jira/browse/JCRRMI-3 Project: Jackrabbit JCR-RMI Issue Type: Bug Reporter: Marcel Reutegger Priority: Minor The two methods will throw an exception in case the remote session is not available anymore. For most other methods an exception is OK in that case, but I think for the methods isLive() and logout() (both do not declare any exception) a client expects a different behavior. I propose we change it as follows: - Session.isLive(): return false if remote session is not available anymore - Session.logout(): write a log message, but do not throw a runtime exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1269) Stop using BaseException
[ https://issues.apache.org/jira/browse/JCR-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662275#action_12662275 ] Felix Meschberger commented on JCR-1269: Looking again at this issue and the related discussion, I do not change my mind with respect to simply removing the BaseException. I still think, it should have been renamed and the Jackrabbit-internal exception extend from it. What we cold do is make the BaseException extend RepositoryException, because that's what it ultimately is - an exception in the Repository Stop using BaseException Key: JCR-1269 URL: https://issues.apache.org/jira/browse/JCR-1269 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 1.6.0 Attachments: BaseException.patch The o.a.j.BaseException class is deprecated (since JCR-1169) and not caught anywhere, so there's no need to keep using it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1269) Stop using BaseException
[ https://issues.apache.org/jira/browse/JCR-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662295#action_12662295 ] Felix Meschberger commented on JCR-1269: @angela: I see your point, this is why I suggested to have the BaseException extend the RepositoryException @Jukka: The problem is consistent exception handling and understanding what this is all about. In that sense its kind of a categorization of the exceptions. Of course the exceptions previously extending BaseException could just extend RepositoryException. But having them extend Exception is IMHO wrong. Anyway, since these are just internal exceptions, I don't care too much -- unless this would lead to method declarations of the form public type someMethod() throws Exception Stop using BaseException Key: JCR-1269 URL: https://issues.apache.org/jira/browse/JCR-1269 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 1.6.0 Attachments: BaseException.patch The o.a.j.BaseException class is deprecated (since JCR-1169) and not caught anywhere, so there's no need to keep using it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1823) Repository.login throws IllegalStateException
[
https://issues.apache.org/jira/browse/JCR-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662400#action_12662400
]
Felix Meschberger commented on JCR-1823:
Looks good to me, too, and makes perfect sense.
Repository.login throws IllegalStateException
-
Key: JCR-1823
URL: https://issues.apache.org/jira/browse/JCR-1823
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Felix Meschberger
Attachments: JCR-1823.patch
Calling any login method on Repository instance, which has been shut down
throws an IllegalStateException, which is caused by the
RepositoryImpl.sanityCheck method.
This exception is unexpected by callers of the login method, which is
specified to throw one of LoginException, NoSuchWorkspaceException and
RepositoryException. In particular the spec says, that a RepositoryException
is thrown if another error occurs.
So I suggest to modify the RepositoryImpl.login(Credentials, String) as
follows (patch against trunk):
Index:
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
===
---
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
(revision 706543)
+++
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
(working copy)
@@ -1358,6 +1358,8 @@
} catch (AccessDeniedException ade) {
// authenticated subject is not authorized for the specified
workspace
throw new LoginException(Workspace access denied, ade);
+} catch (RuntimeException re) {
+throw new RepositoryException(re.getMessage(), re);
} finally {
shutdownLock.readLock().release();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1865) Add the Data Store to the Jackrabbit API
[ https://issues.apache.org/jira/browse/JCR-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649292#action_12649292 ] Felix Meschberger commented on JCR-1865: I'm not sure if this would be fully backward compatible Well, you already renamed the interface, right ? So you already have kind of a backwards compatibility issue. In addition, there has not been an official API yet (interfaces hidden in implementation code should not be called API ;-) ), so IMHO there is no need to worry. * single method gc(): multiple repositories can use the same data store (sharing the data store). In that case, you need to call mark() of all repositories before calling sweep() (on the first repository). As Jukka already said, sharing the store among multiple repositories is an implementation detail of the data store and is of no concern to the administrator (+1 for making it a management API BTW). Synchronization among the repositories sharing the data store is the task of the data store. our lower level APIs What is lower level APIs ? Add the Data Store to the Jackrabbit API Key: JCR-1865 URL: https://issues.apache.org/jira/browse/JCR-1865 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: api.patch, core.patch Currently, the garbage collection is not part of the Jackrabbit API. However, the data store garbage collection must be used once in a while if the data store is enabled. I propose to add the required interfaces to the Jackrabbit API. This will also allow to call garbage collection using RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1823) Repository.login throws IllegalStateException
Repository.login throws IllegalStateException
-
Key: JCR-1823
URL: https://issues.apache.org/jira/browse/JCR-1823
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Felix Meschberger
Calling any login method on Repository instance, which has been shut down
throws an IllegalStateException, which is caused by the
RepositoryImpl.sanityCheck method.
This exception is unexpected by callers of the login method, which is specified
to throw one of LoginException, NoSuchWorkspaceException and
RepositoryException. In particular the spec says, that a RepositoryException is
thrown if another error occurs.
So I suggest to modify the RepositoryImpl.login(Credentials, String) as follows
(patch against trunk):
Index:
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
===
---
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
(revision 706543)
+++
/usr/src/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RepositoryImpl.java
(working copy)
@@ -1358,6 +1358,8 @@
} catch (AccessDeniedException ade) {
// authenticated subject is not authorized for the specified
workspace
throw new LoginException(Workspace access denied, ade);
+} catch (RuntimeException re) {
+throw new RepositoryException(re.getMessage(), re);
} finally {
shutdownLock.readLock().release();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned JCR-1812: -- Assignee: Felix Meschberger WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed JCR-1812. -- Resolution: Fixed Applied patch to 1.5 branch in Rev. 704863 and to trunk in Rev. 704864. WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-1812: --- Attachment: JCR-cluster-update-log.patch Proposed patch, which also includes making use of SLF4Js log call optimization for not concatenating strings if not needed. WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering Affects Versions: core 1.4.2 Reporter: Felix Meschberger Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-1812: --- Fix Version/s: 1.6.0 WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0, 1.6.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1749) JCRUrlConnection relies on nt:file/nt:resource
JCRUrlConnection relies on nt:file/nt:resource -- Key: JCR-1749 URL: https://issues.apache.org/jira/browse/JCR-1749 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.4 Reporter: Felix Meschberger Assignee: Felix Meschberger The JCRUrlConnection class implementing the jcr: URL handler for the JCR class loader relies on the fact that the intended primary type of the jcr:content child node of an nt:file node is of type nt:resource. When writing files with the Jackrabbit WebDAV server this is not the case as the jcr:content child node is of type nt:unstructured. As a result the JCRUrlConnection.connect method fails with an ItemNotFoundException in the Util.getProperty(Item) method because the primary item of the nt:unstructured node type is not defined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1749) JCRUrlConnection relies on nt:file/nt:resource
[ https://issues.apache.org/jira/browse/JCR-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-1749: --- Component/s: jackrabbit-classloader JCRUrlConnection relies on nt:file/nt:resource -- Key: JCR-1749 URL: https://issues.apache.org/jira/browse/JCR-1749 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-classloader Affects Versions: 1.4 Reporter: Felix Meschberger Assignee: Felix Meschberger The JCRUrlConnection class implementing the jcr: URL handler for the JCR class loader relies on the fact that the intended primary type of the jcr:content child node of an nt:file node is of type nt:resource. When writing files with the Jackrabbit WebDAV server this is not the case as the jcr:content child node is of type nt:unstructured. As a result the JCRUrlConnection.connect method fails with an ItemNotFoundException in the Util.getProperty(Item) method because the primary item of the nt:unstructured node type is not defined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1749) JCRUrlConnection relies on nt:file/nt:resource
[ https://issues.apache.org/jira/browse/JCR-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved JCR-1749. Resolution: Fixed Fix Version/s: 1.5 Removed the dependency on the concrete types of nodes accessed. Rather check for the actual data present or not. This mostly is of importance in the Util class providing access to the URL's data property. The other location of importance is the JCRURLConnection.connect() method, which loads the content length, content type and last modification time fields from the repository. Fixed in Rev. 697778. JCRUrlConnection relies on nt:file/nt:resource -- Key: JCR-1749 URL: https://issues.apache.org/jira/browse/JCR-1749 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-classloader Affects Versions: 1.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: 1.5 The JCRUrlConnection class implementing the jcr: URL handler for the JCR class loader relies on the fact that the intended primary type of the jcr:content child node of an nt:file node is of type nt:resource. When writing files with the Jackrabbit WebDAV server this is not the case as the jcr:content child node is of type nt:unstructured. As a result the JCRUrlConnection.connect method fails with an ItemNotFoundException in the Util.getProperty(Item) method because the primary item of the nt:unstructured node type is not defined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
