[jr3] Release roadmap

[Jukka Zitting]

Hi,

As a followup to the strategic plan proposal, and to help turn our
focus from abstract planning to actual deliverables, here's a quick
draft roadmap for possible releases we could/should be making still in
H1/2012. It's still necessarily incomplete (for example I excluded
query and indexing features for now as I don't yet have a good idea of
when or how they should be addressed), but I think a roadmap like this
should help us focus on the right things at the right time.

For example, IMHO agreeing on the clustering model and getting a basic
implementation in place is a fundamental decision that needs to be
done as early as possible (by April in this draft), followed soon by
merging of concurrent CRUD operations. Only after we have those in
place can we start making solid decisions about higher-level features.
This doesn't mean that we shouldn't take such features into account
when designing and implementing the clustering model, just that we
shouldn't start implementing them before the basics are in place.

This is a pretty tight schedule mostly to bring up a sense of focus
that we currently seem to be lacking. The proposed schedule should be
reachable with a few persons working full time on this, which I think
(and hope) we should be able to arrange. And it's more of a guideline
than a fixed plan, we can proceed faster on some issues if possible or
postpone others where needed. We may even decide to drop some items
entirely or introduce new items to the plan.

With that background, here's the proposed roadmap:

* 0.1 - March 2012
  * Basic JCR and HTTP interfaces (Hello, World!)
  * In-memory storage (no-need for persistence yet)
  * Runnable jar for easy deployment
  * Integration tests to verify the above

* 0.2 - April 2012
  * Basic CRUD operations over JCR and HTTP
  * Extension model for plugging in alternative storage backends
  * Basic on-disk or in-cloud persistence (no performance or stability
goals yet)
  * Clustering model that supports the above CRUD operations
  * Runnable jar with "join cluster" functionality
  * Integration tests to verify the above

* 0.3 - May 2012
  * Basic (Hello, World! -level) JavaScript-friendly HTTP API
  * Simple WebDAV layer with remote filesystem semantics
  * Automatic merging of concurrent CRUD operations
  * Extension model for plugging in features like access control, node
types, etc.
  * Basic (Hello, World! -level) implementation of one such pluggable feature
  * OSGi bundle packaging
  * Integration tests to verify the above
  * Basic performance tests for simple read and write scenarios

* 0.4 - June 2012
  * Bindings for jQuery
  * WebDAV(ex)-based remoting
  * Support for all JSON and JCR data types, including multivalued properties
  * Basic support for flat hierarchies (no performance goals yet)
  * Basic support for access control based on the extension model
  * Basic support for node types based on the extension model
  * Basic support for observation based on the extension model
  * Basic support for locking (if needed/wanted)
  * OSGi/Spring/etc. pluggability of extensions
  * Integration tests to verify the above
  * Performance benchmark against selected other NoSQL databases
  * Performance tests for clustered deployments
  * Basic scalability tests for simple read and write scenarios

BR,

Jukka Zitting

Re: [jr3] Strategic plan

[Jukka Zitting]

Hi,

On Thu, Feb 23, 2012 at 12:45 PM, Jukka Zitting  wrote:
> Based on the various recent and older discussions, here's my very
> high-level suggestion on what to target and how to reach it.

I put this proposal up on the wiki at [1] so we can iterate it based
on emerging consensus.

[1] http://wiki.apache.org/jackrabbit/Jackrabbit%203%20Strategic%20Plan

BR,

Jukka Zitting

[jr3] Strategic plan

[Jukka Zitting]

Hi,

Based on the various recent and older discussions, here's my very
high-level suggestion on what to target and how to reach it.  Take
this as a proposed strategic plan, which doesn't directly address more
tactical issues of which specific features to implement or how.
Following the Situation-Target-Path model from [1], here's my
proposal:

Situation
-

In Jackrabbit 2.x we have a solid and feature-rich content repository that
works well especially for the needs of traditional web sites and integrated
content management applications. However, the trends in user expectations
(especially for personalized, interactive and collaborative content),
application architectures (distributed, loosely coupled, multi-platform
solutions with lots of data) and hardware design (horizontal rather than
vertical scaling) have rendered some of the original Jackrabbit design
decisions (that date back almost a decade) obsolete and there's no easy
way to incrementally update the design.

This problem has been a know issue for years (the first proposals to address
it date back to 2008), and over the last year we've been actively prototyping
promising ideas to gather more experience on how they work in practice. Now
is the time to move to the next phase where we take that experience and all
the knowledge we've gathered from working with existing Jackrabbit versions
and use it to build a new repository that better matches today's needs.

Target
--

We want to implement a scalable and performant hierarchical content
repository for use as the foundation of modern world-class web sites and
other demanding content applications. The repository should implement
standards like JCR, WebDAV and CMIS, and be easily accessible from various
platforms, especially from JavaScript clients running in modern browser
environments. The implementation should provide more out-of-the-box
functionality than typical NoSQL databases while achieving comparable
levels of scalability and performance.

By 2013 the new repository should have stabilized its internal architecture
and the implementation should be ready for production use in major deployments
that don't need all the designed features to be ready yet. By 2014 the
repository should have reached comparable level of functionality on all
Jackrabbit 2.x features that we haven't explicitly decided not to support.
It should be possible to migrate existing Jackrabbit applications and
deployments to the new repository implementation with little effort.

Path


Since the goals of the new repository implementation are somewhat different
than the traditional goals of Jackrabbit (i.e. to be "a fully conforming JCR
implementation"), we should organize the implementation work as a new
Jackrabbit subproject with its own identity (i.e. not just "Jackrabbit 3").
This subproject shall have it's own dev@ mailing list, source repository,
issue tracker and release cycle. For now the effort will remain a part of
Jackrabbit and fall within the oversight of the Jackrabbit PMC, but down
the line we may want to branch it off to a separate TLP, possibly through
the Incubator.

The new repository shall be implemented in an open, collaborative fashion
based on the Apache principles. The effort shall be open to all contributors
and actively strive to make it easy for new people to get involved. To
achieve this, the new architecture should be designed to be modular and
easily extensible. Extra care shall also be taken to make the new repository
trivially easy to deploy and use for the most common use cases.

To enable a rapid feedback cycle and to make it easy to track our progress,
we shall adopt a "release early, release often" model of making new releases
at least once a month and maintain a growing set of automated integration and
performance tests to maintain release quality. A key design constraint for
all features is to make them easily testable.

To get started on all this, I propose that we select a name for the new
repository and set up the proposed subproject infrastructure over the next
two weeks. Then we'll target at releasing the first 0.1 version of the new
repository by the end of March. The minimum requirements for that release
are only that it's accessible through HTTP and JCR ("Hello, World!" level OK),
come with a runnable jar for easy deployment, and have a basic integration
test suite that verifies that the release meets the above requirements.
We'll build on from there!

[1] 
http://en.wikibooks.org/wiki/Business_Strategy/Overview_of_Strategic_Planning#Methodologies

BR,

Jukka Zitting

[jira] [Resolved] (JCR-3236) Can not instantiate lucene Analyzer in SearchIndex

[Jukka Zitting (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-3236.


   Resolution: Fixed
Fix Version/s: 2.4.1
 Assignee: Jukka Zitting

This is a regression from JCR-2415 where we updated to Lucene version 3. 
Analyzers
that have a public empty default constructor still work, but the updated once 
that in Lucene 3 require a Version argument don't. Note that Jackrabbit already 
uses the StandardAnalyzer class as the default when no explicit analyzer is 
specified, so as a quick workaround you can just remove that configuration 
option.

Fixed in revision 1291424 (by providing the Version argument where needed), and 
merged to the 2.4 branch in revision 1291437. We'll ship this fix shortly in 
2.4.1.

> Can not instantiate lucene Analyzer in SearchIndex
> --
>
> Key: JCR-3236
> URL: https://issues.apache.org/jira/browse/JCR-3236
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.4
>Reporter: YP
>Assignee: Jukka Zitting
> Fix For: 2.4.1
>
>
> In the Lucene 3, the there is no default constructor anymore in Analyzer 
> classes
> 11:46:45.946 [main] WARN  o.a.j.core.query.lucene.SearchIndex - Invalid 
> Analyzer class: org.apache.lucene.analysis.standard.StandardAnalyzer
> java.lang.InstantiationException: 
> org.apache.lucene.analysis.standard.StandardAnalyzer
> at java.lang.Class.newInstance0(Class.java:340) ~[na:1.6.0_26]
> at java.lang.Class.newInstance(Class.java:308) ~[na:1.6.0_26]
> at 
> org.apache.jackrabbit.core.query.lucene.SearchIndex.setAnalyzer(SearchIndex.java:1892)
>  ~[jackrabbit-core-2.4.0.jar:2.4.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.6.0_26]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
> ~[na:1.6.0_26]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  ~[na:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_26]
> at 
> org.apache.jackrabbit.core.config.BeanConfig.setProperty(BeanConfig.java:255) 
> [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:203) 
> [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.config.RepositoryConfigurationParser$1.getQueryHandler(RepositoryConfigurationParser.java:652)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.config.WorkspaceConfig.getQueryHandler(WorkspaceConfig.java:251)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.SearchManager.(SearchManager.java:171) 
> [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1855)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:2092)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1997)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:510)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:318) 
> [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:582) 
> [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(BindableRepository.java:141)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.jndi.BindableRepository.init(BindableRepository.java:117)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.jndi.BindableRepository.(BindableRepository.java:106)
>  [jackrabbit-core-2.4.0.jar:2.4.0]
> at 
> org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:52)
>  [jackrabbit-core-2.4.0.jar:2.4.0]

--
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

Re: [jira] [Resolved] (JCR-3237) add missing name constants for mix:title

[Jukka Zitting]

Hi,

On Fri, Feb 17, 2012 at 2:52 PM, Felix Meschberger  wrote:
> Me thinks that the version in o.a.j.spi.commons.name.package-info.java must
> be increased to 2.4.1 due to this addition.

I've been taking care of that as a part of cutting a release.
Meanwhile if the package-info update is needed (for OSGi dependency
reasons) already for the SNAPSHOT, any committer can go ahead and
update the version.

BR,

Jukka Zitting

Re: Support sending emails

[Jukka Zitting]

Hi,

On Fri, Feb 17, 2012 at 9:57 AM, Stefan Sandberg
 wrote:
> I have started use Jackrabbit and I wonder if Jackrabbit supports sending
> emails from a list?

No, Jackrabbit has no built-in email capabilities.

BR,

Jukka Zitting

Re: [Jackrabbit Wiki] Update of "Goals and non goals for Jackrabbit 3" by MichaelDürig

[Jukka Zitting]

Hi,

On Thu, Feb 16, 2012 at 12:22 PM, Apache Wiki  wrote:
> === Design principle ===
> Best effort: everything might be corrupt at any time:
>  * node types
>  * child node existence
>  * clients may not make '''any''' consistency assumptions

That's too vague, IMHO. A client needs to be able to make *some*
assumptions about the consistency of the repository. For example, if I
write something to the repository and nobody else modifies that
content, it should be safe for me to assume that the content still
exists (in a consistent state) when I next look for it. What happens
when others modify the content is a different question, but even there
we need to be able to give some deterministic guarantees about
(eventual) consistency.

Also, the word "corrupt" here sounds quite harsh. IMHO a corruption is
always a big problem. Instead we may want to allow the repository to
be at times "out of sync" or "temporarily inconsistent" as long as
it'll eventually reach a more stable state.

>  * Pass TCK. But TCK might be adapted for invalid or edge cases.

"Pass TCK" is a bit vague unless we specify which optional features we
intend to support. Any changes to the TCK need to be based on a more
accurate reading of the spec or (where we feel the spec is too strict)
a proposal to JSR 333 to relax the requirements.

> Scalability:

We need more specific benchmarks for these. Good early guidelines though.

> === Non goals ===
> [...]
>  * Consistency guarantees

As discussed above, we IMHO definitely need consistency guarantees,
the question is just how strict we want to make them.

>  * JCR lock == sync

Can you elaborate? I'd either implement locking correctly or not
implement it at all, not something in between that a client can't
really rely on.

BR,

Jukka Zitting

[jira] [Commented] (JCR-134) Unreferenced VersionHistory should be deleted automatically.

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208497#comment-13208497
 ] 

Jukka Zitting commented on JCR-134:
---

> It would be good to allow rootVersion removal when its versioned node is 
> already removed.

Sounds like a reasonable idea.

> Does it make sense to create issue for this use case? 

Yes, please do.

> Unreferenced VersionHistory should be deleted automatically.
> 
>
> Key: JCR-134
> URL: https://issues.apache.org/jira/browse/JCR-134
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: versioning
>Reporter: Tobias Bocanegra
>Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 1.6
>
> Attachments: jackrabbit-1.4.x-JCR-134-first-try-2008-08-11.patch
>
>
> since the creation of a VersionHistory is triggered by the creation of a 
> mix:versionable node, the removal should happen automatically, as soon as no 
> references to that version histroy exist anymore. this is the case, when all 
> mix:versionable nodes (in all workspaces) belonging to that VH are deleted, 
> and all the versions in the VH are removed i.e. only the jcr:rootVersion is 
> left. At this point, the VH should be deleted aswell.

--
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

Jackrabbit 2.2.12 release plan

[Jukka Zitting]

Hi,

As you probably already noticed, I just backported the improvements
JCR-3066 and JCR-3146 to the 2.2 branch. The rationale is to get a way
to control the size of also the non-forked pool of text extraction
threads with Jackrabbit 2.2.x, something that was possible in
Jackrabbit 1.x but unfortunately not again before 2.4.0 where we
restored that functionality with JCR-3146.

