[MAGNOLIA-1140] move to jackrabbit 1.3.3 Created: 13/Oct/06  Updated: 23/Jan/13  Resolved: 05/Nov/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 3.5 RC1

Type: Improvement Priority: Critical
Reporter: Philipp Bärfuss Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Microsoft Word POM & PDM Issue Analysis Workbook.xls    
Issue Links:
relation
is related to MAGNOLIA-1675 jackrabbit: support newer versions of... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MAGNOLIA-1817 Document/script the update of an exis... Sub-task Closed Jan Haderka  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Comments   
Comment by Magnolia International [ 05/Dec/06 ]

1.1.1 has been released

Comment by Fabrizio Giustina [ 15/Dec/06 ]

Jackrabbit version changed pom.xml: everything works fine, no changes are needed. We'll probably have to only fix the nodetype registration to avoid errors logged while checking if nodetypes are already registered, should be done in a better way now.

Comment by Magnolia International [ 18/Dec/06 ]

Reopening for discussion.
(+why not 1.1.1 ?)

Comment by Anthony Ogier [ 18/Dec/06 ]

I was asking myself the same as Grégory ... because with that version, the Excel parser is not usable currently ... I will post an excel file which makes the DMS indexer fail, and then the Document paragraph fails too.

Comment by Anthony Ogier [ 18/Dec/06 ]

The evil file, from POI bugzilla http://issues.apache.org/bugzilla/show_bug.cgi?id=29982

Comment by Sameer Charles [ 18/Dec/06 ]

be careful while moving to 1.1.1
if you update existing project with 1.1.1 you will see hundreds of exceptions from jackrabbit while copying nodes, I did not investigated further.

Comment by Magnolia International [ 19/Dec/06 ]

For the records, impacted commits are rev. 7828 to 7832.

Comment by Fabrizio Giustina [ 19/Dec/06 ]

Hi Grégory,
I think that it's important to move to new jackrabbit version in trunk, at least for testing forward compatibility... I see that several issues have been fixed in 1.1 so I would rather try to keep trunk aligned to the latest version using an "update if it doesn't break" logic more that "stick to the version that was used to work" logic... What could you suggest to people working with magnolia 3.0? Don't upgrate to 3.0.1 if not really strongly needed?

Anyway, looks like jackrabbit 1.2 is also very very close and I would like to properly test magnolia and eventually report problems/bugs we found so that they can be fixed before the release...

(ps about the other deps: I also updated commons-lang and ehcache to the last minor version only after testing them on other projects, they are guarantee to be totally compatable)

Comment by Fabrizio Giustina [ 07/Feb/07 ]

trunk is now using jackrabbit 1.2.1 (and lucene 2..0!), I will test migration from 3.0 -> 3.1-SNAPSHOT on the next days to see if there are problems upgrading an existing jackrabbit 1.0 repository.

Comment by Sameer Charles [ 07/Feb/07 ]

while you are on this, can you please test copy/move operation within and inter workspace.
for me these does not work, I get hundereds of exceptions and its not persisted.

Comment by Fabrizio Giustina [ 18/Feb/07 ]

I did several tests on a website running on magnolia 3.0.1, upgrading the jackrabbit dependency from 1.0.1 to 1.2.1: tested heavy copy operations on website trees with many pages/heavy binary properties, tested move, delete, activate...
result: no problem at all for me by simply upgrading jackrabbit from 1.0.1 to 1.2.1 I got no errors at all.

Sameer, could you post the errors you are getting? Maybe the culprit is not jackrabbit itself, check if the problem for you could be:

  • lucene upgraded to 2.0: you should be able to delete the lucene index and to see if this helps
  • derby version: the new version of jackrabbit uses a newer derby version: although I never had problems in upgrading derby you might want to try with the same version used by magnolia 3.0.1

In a few days jackrabbit 1.2.2 will be out, with the few interesting enhancements related to clustering: as soon as this upgrade issue is cleared I would like to vote a release for 3.1 (as previously said the jackrabbit upgrade really worths it).

Comment by Fabrizio Giustina [ 18/Feb/07 ]

Snippets from jackrabbit release notes:

Apache Jackrabbit 1.2.x is fully compatible with the previous 1.x releases.
A previous Apache Jackrabbit 1.x installation can be upgraded by replacing
the relevant jar files with the new versions (see below). No changes to
repository contents are needed.

[...]

The Apache Lucene dependency used for full text indexing has been upgraded
to version 2.0 in this release. Lucene 2.0 is able to continue using
existing index files, but you can also manually recreate the index with
Lucene 2.0 extensions by removing the "index" directories of a closed
repository. Jackrabbit will automatically re-index content when the
repository is next started.

