You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Alexandru Popescu <th...@gmail.com> on 2006/03/15 11:29:29 UTC
mixin property and ConstraintViolationException
Hi!
I have an exception in my application that unfortunatelly I cannot
understand. The node on which I work has a mixin: cmed:classifiable, that
declares the following property:
[code]
<propertyDefinition name="category0" requiredType="Long" autoCreated="false"
mandatory="false" onParentVersion="COPY" protected="false" multiple="true"
/>
[/code]
and here is the code that results in the following exception:
[stack]
javax.jcr.nodetype.ConstraintViolationException: no matching property
definition found for {}category0
at
org.apache.jackrabbit.core.nodetype.EffectiveNodeType.getApplicablePropertyDef
(EffectiveNodeType.java:797)
at org.apache.jackrabbit.core.NodeImpl.getApplicablePropertyDefinition(
NodeImpl.java:884)
at org.apache.jackrabbit.core.NodeImpl.getOrCreateProperty(NodeImpl.java
:433)
at org.apache.jackrabbit.core.NodeImpl.getOrCreateProperty(NodeImpl.java
:403)
at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:1891)
at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:1875)
[/stack]
[code]
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
if (collection == null) {
return;
}
// Add all collection element into an Value array
Value[] values = new Value[collection.getSize()];
// initialize the values
parentNode.setProperty(jcrName, values); /// <============== here is
the exception
[/code]
I am wondering what exactly I am doing wrong. Any comments, ideas, hints on
why this is happening would help me pass over this critical problem. I am
using the jackrabit rc1 version.
many thanks in advance,
./alex
--
.w( the_mindstorm )p.
Re: mixin property and ConstraintViolationException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/15/06, Alexandru Popescu <th...@gmail.com> wrote:
> Many thanks for describing the version policy. It makes a lot of sense. And
> I've been also thinking about the export/import functionality as the single
> standard way of assurin content upgrades. Though, this task can be really
> tedious considering a very very big repository. Add to this some binary
> content, and I am quite sure that the export/import would need more than 4Gb
> of RAM for creating and writting the XML, or a very good strategy to slice
> the content.
It is possible to stream the XML imports and exports using SAX events
so we can do that even with moderate RAM requirements, but you are
right in that the XML format is probably not the optimum alternative
for large repositories.
The PersistenceManager abstraction makes it a lot easier for us to
maintain backwards compatibility for stored content as it is possible
to keep the old persistence managers around if we want to introduce
structural changes or other improvements to the storage formats. Thus
the upgrade issue should mostly affect situations where you want to
migrate your content to a persistence manager that is more optimized
to your requirements. This is something that we haven't faced yet, but
once we do, it might be useful to create a lower-level persistence
manager to persistence manager content migration tool.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: mixin property and ConstraintViolationException
Posted by Alexandru Popescu <th...@gmail.com>.
Thank Jukka!
I am not sure that I can fill in a bug yet, because I cannot reproduce the
problem. Probably it was originated in incompatible repository versions.
Many thanks for describing the version policy. It makes a lot of sense. And
I've been also thinking about the export/import functionality as the single
standard way of assurin content upgrades. Though, this task can be really
tedious considering a very very big repository. Add to this some binary
content, and I am quite sure that the export/import would need more than 4Gb
of RAM for creating and writting the XML, or a very good strategy to slice
the content.
However, I have to agree with you that there are no other possibilities :-(.
once again many thanks,
./alex
--
.w( the_mindstorm )p.
On 3/15/06, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> I'm not sure I can help you with the problem you were facing. Can you
> file a bug report with steps to reproduce? I'll comment on the release
> versioning questions though.
>
> On 3/15/06, Alexandru Popescu <th...@gmail.com> wrote:
> > The questions now:
> > - why do these incompatibilities appear when upgrading jackrabbit
> version?
> > - what is the way to recover content before/after an upgrade?
> > - are there any known solutions for this kind of problem?
> > - is this gonna be a problem in the future?
>
> So far there have been no guarantees on backwards compatibility, even
> the 0.9 release explicitly warned about possible compatibility issues
> when upgrading to 1.0. This is however going to change once the 1.0
> release is out.
>
> The plan is to adopt a three-level MAJOR.MINOR.PATCH versioning
> scheme, where each PATCH version (like 1.0.x) will be drop-in
> compatible with other versions of the same MINOR release. PATCH
> releases will be made from the MINOR release branches to fix reported
> bugs, but will contain no new features or non-compatible changes. It
> should always be possible to switch between PATCH releases by just
> changing the jar files and restarting Jackrabbit.
>
> The MINOR releases can contain new features and other internal changes
> but should not break binary compatibility with clients that only use
> the JCR and org.apache.jackrabbit.api interfaces. It is possible
> (although not preferred) that a MINOR release upgrade will require a
> system view export/import or a similar backup/restore procedure for
> existing content and configuration, but clear instructions on doing so
> will be included in the release notes if something like that is
> needed.
>
> MAJOR releases may contain changes to the client APIs and extensive
> internal modifications. The foreseeable future for Jackrabbit is to
> release 2.0 for the JCR 2.0 API in 2007 when the JSR-283 is final.
>
> I hope this answers your questions.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: mixin property and ConstraintViolationException
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
I'm not sure I can help you with the problem you were facing. Can you
file a bug report with steps to reproduce? I'll comment on the release
versioning questions though.
On 3/15/06, Alexandru Popescu <th...@gmail.com> wrote:
> The questions now:
> - why do these incompatibilities appear when upgrading jackrabbit version?
> - what is the way to recover content before/after an upgrade?
> - are there any known solutions for this kind of problem?
> - is this gonna be a problem in the future?
So far there have been no guarantees on backwards compatibility, even
the 0.9 release explicitly warned about possible compatibility issues
when upgrading to 1.0. This is however going to change once the 1.0
release is out.
The plan is to adopt a three-level MAJOR.MINOR.PATCH versioning
scheme, where each PATCH version (like 1.0.x) will be drop-in
compatible with other versions of the same MINOR release. PATCH
releases will be made from the MINOR release branches to fix reported
bugs, but will contain no new features or non-compatible changes. It
should always be possible to switch between PATCH releases by just
changing the jar files and restarting Jackrabbit.
The MINOR releases can contain new features and other internal changes
but should not break binary compatibility with clients that only use
the JCR and org.apache.jackrabbit.api interfaces. It is possible
(although not preferred) that a MINOR release upgrade will require a
system view export/import or a similar backup/restore procedure for
existing content and configuration, but clear instructions on doing so
will be included in the release notes if something like that is
needed.
MAJOR releases may contain changes to the client APIs and extensive
internal modifications. The foreseeable future for Jackrabbit is to
release 2.0 for the JCR 2.0 API in 2007 when the JSR-283 is final.
I hope this answers your questions.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: mixin property and ConstraintViolationException
Posted by Alexandru Popescu <th...@gmail.com>.
I have done the following steps:
- cleaned the repository completely
- added a prefix to category0 property (cmed:category0)
and now I cannot reproduce anymore the problem. This should be the good part
of the story.
The questions now:
- why do these incompatibilities appear when upgrading jackrabbit version?
- what is the way to recover content before/after an upgrade?
- are there any known solutions for this kind of problem?
- is this gonna be a problem in the future?
I am asking all these questions because I am wondering what can be done at
the moment the repository contains tones (and I mean it) of data and a
serious bug is found and I would consider uprading.
Please give me any ideas, comments on these questions. You help is highly
appreciated and needed, before deciding to go in production with such a
system.
many, many thanks in advance,
./alex
--
.w( the_mindstorm )p.
On 3/15/06, Alexandru Popescu <th...@gmail.com> wrote:
>
> Hi!
>
> I have an exception in my application that unfortunatelly I cannot
> understand. The node on which I work has a mixin: cmed:classifiable, that
> declares the following property:
>
> [code]
> <propertyDefinition name="category0" requiredType="Long"
> autoCreated="false" mandatory="false" onParentVersion="COPY"
> protected="false" multiple="true" />
> [/code]
>
> and here is the code that results in the following exception:
>
> [stack]
> javax.jcr.nodetype.ConstraintViolationException: no matching property
> definition found for {}category0
> at
> org.apache.jackrabbit.core.nodetype.EffectiveNodeType.getApplicablePropertyDef
> (EffectiveNodeType.java:797)
> at org.apache.jackrabbit.core.NodeImpl.getApplicablePropertyDefinition
> (NodeImpl.java:884)
> at org.apache.jackrabbit.core.NodeImpl.getOrCreateProperty(
> NodeImpl.java:433)
> at org.apache.jackrabbit.core.NodeImpl.getOrCreateProperty(
> NodeImpl.java:403)
> at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:1891)
> at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:1875)
> [/stack]
>
> [code]
> if (parentNode.hasProperty(jcrName)) {
> parentNode.setProperty(jcrName, (Value[]) null);
> }
>
> if (collection == null) {
> return;
> }
>
>
> // Add all collection element into an Value array
> Value[] values = new Value[collection.getSize()];
> // initialize the values
> parentNode.setProperty(jcrName, values); /// <============== here
> is the exception
> [/code]
>
> I am wondering what exactly I am doing wrong. Any comments, ideas, hints
> on why this is happening would help me pass over this critical problem. I am
> using the jackrabit rc1 version.
>
> many thanks in advance,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>