To get this improvement out also for users of Jackrabbit 2.2.x, I'd
like to start preparing for a 2.2.12 maintenance release next week. If
you have other bugfixes or low-risk improvements that should go into
the release, please label them for 2.2.12 in Jira.

BR,

Jukka Zitting

[jira] [Updated] (JCR-3146) Text extraction may congest thread pool in the repository

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3146:
---

Fix Version/s: 2.2.12

Merged to the 2.2 branch in revision 1242468.

> Text extraction may congest thread pool in the repository
> -
>
> Key: JCR-3146
> URL: https://issues.apache.org/jira/browse/JCR-3146
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 2.2.12, 2.3.4
>
> Attachments: JCR-3146.patch
>
>
> Text extraction congests the thread pool in the repository when e.g. many 
> PDFs are loaded into the workspace. Tasks submitted by the index merger are 
> delayed because of that and will result in many index segment folders.

--
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] [Updated] (JCR-3066) Use only one scheduler for repository tasks

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3066:
---

Fix Version/s: 2.2.12

Merged to the 2.2 branch in revision 1242446 as a dependency of JCR-3146.

> Use only one scheduler for repository tasks
> ---
>
> Key: JCR-3066
> URL: https://issues.apache.org/jira/browse/JCR-3066
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>    Reporter: Jukka Zitting
>    Assignee: Jukka Zitting
>Priority: Minor
>  Labels: thread, timer
> Fix For: 2.2.12, 2.3
>
>
> There are still a few Timer instances being used by Jackrabbit. It would be 
> better if all tasks were scheduled by the central ScheduledExecutorService 
> thread pool of the repository.

--
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

[ANNOUNCE] Apache Jackrabbit 2.4.0 released

[Jukka Zitting]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.4.0. The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release.


Release Notes -- Apache Jackrabbit -- Version 2.4.0

Introduction


This is Apache Jackrabbit(TM) 2.4, a fully compliant implementation of the
Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.4 is an incremental feature release based on and
compatible with earlier stable Jackrabbit 2.x releases. Jackrabbit 2.4.x
releases are considered stable and targeted for production use.

Changes since Jackrabbit 2.2.0
--

New features

  [JCR-2859] Make open scoped locks recoverable
  [JCR-2936] JMX Bindings for Jackrabbit
  [JCR-3005] Make it possible to get multiple nodes in one call via davex
  [JCR-3040] JMX Stats for the Session
  [JCR-3117] Stats for the PersistenceManager
  [JCR-3118] Configurable actions upon authorizable creation and removal
  [JCR-3124] Stats for Queries
  [JCR-3140] Add configurable hook for password validation
  [JCR-3154] Stats for Queries continued
  [JCR-3183] Add memory based bundle store

Improvements

  [JCR-1443] Make JCAManagedConnectionFactory non final, so it can be extended
  [JCR-2798] JCAManagedConnectionFactory should chain cause exception
  [JCR-2887] Split PrivilegeRegistry in a per-session manager instance ...
  [JCR-2906] Multivalued property sorted by last/random value
  [JCR-2989] Support for embedded index aggregates
  [JCR-3017] Version history recovery fails in case a version does not ...
  [JCR-3030] Permit using different tablespaces for tables and indexes ...
  [JCR-3084] Script for checking releases
  [JCR-3085] better diagnostics when version storage is broken
  [JCR-3091] Lucene Scorer implementations should handle the 'advance' ...
  [JCR-3098] Add hit miss statistics and logging to caches
  [JCR-3102] InternalVersion.getFrozenNode confused about root version?
  [JCR-3107] Speed up hierarchy cache initialization
  [JCR-3109] Move PersistenceManagerTest from o.a.j.core to o.a.j.core
  [JCR-3114] expose PM for versioning manager so that the consistency ...
  [JCR-3119] Improve aggregate node indexing code
  [JCR-3120] Change log level in UserManagerImpl#getAuthorizable(NodeImpl) ...
  [JCR-3122] QueryObjectModelImpl should execute queries as SessionOperation(s)
  [JCR-3127] Upgrade to Tika 0.10
  [JCR-3129] It should be possible to create a non-transient Repository ...
  [JCR-3132] Test tooling updates
  [JCR-3133] Query Stats should use the TimeSeries mechanism
  [JCR-3135] Upgrade to Logback 1.0
  [JCR-3136] Add m2e lifecycle mappings for Eclipse Indigo
  [JCR-3138] Skip sync delay when changes are found
  [JCR-3141] Upgrade to Tika 1.0
  [JCR-3142] Create OSGi Bundles from jackrabbit-webdav and ...
  [JCR-3143] SessionImpl#isSupportedOption: Skip descriptor evaluation ...
  [JCR-3146] Text extraction may congest thread pool in the repository
  [JCR-3161] Add JcrUtils.getPropertyTypeNames
  [JCR-3162] Index update overhead on cluster slave due to JCR-905
  [JCR-3165] Consolidate compare behaviour for Value(s) and Comparable(s)
  [JCR-3167] Make Jackrabbit compile on Java 7
  [JCR-3170] Precompile JavaCC parsers in jackrabbit-spi-commons
  [JCR-3172] implement PERSIST events for the EventJournal
  [JCR-3177] Remove jdk 1.4 restriction for jcr-tests
  [JCR-3178] Improve error messages for index aggregates
  [JCR-3184] extend ConsistencyChecker API to allow adoption of orphaned ...
  [JCR-3185] refactor consistency checks in BundleDBPersistenceManager ...
  [JCR-3199] workspace-wide default for lock timeout
  [JCR-3200] consistency check should get node ids in chunks, not rely on ...
  [JCR-3202] AuthorizableImpl#memberOf and #declaredMemberOf should ...
  [JCR-3203] GroupImp#getMembers and #getDeclaredMembers should return ...
  [JCR-3222] Allow servlet filters to specify custom session providers

Bug fixes

  [JCR-2539] spi2dav: Observation's user data not property handled
  [JCR-2540] spi2dav : move/reorder not properly handled by observation
  [JCR-2541] spi2dav : EventJournal not  implemented
  [JCR-2542] spi2dav: EventFilters not respected
  [JCR-2543] spi2dav : Query offset not respected
  [JCR-2774] Access control for repository level API operations
  [JCR-2892] Large fetch sizes have potentially deleterious effects on ...
  [JCR-2930] same named child nodes disappear on restore
  [JCR-3082] occasional index out of bounds exception while running ...
  [JCR-3086] potential infinite loop around InternalVersionImpl.getSuccessors
  [JCR-3089] javax.jcr.RepositoryException when a JOIN SQL2 query is ...
  [JCR-3090] setFetchSize() fails in getAllNodeIds()
  [JCR-3093] Inconsistency between Session.getProperty and Node
  [JCR-3095] Move operation may turn AC cache

[ANNOUNCE] Apache Jackrabbit 2.2.11 released

[Jukka Zitting]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.2.11. The release is available for download at:

   http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release.


Release Notes -- Apache Jackrabbit -- Version 2.2.11

Introduction


This is Apache Jackrabbit(TM) 2.2, a fully compliant implementation of the
Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.2.11 is patch release that contains fixes and
improvements over previous 2.2.x releases. This release is backwards
compatible with all earlier 2.x releases.

Changes in this release
---

Improvements

  [JCR-3107] Speed up hierarchy cache initialization
  [JCR-3167] Make Jackrabbit compile on Java 7

Bug fixes

  [JCR-3148] Using transactions still leads to memory leak
  [JCR-3174] Destination URI should be normalized
  [JCR-3175] InputContextImpl: cannot upload file larger than 2GB
  [JCR-3210] NPE in spi2dav when server does not send all headers
  [JCR-3223] Disallow unregistering of node types still (possibly) in use

For more detailed information about all the changes in this and other
Jackrabbit releases, please see the Jackrabbit issue tracker at

https://issues.apache.org/jira/browse/JCR

Node type unregistration problem in 2.2.[0-10]
--

Earlier 2.2.x releases (< 2.2.11) mistakenly allowed node types to be
unregistered without no checks on whether those types are still referenced
in content. Before Jackrabbit 2.1 the "checkForReferencesInContent" method
used to always throw a "not yet implemented" exception since we haven't yet
implemented that functionality and didn't want people to accidentally break
the consistency of their content by removing types that are still used.
However, before the 2.1 release this exception was accidentally disabled
and thus in Jackrabbit versions 2.1.x and 2.2.x it has so far been possible
to remove node types with no such consistency constraints.

This issue was fixed in Jackrabbit 2.2.11 by re-enabling the exception in
the checkForReferencesInContent method, which will break all client code
that tries to unregister node types. If you need this functionality and
are aware of the potential problems, you can restore the old behaviour
by setting the disableCheckForReferencesInContentException system property
to "true".

Data consistency issue in 2.2.[0-6]
---

Earlier 2.2.x releases (< 2.2.7) had a problem where very large positive
or negative long property values (more than 62 bits) could not be correctly
read from the reepository. The values are still correctly stored in the
reporistory, and can be properly read after upgrading to this release,
but any previous computations or other information derived from such
properties should be checked for correctness.

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.txt file for instructions on how to build this release.

The source archive is accompanied by SHA1 and MD5 checksums and a PGP
signature that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS.

About Apache Jackrabbit
---

Apache Jackrabbit is a fully conforming implementation of the Content
Repository for Java Technology API (JCR). A content repository is a
hierarchical content store with support for structured and unstructured
content, full text search, versioning, transactions, observation, and
more.

For more information, visit http://jackrabbit.apache.org/

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 100 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 2,500+ contributors.

For more information, visit http://www.apache.org/

Re: [VOTE] Release Apache Jackrabbit 2.4.0

[Jukka Zitting]

Hi,

On Sat, Feb 4, 2012 at 9:11 AM, Torgeir Veimo  wrote:
> On 4 February 2012 01:16, Jukka Zitting  wrote:
>> Is there an issue filed for this? A patch?
>>
>> Sounds like something we should do for 2.4.1.
>
> I thought it was fixed in 2.3.0
> (https://issues.apache.org/jira/browse/JCR-2836) but it appears it
> isn't.

Looks like the issue reappeared at some point (unfortunately our
Tomcat integration test doesn't look for the leak warnings). I filed
JCR-3227 [1] for one aspect, and it looks like the Derby upgrade
opened up another problem with the DerbyShutdown mechanism we added
earlier. Let's target at having these fixed (and added to the
integration test) in 2.4.1 within a few weeks.

[1] https://issues.apache.org/jira/browse/JCR-3227

BR,

Jukka Zitting

[RESULT] [VOTE] Release Apache Jackrabbit 2.4.0

[Jukka Zitting]

Hi,

On Fri, Feb 3, 2012 at 1:53 PM, Jukka Zitting  wrote:
> Please vote on releasing this package as Apache Jackrabbit 2.4.0.

The vote passes as follows (* marks a PMC member):

+1 Alex Parvulescu *
+1 Bart van der Schans *
+1 Claus Köll *
+1 David Buchmann
+1 Jukka Zitting *
+1 Michael Dürig *

Thanks for voting! I'll push the release out.

BR,

Jukka Zitting

[jira] [Commented] (JCR-3213) Speed up NodeIndexer.isIndexed() check

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202234#comment-13202234
 ] 

Jukka Zitting commented on JCR-3213:


Made the suggested change in revision 1241418.

> Speed up NodeIndexer.isIndexed() check
> --
>
> Key: JCR-3213
> URL: https://issues.apache.org/jira/browse/JCR-3213
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Alex Parvulescu
>Priority: Minor
> Fix For: 2.5
>
> Attachments: JCR-3213.patch
>
>
> The isIndexed() method is called for every value in a multi-valued property. 
> This may be quite expensive when there are a lot of values.

--
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-3227) VolatileIndex not closed properly

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202233#comment-13202233
 ] 

Jukka Zitting commented on JCR-3227:


+1 looks good. The null assignment can be skipped since the next statement just 
overrides it.

> VolatileIndex not closed properly
> -
>
> Key: JCR-3227
> URL: https://issues.apache.org/jira/browse/JCR-3227
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.4
>    Reporter: Jukka Zitting
>Priority: Minor
> Attachments: JCR-3227.patch
>
>
> The MultiIndex.resetVolatileIndex() method doesn't properly close the 
> existing VolatileIndex instance before creating a new one. This can confuse 
> the DynamicPooledExecutor reference count added in JCR-2836, leading to a 
> background thread leak.

--
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-3213) Speed up NodeIndexer.isIndexed() check

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202214#comment-13202214
 ] 

Jukka Zitting commented on JCR-3213:


It looks like the code could be simplified by moving the isIndexed conditional 
right up to the createDoc() method. The only complication seems to be the 
handling of jcr:primaryType and jcr:mixinTypes properties, but I think we can 
cover that by making the isIndexed() method always return true for those names.

> Speed up NodeIndexer.isIndexed() check
> --
>
> Key: JCR-3213
> URL: https://issues.apache.org/jira/browse/JCR-3213
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Alex Parvulescu
>Priority: Minor
> Fix For: 2.5
>
> Attachments: JCR-3213.patch
>
>
> The isIndexed() method is called for every value in a multi-valued property. 
> This may be quite expensive when there are a lot of values.

--
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] [Created] (JCR-3227) VolatileIndex not closed properly

[Jukka Zitting (Created) (JIRA)]

VolatileIndex not closed properly
-

 Key: JCR-3227
 URL: https://issues.apache.org/jira/browse/JCR-3227
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.4
Reporter: Jukka Zitting
Priority: Minor


The MultiIndex.resetVolatileIndex() method doesn't properly close the existing 
VolatileIndex instance before creating a new one. This can confuse the 
DynamicPooledExecutor reference count added in JCR-2836, leading to a 
background thread leak.

--
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