Also the Apache Derby dependency has been upgraded to version 10.2.
Like Lucene, the new Derby version can keep using existing database files.
New repositories and workspaces will however be created using extensions
and improvements introduced in the 10.2 version.

Comment by David Smith [ 20/Feb/07 ]

Just to add some observations from the peanut gallery on this issue –

I rebuilt the 3.0 branch on Feb. 19, 2007 (rev 8442 I believe), with jackrabbit 1.2.1 and tried it out with a mysql backend. No problems to report here. The debug log of the new magnolia-3.0.2-SNAPSHOT reported a warning NoClassDefFoundError on org.apache.jackrabbit.core.query.PdfTextFilter, but happily boostrapped anyway.

The refactored database persistence manager also transparently reconnected to the MySQL backend after the connection timed-out overnight (yeah!). There was a stack trace or two in the logs, but it still kept working.

As to copy/move operations, I've been doing that within the config workspace w/ no issue.

The build did required running the clean target before building to clear out the older lucene 1.4.x and jackrabbit 1.0 jars.

I also notice they moved the persistence manager classes and left a stub class for backwards compatibility. In a jackrabbit 1.2.x upgrade, WEB-INF/config/repo-conf/jackrabbit*.xml should probably be updated to the new packages for these.

Comment by Fabrizio Giustina [ 22/Feb/07 ]

I just found a different behavior in jackrabbit > 1.0.x that impact magnolia activation:
in jackrabbit 1.0 node.getProperty(ItemType.JCR_PRIMARY_TYPE) returns the original node type for frozen nodes
in jackrabbit 1.2.2 node.getProperty(ItemType.JCR_PRIMARY_TYPE) always returns nt:frozenNode for frozen nodes and you have to call node.getProperty(ItemType.JCR_FROZEN_PRIMARY_TYPE) to get the original node type.

The new behavior looks correct (is this maybe a fix in jackrabbit?) but breaks activation since child nodes are not activated because the frozen nodes are filtered. In order to restore the old behavior I hat to modify Content.getNodeTypeName() by doing:

public String getNodeTypeName() throws RepositoryException {

if (this.node.hasProperty(ItemType.JCR_FROZEN_PRIMARY_TYPE))

{ return this.node.getProperty(ItemType.JCR_FROZEN_PRIMARY_TYPE).getString(); }

return this.node.getProperty(ItemType.JCR_PRIMARY_TYPE).getString();
}

so far, this seems to perfectly reproduce the old behavior and activation works correctly again.
If you are aware of any potential impact of this change in jackrabbit please advice.

Comment by Magnolia International [ 18/Apr/07 ]

regarding the above comment:

  • we also need to correct the isNodeType(Node n,String type) method of the Content class (will do)
  • we need to ensure migration is seamless (i.e that versions created with Magnolia 3.0.x/Jackrabbit1.0 are still useable with M3.1.x/JR1.2.x
Comment by Magnolia International [ 18/Apr/07 ]
  • reimplemented and tested Content.isNodeType(Node node, String type) so that it compares the original node type (jcr:frozenPrimaryType) if the node is frozen and we're NOT specifically looking for frozen nodes (this is needed for the version (p)review to work again)
  • did not reimplement Content.isNodeType(String type); both isNodeType methods should be consistent, but they're implemented differently; I'd like to review this, be more consistent (see below) and reimplement properly.
  • Content.getNodeTypeName() and Content.getNodeType() are inconsistent.
  • we're inconsistent in using node.getPrimaryNodeType() or node.getProperty("jcr:primaryNodeType")
Comment by Fabrizio Giustina [ 25/Apr/07 ]

jackrabbit 1.3 is out, we should jump directly to that version now...

jackrabbit 1.3 is still compatible with previous 1.x versions and it doesn't require any change. We should test the following enhancements in 1.3:

  • use tet extractors instead of text filters (indexing is executed in a background thread)
  • try the new persistence manager bundled with this release which should be faster than the previous ones
Comment by Fabrizio Giustina [ 25/Apr/07 ]

updated poms to 1.3 + updated repository configuration files to use text extractors

Comment by Magnolia International [ 09/May/07 ]

added PlainTextExtractor to repo config files

Comment by Magnolia International [ 03/Aug/07 ]

1.3.1 is out.

Comment by Philipp Bracher [ 15/Aug/07 ]

pom updated to jackrabbit version 1.3.1

Comment by Magnolia International [ 12/Oct/07 ]

1.3.3 was released :-D

Comment by Fabrizio Giustina [ 05/Nov/07 ]

work completed

Generated at Mon Feb 12 03:24:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.