gmane.comp.apache.jackrabbit.devel

Updated: (JCR-1691) Includes new (old) mimetypes that OpenOfficeTextExtractor can handle

Leslie H. Watter (JIRA — 2008-07-24T19:09:32

[ https://issues.apache.org/jira/browse/JCR-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leslie H. Watter updated JCR-1691: ---------------------------------- Attachment: OpenOfficeTextExtractor-mimetype.patch patch file to add mimetypes supported.

Created: (JCR-1691) Includes new (old) mimetypes that OpenOfficeTextExtractor can handle

Leslie H. Watter (JIRA — 2008-07-24T18:11:31

Includes new (old) mimetypes that OpenOfficeTextExtractor can handle -------------------------------------------------------------------- Key: JCR-1691 URL: https://issues.apache.org/jira/browse/JCR-1691 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-text-extractors Affects Versions: core 1.4.5 Environment: OS: Linux Debian kernel 2.6.18 java version "1.5.0_14" Reporter: Leslie H. Watter Priority: Trivial The following patch adds the old openoffice (1.0 version) mimetypes to have their contents extracted. I've tested with simple files and it worked here. $ cat OpenOfficeTextExtractor-mimetype.patch --- jackrabbit-1.4/jackrabbit-text-extractors/src/main/java/org/apache/jackrabbit/extractor/OpenOfficeTextExtractor.java 2007-12-19 12:57:58.000000000 -0200 +++ jackrabbit-1.4-modified/jackrabbit-text-extractors/src/main/java/org/apache/jackrabbit/extractor/OpenOfficeTextExtractor.

Commented: (JCR-1632) Mixin type loss

Grégory Joseph (JIRA — 2008-07-24T16:55:31

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616533#action_12616533 ] Grégory Joseph commented on JCR-1632: ------------------------------------- wow that'd be awesome :)

Commented: (JCR-1216) Unreferenced sessions should get garbage collected

Thomas Mueller (JIRA — 2008-07-24T15:15:31

[ https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616500#action_12616500 ] Thomas Mueller commented on JCR-1216: ------------------------------------- The problem seems to be TransientRepository.session, which is a HashSet.

Updated: (JCR-1632) Mixin type loss

Jukka Zitting (JIRA — 2008-07-24T14:37:31

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1632: ------------------------------- Fix Version/s: (was: 1.5) core 1.4.6 No problem. Merged to the 1.4 branch in revision 679425. Would you like us to make an official jackrabbit-core 1.4.6 release with this fix?

Re: Component releases, proposed solution

Thomas Müller — 2008-07-24T14:20:40

Hi, USE_DATA_STORE is used in multiple places, I don't think it's a big problem. And at some point the setting can be removed (I think it could be removed by now). This system property is only enabled for testing. If disabled by default, it can be enabled to test an unreleased feature. If enabled by default, it can be used as a 'kill switch' to test if this functionality is responsible for a problem. I don't see a use case where you want to start multiple repositories with different settings. I don't see a use case for that currently. The system property is not something that people need to or should use (unless they want to explicitly test). It is a final field, and initialized only once. The system property is not final, but if clearly documented I don't think there is a risk people use it in production. This flag is used instead of branching, and given the disadvantages of branching I think it is worth thinking about it. In that case there is a bigger risk that people use it in production I thin

Commented: (JCR-1632) Mixin type loss

Grégory Joseph (JIRA — 2008-07-24T14:15:33

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616484#action_12616484 ] Grégory Joseph commented on JCR-1632: ------------------------------------- Any chance this could be backported to 1.4 ?

Updated: (JCR-1632) Mixin type loss

Stefan Guggisberg (JIRA — 2008-07-24T12:35:31

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated JCR-1632: ----------------------------------- Fix Version/s: 1.5

Resolved: (JCR-1690) PM - Simple vs. Bundle - mixin removal handling

Stefan Guggisberg (JIRA — 2008-07-24T12:35:31

[ https://issues.apache.org/jira/browse/JCR-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-1690. ------------------------------------ Resolution: Duplicate Fix Version/s: 1.5 resolving as duplicate of JCR-1632 which i just fixed.

Resolved: (JCR-1632) Mixin type loss

Stefan Guggisberg (JIRA — 2008-07-24T12:33:31

[ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-1632. ------------------------------------ Resolution: Fixed fixed in svn r 679389

Re: Component releases, proposed solution

Jukka Zitting — 2008-07-24T11:16:02

Hi, On Wed, Jul 23, 2008 at 9:35 AM, Felix Meschberger gmail.com> wrote: -1 I'm more a fan of release branches than development branches. Why? a) It makes it easy to produce patch releases containing just bug fixes. Such maintenance releases are important as they can be easily applied in production with low risk of regressions and zero need for configuration changes. b) Release branches only require "one-way merging" from trunk. This is quite simple and pretty well supported by Subversion. Development branches however require "two-way merging", first to keep up with other changes in trunk and then to merge changes back to trunk. The merge tracking feature in Subversion 1.5 makes this easier, but it's still tricky. c) I think it's important that we have all development happening in the same tree. Any extensive development effort that lasts longer than a few weeks will require coordination with other developers, and the easiest way to do that is to keep it in trunk. Our trunk is (and should be)

Re: PM - Simple vs. Bundle - mixin removal handling

Stefan Guggisberg — 2008-07-24T09:49:13

On Thu, Jul 24, 2008 at 9:59 AM, Marcel Reutegger gmx.net> wrote: right, i agree. it's the same problem: there's a bug in AbstractBundlePersistenceManager which may lead to jcr:mixinTypes properties not reflecting the actual set of assigned mixin types. cheers stefan

Resolved: (JCR-1689) Multiple tests test for locking instead of versioning

Marcel Reutegger (JIRA — 2008-07-24T08:25:31

[ https://issues.apache.org/jira/browse/JCR-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1689. ----------------------------------- Resolution: Fixed Fix Version/s: 1.5 Applied patch in revision: 679300 Thank you for reporting this issue and providing a patch.

Re: PM - Simple vs. Bundle - mixin removal handling

Marcel Reutegger — 2008-07-24T07:59:52

Hi, not sure, but I think this has already been reported before. this issue looks very similar: https://issues.apache.org/jira/browse/JCR-1632 regards marcel Jan Haderka wrote:

Re: Component releases, proposed solution

Felix Meschberger — 2008-07-24T06:53:37

Hi, Thomas Müller schrieb: Sure, if it only concerns a single location or limited set of locations. If it touches multiple places, this is not that easy. I basically like the idea but have my reservations with respect to system property use: It makes it difficult in embedded situations and even almost makes it impossible to use in app server or servlet container environments. For example: you want to have two repositories in the same Java VM, one with and one without data store.... If is really just for testing, a "public" field is bad, because this quickly becomes (de-facto) API. And a branch may still be better suited. Probably better -- also for visibility -- would be to have a functionality to provide this kind of setup as part of the Repository descriptors. (And yes, I cannot imagine how to implement this in the InternalValue class you presented. Maybe the use case is slightly wrong in that the InternalValue should just use a "store", which in turn either uses the new data store code

Re: PM - Simple vs. Bundle - mixin removal handling

Jan Haderka — 2008-07-23T20:33:35

You're welcome. :) Reported on jira as https://issues.apache.org/jira/browse/JCR-1690 Cheers, Jan

Created: (JCR-1690) PM - Simple vs. Bundle - mixin removal handling

Jan Haderka (JIRA — 2008-07-23T20:31:31

PM - Simple vs. Bundle - mixin removal handling ----------------------------------------------- Key: JCR-1690 URL: https://issues.apache.org/jira/browse/JCR-1690 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.5 Reporter: Jan Haderka Following code (assuming node had mixin mix:versionable before): node.removeMixin("mix:versionable"); node.save(); leads to difference in stored data based on PM used. If you perform the operation above and restart your repository call to: node.isMixinType("mix:versionable"); will return false after restart in both cases, but doing: hasMixin(node, "mix:versionable"); will return true when repository is using bundled PM. The hasMixin() method just iterates over all values of jcr:mixinTypes property: public static void hasMixin(Node node, String mixin) { try { Value[] vals = node.getProperty("jcr:mixinTypes").getValues(); for (int i = 0; i < vals.length; i++) {

Re: Component releases, proposed solution

Thomas Müller — 2008-07-23T16:50:40

Hi, If done correctly, major new development can be done in the trunk without risk. How to do that: Use a (static final boolean) constant to enable / disable a certain new feature or new code path. It is used in the DataStore implementation. At first, it was disabled (only enabled when I run tests), and now it is enabled by default: class InternalValue { public static final boolean USE_DATA_STORE = Boolean.valueOf(System.getProperty("org.jackrabbit.useDataStore", "true")).booleanValue(); } and then, everywhere where it is required, do this: if (USE_DATA_STORE) { // new code } else { // old code } As an added advantage, it's easy to find out if this feature is responsible for a problem, by disabling the system property. That's a good idea. Regards, Thomas

Re: PM - Simple vs. Bundle - mixin removal handling

Stefan Guggisberg — 2008-07-23T16:39:17

hi jan On Wed, Jul 23, 2008 at 5:10 PM, Jan Haderka magnolia.info> wrote: it's a bug. thanks for your detailed analysis! could please create a jira issue? thanks stefan

Created: (JCR-1689) Multiple tests test for locking instead of versioning

Janne Jalkanen (JIRA — 2008-07-23T15:17:31

Multiple tests test for locking instead of versioning ----------------------------------------------------- Key: JCR-1689 URL: https://issues.apache.org/jira/browse/JCR-1689 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Environment: SVN trunk as of 23-Jul-08 Reporter: Janne Jalkanen Priority: Minor Attachments: jcr-tck-patch.txt Multiple tests claim to check whether versioning is supported, but in reality check for locking. Patch included.

Updated: (JCR-1689) Multiple tests test for locking instead of versioning

Janne Jalkanen (JIRA — 2008-07-23T15:17:31

[ https://issues.apache.org/jira/browse/JCR-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janne Jalkanen updated JCR-1689: -------------------------------- Attachment: jcr-tck-patch.txt Patch fixes three TCK test cases to make the proper check.