Re: [jr3 microkernel] Change log consolidation

[Jukka Zitting]

Hi,

On Mon, Feb 6, 2012 at 2:48 PM, Stefan Guggisberg
 wrote:
> BTW, that's how it the transient space is implemented in the current
> jackrabbit-core.

Exactly. I think that also answers Thomas' concern (b).

BR,

Jukka Zitting

Re: [jr3 microkernel] Change log consolidation

[Jukka Zitting]

Hi,

On Mon, Feb 6, 2012 at 1:53 PM, Michael Dürig  wrote:
>> An alternative that AFAICT achieves the same effect in perhaps an
>> easier to understand manner would be to use the state of the content
>> tree instead of changes to that state as the key concept. [...]
>
> That's more or less what I started with [1] and what I referred to as can of
> worms in my original mail. Detecting and normalizing/consolidating moves
> turned out to be too tricky there. You basically have the same cases I
> identified (1. - 16.) but its much more difficult to tell them apart.

Instead of separate Added/Existing/Moved/Removed instances in the
ChangeTree, did you consider keeping the modified content just as
(say) TransientNode instances, without trying to keep track of how
they came to exist? Then, when you actually need the change log, you
should still be able to construct it by diffing the transient tree
against the persistent base state of the content tree. The only caveat
I know of is that moves can only be reliably detected for
referenceable nodes or ones with an equivalent internal unique ID
(which we shouldn't have trouble doing if needed).

BR,

Jukka Zitting

[jira] [Commented] (JCR-2650) don't silently merge session-local transient changes with external changes before save().

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201231#comment-13201231
 ] 

Jukka Zitting commented on JCR-2650:


In fact the above deadlock scenario still exists (see JCR-3226). Instead of 
stateCreated(), this issue fixed the potential problem with the (much more 
frequent) stateModified() method.

> don't silently merge session-local transient changes with external changes 
> before save().
> -
>
> Key: JCR-2650
> URL: https://issues.apache.org/jira/browse/JCR-2650
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Stefan Guggisberg
> Fix For: 2.2
>
> Attachments: JCR-2650 (cleaned).patch, JCR-2650.patch
>
>
> currently, external changes (i.e. changes committed by other sessions) are 
> silently merged with transient changes. this might potentially cause 
> concurrency issues/inconsistent transient state (see e.g. JCR-2632).
> it would probably be better to isolate transient changes from external 
> changes until they're saved (true copy-on-write). 

--
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] [Created] (JCR-3226) stateCreated deadlock

[Jukka Zitting (Created) (JIRA)]

stateCreated deadlock
-

 Key: JCR-3226
 URL: https://issues.apache.org/jira/browse/JCR-3226
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2, 2.4
Reporter: Jukka Zitting


In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got 
fixed by postponing the work to the save() call.

Unfortunately this still leaves the stateCreated() method vulnerable to a 
similar (though much less likely) deadlock scenario (observed in Jackrabbit 
2.2.x):

Thread A:
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118)
- waiting to lock <0x7ffec8ddfa18> (a 
org.apache.jackrabbit.core.state.NodeState)
- locked <0x7ffec8ddf9d8> (a 
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152)
- locked <0x7ffec8ddf9d8> (a 
org.apache.jackrabbit.core.state.NodeState)
at 
org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791)
at 
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at 
org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428)
at 
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at 
org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398)
at 
org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231)
at 
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309)
at 
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777)
at 
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488)
at 
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351)
at 
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at 
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
at 
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289)
at 
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)

Thread B:
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119)
- waiting to lock <0x7ffec8ddf9d8> (a 
org.apache.jackrabbit.core.state.NodeState)
- locked <0x7ffec8ddfa18> (a 
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869)
- locked <0x7ffec8ddfa18> (a 
org.apache.jackrabbit.core.state.NodeState)
at 
org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836)
at 
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at 
org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42)
at 
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758)

IIUC this can only occur when two sessions are concurrently importing a node 
with the same UUID.

--
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

[RESULT] [VOTE] Release Apache Jackrabbit 2.2.11

[Jukka Zitting]

Hi,

On Tue, Jan 31, 2012 at 11:43 AM, Jukka Zitting  wrote:
> Please vote on releasing this package as Apache Jackrabbit 2.2.11.

The vote passes as follows:

+1 Alex Parvulescu
+1 Bart van der Schans
+1 Jukka Zitting
+1 Michael Dürig

Thanks! I'll push the release out

BR,

Jukka Zitting

Re: [jr3 microkernel] Change log consolidation

[Jukka Zitting]

Hi,

On Fri, Feb 3, 2012 at 7:44 PM, Michael Dürig  wrote:
> While working on a new transient space implementation [1] I discovered that
> recreating a list of changes from transient modifications to the hierarchy
> is like opening a can of worms. Rethinking things it turned out, that it is
> much simpler to directly consolidate the change log.

Sounds useful, especially for cases where potentially conflicting
changes need to be merged. The more we can simplify and/or normalize
changes, the easier merging them is.

An alternative that AFAICT achieves the same effect in perhaps an
easier to understand manner would be to use the state of the content
tree instead of changes to that state as the key concept. Instead of a
commit(changeLog, baseState) method we could have a commit(newState,
baseState) method for persisting changes. The backend could then do a
diff between the two states, which should result in pretty much the
same list of changes as the proposed change log consolidation
mechanism. The only tricky part that I can think of is detecting moves
of non-referenceable nodes, but even that should be doable with hidden
UUIDs like what we already have in current Jackrabbit.

The nice thing about such state-based handling of changes is that the
transient space in any case needs to maintain a representation of the
state of the modified tree.

PS. You might already have discussed and dismissed this idea off-list.
If yes, what was the deal-breaker?

BR,

Jukka Zitting

Re: reopen a closed issue?

[Jukka Zitting]

Hi,

On Fri, Feb 3, 2012 at 4:21 PM, Alex Parvulescu
 wrote:
> How can I reopen a closed issue?

We're using the no-reopen-closed workflow, which explicitly prevents
reopening of closed issues. The idea behind this is to freeze the list
of issues resolved in a given release after that release has been
published.

> I have resolved an issue [0] but shortly after it was accidentally marked as
> 'Closed'. This is not standard workflow, so I'd like to turn it into
> 'Resolved' again until the actual release happens.

In theory we could temporarily change the workflow settings to do
this, but in practice I'd just leave it closed as you can still
comment on or edit the issue if needed. The only downside of an issue
being closed before the release in which the fix is shipped is that
you can't reopen the issue in case the fix turns out to be flawed. If
that becomes a more common problem we can restrict the permission to
close issues only to committers, but for now I'd just leave things
as-is.

BR,

Jukka Zitting

Re: [VOTE] Release Apache Jackrabbit 2.4.0

[Jukka Zitting]

Hi,

On Fri, Feb 3, 2012 at 3:06 PM, Torgeir Veimo  wrote:
> On 3 February 2012 22:53, Jukka Zitting  wrote:
>> A candidate for the Jackrabbit 2.4.0 release is available at:
>
> Feb 4, 2012 12:04:30 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/main] appears to have started a thread
> named [Timer-13] but has failed to stop it. This is very likely to
> create a memory leak.
> Feb 4, 2012 12:04:30 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/main] appears to have started a thread
> named [DynamicPooledExecutor] but has failed to stop it. This is very
> likely to create a memory leak.
> Feb 4, 2012 12:04:32 AM org.apache.catalina.startup.HostConfig deployWAR
>
> Any hope to get these issues fixed?

Is there an issue filed for this? A patch?

Sounds like something we should do for 2.4.1.

BR,

Jukka Zitting

[VOTE] Release Apache Jackrabbit 2.4.0

[Jukka Zitting]

Hi,

A candidate for the Jackrabbit 2.4.0 release is available at:

http://people.apache.org/~jukka/jackrabbit/2.4.0/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/jackrabbit/tags/2.4.0/

The SHA1 checksum of the archive is ff9332ffb571ebd3b22717a8f30e4aa2c5e6d759.

A staged Maven repository is available for review at:

https://repository.apache.org/content/repositories/orgapachejackrabbit-183/

The command for running automated checks against this release candidate is:

$ sh check-release.sh jukka 2.4.0 ff9332ffb571ebd3b22717a8f30e4aa2c5e6d759

Please vote on releasing this package as Apache Jackrabbit 2.4.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit 2.4.0
[ ] -1 Do not release this package because...

My vote is +1.

BR,

Jukka Zitting

[jira] [Resolved] (JCR-3203) GroupImp#getMembers and #getDeclaredMembers should return RangeIterator

[Jukka Zitting (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-3203.


Resolution: Fixed

Resolving for 2.4 to get the change that was already made reflected in the 
release notes. Let's use followup issues for further improvements.

> GroupImp#getMembers and #getDeclaredMembers should return RangeIterator
> ---
>
> Key: JCR-3203
> URL: https://issues.apache.org/jira/browse/JCR-3203
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core, security
>Reporter: angela
>Priority: Minor
> Fix For: 2.4
>
>
> for those cases where the total amount of members can easily be 
> detected/calculated the
> implementations of Group#getMembers() and #getDeclaredMembersOf() should 
> return a RangeIterator.
> so far i found that Group#declaredMembers() can be easily adjusted for those 
> cases where
> the group members are stored in a multivalued property.

--
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-3225) ConcurrentModificationException in QueryStatImpl

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199632#comment-13199632
 ] 

Jukka Zitting commented on JCR-3225:


Merged to the 2.4 branch in revision 1240068.

> ConcurrentModificationException in QueryStatImpl
> 
>
> Key: JCR-3225
> URL: https://issues.apache.org/jira/browse/JCR-3225
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.3.6, 2.3.7
>Reporter: Christan Keller
> Fix For: 2.4
>
>
> Running with qurystats enabled the Query#execute can throw 
> ConcurrentModificationException
> caused by the iterator which backing collection is changed from another thread
> see logQuery method
> Iterator iterator = popularQueries.iterator();
> while (iterator.hasNext()) {
> -->QueryStatDtoImpl qsdi = iterator.next();
> if (qsdi.equals(qs)) {
> qs.setOccurrenceCount(qsdi.getOccurrenceCount() + 1);
> iterator.remove();
> break;
> }
> }
> popularQueries.offer(qs);

--
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

Re: [VOTE] Release Apache Jackrabbit 2.2.11

[Jukka Zitting]

Hi,

On Tue, Jan 31, 2012 at 2:50 PM, Michael Dürig  wrote:
> testCloseSessionWhileRunningGc(org.apache.jackrabbit.core.data.GarbageCollectorTest)

That's JCR-3097 [1]. I added 2.2.11 to the "Affects Versions" field of
that bug, so I'd say we can treat it as a known, non-blocking issue.

[1] https://issues.apache.org/jira/browse/JCR-3097

BR,

Jukka Zitting

[jira] [Updated] (JCR-3097) Occasional testCloseSessionWhileRunningGc test failures

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3097:
---

Affects Version/s: 2.2.11

Occurs also in 2.2.11

> Occasional testCloseSessionWhileRunningGc test failures
> ---
>
> Key: JCR-3097
> URL: https://issues.apache.org/jira/browse/JCR-3097
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.2.11, 2.3
>    Reporter: Jukka Zitting
>Priority: Minor
>
> We see the following test failure every now and then:
> junit.framework.AssertionFailedError: Exception 'session has been closed' 
> expected
>   at junit.framework.Assert.fail(Assert.java:47)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testCloseSessionWhileRunningGc(GarbageCollectorTest.java:68)
> See https://builds.apache.org/job/Jackrabbit-trunk/1686/ for one example.

--
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

Re: [jr3 Microkernel] compiler settings in pom.xml

[Jukka Zitting]

Hi,

On Tue, Jan 31, 2012 at 3:30 PM, Michael Dürig  wrote:
> On 31.1.12 13:31, Jukka Zitting wrote:
>> Are there significant parts of Jackrabbit 3 that would be better
>> expressed in some other programming language than Java, one with which
>> enough of us (at least everyone working on those parts) are familiar
>> and comfortable?
>
> Like Felix guessed I was primarily thinking of Scala. However there are
> other options like Clojure and Kotlin. If it weren't for the JVM I'd even
> say Haskell.

All of these fail to qualify against the criteria of enough of us
being familiar and comfortable with the language.

The only languages besides Java that I think we could seriously
consider for selected components are JavaScript (with Rhino), Python
(with Jython), or possibly C(++) for some lower-level stuff. Even with
these I suspect we'd turn off about 50% of the committers.

BR,

Jukka Zitting

Re: Jackrabbit 2.4 release plan

[Jukka Zitting]

Hi,

On Tue, Jan 31, 2012 at 3:26 PM, Torgeir Veimo  wrote:
> Any hope for support for lucene version > 3.3?

I think it's too late for a potentially risky change like that. It
would have been great to integrate such a change a few weeks or months
ago for 2.3.x if there had been a patch that passed all integration
tests. Now it's best to postpone the Lucene upgrade to Jackrabbit
2.5.x.

BR,

Jukka Zitting

Re: Jackrabbit 2.4 release plan

[Jukka Zitting]

Hi,

On Mon, Jan 16, 2012 at 6:46 PM, Jukka Zitting  wrote:
> I think we should postpone cutting the 2.4.0 release two weeks ahead
> to the end of January.

OK, I think it's now time to start making the release. I already
started drafting the release notes, and will still go through the
issue tracker for any pending tasks that we may have missed.

I won't cut the release candidate before tomorrow at the earliest, so
if you still have some improvements that really should be in 2.4 but
aren't committed yet, please let me know and I'll see what we can do
to get them included. Once the 2.4.0 release is out, we'll switch the
2.4 branch to maintenance mode and target all new features to the
unstable 2.5.x release series.

