jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Haderka <jan.hade...@magnolia.info>
Subject PM - Simple vs. Bundle - mixin removal handling
Date Wed, 23 Jul 2008 15:10:12 GMT

I have a question about purpose of perceived difference in handling
mixins when using Simple or Bundled PM.

Following code (assuming node had mixin mix:versionable before):
leads to difference in stored data based on PM used.
If you perform the operation above and restart your repository
call to:
will return false after restart in both cases, but
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++) {
      if (mixin.equals(vals[i].getString())) {
        return true;
  } catch (PathNotFoundException e) {
    // property not found == can't contain anything
    return false;
  return false;

I think the difference is caused by following code (JR 1.4.5) in
AbstractBundledPersistenceManager (which doesn't seem to have equivalent
in simple PM)

557                // skip primaryType pr mixinTypes properties
558                if (id.getName().equals(QName.JCR_PRIMARYTYPE)
559                    || id.getName().equals(QName.JCR_MIXINTYPES)
560                    || id.getName().equals(QName.JCR_UUID)) {
561                    continue;
562                }

I'm not sure whether it is a bug or not, it doesn't seem to have any
side effects.
Can someone explain to me what is the reason for skipping primary and
mixin types property changes when persisting nodes?

In case it is relevant: I discovered & tested this while working with
Derby bundle & simple PM and using JR 1.4.5 


View raw message