BR,

Jukka Zitting

Re: [jr3 Microkernel] compiler settings in pom.xml

[Jukka Zitting]

Hi,

On Tue, Jan 31, 2012 at 2:22 PM, Michael Dürig  wrote:
> I'd rather go for a modern language instead of taping things together ;-)

Indeed, that's another point I've been thinking about

Are there significant parts of Jackrabbit 3 that would be better
expressed in some other programming language than Java, one with which
enough of us (at least everyone working on those parts) are familiar
and comfortable?

I'd expect the answer to be no, especially given the latter
constraint, but if we do want to do something like this, now would be
the right time to make that decision.

BR,

Jukka Zitting

Re: [jr3 Microkernel] compiler settings in pom.xml

[Jukka Zitting]

Hi,

On Mon, Jan 30, 2012 at 5:54 PM, Dominique Pfister  wrote:
> So my question is: should we change this setting from 1.5 to 1.6 (which I
> favor) or review our code?

+1 to 1.6

And while we're at it, would people be interested in using a "language
enhancement" tool like Lombok [1] to reduce the amount of commonly
needed boilerplate code? The downside is that the such custom
extensions increase the entry barrier for people trying to understand
the code and might make some tool integration (debugging, etc.) a bit
harder. Personally I think the benefits would be worth it.

[1] http://projectlombok.org/

BR,

Jukka Zitting

[VOTE] Release Apache Jackrabbit 2.2.11

[Jukka Zitting]

Hi,

A candidate for the Jackrabbit 2.2.11 release is available at:

http://people.apache.org/~jukka/jackrabbit/2.2.11/

The release candidate is a zip archive of the sources in:

    http://svn.apache.org/repos/asf/jackrabbit/tags/2.2.11/

The SHA1 checksum of the archive is 9d7c16265ee5c8578fef3b120389a0c22a4e4d4f.

A staged Maven repository is available for review at:

    https://repository.apache.org/content/repositories/orgapachejackrabbit-163/

The command for running automated checks against this release candidate is:

    $ sh check-release.sh jukka 2.2.11 9d7c16265ee5c8578fef3b120389a0c22a4e4d4f

Please vote on releasing this package as Apache Jackrabbit 2.2.11.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

    [ ] +1 Release this package as Apache Jackrabbit 2.2.11
    [ ] -1 Do not release this package because...

My vote is +1.

BR,

Jukka Zitting

[jira] [Commented] (JCR-3221) Jackrabbit in Sling won't bootstrap against oracle

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195464#comment-13195464
 ] 

Jukka Zitting commented on JCR-3221:


The isNew() method of NodePropBundle is managed internally by Jackrabbit. The 
flag is set to false if the bundle is loaded from the underlying persistence 
store, and to true if the bundle was created in memory and is now for the first 
time being persisted.

The SharedItemStateManager initialization code referenced in the stack trace 
above does the following:

if (!hasNonVirtualItemState(rootNodeId)) {
createRootNodeState(rootNodeId, ntReg);
}

Since Jackrabbit is supposed to be the only instance accessing the underlying 
database, there should be no need to double-check this flag with a 
bundleSelectSQL instruction. The only case I can think of when something like 
this could happen is when another Jackrabbit instance is concurrently accessing 
the same database.

I suspect this might rather be a Sling problem instead of a Jackrabbit one. Can 
you check whether you can reproduce the problem with the following command when 
you have no other Java processes running:

$ java -jar jackrabbit-standalone-2.2.10.jar --conf /path/to/repository.xml

If this also fails, please attach the repository.xml file (you can remove any 
sensitive database connection details) so we can try reproducing the problem. 
The above command certainly works with the default Jackrabbit configuration.

> Jackrabbit in Sling won't bootstrap against oracle
> --
>
> Key: JCR-3221
> URL: https://issues.apache.org/jira/browse/JCR-3221
> Project: Jackrabbit Content Repository
>  Issue Type: Test
>  Components: config
>Affects Versions: 2.2.10
> Environment: Windows 7, Java JRE 1.6.0_29
>Reporter: Rohit Nijhawan
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> 1. Trying to use jackrabbit persistence config to Oracle under Sling 
> 2. Trying to run the jackrabbit standalone server against Oracle
> in Sling, seeing this error repeatedly. If I run a DELETE FROM 
> JCR_DEFAULT_BUNDLE, the server starts up in sling but only 28/75 bundles are 
> active and only 101/152 services launch after all the bundles are manually 
> made active by pressing the |>| play button beside them. 
> AuthenticationSupport service never runs. I can log in but not upload content.
> And in the the jackrabbit standalone server, if I delete from 
> JCR_DEFAULT_BUNDLE, the server never starts up fully. It stays at Starting 
> the server...
> I have tried both: the pool.OraclePersistenceManager and 
> bundle.OraclePersistenceManager classes. I've seen similar issues with 
> 'writing the bundle' error but not one that was enforced on a unique 
> constraint from an index.
> 2012-01-26 10:32:14.533 ERROR [main] BundleDbPersistenceManager.java:1108 
> FATAL error while writing the bundle: deadbeef-cafe-babe-cafe-babecafebabe
> java.sql.SQLException: ORA-1: unique constraint 
> (MIC_COMMON_SB.JCR_DEFAULT_BUNDLE_IDX) violated
>   at 
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113) 
> ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) 
> ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) 
> ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:754) ~[na:Oracle 
> JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:972)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1192)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3415)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3521)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:169)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at

[jira] [Resolved] (JCR-3222) Allow servlet filters to specify custom session providers

[Jukka Zitting (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-3222.


   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Jukka Zitting

OK, I've now combined the two approaches. Revision 1236819 is my original patch 
and revision 1236821 a modified version of Felix' patch with support for 
potentially more than just a single external SessionProvider service. Note that 
the request attribute mechanism works for all webdav servlets, while the OSGi 
service mechanism only works for the davex servlet (since it's the only servlet 
configured as an OSGi service).

Additionally in revision 1236820 I moved some extra SessionProviderImpl code 
(added in JCR-2539 and JCR-2542) to the JCRWebdavServlet class where it belongs 
better. That clears up the SessionProvider API contract and avoids breaking 
functionality when using custom SessionProvider implementations.

Merged to the 2.4 branch in revision 1236837.


> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 2.4
>
> Attachments: 
> 0001-JCR-3222-Allow-servlet-filters-to-specify-custom-ses.patch, 
> JCR-3222-fmeschbe.patch, jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
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-3221) Jackrabbit in Sling won't bootstrap against oracle

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194970#comment-13194970
 ] 

Jukka Zitting commented on JCR-3221:


Sounds like you may have some other Jackrabbit instance concurrently accessing 
the same database backend. Make sure that you start with a clean database and 
only run a single Jackrabbit instance at a time.

If you you're setting up a cluster, note that you need to explicitly configure 
all nodes instead of just sharing the same repository.xml configuration file. 
See http://wiki.apache.org/jackrabbit/Clustering for details.

> Jackrabbit in Sling won't bootstrap against oracle
> --
>
> Key: JCR-3221
> URL: https://issues.apache.org/jira/browse/JCR-3221
> Project: Jackrabbit Content Repository
>  Issue Type: Test
>  Components: config
>Affects Versions: 2.2.10
> Environment: Windows 7, Java JRE 1.6.0_29
>Reporter: Rohit Nijhawan
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> 1. Trying to use jackrabbit persistence config to Oracle under Sling 
> 2. Trying to run the jackrabbit standalone server against Oracle
> in Sling, seeing this error repeatedly. If I run a DELETE FROM 
> JCR_DEFAULT_BUNDLE, the server starts up in sling but only 28/75 bundles are 
> active and only 101/152 services launch after all the bundles are manually 
> made active by pressing the |>| play button beside them. 
> AuthenticationSupport service never runs. I can log in but not upload content.
> And in the the jackrabbit standalone server, if I delete from 
> JCR_DEFAULT_BUNDLE, the server never starts up fully. It stays at Starting 
> the server...
> I have tried both: the pool.OraclePersistenceManager and 
> bundle.OraclePersistenceManager classes. I've seen similar issues with 
> 'writing the bundle' error but not one that was enforced on a unique 
> constraint from an index.
> 2012-01-26 10:32:14.533 ERROR [main] BundleDbPersistenceManager.java:1108 
> FATAL error while writing the bundle: deadbeef-cafe-babe-cafe-babecafebabe
> java.sql.SQLException: ORA-1: unique constraint 
> (MIC_COMMON_SB.JCR_DEFAULT_BUNDLE_IDX) violated
>   at 
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113) 
> ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) 
> ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) 
> ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:754) ~[na:Oracle 
> JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:972)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1192)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3415)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3521)
>  ~[na:Oracle JDBC Driver version - "10.2.0.5.0"]
>   at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:169)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:169)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at 
> org.apache.jackrabbit.core.util.db.ConnectionHelper.execute(ConnectionHelper.java:474)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at 
> org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyUpdate(ConnectionHelper.java:335)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at 
> org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:323)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at 
> org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:319)
>  ~[jackrabbit-standalone-2.2.10.jar:na]
>   at 
> org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(ConnectionHelper.java:487)
>  ~[jackrabbit-s

[jira] [Updated] (JCR-3222) Allow servlet filters to specify custom session providers

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3222:
---

Attachment: 0001-JCR-3222-Allow-servlet-filters-to-specify-custom-ses.patch

> But I don't like this -- special case handling affecting all but used by one 
> only.

You don't have the same concern about injecting the ResourceResolver instance 
as a request attribute? Just like the OSGi service space, the attributes 
support in servlet requests (or servlet context, etc.) is a whiteboard shared 
by multiple providers and consumers. Why would adding a properly namespaced 
attribute affect anyone but the consumer of that attribute?

Additionally, the AuthHttpContext class in the Sling davex bundle is already 
designed specifically for the needs of the davex servlet (it needs to interpret 
the workspace part of the URL). So I don't see how this would affect anyone but 
the davex servlet.

Anyway, I guess we should simply allow both approaches and let downstream users 
decide which mechanism they want to use.

PS. Sorry about uploading the wrong file above... :-) I've uploaded the actual 
patch.

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: 
> 0001-JCR-3222-Allow-servlet-filters-to-specify-custom-ses.patch, 
> JCR-3222-fmeschbe.patch, jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
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] [Updated] (JCR-3223) Disallow unregistering of node types still (possibly) in use

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3223:
---

Fix Version/s: 2.4

Thanks!

Since this accidental "feature" has been out for quite a while in Jackrabbit 
2.1 and 2.2, there are probably already users who are relying on this mistaken 
behavior. To avoid breaking the functionality entirely for such users, I 
introduced a -DdisableCheckForReferencesInContentException=true feature flag in 
in trunk revision 1236709 and merged it also to the 2.2 and 2.1 branches. 
Setting that system property will restore the earlier broken behavior where the 
exception from checkForReferencesInContent() was disabled.

> Disallow unregistering of node types still (possibly) in use
> 
>
> Key: JCR-3223
> URL: https://issues.apache.org/jira/browse/JCR-3223
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.1.6, 2.2.10
>Reporter: Berry van Halderen
>Assignee: Berry van Halderen
> Fix For: 2.1.7, 2.2.11, 2.4
>
>


--
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

Re: Reloading node types in clustered environment

[Jukka Zitting]

Hi,

On Fri, Jan 27, 2012 at 2:26 PM, Berry van Halderen
 wrote:
> Small investigation shows that some fix for JCR-2587 inadvertently
> contained this change, which was reverted (much) later on the trunk,
> but after the 2.1.x and 2.2.x branch were made.

Argh, we definitely should fix that. Good catch!

> Though not a big issue, I'd like to merge this change also back
> into the 2.1.x and 2.2.x branches (unless objections, I'll do this).

Please do so. I'm all set to cut the 2.2.11 release candidate, and
having this fix in would be great.

BR,

Jukka Zitting

[jira] [Commented] (JCR-3222) Allow servlet filters to specify custom session providers

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194663#comment-13194663
 ] 

Jukka Zitting commented on JCR-3222:


> This is wrong. 

That's what the HttpContext.handleSecurity() method does, right? It's needs to 
be able to take over the entire processing of a request.

> By having a contextId service property a whiteboard servlet service can refer 
> to a whiteboard
> HttpContext service which implements that method accordingly.

You need some code to actually implement the HttpContext interface. That code 
could simply do request.setAttribute(SessionProvider.class.getName(), 
customSessionProvider) in the handleSecurity() method, right? I don't see why 
the SessionProvider instance would need to be an OSGi service in this case.

Of course, if there is a case why some component would want to implement the 
SessionProvider interface without the ability to terminate request processing 
or to send a custom HTTP response, then I could see why accessing 
SessionProviders as OSGi services would be useful. In such a case though, we 
should support potentially more than just a single SessionProvider service and 
make sure that the releaseSession() calls get routed to the correct provider 
(which your current patch doesn't guarantee).


> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>      Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: JCR-3222-fmeschbe.patch, 
> jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
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

Re: Reloading node types in clustered environment

[Jukka Zitting]

Hi,

On Fri, Jan 27, 2012 at 10:35 AM, Berry van Halderen
 wrote:
> I've fixed this in our own code, but still I'm a bit worried about this change
> of behavior It used to be impossible to unregister a node type when it
> was still in use (or at least never to unregister a node type).  Not being
> able to unregister a node type when still in use seems to be the most
> correct semantics.

That should still be the case. The
NodeTypeRegistry.unregisterNodeTypes() method calls the protected
checkForReferencesInContent() method before actually removing the
type. The default implementation of checkForReferencesInContent()
simply throws a RepositoryException with a "not yet implemented"
message, which in practice prevents any node types from being
unregisted.

Until a the checkForReferencesInContent() is properly implemented (see
the javadoc for ideas on how to do that), it's possible for downstream
projects or deployments to override the method in case they already
have some other mechanism for guaranteeing that a node type can safely
be removed. I suppose the repository you're using does override the
method, but doesn't give such a strong guarantee of consistency.

BR,

Jukka Zitting

Re: Clustering persistent storage consistency issues

[Jukka Zitting]

Hi,

On Fri, Jan 27, 2012 at 9:50 AM, Berry van Halderen
 wrote:
> Before a JCR save action, the journal table in the database is
> consulted.  If there are logged actions performed by other Jackrabbit
> instances in the cluster than these actions are imported/replayed first
> (SharedItemStateManager.doExternalUpdate).  Then the actual changes
> are written to the database.  Where this fails, it that in between the
> check for external updates and actually writing stuff into the database,
> there might actually be update performed by another Jackrabbit instance.

That shouldn't be possible since the first cluster node should be
holding the cluster lock during the entire "update-persist" operation.
Thus another cluster node shouldn't be able to make any concurrent
changes.

BR,

Jukka Zitting

[jira] [Commented] (JCR-3222) Allow servlet filters to specify custom session providers

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194180#comment-13194180
 ] 

Jukka Zitting commented on JCR-3222:


I considered the OSGi whiteboard pattern for this, but it doesn't work for the 
Sling davex bundle. The Sling authentication code needs to be able to take over 
the entire processing of a request instead of just servicing a getSession() 
call. Thus a Sling component that interacts with the default Jackrabbit davex 
servlet in any case needs to be set up as a servlet filter (or a subclass like 
it currently is). Therefore passing the appropriate SessionProvider as a 
request attribute is IMHO a much more straightforward solution. And it works 
nicely also in non-OSGi deployments.

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: JCR-3222-fmeschbe.patch, 
> jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
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] [Updated] (JCR-3222) Allow servlet filters to specify custom session providers

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3222:
---

Attachment: jackrabbit-jcr-server-2.6-SNAPSHOT.jar

Proposed patch.

> Allow servlet filters to specify custom session providers
> -
>
> Key: JCR-3222
> URL: https://issues.apache.org/jira/browse/JCR-3222
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server
>    Reporter: Jukka Zitting
>Priority: Minor
> Attachments: jackrabbit-jcr-server-2.6-SNAPSHOT.jar
>
>
> In order to integrate the Jackrabbit davex server functionality with their 
> custom authentication logic, the Sling project currently needs to embed and 
> subclass the davex servlet classes. It would be cleaner if such tight 
> coupling wasn't needed.
> One way to achieve something like that would be to allow external components 
> to provide a custom SessionProvider instance as an extra request attribute. 
> This way for example a servlet filter that implements such custom 
> authentication logic could easily make its functionality available to the 
> standard davex servlet in Jackrabbit.

--
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] [Created] (JCR-3222) Allow servlet filters to specify custom session providers

[Jukka Zitting (Created) (JIRA)]

Allow servlet filters to specify custom session providers
-

 Key: JCR-3222
 URL: https://issues.apache.org/jira/browse/JCR-3222
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-server
Reporter: Jukka Zitting
Priority: Minor


In order to integrate the Jackrabbit davex server functionality with their 
custom authentication logic, the Sling project currently needs to embed and 
subclass the davex servlet classes. It would be cleaner if such tight coupling 
wasn't needed.

One way to achieve something like that would be to allow external components to 
provide a custom SessionProvider instance as an extra request attribute. This 
way for example a servlet filter that implements such custom authentication 
logic could easily make its functionality available to the standard davex 
servlet in Jackrabbit.

--
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

Re: [jr3 Microkernel] how should we handle failed save operations?

[Jukka Zitting]

Hi,

On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürig  wrote:
> In an earlier discussion (probably offline), we decided to not implement
> Item.refresh() since it doesn't go well with the MVCC model jr3 is based on.

I'd implement Item.refresh() like this:

public void refresh(boolean keepChanges) throws RepositoryException {
if (!keepChanges) {
discardTransientChangesBelowThisItem();
}

// Update the MVCC base state of this session to the latest
// state of the workspace.
getSession().refresh(true);
}

In other words, Item.refresh() would always trigger a refresh() of the
entire session. That's OK spec-wise, since it's always OK for the
implementation to refresh the session state at any point of time it
wants.

> Furthermore, JCR doesn't have an Item.undo() method for undoing changes.

I'd treat refresh(false) as undo(), both on Item and Session level.

> This may lead to problems when a Session.save() fails due to the underlying
> Microkernel.commit failing because it detected a conflict. Now there might
> be some transient changes (like deletions) which can't be selectively undone
> by the user. So the user is left with a transient space containing his
> changes but he can only discard them as a whole. Not very satisfactory.

I think that's fine, especially if we implement Item.refresh(false)
with an internal discardTransientChangesBelowThisItem() operation as
described above.

> 1) The Microkernel makes as much effort as possible to three way merge
> changes.

I think we should do this in any case.

> 2) The user needs to do a session refresh with keep changes = true and save
> again.

I'd always automatically trigger a refresh(true) at the beginning of a
save() call.

> 3) Introduce a Item.undo method on the JCR API.

As mentioned above, I think Item.refresh(false) could already cover
the required functionality.

BR,

Jukka Zitting

Re: Build failed in Jenkins: Jackrabbit-2.2 #57

[Jukka Zitting]

Hi,

On Wed, Jan 25, 2012 at 5:10 PM, Apache Jenkins Server
 wrote:
> Jan 25, 2012 4:10:54 PM hudson.remoting.Channel$ReaderThread run
> SEVERE: I/O error in channel channel
> java.io.StreamCorruptedException
>        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332)
>        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
>        at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109)
> killed.
> channel stopped

Trouble again with Apache's Jenkins server. I'll look at alternative
locations for running our CI builds.

BR,

Jukka Zitting

[jira] [Updated] (JCR-3210) NPE in spi2dav when server does not send all headers

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3210:
---

Affects Version/s: (was: 2.3.5)
   2.2.10
   2.3.6
Fix Version/s: 2.2.11

Merged to the 2.2 branch in revision 1235796.

> NPE in spi2dav when server does not send all headers
> 
>
> Key: JCR-3210
> URL: https://issues.apache.org/jira/browse/JCR-3210
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Affects Versions: 2.2.10, 2.3.6
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 2.2.11, 2.3.7
>
>
> The ValueLoader may throw a NPE if the desired headers are not present in the 
> response:
> org.apache.jackrabbit.spi2davex.ValueLoader:
> public Map loadHeaders(String uri, String[] headerNames) 
> throws IOException, RepositoryException {
> 
> for (String name : headerNames) {
> --->headers.put(name, 
> method.getResponseHeader(name).getValue());
> }
> .
> }
> In my case, the server does not return the ETag response header, but the 
> 'loadHeaders' is indirectly called by the QValueFactoryImpl:
> this.preInitialize(new String[] {HEADER_ETAG, 
> HEADER_LAST_MODIFIED});

--
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] [Updated] (JCR-3175) InputContextImpl: cannot upload file larger than 2GB

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3175:
---

Affects Version/s: (was: 2.4)
   2.2.10
   2.3.5
Fix Version/s: 2.2.11

Merged to the 2.2 branch in revision 1235791.

> InputContextImpl: cannot upload file larger than 2GB
> 
>
> Key: JCR-3175
> URL: https://issues.apache.org/jira/browse/JCR-3175
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.2.10, 2.3.5
> Environment: Not applicable
>Reporter: Javier Godoy
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.2.11, 2.3.6
>
> Attachments: patch
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> If an entity is larger than 2GB, the Content-Length cannot be obtained by 
> using getIntHeader because of integer overflow. One needs to parse the value 
> of the header from string to long. This issue affects 
> InputContextImpl.getContentLength() in org.apache.jackrabbit.webdav.io from 
> webdav/java (the current behavior is that the header is converted from string 
> to int by the servlet API, then from int to long by Jackrabbit)
> Testcase: largefile from Litmus. (test 3 - large_put fails when the PUT 
> request is received)

--
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] [Updated] (JCR-3174) Destination URI should be normalized

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3174:
---

Affects Version/s: 2.2.10
Fix Version/s: 2.2.11

Merged to the 2.2 branch in revision 1235779.

> Destination URI should be normalized
> 
>
> Key: JCR-3174
> URL: https://issues.apache.org/jira/browse/JCR-3174
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Affects Versions: 2.2.10, 2.3.6
> Environment: Not applicable
>Reporter: Javier Godoy
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.2.11, 2.3.6
>
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> WebdavRequestImpl.getHrefLocator tests if the URI passed as parameter starts 
> with the context path, and passes the next segments to the locator factory.
>  
> There is a potential hole if the parameter contains "..", because 
> "http://example.com/dav/../foo"; starts with the context path 
> "http://example.com/dav"; but represents to "http://example.com/foo";. 
> Currently, it is up to the locator factory to detect this situation, meaning 
> that every locator factory should implement this check. Additionally, 
> DavLocatorFactory.createResourceLocator cannot throw exceptions, hence it 
> would not fail cleanly (RuntimeException causing a 500 INTERNAL SERVER ERROR 
> response, when a 403 FORBIDDEN status code would have been apropriate)
> Note that the Request-URI should have already been normalized by the servlet 
> container, but in COPY/MOVE operations, the Destination-URI is not normalized.
> Conformant clients MUST NOT use dot-segments ("." or "..")  [RFC 4918, 
> Section 8.3] in Simple-Ref constructions such as the Destination header [RFC 
> 4918, Section 10.3]), but the server should be able to detect this error.
> Proposed change in WebdavRequestImpl:193 (in package 
> org.apache.jackrabbit.webdav from webdav/java)
> - ref = uri.getRawPath();
> + ref = uri.normalize().getRawPath();
> (This causes /dav/../foo to be rejected because it doesn't start with the 
> context path, and accepts dav/foo/../bar because it starts with the context 
> path)

--
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] [Updated] (JCR-3167) Make Jackrabbit compile on Java 7

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3167:
---

Fix Version/s: 2.2.11

Merged to the 2.2 branch in revision 1235761.

> Make Jackrabbit compile on Java 7
> -
>
> Key: JCR-3167
> URL: https://issues.apache.org/jira/browse/JCR-3167
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>    Reporter: Jukka Zitting
>    Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 2.2.11, 2.3.5
>
>
> Compiling on Java 7 fails with the following error:
> 
> jackrabbit-core/src/main/java/org/apache/jackrabbit/core/util/db/DataSourceWrapper.java:[30,7]
>  error:
> DataSourceWrapper is not abstract and does not override abstract method 
> getParentLogger() in CommonDataSource
> We should fix that.

--
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] [Updated] (JCR-3148) Using transactions still leads to memory leak

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3148:
---

Fix Version/s: 2.2.11

Merged to the 2.2 branch in revision 1235755.

> Using transactions still leads to memory leak
> -
>
> Key: JCR-3148
> URL: https://issues.apache.org/jira/browse/JCR-3148
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 2.2.5
>Reporter: Boris Pruessmann
>Assignee: Claus Köll
> Fix For: 2.2.11, 2.3.4
>
> Attachments: XASessionImpl.patch
>
>
> This is a result of the way that JCR-395 was fixed. If you look at the code, 
> you'll see that txGlobal.remove(xid) is called as the last statement in both 
> XASessionImpl.commit() and XASessionImpl.rollback(). However, in both methods 
> an exception could be thrown either as a result of calling tx.commit() (or 
> tx.prepare()) and tx.rollback(). 
> As a result, the transaction will not be removed from txGlobals whenever the 
> commit or the rollback has failed for any reason. My suggestion would be to 
> move the txGlobal.remove(xid) into a finally block.

--
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] [Updated] (JCR-3214) [Lock] weird number for "infinite"

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3214:
---

Fix Version/s: (was: 2.6)
   2.4

Merged to the 2.4 branch in revision 1235746.

> [Lock] weird number for "infinite"
> --
>
> Key: JCR-3214
> URL: https://issues.apache.org/jira/browse/JCR-3214
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, locks
>Reporter: David Buchmann
>Assignee: Julian Reschke
> Fix For: 2.4
>
>
> (this is a follow-up of JCR-3205)
> i am surprised by the davex reply to a lock request with infinite timeout 
> (before and after the fix from JCR-3205):
> Second-2147483
> this number is
> 2^21+50331
> which seems pretty random to me. coincidally, this number is exactly 2^31 - 1 
> (2147483647) without the last 3 digits. can it be that there are some weird 
> string operations happening on server side?

--
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] [Updated] (JCR-3220) simple webdav server does not support lock timeouts

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3220:
---

Affects Version/s: 2.3.7
Fix Version/s: (was: 2.6)
   2.4

Merged to the 2.4 branch in revision 1235743.

> simple webdav server does not support lock timeouts
> ---
>
> Key: JCR-3220
> URL: https://issues.apache.org/jira/browse/JCR-3220
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, locks
>Affects Versions: 2.3.7
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.4
>
>
> The "simple" WebDAV server still does not support lock timeouts (HTTP trace 
> shows MS word requests 3600s timeout but gets infinity).

--
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] [Updated] (JCR-3218) UserImporter should trigger execution AuthorizableActions in case of user/group creation

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3218:
---

Fix Version/s: (was: 2.3.7)
   2.4

Merged to the 2.4 branch in revision 1235741.

> UserImporter should trigger execution AuthorizableActions in case of 
> user/group creation
> 
>
> Key: JCR-3218
> URL: https://issues.apache.org/jira/browse/JCR-3218
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core, security
>Reporter: angela
>Assignee: angela
> Fix For: 2.4
>
>
> in accordance to the new implementation specific extensions made to user 
> mangement in JCR-3118 the user-importer
> should be adjusted as well.

--
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] [Updated] (JCR-3209) lock token validity

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3209:
---

Issue Type: Improvement  (was: Task)

Do we want to include this already in 2.4? Seems like a relatively low-risk 
change so we could still backport this before the 2.4.0 release gets cut.

> lock token validity
> ---
>
> Key: JCR-3209
> URL: https://issues.apache.org/jira/browse/JCR-3209
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-jcr-server, jackrabbit-spi2dav, locks
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.6
>
> Attachments: JCR-3209.diff
>
>
> There are several minor issues in the mapping between JCR lock tokens and 
> WebDAV lock tokens:
> 1) WebDAV lock tokens are supposed to use URI syntax (such as 
> opaquelocktoken: or urn:uuid:)
> 2) The server currently computes lock tokens for session-scoped locks based 
> on the node id; these are not valid JCR lock tokens though and cause 
> exceptions when they are re-added when they appear in a Lock-Token header or 
> an If header. This will likely cause requests to fail that use both types of 
> locks (yes, maybe academic but should be fixed anyway)
> Proposal:
> a) Map lock tokens to oqaquelocktoken URIs, using a constant UUID plus a 
> postfix encoding the original lock token
> b) Use a syntax that allows to distinguish between tokens for open-scoped 
> locks or session-scoped locks, so that we do not try to add the latter type 
> to the Session (alternatively, handle exceptions doing so gracefully)

--
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] [Updated] (JCR-3216) When fetching node ids in checks for the checker all queries should use the same ordering

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3216:
---

Fix Version/s: (was: 2.5)

> When fetching node ids in checks for the checker all queries should use the 
> same ordering
> -
>
> Key: JCR-3216
> URL: https://issues.apache.org/jira/browse/JCR-3216
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Bart van der Schans
>Assignee: Bart van der Schans
>Priority: Minor
> Fix For: 2.4
>
>
> The "bundleSelectAllIdsSQL" query and the "bundleSelectAllIdsFromSQL" should 
> use the same ordering.

--
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] [Closed] (JCR-2541) spi2dav : EventJournal not implemented

[Jukka Zitting (Closed) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting closed JCR-2541.
--


> spi2dav : EventJournal not  implemented
> ---
>
> Key: JCR-2541
> URL: https://issues.apache.org/jira/browse/JCR-2541
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, jackrabbit-spi2dav, JCR 2.0, 
> observation
>Affects Versions: 2.0
>Reporter: angela
>Assignee: Julian Reschke
> Fix For: 2.3.6
>
> Attachments: 2541.diff, JCR-2541.diff
>
>
> i didn't look at the details just realized that all EventJournalTest of the 
> TCK fail in the setup
> jcr2spi - spi2dav(ex) - jcr-server.
> i assume that this is due to missing implementation (the corresponding SPI 
> method throws UnsupportedRepositoryOperationException).

--
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

Re: Jackrabbit SPI export version

[Jukka Zitting]

Hi,

On Wed, Jan 25, 2012 at 1:06 AM, Tobias Bocanegra  wrote:
> how about adding getSelectorJcrNames() and deprecate the other one?

Yes, we can do that. It just feels silly that we have to go through
hoops like that when AFAICT were the only ones using and implementing
this interface.

And (correct me if I'm wrong), isn't the OSGi framework supposed to be
able to deal with cases where for backwards compatibility reasons more
than one version of a package needs to be present?

I'd understand this desire better if the objection was about 1233468
(the actual API change) rather than 1227240 (the OSGi package version
update). Is there any actual client or implementation code that gets
broken by revision 1233468 but that I didn't already update? Why then
is revision 1227240 causing trouble?

BR,

Jukka Zitting

Re: Jackrabbit SPI export version

[Jukka Zitting]

Hi,

On Wed, Jan 25, 2012 at 12:36 AM, Felix Meschberger  wrote:
> I got a big problem with Jackrabbit SPI version 2.3.7 just released: This 
> increases the
> export version of the org.apache.jackrabit.spi package from 2.4.0 to 3.0.0.

Yes, I changed the SPI in a minor but backwards-incompatible way in
JCR-3198 (the QueryInfo.getSelectorNames signature was clearly wrong,
as selector names are opaque strings, not qualified names). Thus the
increase in the package version.

> Consequence of this is, that I have a hard time updating the Sling DavEx
> bundle to this latest release ...

What's the exact problem you're having?

BR,

Jukka Zitting

[ANNOUNCE] Apache Jackrabbit 2.3.7 released

[Jukka Zitting]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.3.7. The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release.


Release Notes -- Apache Jackrabbit -- Version 2.3.7

Introduction


This is Apache Jackrabbit(TM) 2.3, a fully compliant implementation of the
Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.3 is an unstable series of releases cut directly from
Jackrabbit trunk, with a focus on new features and other improvements.
For production use we recommend the latest stable 2.2 release.

Changes in Jackrabbit 2.3.7
---

New features

  [JCR-2859] Make open scoped locks recoverable

Improvements

  [JCR-3184] extend ConsistencyChecker API to allow adoption of orphaned ...
  [JCR-3185] refactor consistency checks in BundleDBPersistenceManager ...
  [JCR-3199] workspace-wide default for lock timeout
  [JCR-3200] consistency check should get node ids in chunks, not rely on ...
  [JCR-3202] AuthorizableImpl#memberOf and #declaredMemberOf should ...

Bug fixes

  [JCR-2543] spi2dav : Query offset not respected
  [JCR-3189] JCARepositoryManager.createNonTransientRepository throws NPE ...
  [JCR-3194] ConcurrentModificationException in CacheManager.
  [JCR-3195] wrong assumptions in test cases about lock tokens
  [JCR-3198] Broken handling of outer join results over davex
  [JCR-3205] Missing support for lock timeout and ownerHint in jcr-server
  [JCR-3210] NPE in spi2dav when server does not send all headers

Changes in Jackrabbit 2.3.6
---

New features

  [JCR-3005] Make it possible to get multiple nodes in one call via davex
  [JCR-3183] Add memory based bundle store

Improvements

  [JCR-3162] Index update overhead on cluster slave due to JCR-905
  [JCR-3172] implement PERSIST events for the EventJournal
  [JCR-3177] Remove jdk 1.4 restriction for jcr-tests
  [JCR-3178] Improve error messages for index aggregates

Bug fixes

  [JCR-2541] spi2dav : EventJournal not  implemented
  [JCR-2930] same named child nodes disappear on restore
  [JCR-3174] Destination URI should be normalized
  [JCR-3175] InputContextImpl: cannot upload file larger than 2GB
  [JCR-3176] JCARepositoryManager does not close InputStream

Changes in Jackrabbit 2.3.5
---

Improvements

  [JCR-2887] Split PrivilegeRegistry in a per-session manager instance ...
  [JCR-2906] Multivalued property sorted by last/random value
  [JCR-3138] Skip sync delay when changes are found
  [JCR-3161] Add JcrUtils.getPropertyTypeNames
  [JCR-3165] Consolidate compare behaviour for Value(s) and Comparable(s)
  [JCR-3167] Make Jackrabbit compile on Java 7
  [JCR-3170] Precompile JavaCC parsers in jackrabbit-spi-commons

Bug fixes

  [JCR-3159] LOWER operand with nested LOCALNAME operand not work with SQL2
  [JCR-3160] Session#move doesn't trigger rebuild of parent node aggregation
  [JCR-3163] NPE in RepositoryServiceImpl.getPropertyInfo()

Changes in Jackrabbit 2.3.4
---

New features

  [JCR-2936] JMX Bindings for Jackrabbit
  [JCR-3040] JMX Stats for the Session
  [JCR-3140] Add configurable hook for password validation
  [JCR-3154] Stats for Queries continued

Improvements

  [JCR-3129] It should be possible to create a non-transient Repository ...
  [JCR-3133] Query Stats should use the TimeSeries mechanism
  [JCR-3142] Create OSGi Bundles from jackrabbit-webdav and ...
  [JCR-3143] SessionImpl#isSupportedOption: Skip descriptor evaluation ...
  [JCR-3146] Text extraction may congest thread pool in the repository

Bug fixes

  [JCR-2539] spi2dav: Observation's user data not property handled
  [JCR-2540] spi2dav : move/reorder not properly handled by observation
  [JCR-2542] spi2dav: EventFilters not respected
  [JCR-3148] Using transactions still leads to memory leak
  [JCR-3149] AccessControlProvider#getEffectivePolicies for a set of ...
  [JCR-3151] SharedFieldCache can cause a memory leak
  [JCR-3152] AccessControlImporter does not import repo level ac content
  [JCR-3156] Group#getMembers may list inherited members multiple times

Changes in Jackrabbit 2.3.3
---

New features

  [JCR-3118] Configurable actions upon authorizable creation and removal

Improvements

  [JCR-1443] ake JCAManagedConnectionFactory non final, so it can be extended
  [JCR-2798] JCAManagedConnectionFactory should chain cause exception
  [JCR-3120] Change log level in UserManagerImpl#getAuthorizable(NodeImpl) ...
  [JCR-3127] Upgrade to Tika 0.10
  [JCR-3132] Test tooling updates
  [JCR-3135] Upgrade to Logback 1.0
  [JCR-3136] Add m2e lifecycle mappings for Eclipse Indigo
  [JCR-3141] Upgrade to Tika 1.0

Bug fixes

  [JCR-3093] Inconsistency between Session.getProperty and Node
  [JCR-3110] QNodeTypeDef

Re: "FineGrainedISMLocking" not allowing read while write lock is acquired.

[Jukka Zitting]

Hi,

On Mon, Jan 23, 2012 at 2:31 PM, Mahesh  wrote:
> Still after changing ISMLocking to ‘FineGrainedISMLocking’ there are
> read locks waiting. Hence I am confused and stuck.

Looks like your threads are blocked accessing version histories.
Access to the version storage is controlled by a separate read/write
lock.

BR,

Jukka Zitting

Jackrabbit 2.2.11 release plan

[Jukka Zitting]

Hi,

We have a need for a new Jackrabbit 2.2 patch release with the
JCR-3107 improvement included. There are also a number of smaller bug
fixes that could be backported.

Thus I'm planning to cut a Jackrabbit 2.2.11 release candidate within
the next few days. Please let me know if you'd like to see some
specific fixes included.

Note that normally we only include bugfixes in patch releases from
maintenance branches, but the benefit/risk ratio of the JCR-3107
improvement seems high enough to justify including it in 2.2.x.

BR,

Jukka Zitting

[RESULT] [VOTE] Release Apache Jackrabbit 2.3.7

[Jukka Zitting]

Hi,

On Thu, Jan 19, 2012 at 7:23 PM, Jukka Zitting  wrote:
> Please vote on releasing this package as Apache Jackrabbit 2.3.7.

The vote passes as follows (* marks a PMC member):

+1 Bart van der Schans *
+1 Claus Köll *
+1 David Buchmann
+1 Jukka Zitting *
+1 Tobias Bocanegra *

Thanks! I'll push the release out.

PS. David, can you file a bug report about the problem you described?
It sounds like it could be a regression from JCR-3198.

BR,

Jukka Zitting

Re: [jr3] Orderable child nodes: required (to be the default)?

[Jukka Zitting]

Hi,

On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegra  wrote:
> so for large childnode lists, a stable but uncontrollable order
> would be ok, although violating the spec?

I wouldn't violate the spec for this. If you have an orderable node
(like nt:unstructured), then the repository should keep track of the
order of child nodes regardless of how many they are. IMHO it's OK for
the repository *not* to scale up or perform well if someone dumps a
million child nodes to an orderable parent.

However, it would be great if we could implement efficient storage for
nodes with lots (i.e. millions) of unorderable children. In such a
case I'd say we can expect the client to explicitly use a parent node
with a custom node type that doesn't require orderability.

I wouldn't even promise a stable iteration order for such cases. The
repository should be free to for example reorder the internal data
structure based on frequent access patterns.

BR,

Jukka Zitting

Re: [jr3] Orderable child nodes: required (to be the default)?

[Jukka Zitting]

Hi,

Thinking about this more generally, it would definitely be useful to
be able to use a more efficient underlying storage for unorderable
nodes. However, there still are hard use cases that require us to
support orderable nodes as indicated by the type of the parent node.
Thus the implementation basically has two options:

1) Use a single data structure for all nodes, like Jackrabbit
currently does. This simplifies the implementation but prevents us
from enjoying the performance and scalability benefits of unorderable
nodes.

2) Use two data structures, one for orderable and another for
unorderable nodes. This is more complex (not least because it links
node types to the underlying storage model), but is probably required
if we want to efficiently support up to millions of child nodes per a
single parent.

It might also be possible to have the underlying storage model
unorderable, and just include extra ordering metadata at a higher
layer where also node types are handled. Option 2b, if you like, with
probably fairly significant overhead when iterating over nodes (the
implementation would probably need to pre-fetch all child nodes in
advance to access their ordering metadata).

If we do have native support for unorderable nodes, then I wouldn't
promise any particular ordering (alphabetic, insertion order, etc.)
but rather leave it undefined like in Java's Map interface. The
underlying implementation is then free to use whatever ordering it
thinks is best.

PS. Note that ordering affects not just node traversal, but also the
document ordering used in search results. Though in practice we
already now disable document ordering of search results by default.

BR,

Jukka Zitting

Re: Question about consistency checker and node ordering in queries

[Jukka Zitting]

Hi,

On Fri, Jan 20, 2012 at 5:16 PM, Bart van der Schans
 wrote:
> Does anybody have an objection to adding an order clause to the
> "bundleSelectAllIdsSQL" statement? If not, I'll create an issue and
> add it.

Sounds like the right thing to do.

BR,

Jukka Zitting

Re: [jr3] Orderable child nodes: required (to be the default)?

[Jukka Zitting]

Hi,

On Fri, Jan 20, 2012 at 4:35 PM, Thomas Mueller  wrote:
> If we use alphabetical child node lists by default for Jackrabbit 3, then
> we would need to use a different default node type?

Right, though I suppose there are quite a few applications that use
nt:unstructured either as-is or as a base type for many purposes.

> Is it even possible to use a different node type than nt:unstructured
> in Jackrabbit 3?

It is. The default use of nt:unstructured in Jackrabbit 1.x and 2.x
boils down to the use of nt:unstructured as the base type of rep:root.
It should be fairly straightforward to change the root type to specify
an unorderable type as the default for any child nodes.

Doing so may cause some breakage in existing clients that don't
explicitly specify the types they want, but that breakage should be
manageable with proper release notes and workaround instructions.

BR,

Jukka Zitting

[VOTE] Release Apache Jackrabbit 2.3.7

[Jukka Zitting]

Hi,

A candidate for the Jackrabbit 2.3.7 release is available at:

http://people.apache.org/~jukka/jackrabbit/2.3.7/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/jackrabbit/tags/2.3.7/

The SHA1 checksum of the archive is f772f95a79edf2b45ed3fa18d86acd75a0cf0b06.

A staged Maven repository is available for review at:

https://repository.apache.org/content/repositories/orgapachejackrabbit-098/

The command for running automated checks against this release candidate is:

$ sh check-release.sh jukka 2.3.7 f772f95a79edf2b45ed3fa18d86acd75a0cf0b06

Please vote on releasing this package as Apache Jackrabbit 2.3.7.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit 2.3.7
[ ] -1 Do not release this package because...

My vote is +1.

BR,

Jukka Zitting

[jira] [Updated] (JCR-3184) extend ConsistencyChecker API to allow adoption of orphaned nodes to a to-be-specified parent node

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3184:
---

Issue Type: Improvement  (was: Task)

> extend ConsistencyChecker API to allow adoption of orphaned nodes to a 
> to-be-specified parent node
> --
>
> Key: JCR-3184
> URL: https://issues.apache.org/jira/browse/JCR-3184
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.3.7
>
> Attachments: JCR-3184.diff
>
>
> The optional ConsistencyChecker API on persistence managers allows analyzing 
> and fixing storage inconsistencies. The current fixup code though does not 
> attempt to "adopt" orphaned nodes.

--
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] [Updated] (JCR-3185) refactor consistency checks in BundleDBPersistenceManager into a standalone class that could be re-used for other PMs

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3185:
---

Fix Version/s: 2.3.7
   Issue Type: Improvement  (was: Task)

> refactor consistency checks in BundleDBPersistenceManager into a standalone 
> class that could be re-used for other PMs
> -
>
> Key: JCR-3185
> URL: https://issues.apache.org/jira/browse/JCR-3185
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.3.7
>
> Attachments: JCR-3185.diff
>
>
> see subject

--
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] [Updated] (JCR-3181) add test case for recovering from broken version history hierarchy

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3181:
---

Fix Version/s: 2.6
   Issue Type: Improvement  (was: Task)

> add test case for recovering from broken version history hierarchy
> --
>
> Key: JCR-3181
> URL: https://issues.apache.org/jira/browse/JCR-3181
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core, versioning
>Affects Versions: 2.4
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.6
>
>
> The test should exercise recovery from a missing parent node of a VHR.

--
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-3189) JCARepositoryManager.createNonTransientRepository throws NPE with no JCAManagedConnectionFactory.CONFIGFILE_KEY

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189101#comment-13189101
 ] 

Jukka Zitting commented on JCR-3189:


Merged to the 2.4 branch revision 1233365.

> JCARepositoryManager.createNonTransientRepository throws NPE with no 
> JCAManagedConnectionFactory.CONFIGFILE_KEY
> ---
>
> Key: JCR-3189
> URL: https://issues.apache.org/jira/browse/JCR-3189
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jca
>Affects Versions: 2.3.5
>Reporter: Dave Brosius
>Assignee: Claus Köll
>Priority: Minor
> Fix For: 2.4
>
>
> JCARepositoryManager.createNonTransientRepository fails if
> String configFile = 
> parameters.get(JCAManagedConnectionFactory.CONFIGFILE_KEY);
> is null, because
> config = RepositoryConfig.create(configFile, homeDir);
> will always throw an NPE, perhaps the call should just be
> config = RepositoryConfig.create(homeDir);

--
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-3212) add TCK test for Info map of NODE_MOVED event on node reordering

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189093#comment-13189093
 ] 

Jukka Zitting commented on JCR-3212:


FTR, the relevant commit was in revision 1233069. Jira doesn't see it because 
the issue referenced in the commit was JCR-3207. I fixed the commit message 
afterwards with "svn propset --revprop svn:log".

> add TCK test for Info map of NODE_MOVED event on node reordering
> 
>
> Key: JCR-3212
> URL: https://issues.apache.org/jira/browse/JCR-3212
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-jcr-tests, observation
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.6
>
>
> add the TCK test for this problem, and mark this as known test failure for now

--
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] [Updated] (JCR-3200) consistency check should get node ids in chunks, not rely on total count

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3200:
---

Fix Version/s: (was: 2.6)
   2.4

Looks good to me and works for simple tests, so I merged also this one to the 
2.4 branch. Revision 1233349.

> consistency check should get node ids in chunks, not rely on total count
> 
>
> Key: JCR-3200
> URL: https://issues.apache.org/jira/browse/JCR-3200
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.4
>
> Attachments: JCR-3200.diff
>
>
> The PM consistency checker should use the paging feature to fetch nodeIds in 
> chunks, and also not rely on the total number of ids for logging purposes.

--
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

Re: Jackrabbit-trunk - Build # 1821 - Unstable

[Jukka Zitting]

Hi,

Not sure whether this ("Can not rename ... media read only?") is a
problem with the Jenkins slave or something we should look at:

org.apache.jackrabbit.core.data.DataStoreException: Could not add record
at 
org.apache.jackrabbit.core.data.FileDataStore.addRecord(FileDataStore.java:252)
at 
org.apache.jackrabbit.core.data.ConcurrentGcTest.doTest(ConcurrentGcTest.java:133)
at 
org.apache.jackrabbit.core.data.ConcurrentGcTest.testFile(ConcurrentGcTest.java:114)
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:592)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at 
org.apache.jackrabbit.test.ConcurrentTestSuite.access$001(ConcurrentTestSuite.java:29)
at 
org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown 
Source)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: Can not rename
/export/home/hudson/hudson-slave/workspace/Jackrabbit-trunk/trunk/jackrabbit-core/target/ConcurrentGcTest/fs/tmp8592574245007180213.tmp
to 
/export/home/hudson/hudson-slave/workspace/Jackrabbit-trunk/trunk/jackrabbit-core/target/ConcurrentGcTest/fs/2a/1c/dc/2a1cdc6966424a8a5014588bb5a647234a3e38ba
(media read only?)
at 
org.apache.jackrabbit.core.data.FileDataStore.addRecord(FileDataStore.java:225)
... 19 more

BR,

Jukka Zitting



On Thu, Jan 19, 2012 at 10:38 AM, Apache Jenkins Server
 wrote:
> The Apache Jenkins build system has built Jackrabbit-trunk (build #1821)
>
> Status: Unstable
>
> Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1821/ 
> to view the results.

Re: Jackrabbit-trunk - Build # 1818 - Still Failing

[Jukka Zitting]

Hi,

On Wed, Jan 18, 2012 at 4:15 PM, Apache Jenkins Server
 wrote:
> Status: Still Failing

Something wrong with Jenkins. The trunk build itself is fine.

BR,

Jukka Zitting

[jira] [Updated] (JCR-3199) workspace-wide default for lock timeout

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3199:
---

Fix Version/s: (was: 2.5)
   2.4

Merged to the 2.4 branch in revision 1232546.

> workspace-wide default for lock timeout
> ---
>
> Key: JCR-3199
> URL: https://issues.apache.org/jira/browse/JCR-3199
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core, locks
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.4
>
> Attachments: JCR-3199.diff
>
>
> There should be a way to define a workspace-wide default for JCR lock 
> timeouts (in case the code creating the lock did not specify one).

--
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-3205) Missing support for lock timeout and ownerHint in jcr-server

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187869#comment-13187869
 ] 

Jukka Zitting commented on JCR-3205:


Merged to the 2.4 branch in revision 1232530.

> Missing support for lock timeout and ownerHint in jcr-server
> 
>
> Key: JCR-3205
> URL: https://issues.apache.org/jira/browse/JCR-3205
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, locks
>Affects Versions: 2.3.6
>Reporter: David Buchmann
>Assignee: angela
> Fix For: 2.4
>
> Attachments: tcpdump.log
>
>
> trying to set the lock timeout when creating a lock seems not to work over 
> the davex transport. the timeout is always 2147483.
> this was my test code:
> import javax.jcr.*;
> import javax.jcr.lock.*;
> import org.apache.jackrabbit.jcr2spi.RepositoryImpl;
> import org.apache.jackrabbit.jcr2spi.config.RepositoryConfig;
> String url = "http://localhost:8080/server/";;
> String workspace = "tests";
> RepositoryConfig config = new RepositoryConfigImplTest(repoUrl);
> Repository repo = RepositoryImpl.create(config);
> Credentials sc = new SimpleCredentials("admin","admin".toCharArray());
> Session s = repo.login(sc,workspace);
> Node t;
> if (s.getRootNode().hasNode("test")) {
> t = s.getRootNode().getNode("test");
> } else {
> t = s.getRootNode().addNode("test", "nt:unstructured");
> }
> t.addMixin("mix:lockable");
> s.save();
> LockManager m = s.getWorkspace().getLockManager();
> Lock l = m.lock(t.getPath(), false, true, 10, "me");
> System.out.println(l.getSecondsRemaining());
> and the output is 2147483
> the relevant communication fragment is below, i attach the full trace in case 
> i miss something.
> LOCK /server/tests/jcr%3aroot/test HTTP/1.1
> Timeout: Second-10
> Depth: 0
> Link: ; 
> rel="http://www.day.com/jcr/webdav/1.0/session-id";
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: Jakarta Commons-HttpClient/3.0
> Host: localhost:8080
> Content-Length: 254
> Content-Type: text/xml; charset=UTF-8
>  xmlns:D="DAV:"> xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/>me
> HTTP/1.1 200 OK
> Content-Type: text/xml; charset=utf-8
> Content-Length: 450
> Lock-Token: 
> Server: Jetty(6.1.x)
>  xmlns:D="DAV:">  
> xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/>0Second-2147483adminaa724c28-3c24-41e8-a3b4-9fc129adf732
> by the way: if i do not explicitly logout before the program exits, the lock 
> is also not released even though it is session based. should the session not 
> trigger a logout on destruction?

--
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-3203) GroupImp#getMembers and #getDeclaredMembers should return RangeIterator

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187866#comment-13187866
 ] 

Jukka Zitting commented on JCR-3203:


Merged to the 2.4 branch in revision 1232526.

> GroupImp#getMembers and #getDeclaredMembers should return RangeIterator
> ---
>
> Key: JCR-3203
> URL: https://issues.apache.org/jira/browse/JCR-3203
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core, security
>Reporter: angela
>Priority: Minor
> Fix For: 2.4
>
>
> for those cases where the total amount of members can easily be 
> detected/calculated the
> implementations of Group#getMembers() and #getDeclaredMembersOf() should 
> return a RangeIterator.
> so far i found that Group#declaredMembers() can be easily adjusted for those 
> cases where
> the group members are stored in a multivalued property.

--
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-3202) AuthorizableImpl#memberOf and #declaredMemberOf should return RangeIterator

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187865#comment-13187865
 ] 

Jukka Zitting commented on JCR-3202:


Merged to the 2.4 branch in revision 1232526.

> AuthorizableImpl#memberOf and #declaredMemberOf should return RangeIterator
> ---
>
> Key: JCR-3202
> URL: https://issues.apache.org/jira/browse/JCR-3202
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 2.4
>
>
> it would be favorable if the iterator returned by Authorizable#memberOf and 
> #declaredMemberOf
> would return a RangeIterator in order to all the caller to determine the size 
> without having to
> iterate.

--
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] [Updated] (JCR-3195) wrong assumptions in test cases about lock tokens

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3195:
---

Affects Version/s: 2.3.6
Fix Version/s: (was: 2.5)
   2.4

Merged to the 2.4 branch in revision 1232513 as a dependency of JCR-2859.

> wrong assumptions in test cases about lock tokens
> -
>
> Key: JCR-3195
> URL: https://issues.apache.org/jira/browse/JCR-3195
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-tests, test
>Affects Versions: 2.3.6
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.4
>
>
> Several test cases assume that Lock.getLockToken has to return null for locks 
> not attached to the current session. However, this is optional. Citing the 
> Javadoc for getLockToken:
>  * May return the lock token for this lock. If this lock is open-scoped 
> and
>  * the current session either holds the lock token for this lock, or the
>  * repository chooses to expose the lock token to the current session, 
> then
>  * this method will return that lock token. Otherwise this method will
>  * return null.

--
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] [Updated] (JCR-2859) Make open scoped locks recoverable

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-2859:
---

Fix Version/s: (was: 2.5)
   2.4

Merged to the 2.4 branch in revision 1232513.

> Make open scoped locks recoverable
> --
>
> Key: JCR-2859
> URL: https://issues.apache.org/jira/browse/JCR-2859
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: locks
>Reporter: Carsten Ziegeler
>Assignee: Julian Reschke
> Fix For: 2.4
>
> Attachments: JCR-2859.diff, JCR-2859.diff, JCR-2859.patch, 
> OpenScopeLockTest.java
>
>
> The lock tokens for open scoped locks are currently tied to the session which 
> created the lock. If the session dies (for whatever reason) there is no way 
> to recover the lock and unlock the node.
> There is a theoretical way of adding the lock token to another session, but 
> in most cases the lock token is not available.
> Fortunately, the spec allows to relax this behaviour and I think it would 
> make sense to allow all sessions from the same user to unlock the node - this 
> is still in compliance with the spec but would make unlocked locked nodes 
> possible in a programmatic way.

--
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] [Updated] (JCR-3194) ConcurrentModificationException in CacheManager.

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3194:
---

Fix Version/s: 2.4

Merged to the 2.4 branch in revision 1232474.

> ConcurrentModificationException in CacheManager.
> 
>
> Key: JCR-3194
> URL: https://issues.apache.org/jira/browse/JCR-3194
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.3.4
>Reporter: Mat Lowery
> Fix For: 2.4
>
>
> Using the test code below, I was able to produce this stack:
> java.util.ConcurrentModificationException
>   at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762)
>   at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795)
>   at 
> org.apache.jackrabbit.core.cache.CacheManager.logCacheStats(CacheManager.java:164)
>   at 
> org.apache.jackrabbit.core.cache.CacheManager.cacheAccessed(CacheManager.java:137)
>   at 
> org.apache.jackrabbit.core.cache.AbstractCache.recordCacheAccess(AbstractCache.java:122)
>   at 
> org.apache.jackrabbit.core.cache.ConcurrentCache.get(ConcurrentCache.java:122)
>   at 
> org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(MLRUItemStateCache.java:71)
>   at 
> org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(ItemStateReferenceCache.java:139)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1716)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:268)
>   at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:110)
>   at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:175)
>   at 
> org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
>   at 
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
>   at 
> org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:382)
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)
>   at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
>   at 
> org.apache.jackrabbit.core.ItemManager.getRootNode(ItemManager.java:531)
>   at 
> org.apache.jackrabbit.core.SessionImpl.getRootNode(SessionImpl.java:760)
>   at test.JackrabbitTest$1.run(JackrabbitTest.java:37)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> -
> package test;
> import java.io.File;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicBoolean;
> import java.util.concurrent.atomic.AtomicInteger;
> import javax.jcr.Repository;
> import javax.jcr.RepositoryException;
> import javax.jcr.Session;
> import javax.jcr.SimpleCredentials;
> import org.apache.jackrabbit.core.TransientRepository;
> public class JackrabbitTest {
>  public static void main(final String[] args) throws Exception {
>File dir = File.createTempFile("jackrabbit-test", "");
>dir.delete();
>dir.mkdir();
>System.out.println("created temporary directory: " +
>dir.getAbsolutePath());
>dir.deleteOnExit();
>final Repository jcrRepo = new TransientRepository(dir);
>final AtomicBoolean passed = new AtomicBoolean(true);
>final AtomicInteger counter = new AtomicInteger(0);
>ExecutorService executor = Executors.newFixedThreadPool(50);
>Runnable runnable = new Runnable() {
>  @Override
>  public void run() {
>try {
>  Session session = jcrRepo.login(
>  new SimpleCredentials("admin",
>  "admin".toCharArray()));
>  session.getRootNode().addNode("n" +
>  counter.getAndIncrement()); //unique name
>  session.save();
>  session.logout();
>} catch (RepositoryException e) {
>  e.printStackTrace();
>  passed.set(false);
>}
>  }
>};
>System.out.println("Running threads");
>for (int i = 0; i<  500; i++) {
>  executor.execute(

[jira] [Updated] (JCR-3210) NPE in spi2dav when server does not send all headers

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3210:
---

Fix Version/s: (was: 2.6)
   2.4

Merged to the 2.4 branch in revision 1232469.

> NPE in spi2dav when server does not send all headers
> 
>
> Key: JCR-3210
> URL: https://issues.apache.org/jira/browse/JCR-3210
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Affects Versions: 2.3.5
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 2.4
>
>
> The ValueLoader may throw a NPE if the desired headers are not present in the 
> response:
> org.apache.jackrabbit.spi2davex.ValueLoader:
> public Map loadHeaders(String uri, String[] headerNames) 
> throws IOException, RepositoryException {
> 
> for (String name : headerNames) {
> --->headers.put(name, 
> method.getResponseHeader(name).getValue());
> }
> .
> }
> In my case, the server does not return the ETag response header, but the 
> 'loadHeaders' is indirectly called by the QValueFactoryImpl:
> this.preInitialize(new String[] {HEADER_ETAG, 
> HEADER_LAST_MODIFIED});

--
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] [Updated] (JCR-3184) extend ConsistencyChecker API to allow adoption of orphaned nodes to a to-be-specified parent node

[Jukka Zitting (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3184:
---

Fix Version/s: (was: 2.5)
   2.4

Merged to the 2.4 branch in revision 1232414. It'll be useful to have this 
already in 2.4.0.

> extend ConsistencyChecker API to allow adoption of orphaned nodes to a 
> to-be-specified parent node
> --
>
> Key: JCR-3184
> URL: https://issues.apache.org/jira/browse/JCR-3184
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.4
>
> Attachments: JCR-3184.diff
>
>
> The optional ConsistencyChecker API on persistence managers allows analyzing 
> and fixing storage inconsistencies. The current fixup code though does not 
> attempt to "adopt" orphaned nodes.

--
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-3208) locking a node twice yields the same lock token

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187687#comment-13187687
 ] 

Jukka Zitting commented on JCR-3208:


It's probably best to raise an issue in JSR 333 for a clarification on the 
uniqueness requirements on lock tokens.

> locking a node twice yields the same lock token
> ---
>
> Key: JCR-3208
> URL: https://issues.apache.org/jira/browse/JCR-3208
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core, locks
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: JCR-3208.diff
>
>
> Due to the way jackrabbit assigns lock tokens, the same lock token is 
> generated every time a node is locked.
> This seems to contradict a JCR requirement:
> "A lock token is a string that uniquely identifies a particular lock and acts 
> as a key granting lock ownership to any session that hold the token." 
> <http://www.day.com/specs/jcr/2.0/17_Locking.html#17.5%20Lock%20Token>
> ...in that two subsequent locks on the same node get the same token.
> (This may be harmless but we should consider fixing this for compliance 
> reasons)

--
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

Re: Jackrabbit 2.4 release plan

[Jukka Zitting]

Hi,

On Mon, Jan 2, 2012 at 5:17 PM, Jukka Zitting  wrote:
> And there hasn't been much work in trunk or the 2.4 branch since the
> 2.3.6, so also from that perspective we should let things rest a bit
> longer before cutting the first stable 2.4 release.
>
> Thus I suggest that we postpone the 2.4.0 cut date two weeks ahead to
> Tuesday, Jan 17th.

We actually did get some active work done on areas like locking
(including a new configuration option) and I'd like to complete
exposing the query stats by Alex through JMX interfaces before 2.4, so
I think we should postpone cutting the 2.4.0 release two weeks ahead
to the end of January. Instead I'll tomorrow cut a 2.3.7 release
candidate from the latest 2.4 branch after merging any relevant
changes from trunk.

BR,

Jukka Zitting

[jira] [Commented] (JCR-3208) locking a node twice yields the same lock token

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186999#comment-13186999
 ] 

Jukka Zitting commented on JCR-3208:


> admin to unlock

Explicit admin intervention is already taking the repository outside the scope 
of normal JCR semantics, so I wouldn't be too worried about this case.

A similar case could arise if in step 2 user A explicitly hands over the lock 
token to user B, but in that case I'd assume the users to be aware of each 
others actions and synchronize accordingly.

So while it might be useful to do this (and it looks like this could be 
achieved in a backwards-compatible manner), I'm not sure how pressing the issue 
is. If there's an itch to fix this, +1 to proceed.

PS. The one thing that could be a pretty reason to do this is that with the 
lock token based directly on the UUID of the node, anyone with sufficient read 
access to a node can calculate the token of an open-scoped lock and thus unlock 
the node without interaction with an administrator or the original lock holder. 
That could be a security and/or consistency issue in some circumstances.


> locking a node twice yields the same lock token
> ---
>
> Key: JCR-3208
> URL: https://issues.apache.org/jira/browse/JCR-3208
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core, locks
>Reporter: Julian Reschke
>Priority: Minor
>
> Due to the way jackrabbit assigns lock tokens, the same lock token is 
> generated every time a node is locked.
> This seems to contradict a JCR requirement:
> "A lock token is a string that uniquely identifies a particular lock and acts 
> as a key granting lock ownership to any session that hold the token." 
> <http://www.day.com/specs/jcr/2.0/17_Locking.html#17.5%20Lock%20Token>
> ...in that two subsequent locks on the same node get the same token.
> (This may be harmless but we should consider fixing this for compliance 
> reasons)

--
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-3208) locking a node twice yields the same lock token

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186929#comment-13186929
 ] 

Jukka Zitting commented on JCR-3208:


Is this a problem (either in practice or in theory)? The token uniquely 
identifies a lock at any given time in a given workspace. AFAICT that's the 
scope of uniqueness that the spec really requires.

> locking a node twice yields the same lock token
> ---
>
> Key: JCR-3208
> URL: https://issues.apache.org/jira/browse/JCR-3208
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core, locks
>Reporter: Julian Reschke
>Priority: Minor
>
> Due to the way jackrabbit assigns lock tokens, the same lock token is 
> generated every time a node is locked.
> This seems to contradict a JCR requirement:
> "A lock token is a string that uniquely identifies a particular lock and acts 
> as a key granting lock ownership to any session that hold the token." 
> <http://www.day.com/specs/jcr/2.0/17_Locking.html#17.5%20Lock%20Token>
> ...in that two subsequent locks on the same node get the same token.
> (This may be harmless but we should consider fixing this for compliance 
> reasons)

--
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] (JCRSITE-37) Migrate web site from Confluence to Apache CMS

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183476#comment-13183476
 ] 

Jukka Zitting commented on JCRSITE-37:
--

I've now set up the basic CMS site sources and done an initial migration of 
Confluence pages.

I filed INFRA-4311 to set up a staging build so we can start checking how the 
migrated site looks in practice.

> Migrate web site from Confluence to Apache CMS
> --
>
> Key: JCRSITE-37
> URL: https://issues.apache.org/jira/browse/JCRSITE-37
> Project: Jackrabbit Site
>  Issue Type: Task
>  Components: site
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>  Labels: cms
>
> As discussed earlier (http://markmail.org/message/h5zp3f67g5zftltf) we should 
> migrate our web site away from the Confluence wiki to the Apache CMS system 
> (http://www.apache.org/dev/cms.html).

--
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

Re: Jackrabbit-trunk - Build # 1807 - Failure

[Jukka Zitting]

Hi,

On Wed, Jan 4, 2012 at 10:14 PM, Apache Jenkins Server
 wrote:
> The Apache Jenkins build system has built Jackrabbit-trunk (build #1807)
>
> Status: Failure

Jenkins problem again.

BR,

Jukka Zitting

[jira] [Commented] (JCR-3185) refactor consistency checks in BundleDBPersistenceManager into a standalone class that could be re-used for other PMs

[Jukka Zitting (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180372#comment-13180372
 ] 

Jukka Zitting commented on JCR-3185:


> Loading the whole list in memory will run out of memory in many cases. 

That's best handled on the client side, e.g. by making the consistency checker 
process things in chunks of say 1m nodes at a time. I'd track that as a 
separate issue.

> don't log the size

That's what I'd do.

> refactor consistency checks in BundleDBPersistenceManager into a standalone 
> class that could be re-used for other PMs
> -
>
> Key: JCR-3185
> URL: https://issues.apache.org/jira/browse/JCR-3185
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: JCR-3185.diff
>
>
> see subject

--
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] [Resolved] (JCR-2535) jcr-server: Search fails with RepositoryException as Row.getPath() is used with multiple selector names

[Jukka Zitting (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2535.


Resolution: Duplicate

This got fixed in JCR-3198.

> jcr-server: Search fails with RepositoryException as Row.getPath() is used 
> with multiple selector names
> ---
>
> Key: JCR-2535
> URL: https://issues.apache.org/jira/browse/JCR-2535
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, JCR 2.0
>Affects Versions: 2.0
>Reporter: angela
>
> SearchResourceImpl line 246 call Row.getPath() without testing for multiple 
> selector names.
> this causes the query to fail with the following RepositoryException:
> javax.jcr.RepositoryException: More than one selector. Use getPath(String) 
> instead.
> i have the impression this should be easy to fix for somebody familiar with 
> the query. the comment
> says:  // get the path for the first selector and build [...]
> but apparently Row.getPath() isn't the right choice.

--
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] [Resolved] (JCR-3198) Broken handling of outer join results over davex

[Jukka Zitting (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-3198.


   Resolution: Fixed
Fix Version/s: 2.4

Fixed in revision 1227240 and merged to the 2.4 branch in revision 1227247.

> Broken handling of outer join results over davex
> 
>
> Key: JCR-3198
> URL: https://issues.apache.org/jira/browse/JCR-3198
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server, jackrabbit-jcr2spi, 
> jackrabbit-spi, jackrabbit-spi2dav
>Affects Versions: 2.3.6
>    Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>  Labels: davex, join, outer, sql2
> Fix For: 2.4
>
>
> The davex join support added in JCR-3089 only works correctly when the join 
> returns at least one row and none of the returned rows contain null values 
> for any of the selectors. This should be reasonably straightforward to fix.

--
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