Nabble - Jackrabbit - Dev

[jira] Assigned: (JCR-2385) webdav: nullpointer exception while getting the tikka detector

2009-11-05T06:59:32Z

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

angela reassigned JCR-2385:
---------------------------

Assignee: Jukka Zitting

jukka, i guess this is yours :)

> webdav: nullpointer exception while getting the tikka detector
> ---------------------------------------------------------------
>
> Key: JCR-2385
> URL: https://issues.apache.org/jira/browse/JCR-2385
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
> Affects Versions: 2.0-alpha11
> Reporter: Philipp Koch
> Assignee: Jukka Zitting
>
> seems to be introduced by https://issues.apache.org/jira/browse/JCR-2334
> 05.11.2009 14:28:27 *MARK * servletengine: Servlet threw exception:
> java.lang.NullPointerException
> at org.apache.jackrabbit.server.io.DefaultHandler.detect(DefaultHandler.java:668)
> at org.apache.jackrabbit.server.io.XmlHandler.canExport(XmlHandler.java:152)
> at org.apache.jackrabbit.server.io.DefaultHandler.canExport(DefaultHandler.java:557)
> at org.apache.jackrabbit.server.io.PropertyManagerImpl.exportProperties(PropertyManagerImpl.java:58)
> at org.apache.jackrabbit.webdav.simple.DavResourceImpl.initProperties(DavResourceImpl.java:320)
> at org.apache.jackrabbit.webdav.simple.DeltaVResourceImpl.initProperties(DeltaVResourceImpl.java:248)
> at org.apache.jackrabbit.webdav.simple.VersionControlledResourceImpl.initProperties(VersionControlledResourceImpl.java:320)
> at org.apache.jackrabbit.webdav.simple.DavResourceImpl.getProperties(DavResourceImpl.java:300)
> at org.apache.jackrabbit.webdav.MultiStatusResponse.<init>(MultiStatusResponse.java:181)
> at org.apache.jackrabbit.webdav.MultiStatus.addResourceProperties(MultiStatus.java:62)
> at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doPropFind(AbstractWebdavServlet.java:447)
> at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:235)
> at com.day.crx.j2ee.CRXDavServlet.service(CRXDavServlet.java:76)
> at com.day.crx.j2ee.ResourceServlet.service(ResourceServlet.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at com.day.j2ee.servletengine.ServletRuntimeEnvironment.service(ServletRuntimeEnvironment.java:228)
> at com.day.j2ee.servletengine.RequestDispatcherImpl.doFilter(RequestDispatcherImpl.java:315)
> at com.day.j2ee.servletengine.RequestDispatcherImpl.service(RequestDispatcherImpl.java:334)
> at com.day.j2ee.servletengine.RequestDispatcherImpl.service(RequestDispatcherImpl.java:378)
> at com.day.j2ee.servletengine.ServletHandlerImpl.execute(ServletHandlerImpl.java:313)
> at com.day.j2ee.servletengine.DefaultThreadPool$DequeueThread.run(DefaultThreadPool.java:134)
> at java.lang.Thread.run(Thread.java:613)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Unicode, NFC,NFD and node names

2009-11-05T06:39:31Z

2009/11/5 Grégory Joseph <gregory.joseph@...>:

> Hi Toby,
>
> On Nov 5, 2009, at 12:26 AM, Tobias Bocanegra wrote:
>
>> hi,
>> i don't think this should be the job of the repository to do
>> normalization of the paths. likewise a good filesystem (a case
>> sensitive one :-) does no normalization of it's paths neither.
>
> Since I wrote this yesterday in quite a rush, let me just stress the fact
> that I'm only talking about unicode normalization forms; a filesystem won't
> have to bother about that, since it doesn't have a whole slew of clients who
> decide to use one form or the other for no apparent reason. For "fun", you
> might want to see this:
> http://www.mail-archive.com/bug-bash@.../msg05818.html
>
> I can see why one would want to make a differentiation between the 2 forms
> in *values*; in item names, not so much.

well, i see a repository somewhere in between filesystems and databases.

however, i think the path to an item needs to be solid - the search
can still provide you with all stemming and normalization you need.
regards, toby

>
> Thoughts ?
>
> -g
>
>> 2009/11/4 Grégory Joseph <gregory.joseph@...>:
>>>
>>> fwiw, the following solves the simple problem shown by my previous
>>> example:
>>>
>>> private Session wrap(final SessionImpl origSession) throws
>>> RepositoryException {
>>> final WorkspaceImpl workspace = (WorkspaceImpl)
>>> origSession.getWorkspace();
>>> final RepositoryImpl rep = (RepositoryImpl)
>>> origSession.getRepository();
>>> return new SessionImpl(rep, origSession.getSubject(),
>>> workspace.getConfig()) {
>>> public Path getQPath(String path) throws
>>> MalformedPathException,
>>> IllegalNameException, NamespaceException {
>>> // this is the only relevant part:
>>> return super.getQPath(Normalizer.normalize(path,
>>> Normalizer.Form.NFC));
>>> }
>>> };
>>> }
>>>
>>> If there was a way to swap the session implementation or the
>>> Name-and/or-PathResolver implementations that are used by default, I
>>> might
>>> give this a spin.
>>>
>>> Any opinions about the whole problem?
>>>
>>> Cheers,
>>>
>>> -g
>>>
>>> On Nov 4, 2009, at 6:11 PM, Grégory Joseph wrote:
>>>
>>>> Hi list,
>>>>
>>>> Given the following code,
>>>> import java.text.Normalizer;
>>>> ...
>>>>
>>>> final Session session = ...
>>>>
>>>> final Repository rep = session.getRepository();
>>>> System.out.println(rep.getDescriptor("jcr.repository.name") + " " +
>>>> rep.getDescriptor("jcr.repository.version"));
>>>>
>>>> final Node root = session.getRootNode();
>>>> final String name = "föö";
>>>> System.out.println("Normalizer.isNormalized(name,
>>>> Normalizer.Form.NFC) = " + Normalizer.isNormalized(name,
>>>> Normalizer.Form.NFC)); // true
>>>> System.out.println("Normalizer.isNormalized(name,
>>>> Normalizer.Form.NFD) = " + Normalizer.isNormalized(name,
>>>> Normalizer.Form.NFD)); // false
>>>> root.addNode(name);
>>>> session.save();
>>>>
>>>> final Node node1 = root.getNode(name);
>>>> System.out.println("node1 = " + node1);
>>>> final Node node2 = root.getNode(Normalizer.normalize(name,
>>>> Normalizer.Form.NFC));
>>>> System.out.println("node2 = " + node2);
>>>> final Node node3 = root.getNode(Normalizer.normalize(name,
>>>> Normalizer.Form.NFD)); // fails
>>>> System.out.println("node3 = " + node3);
>>>>
>>>> There's a good chance fetching node3 won't work. It might be dependent
>>>> on
>>>> the underlying os and database, but in the case of OSX and Derby, this
>>>> fails. It's not that surprising, really, given that
>>>> Normalizer.normalize(name,
>>>> Normalizer.Form.NFC).equals(Normalizer.normalize(name,
>>>> Normalizer.Form.NFD))
>>>> is NOT true.
>>>>
>>>> Now, taking into account the fact that all sorts of clients will use a
>>>> different Normalizing Form (Firefox seems to encode URL parameters with
>>>> NFD,
>>>> Safari with NFC; linux NFC, OSX finder seems to favor NFD), wouldn't it
>>>> be a
>>>> safe bet to normalize all input at repository level ? Or do you consider
>>>> this is something client applications should do ?
>>>>
>>>> ref: http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms
>>>>
>>>> Thanks for any tip, pointer, idea, feedback or reaction !
>>>>
>>>> Cheers,
>>>>
>>>> -greg
>>>>
>>>>
>>>
>>>
>>>
>
>
>

Re: Unicode, NFC,NFD and node names

2009-11-05T06:27:05Z

Hi Toby,

On Nov 5, 2009, at 12:26 AM, Tobias Bocanegra wrote:

> hi,
> i don't think this should be the job of the repository to do
> normalization of the paths. likewise a good filesystem (a case
> sensitive one :-) does no normalization of it's paths neither.

Since I wrote this yesterday in quite a rush, let me just stress the
fact that I'm only talking about unicode normalization forms; a
filesystem won't have to bother about that, since it doesn't have a
whole slew of clients who decide to use one form or the other for no
apparent reason. For "fun", you might want to see this: http://www.mail-archive.com/bug-bash@.../msg05818.html

I can see why one would want to make a differentiation between the 2
forms in *values*; in item names, not so much.

Thoughts ?

-g

> 2009/11/4 Grégory Joseph <gregory.joseph@...>:
>> fwiw, the following solves the simple problem shown by my previous
>> example:
>>
>> private Session wrap(final SessionImpl origSession) throws
>> RepositoryException {
>> final WorkspaceImpl workspace = (WorkspaceImpl)
>> origSession.getWorkspace();
>> final RepositoryImpl rep = (RepositoryImpl)
>> origSession.getRepository();
>> return new SessionImpl(rep, origSession.getSubject(),
>> workspace.getConfig()) {
>> public Path getQPath(String path) throws
>> MalformedPathException,
>> IllegalNameException, NamespaceException {
>> // this is the only relevant part:
>> return super.getQPath(Normalizer.normalize(path,
>> Normalizer.Form.NFC));
>> }
>> };
>> }
>>
>> If there was a way to swap the session implementation or the
>> Name-and/or-PathResolver implementations that are used by default,
>> I might
>> give this a spin.
>>
>> Any opinions about the whole problem?
>>
>> Cheers,
>>
>> -g
>>
>> On Nov 4, 2009, at 6:11 PM, Grégory Joseph wrote:
>>
>>> Hi list,
>>>
>>> Given the following code,
>>> import java.text.Normalizer;
>>> ...
>>>
>>> final Session session = ...
>>>
>>> final Repository rep = session.getRepository();
>>> System.out.println(rep.getDescriptor("jcr.repository.name")
>>> + " " +
>>> rep.getDescriptor("jcr.repository.version"));
>>>
>>> final Node root = session.getRootNode();
>>> final String name = "föö";
>>> System.out.println("Normalizer.isNormalized(name,
>>> Normalizer.Form.NFC) = " + Normalizer.isNormalized(name,
>>> Normalizer.Form.NFC)); // true
>>> System.out.println("Normalizer.isNormalized(name,
>>> Normalizer.Form.NFD) = " + Normalizer.isNormalized(name,
>>> Normalizer.Form.NFD)); // false
>>> root.addNode(name);
>>> session.save();
>>>
>>> final Node node1 = root.getNode(name);
>>> System.out.println("node1 = " + node1);
>>> final Node node2 = root.getNode(Normalizer.normalize(name,
>>> Normalizer.Form.NFC));
>>> System.out.println("node2 = " + node2);
>>> final Node node3 = root.getNode(Normalizer.normalize(name,
>>> Normalizer.Form.NFD)); // fails
>>> System.out.println("node3 = " + node3);
>>>
>>> There's a good chance fetching node3 won't work. It might be
>>> dependent on
>>> the underlying os and database, but in the case of OSX and Derby,
>>> this
>>> fails. It's not that surprising, really, given that
>>> Normalizer.normalize(name,
>>> Normalizer.Form.NFC).equals(Normalizer.normalize(name,
>>> Normalizer.Form.NFD))
>>> is NOT true.
>>>
>>> Now, taking into account the fact that all sorts of clients will
>>> use a
>>> different Normalizing Form (Firefox seems to encode URL parameters
>>> with NFD,
>>> Safari with NFC; linux NFC, OSX finder seems to favor NFD),
>>> wouldn't it be a
>>> safe bet to normalize all input at repository level ? Or do you
>>> consider
>>> this is something client applications should do ?
>>>
>>> ref: http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms
>>>
>>> Thanks for any tip, pointer, idea, feedback or reaction !
>>>
>>> Cheers,
>>>
>>> -greg
>>>
>>>
>>
>>
>>

[jira] Created: (JCR-2385) webdav: nullpointer exception while getting the tikka detector

2009-11-05T05:56:32Z

webdav: nullpointer exception while getting the tikka detector
---------------------------------------------------------------

Key: JCR-2385
URL: https://issues.apache.org/jira/browse/JCR-2385
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr-server
Affects Versions: 2.0-alpha11
Reporter: Philipp Koch

seems to be introduced by https://issues.apache.org/jira/browse/JCR-2334

05.11.2009 14:28:27 *MARK * servletengine: Servlet threw exception:
java.lang.NullPointerException
at org.apache.jackrabbit.server.io.DefaultHandler.detect(DefaultHandler.java:668)
at org.apache.jackrabbit.server.io.XmlHandler.canExport(XmlHandler.java:152)
at org.apache.jackrabbit.server.io.DefaultHandler.canExport(DefaultHandler.java:557)
at org.apache.jackrabbit.server.io.PropertyManagerImpl.exportProperties(PropertyManagerImpl.java:58)
at org.apache.jackrabbit.webdav.simple.DavResourceImpl.initProperties(DavResourceImpl.java:320)
at org.apache.jackrabbit.webdav.simple.DeltaVResourceImpl.initProperties(DeltaVResourceImpl.java:248)
at org.apache.jackrabbit.webdav.simple.VersionControlledResourceImpl.initProperties(VersionControlledResourceImpl.java:320)
at org.apache.jackrabbit.webdav.simple.DavResourceImpl.getProperties(DavResourceImpl.java:300)
at org.apache.jackrabbit.webdav.MultiStatusResponse.<init>(MultiStatusResponse.java:181)
at org.apache.jackrabbit.webdav.MultiStatus.addResourceProperties(MultiStatus.java:62)
at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doPropFind(AbstractWebdavServlet.java:447)
at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:235)
at com.day.crx.j2ee.CRXDavServlet.service(CRXDavServlet.java:76)
at com.day.crx.j2ee.ResourceServlet.service(ResourceServlet.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at com.day.j2ee.servletengine.ServletRuntimeEnvironment.service(ServletRuntimeEnvironment.java:228)
at com.day.j2ee.servletengine.RequestDispatcherImpl.doFilter(RequestDispatcherImpl.java:315)
at com.day.j2ee.servletengine.RequestDispatcherImpl.service(RequestDispatcherImpl.java:334)
at com.day.j2ee.servletengine.RequestDispatcherImpl.service(RequestDispatcherImpl.java:378)
at com.day.j2ee.servletengine.ServletHandlerImpl.execute(ServletHandlerImpl.java:313)
at com.day.j2ee.servletengine.DefaultThreadPool$DequeueThread.run(DefaultThreadPool.java:134)
at java.lang.Thread.run(Thread.java:613)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

AccessManager isGranted query

2009-11-05T04:56:33Z

Hi guys,

I have implemented a customer access manager class that extends the abstract implementation as provided in the simple example. I have added some code to isGranted(ItemId, int) method that validates the path against my permission system. When I query for multiple items the permission system works fine as the path given for each item is correctly provided, however if a single node is accessed directly by its absolute path the path given to access manager is partial and therefore the validation fails. For example if node is accessed by absolute path: /customer/documents/how_to_use_the_printer the path provided to access managed is: /customer/documents.

Is there are reason for this? and basically how to make it work properly?

Thanks for your help,
ivarsv

[jira] Created: (JCR-2384) Delete Workspace Implementation

2009-11-05T04:40:05Z

Delete Workspace Implementation
-------------------------------

Key: JCR-2384
URL: https://issues.apache.org/jira/browse/JCR-2384
Project: Jackrabbit Content Repository
Issue Type: New Feature
Affects Versions: 2.0-beta1
Reporter: Renaud C.

Implementation for Workspace.deleteWorkspace(...)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2383) JCR Compliance deleteWorkspace not implemented

2009-11-05T02:17:43Z

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

Stefan Guggisberg resolved JCR-2383.
------------------------------------

Resolution: Invalid

from the API javadoc:

<quote>
Throws an UnsupportedRepositoryOperationException if the repository does not support the removal of workspaces.
</quote>

the current implementation does not support removal of workspaces, which is perfectly legal according to the jcr 2.0 spec.

feel free to post an "Improvement" or "New Feature" issue if you need this functionality. patches are of course welcome.

for a related issue, see JCR-1608.

> JCR Compliance deleteWorkspace not implemented
> ----------------------------------------------
>
> Key: JCR-2383
> URL: https://issues.apache.org/jira/browse/JCR-2383
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0-beta1
> Reporter: Renaud C.
>
> JCR API: javax.jcr.Workspace.deleteWorkspace(String)
> => javax.jcr.UnsupportedRepositoryOperationException: not yet implemented

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2383) JCR Compliance deleteWorkspace not implemented

2009-11-05T01:01:54Z

JCR Compliance deleteWorkspace not implemented
----------------------------------------------

Key: JCR-2383
URL: https://issues.apache.org/jira/browse/JCR-2383
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.0-beta1
Reporter: Renaud C.

JCR API: javax.jcr.Workspace.deleteWorkspace(String)

=> javax.jcr.UnsupportedRepositoryOperationException: not yet implemented

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Unicode, NFC,NFD and node names

2009-11-04T15:26:14Z

hi,
i don't think this should be the job of the repository to do
normalization of the paths. likewise a good filesystem (a case
sensitive one :-) does no normalization of it's paths neither.

regards, toby

2009/11/4 Grégory Joseph <gregory.joseph@...>:

> fwiw, the following solves the simple problem shown by my previous example:
>
> private Session wrap(final SessionImpl origSession) throws
> RepositoryException {
> final WorkspaceImpl workspace = (WorkspaceImpl)
> origSession.getWorkspace();
> final RepositoryImpl rep = (RepositoryImpl)
> origSession.getRepository();
> return new SessionImpl(rep, origSession.getSubject(),
> workspace.getConfig()) {
> public Path getQPath(String path) throws MalformedPathException,
> IllegalNameException, NamespaceException {
> // this is the only relevant part:
> return super.getQPath(Normalizer.normalize(path,
> Normalizer.Form.NFC));
> }
> };
> }
>
> If there was a way to swap the session implementation or the
> Name-and/or-PathResolver implementations that are used by default, I might
> give this a spin.
>
> Any opinions about the whole problem?
>
> Cheers,
>
> -g
>
> On Nov 4, 2009, at 6:11 PM, Grégory Joseph wrote:
>
>> Hi list,
>>
>> Given the following code,
>> import java.text.Normalizer;
>> ...
>>
>> final Session session = ...
>>
>> final Repository rep = session.getRepository();
>> System.out.println(rep.getDescriptor("jcr.repository.name") + " " +
>> rep.getDescriptor("jcr.repository.version"));
>>
>> final Node root = session.getRootNode();
>> final String name = "föö";
>> System.out.println("Normalizer.isNormalized(name,
>> Normalizer.Form.NFC) = " + Normalizer.isNormalized(name,
>> Normalizer.Form.NFC)); // true
>> System.out.println("Normalizer.isNormalized(name,
>> Normalizer.Form.NFD) = " + Normalizer.isNormalized(name,
>> Normalizer.Form.NFD)); // false
>> root.addNode(name);
>> session.save();
>>
>> final Node node1 = root.getNode(name);
>> System.out.println("node1 = " + node1);
>> final Node node2 = root.getNode(Normalizer.normalize(name,
>> Normalizer.Form.NFC));
>> System.out.println("node2 = " + node2);
>> final Node node3 = root.getNode(Normalizer.normalize(name,
>> Normalizer.Form.NFD)); // fails
>> System.out.println("node3 = " + node3);
>>
>> There's a good chance fetching node3 won't work. It might be dependent on
>> the underlying os and database, but in the case of OSX and Derby, this
>> fails. It's not that surprising, really, given that
>> Normalizer.normalize(name,
>> Normalizer.Form.NFC).equals(Normalizer.normalize(name, Normalizer.Form.NFD))
>> is NOT true.
>>
>> Now, taking into account the fact that all sorts of clients will use a
>> different Normalizing Form (Firefox seems to encode URL parameters with NFD,
>> Safari with NFC; linux NFC, OSX finder seems to favor NFD), wouldn't it be a
>> safe bet to normalize all input at repository level ? Or do you consider
>> this is something client applications should do ?
>>
>> ref: http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms
>>
>> Thanks for any tip, pointer, idea, feedback or reaction !
>>
>> Cheers,
>>
>> -greg
>>
>>
>
>
>

Re: Unicode, NFC,NFD and node names

2009-11-04T11:36:44Z

fwiw, the following solves the simple problem shown by my previous
example:

private Session wrap(final SessionImpl origSession) throws
RepositoryException {
final WorkspaceImpl workspace = (WorkspaceImpl)
origSession.getWorkspace();
final RepositoryImpl rep = (RepositoryImpl)
origSession.getRepository();
return new SessionImpl(rep, origSession.getSubject(),
workspace.getConfig()) {
public Path getQPath(String path) throws
MalformedPathException, IllegalNameException, NamespaceException {
// this is the only relevant part:
return super.getQPath(Normalizer.normalize(path,
Normalizer.Form.NFC));
}
};
}

If there was a way to swap the session implementation or the Name-and/
or-PathResolver implementations that are used by default, I might give
this a spin.

Any opinions about the whole problem?

Cheers,

-g

On Nov 4, 2009, at 6:11 PM, Grégory Joseph wrote:

> Hi list,
>
> Given the following code,
> import java.text.Normalizer;
> ...
>
> final Session session = ...
>
> final Repository rep = session.getRepository();
> System.out.println(rep.getDescriptor("jcr.repository.name") +
> " " + rep.getDescriptor("jcr.repository.version"));
>
> final Node root = session.getRootNode();
> final String name = "föö";
> System.out.println("Normalizer.isNormalized(name,
> Normalizer.Form.NFC) = " + Normalizer.isNormalized(name,
> Normalizer.Form.NFC)); // true
> System.out.println("Normalizer.isNormalized(name,
> Normalizer.Form.NFD) = " + Normalizer.isNormalized(name,
> Normalizer.Form.NFD)); // false
> root.addNode(name);
> session.save();
>
> final Node node1 = root.getNode(name);
> System.out.println("node1 = " + node1);
> final Node node2 = root.getNode(Normalizer.normalize(name,
> Normalizer.Form.NFC));
> System.out.println("node2 = " + node2);
> final Node node3 = root.getNode(Normalizer.normalize(name,
> Normalizer.Form.NFD)); // fails
> System.out.println("node3 = " + node3);
>
> There's a good chance fetching node3 won't work. It might be
> dependent on the underlying os and database, but in the case of OSX
> and Derby, this fails. It's not that surprising, really, given that
> Normalizer.normalize(name,
> Normalizer.Form.NFC).equals(Normalizer.normalize(name,
> Normalizer.Form.NFD)) is NOT true.
>
> Now, taking into account the fact that all sorts of clients will use
> a different Normalizing Form (Firefox seems to encode URL parameters
> with NFD, Safari with NFC; linux NFC, OSX finder seems to favor
> NFD), wouldn't it be a safe bet to normalize all input at repository
> level ? Or do you consider this is something client applications
> should do ?
>
> ref: http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms
>
> Thanks for any tip, pointer, idea, feedback or reaction !
>
> Cheers,
>
> -greg
>
>

Unicode, NFC,NFD and node names

2009-11-04T09:11:10Z

Hi list,

Given the following code,
import java.text.Normalizer;
...

final Session session = ...

final Repository rep = session.getRepository();
System.out.println(rep.getDescriptor("jcr.repository.name") +
" " + rep.getDescriptor("jcr.repository.version"));

final Node root = session.getRootNode();
final String name = "föö";
System.out.println("Normalizer.isNormalized(name,
Normalizer.Form.NFC) = " + Normalizer.isNormalized(name,
Normalizer.Form.NFC)); // true
System.out.println("Normalizer.isNormalized(name,
Normalizer.Form.NFD) = " + Normalizer.isNormalized(name,
Normalizer.Form.NFD)); // false
root.addNode(name);
session.save();

final Node node1 = root.getNode(name);
System.out.println("node1 = " + node1);
final Node node2 = root.getNode(Normalizer.normalize(name,
Normalizer.Form.NFC));
System.out.println("node2 = " + node2);
final Node node3 = root.getNode(Normalizer.normalize(name,
Normalizer.Form.NFD)); // fails
System.out.println("node3 = " + node3);

There's a good chance fetching node3 won't work. It might be dependent
on the underlying os and database, but in the case of OSX and Derby,
this fails. It's not that surprising, really, given that
Normalizer.normalize(name,
Normalizer.Form.NFC).equals(Normalizer.normalize(name,
Normalizer.Form.NFD)) is NOT true.

Now, taking into account the fact that all sorts of clients will use a
different Normalizing Form (Firefox seems to encode URL parameters
with NFD, Safari with NFC; linux NFC, OSX finder seems to favor NFD),
wouldn't it be a safe bet to normalize all input at repository level ?
Or do you consider this is something client applications should do ?

ref: http://en.wikipedia.org/wiki/Unicode_equivalence#Normal_forms

Thanks for any tip, pointer, idea, feedback or reaction !

Cheers,

-greg

Re: [jira] Created: (JCR-2369) Problem importing node with binary property in a repository configured with datastore

2009-11-04T02:29:59Z

Hi

I am using jackrabbit 1.4 over JBoss server(Version 4.0.5) and trying to migrate to 1.6.
I have the below files in my JBoss deploy folder related to Jackrabbit.
jcr-ds.xml
jackrabbit-jca-1.4.rar
jackrabbit-jcr-rmi-1.4.1.jar
and i also have "jcr-1.0.jar" in JBoss lib directory.

Please give me the steps to follow for migrating to Jackrabbit 1.6.

One more question. "Can i use the old repository?"

JIRA jira@apache.org wrote:

Problem importing node with binary property in a repository configured with datastore
-------------------------------------------------------------------------------------

Key: JCR-2369
URL: https://issues.apache.org/jira/browse/JCR-2369
Project: Jackrabbit Content Repository
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: Luca Tagliani

Using the importXML method of workspace to import some node containing binary properties the nodes are imported correctly and the value of the binary data property is imported
However the binary data goes to the db (persistenceManager) an not to the datastore.

Creating a new node of the same type using the api, the binary data go to the datastore.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2369) Problem importing node with binary property in a repository configured with datastore

2009-11-04T01:49:32Z

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

Thomas Mueller updated JCR-2369:
--------------------------------

Component/s: jackrabbit-core
Priority: Minor (was: Major)
Fix Version/s: 1.6.1

> Problem importing node with binary property in a repository configured with datastore
> -------------------------------------------------------------------------------------
>
> Key: JCR-2369
> URL: https://issues.apache.org/jira/browse/JCR-2369
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.6.0
> Reporter: Luca Tagliani
> Assignee: Thomas Mueller
> Priority: Minor
> Fix For: 1.6.1
>
> Attachments: testBug.zip
>
>
> Using the importXML method of workspace to import some node containing binary properties the nodes are imported correctly and the value of the binary data property is imported
> However the binary data goes to the db (persistenceManager) an not to the datastore.
> Creating a new node of the same type using the api, the binary data go to the datastore.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2369) Problem importing node with binary property in a repository configured with datastore

2009-11-04T01:49:32Z

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

Thomas Mueller resolved JCR-2369.
---------------------------------

Resolution: Fixed

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2369) Problem importing node with binary property in a repository configured with datastore

2009-11-04T01:47:32Z

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

Thomas Mueller commented on JCR-2369:
-------------------------------------

I have committed the bugfix in the 1.6 branch.

The problem doesn't occur in trunk (and in the 2.0 branch), because of some other changes.

> Problem importing node with binary property in a repository configured with datastore
> -------------------------------------------------------------------------------------
>
> Key: JCR-2369
> URL: https://issues.apache.org/jira/browse/JCR-2369
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Luca Tagliani
> Assignee: Thomas Mueller
> Attachments: testBug.zip
>
>
> Using the importXML method of workspace to import some node containing binary properties the nodes are imported correctly and the value of the binary data property is imported
> However the binary data goes to the db (persistenceManager) an not to the datastore.
> Creating a new node of the same type using the api, the binary data go to the datastore.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2368) can't insert new record : no space found in the device

2009-11-04T01:01:35Z

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

Thomas Mueller commented on JCR-2368:
-------------------------------------

I documented the problem at http://wiki.apache.org/jackrabbit/DataStore :

When adding a record, by default the stream is first copied to a temporary file. If you get the exception "Can not insert new record java.io.IOException: No space left on device" that means your temporary directory is too small. The reason for the temp file is: most databases need to know the stream size when adding a record, and the JCR API doesn't provide a way to do that. The mechanism used to add a record depends on the property "storeStream" in resource org/apache/jackrabbit/core/data/db/<databaseType>.properties. Implemented mechanisms are: "tempFile" (default; create a temp file before adding a record), "-1" (use the length -1 when adding the record; currently only supported by the H2 database), and "max" (use the length Integer.MAX_VALUE).

> can't insert new record : no space found in the device
> ------------------------------------------------------
>
> Key: JCR-2368
> URL: https://issues.apache.org/jira/browse/JCR-2368
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: Windows / Oracle
> Reporter: premkumar
> Priority: Critical
> Attachments: repository.xml
>
>
> I'm often getting "can't insert new record : no space found in the device" exception while trying to save the file in repository. But If I save the save file after some time Its getting saved.
>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2379) BindVariable not registered in JCR-SQL2 CONTAINS

2009-11-04T00:23:32Z

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

Marcel Reutegger resolved JCR-2379.
-----------------------------------

Resolution: Fixed
Fix Version/s: 2.0.0

Fixed in revision: 832676

> BindVariable not registered in JCR-SQL2 CONTAINS
> ------------------------------------------------
>
> Key: JCR-2379
> URL: https://issues.apache.org/jira/browse/JCR-2379
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi-commons
> Affects Versions: 2.0-beta1
> Reporter: Philipp Bunge
> Fix For: 2.0.0
>
>
> The following fails with a "java.lang.IllegalArgumentException: not a valid variable in this query:"
> Query query = qm.createQuery("SELECT * FROM [my:document] AS document WHERE CONTAINS(document.original, $x)", Query.JCR_SQL2);
> query.bindVariable("x", vf.createValue("moo"));
> And query.getBindVariableNames() returns an empty array.
> The FullTextSearchExpression _is_ however correctly parsed as a BindVariableValueImpl:
> ((FullTextSearch) ((QueryObjectModelImpl) query).getConstraint()).getFullTextSearchExpression() instanceof BindVariableValue

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2368) can't insert new record : no space found in the device

2009-11-04T00:17:32Z

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

premkumar commented on JCR-2368:
--------------------------------

sorry for the delayed reply. Here is the error log. And attached the repository.xml

[11/4/09 2:35:49:858 EST] 00000043 SystemOut O INFO >
[11/4/09 2:35:49:915 EST] 00000043 SystemOut O WARN > org.apache.jackrabbit.core.data.db.DbDataStore[WebContainer : 1]: Can not insert new record
java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1026)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
at org.apache.jackrabbit.core.data.db.TempFileInputStream.writeToFileAndClose(TempFileInputStream.java:48)
at org.apache.jackrabbit.core.data.db.DbDataStore.moveToTempFile(DbDataStore.java:405)
at org.apache.jackrabbit.core.data.db.DbDataStore.addRecord(DbDataStore.java:332)
at org.apache.jackrabbit.core.value.BLOBInDataStore.getInstance(BLOBInDataStore.java:120)
at org.apache.jackrabbit.core.value.InternalValue.getBLOBFileValue(InternalValue.java:642)
at org.apache.jackrabbit.core.value.InternalValue.create(InternalValue.java:125)
at org.apache.jackrabbit.core.PropertyImpl.setValue(PropertyImpl.java:634)
at org.apache.jackrabbit.core.PropertyImpl.setValue(PropertyImpl.java:549)
at org.apache.jackrabbit.core.NodeImpl.setProperty(NodeImpl.java:2437)
at com.ssc.soareg.jackrabbit.ContentRepository.saveFile(ContentRepository.java:293)
at com.ssc.soareg.jaxr.registry.client.infomodel.ServiceImpl.addExtrinsicObject(ServiceImpl.java:319)
at com.ssc.soareg.governance.client.SOALifeCycleManagerImpl.saveBusinessServices(SOALifeCycleManagerImpl.java:389)
at com.ssc.soareg.registry.server.UploadServlet.service(UploadServlet.java:473)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1075)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:550)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2368) can't insert new record : no space found in the device

2009-11-04T00:17:32Z

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

premkumar updated JCR-2368:
---------------------------

Attachment: repository.xml

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2379) BindVariable not registered in JCR-SQL2 CONTAINS

2009-11-04T00:15:32Z

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

Marcel Reutegger updated JCR-2379:
----------------------------------

Component/s: (was: query)
jackrabbit-spi-commons

This is a bug in the spi-commons module

> BindVariable not registered in JCR-SQL2 CONTAINS
> ------------------------------------------------
>
> Key: JCR-2379
> URL: https://issues.apache.org/jira/browse/JCR-2379
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi-commons
> Affects Versions: 2.0-beta1
> Reporter: Philipp Bunge
>
> The following fails with a "java.lang.IllegalArgumentException: not a valid variable in this query:"
> Query query = qm.createQuery("SELECT * FROM [my:document] AS document WHERE CONTAINS(document.original, $x)", Query.JCR_SQL2);
> query.bindVariable("x", vf.createValue("moo"));
> And query.getBindVariableNames() returns an empty array.
> The FullTextSearchExpression _is_ however correctly parsed as a BindVariableValueImpl:
> ((FullTextSearch) ((QueryObjectModelImpl) query).getConstraint()).getFullTextSearchExpression() instanceof BindVariableValue

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2382) NPE when calling node.getBaseVersion() within the transaction.

2009-11-03T19:51:34Z

NPE when calling node.getBaseVersion() within the transaction.
--------------------------------------------------------------

Key: JCR-2382
URL: https://issues.apache.org/jira/browse/JCR-2382
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.6.0
Environment: winxp
Reporter: Cele Liu

We try to get the base version from a versionable node in the transaction, but if we didn't check in the node, the NPE will throw out. We used the jr-jcr to support XA transaction.
the code likes:
UserTransaction ut = null;
InitialContext tx = new InitialContext();
ut = (UserTransaction) tx.lookup("UserTransaction");
ut.begin();
try {
Session session = getJcrSession();
Node root = session.getRootNode();
Node child = root.addNode("testchild");
root.save();
child.addMixin(JcrConstants.MIX_VERSIONABLE);
child.save();
session.save();
//child.checkin();
javax.jcr.version.Version v = child.getBaseVersion();
session.logout();
ut.commit();
}catch(Exception e){
ut.rollback();
e.printStackTrace(System.err);
fail("failed with " + e.getMessage());
}
The exception stack:
java.lang.NullPointerException
at org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3659)
at com.vitria.modeling.repository.sapi.JcrTransactionTest.testBaseVersionableSample(JcrTransac
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

If we did not run the code in XA transaction or check-in the code before calling the child.getBaseVersion(), the NPE will be gone.
JR1.5.0 doesn't have this issue.

I compare the code between JR1.5.0 and JR 1.6.0. and get some clue.

Please check the code snippet for JR 1.6.0. Looks like in JR 1.6.0, it always look up the node from the version manager.
The NPE happens if the versioned node doesn't exist, v is null and then JR try to get node by the v.getId().

public Version getBaseVersion() throws UnsupportedRepositoryOperationException, RepositoryException {
// check state of this instance
sanityCheck();
boolean isFull = checkVersionable();
InternalVersion v;
if (isFull) {
NodeId id = NodeId.valueOf(getProperty(NameConstants.JCR_BASEVERSION).getString());
v = session.getVersionManager().getVersion(id);
} else {
// note, that the method currently only works for linear version
// graphs (i.e. simple versioning)
v = session.getVersionManager().getHeadVersionOfNode(((NodeId) id));
}
return (Version) session.getNodeById(v.getId());
}

And there is the code snippet for JR 1.5.0, JR doesn't depends on the version manager, it always get the version from the property.

public Version getBaseVersion() throws UnsupportedRepositoryOperationException, RepositoryException {
// check state of this instance
sanityCheck();
checkVersionable();
// transactions workaround.
NodeId id = NodeId.valueOf(getProperty(NameConstants.JCR_BASEVERSION).getString());
session.getVersionManager().getVersion(id);
return (Version) getProperty(NameConstants.JCR_BASEVERSION).getNode();
}

Notice: For JR 1.5.0 and JR 1.6.0, if you didn't check in the node in XA transaction, the API session.getVersionManager().getVersion(id); both will return null.
The difference is 1.6.0 will use the return to perform the look-up, and 1.5.0 doesn't.

After I patch the code to below, the getBaseVersion() cases got passed:
public Version getBaseVersion() throws UnsupportedRepositoryOperationException, RepositoryException {
// check state of this instance
sanityCheck();
boolean isFull = checkVersionable();
InternalVersion v;
if (isFull) {
NodeId id = NodeId.valueOf(getProperty(NameConstants.JCR_BASEVERSION).getString());
v = session.getVersionManager().getVersion(id);
} else {
// note, that the method currently only works for linear version
// graphs (i.e. simple versioning)
v = session.getVersionManager().getHeadVersionOfNode(((NodeId) id));
}
if (v == null){
return (Version) getProperty(NameConstants.JCR_BASEVERSION).getNode();
}else{
return (Version) session.getNodeById(v.getId());
}
}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2145) Exception: "javax.jcr.InvalidItemStateException:Item cannot be saved because it has beenmodified externally: node /" while saving in repository

2009-11-03T12:17:32Z

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

Jukka Zitting resolved JCR-2145.
--------------------------------

Resolution: Invalid
Assignee: Jukka Zitting

The InvalidItemStateException already states what the problem is. Your save() call happened conflict with another save, and the repository was unable to automatically merge the changes. This is expected behaviour. You can prevent such cases by explicitly serializing any such conflicting changes with a JCR lock or some other synchronization mechanism.

> Exception: "javax.jcr.InvalidItemStateException:Item cannot be saved because it has beenmodified externally: node /" while saving in repository
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-2145
> URL: https://issues.apache.org/jira/browse/JCR-2145
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.5.0
> Environment: Solaris OS, JDK 1.5
> Reporter: Ritesh Chauhan
> Assignee: Jukka Zitting
>
> My code is running in Production for past 3 months but today I got this InvalidItemStateException while saving as pdf file in the repository (Log attached below).
> Though, my document got saved in the repository, but still the exception came.
> Not sure whether this happened because of concorrent sessions, i need to know the reason for this exception so that we can avoid this to happen in future and avoid probable loss of Document.
> Here's the error:
> gov.ms.mdes.access.framework.exception.BaseRunTimeException: null
> Inner Exception :javax.jcr.InvalidItemStateException:Item cannot be saved because it has beenmodified externally: node /
> at gov.ms.mdes.access.framework.exception.BaseRunTimeException.wrapAndThrow(BaseRunTimeException.java:138)
> at gov.ms.mdes.access.framework.dms.DmsDataTemplate.save(DmsDataTemplate.java:81)
> at gov.ms.mdes.access.framework.dms.BaseDmsDAO.save(BaseDmsDAO.java:40)
> at gov.ms.mdes.access.batch.op.BatchRepaymentDistributionBalancingReport.performBusinessProcess(BatchRepaymentDistributionBalancingReport.java:75)
> at gov.ms.mdes.access.batch.framework.BatchManager.runBatch(BatchManager.java:219)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.executeBatch(CustomJob.java:83)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.access$000(CustomJob.java:25)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob$BatchThread.run(CustomJob.java:160)
> Caused by: javax.jcr.InvalidItemStateException: Item cannot be saved because it has beenmodified externally: node /
> at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:104)
> at org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:212)
> at sun.reflect.GeneratedMethodAccessor5639.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> at java.lang.Thread.run(Thread.java:595)
> at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> at org.apache.jackrabbit.rmi.server.ServerXASession_Stub.save(Unknown Source)
> at org.apache.jackrabbit.rmi.client.ClientSession.save(ClientSession.java:208)
> at gov.ms.mdes.access.framework.dms.DmsDataTemplate.save(DmsDataTemplate.java:77)
> ... 6 more
>
> Inner Exception:
> javax.jcr.InvalidItemStateException: Item cannot be saved because it has beenmodified externally: node /
> at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:104)
> at org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:212)
> at sun.reflect.GeneratedMethodAccessor5639.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> at java.lang.Thread.run(Thread.java:595)
> at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> at org.apache.jackrabbit.rmi.server.ServerXASession_Stub.save(Unknown Source)
> at org.apache.jackrabbit.rmi.client.ClientSession.save(ClientSession.java:208)
> at gov.ms.mdes.access.framework.dms.DmsDataTemplate.save(DmsDataTemplate.java:77)
> at gov.ms.mdes.access.framework.dms.BaseDmsDAO.save(BaseDmsDAO.java:40)
> at gov.ms.mdes.access.batch.op.BatchRepaymentDistributionBalancingReport.performBusinessProcess(BatchRepaymentDistributionBalancingReport.java:75)
> at gov.ms.mdes.access.batch.framework.BatchManager.runBatch(BatchManager.java:219)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.executeBatch(CustomJob.java:83)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.access$000(CustomJob.java:25)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob$BatchThread.run(CustomJob.java:160)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build is back to stable: Jackrabbit-trunk #913

2009-11-03T06:20:15Z

See <http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/913/changes>

Hudson build is back to stable: Jackrabbit-trunk » Jackrabbit Core #913

2009-11-03T06:20:12Z

See <http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/913/changes>

[jira] Commented: (JCR-2381) Query test fails occasionally

2009-11-03T05:24:59Z

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

Marcel Reutegger commented on JCR-2381:
---------------------------------------

Added test to known issues list.

> Query test fails occasionally
> -----------------------------
>
> Key: JCR-2381
> URL: https://issues.apache.org/jira/browse/JCR-2381
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Marcel Reutegger
> Priority: Minor
>
> From time to time the following query test fails:
> testConcurrentQueryWithDeletes(org.apache.jackrabbit.core.integration.ConcurrentQueryTest)
> with message:
> junit.framework.AssertionFailedError: javax.jcr.PathNotFoundException: /testroot/node0/node2/node4
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.jackrabbit.core.integration.ConcurrentQueryTest.testConcurrentQueryWithDeletes(ConcurrentQueryTest.java:191)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2381) Query test fails occasionally

2009-11-03T05:22:59Z

Query test fails occasionally
-----------------------------

Key: JCR-2381
URL: https://issues.apache.org/jira/browse/JCR-2381
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Reporter: Marcel Reutegger
Priority: Minor

From time to time the following query test fails:

testConcurrentQueryWithDeletes(org.apache.jackrabbit.core.integration.ConcurrentQueryTest)

with message:

junit.framework.AssertionFailedError: javax.jcr.PathNotFoundException: /testroot/node0/node2/node4
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.jackrabbit.core.integration.ConcurrentQueryTest.testConcurrentQueryWithDeletes(ConcurrentQueryTest.java:191)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2295) Occasional query test failures

2009-11-03T05:20:59Z

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

Marcel Reutegger resolved JCR-2295.
-----------------------------------

Resolution: Invalid

I'll resolve this invalid, since the query failures have been caused by a test case introduced for another issue (JCR-2272) which is not yet fixed.

> Occasional query test failures
> ------------------------------
>
> Key: JCR-2295
> URL: https://issues.apache.org/jira/browse/JCR-2295
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, query, test
> Reporter: Jukka Zitting
>
> Our Hudson build caught a query test issue that I just saw also on a local checkout. See the Hudson report for details:
> http://hudson.zones.apache.org/hudson/view/Jackrabbit/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/818/testReport/
> Most of the test errors look like this:
> junit.framework.AssertionFailedError: /testroot/node1 is not part of the result set
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:342)
> at org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeSqlQuery(AbstractQueryTest.java:320)
> at org.apache.jackrabbit.test.api.query.SQLJoinTest.testJoinNtBase(SQLJoinTest.java:103)
> There's also the following failure, though I'm not sure if the problems are related:
> javax.jcr.ItemNotFoundException: failed to build path of 73a2730b-151c-425d-87fe-f4c9b1885b2f: 14eaf724-275f-4a59-aed1-3fcbd7eca88b has no child entry for 73a2730b-151c-425d-87fe-f4c9b1885b2f
> at org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManagerImpl.java:291)
> at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarchyManager.java:198)
> at org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:395)
> at org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:232)
> at org.apache.jackrabbit.core.query.lucene.RowIteratorImpl$RowImpl.getValue(RowIteratorImpl.java:340)
> at org.apache.jackrabbit.commons.query.GQL$RowAdapter.getValue(GQL.java:1016)
> at org.apache.jackrabbit.core.query.AbstractQueryTest.checkResultSequence(AbstractQueryTest.java:235)
> at org.apache.jackrabbit.core.integration.GQLTest.testOrder(GQLTest.java:60)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Hudson build became unstable: Jackrabbit-trunk » Jackrabbit Core #912

2009-11-03T02:38:59Z

Apache Hudson Server wrote:
> See <http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/912/changes>

it's the following test that is failing

testConcurrentQueryWithDeletes(org.apache.jackrabbit.core.integration.ConcurrentQueryTest)

that happens to me from time to time since several
weeks whenever i run the tests irrespective of my
changes.

angela

Hudson build became unstable: Jackrabbit-trunk #912

2009-11-03T02:22:31Z

See <http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/912/changes>

Hudson build became unstable: Jackrabbit-trunk » Jackrabbit Core #912

2009-11-03T02:22:25Z

See <http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/912/changes>

[jira] Commented: (JCR-2145) Exception: "javax.jcr.InvalidItemStateException:Item cannot be saved because it has beenmodified externally: node /" while saving in repository

2009-11-02T10:52:59Z

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

Ivan commented on JCR-2145:
---------------------------

We are also experiencing similar problems.

We are facing an issue where a large number of file uploads fail. We are using jackrabbit and are persisting files in the database. Our environment is clustered with many concurrent users, so I'm wondering if this exception has to do with concurrency issues?

> Exception: "javax.jcr.InvalidItemStateException:Item cannot be saved because it has beenmodified externally: node /" while saving in repository
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-2145
> URL: https://issues.apache.org/jira/browse/JCR-2145
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.5.0
> Environment: Solaris OS, JDK 1.5
> Reporter: Ritesh Chauhan
>
> My code is running in Production for past 3 months but today I got this InvalidItemStateException while saving as pdf file in the repository (Log attached below).
> Though, my document got saved in the repository, but still the exception came.
> Not sure whether this happened because of concorrent sessions, i need to know the reason for this exception so that we can avoid this to happen in future and avoid probable loss of Document.
> Here's the error:
> gov.ms.mdes.access.framework.exception.BaseRunTimeException: null
> Inner Exception :javax.jcr.InvalidItemStateException:Item cannot be saved because it has beenmodified externally: node /
> at gov.ms.mdes.access.framework.exception.BaseRunTimeException.wrapAndThrow(BaseRunTimeException.java:138)
> at gov.ms.mdes.access.framework.dms.DmsDataTemplate.save(DmsDataTemplate.java:81)
> at gov.ms.mdes.access.framework.dms.BaseDmsDAO.save(BaseDmsDAO.java:40)
> at gov.ms.mdes.access.batch.op.BatchRepaymentDistributionBalancingReport.performBusinessProcess(BatchRepaymentDistributionBalancingReport.java:75)
> at gov.ms.mdes.access.batch.framework.BatchManager.runBatch(BatchManager.java:219)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.executeBatch(CustomJob.java:83)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.access$000(CustomJob.java:25)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob$BatchThread.run(CustomJob.java:160)
> Caused by: javax.jcr.InvalidItemStateException: Item cannot be saved because it has beenmodified externally: node /
> at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:104)
> at org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:212)
> at sun.reflect.GeneratedMethodAccessor5639.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> at java.lang.Thread.run(Thread.java:595)
> at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> at org.apache.jackrabbit.rmi.server.ServerXASession_Stub.save(Unknown Source)
> at org.apache.jackrabbit.rmi.client.ClientSession.save(ClientSession.java:208)
> at gov.ms.mdes.access.framework.dms.DmsDataTemplate.save(DmsDataTemplate.java:77)
> ... 6 more
>
> Inner Exception:
> javax.jcr.InvalidItemStateException: Item cannot be saved because it has beenmodified externally: node /
> at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:104)
> at org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:212)
> at sun.reflect.GeneratedMethodAccessor5639.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> at java.lang.Thread.run(Thread.java:595)
> at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> at org.apache.jackrabbit.rmi.server.ServerXASession_Stub.save(Unknown Source)
> at org.apache.jackrabbit.rmi.client.ClientSession.save(ClientSession.java:208)
> at gov.ms.mdes.access.framework.dms.DmsDataTemplate.save(DmsDataTemplate.java:77)
> at gov.ms.mdes.access.framework.dms.BaseDmsDAO.save(BaseDmsDAO.java:40)
> at gov.ms.mdes.access.batch.op.BatchRepaymentDistributionBalancingReport.performBusinessProcess(BatchRepaymentDistributionBalancingReport.java:75)
> at gov.ms.mdes.access.batch.framework.BatchManager.runBatch(BatchManager.java:219)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.executeBatch(CustomJob.java:83)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob.access$000(CustomJob.java:25)
> at gov.ms.mdes.access.batch.framework.scheduling.impl.quartz.job.CustomJob$BatchThread.run(CustomJob.java:160)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2369) Problem importing node with binary property in a repository configured with datastore

2009-11-02T08:40:59Z

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

Thomas Mueller commented on JCR-2369:
-------------------------------------

I can reproduce the problem with Jackrabbit 1.6

> Problem importing node with binary property in a repository configured with datastore
> -------------------------------------------------------------------------------------
>
> Key: JCR-2369
> URL: https://issues.apache.org/jira/browse/JCR-2369
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Luca Tagliani
> Assignee: Thomas Mueller
> Attachments: testBug.zip
>
>
> Using the importXML method of workspace to import some node containing binary properties the nodes are imported correctly and the value of the binary data property is imported
> However the binary data goes to the db (persistenceManager) an not to the datastore.
> Creating a new node of the same type using the api, the binary data go to the datastore.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (JCR-2369) Problem importing node with binary property in a repository configured with datastore

2009-11-02T08:40:59Z

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

Thomas Mueller reassigned JCR-2369:
-----------------------------------

Assignee: Thomas Mueller

> Problem importing node with binary property in a repository configured with datastore
> -------------------------------------------------------------------------------------
>
> Key: JCR-2369
> URL: https://issues.apache.org/jira/browse/JCR-2369
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Luca Tagliani
> Assignee: Thomas Mueller
> Attachments: testBug.zip
>
>
> Using the importXML method of workspace to import some node containing binary properties the nodes are imported correctly and the value of the binary data property is imported
> However the binary data goes to the db (persistenceManager) an not to the datastore.
> Creating a new node of the same type using the api, the binary data go to the datastore.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2380) NPE in ObservationManagerImpl.getRegisteredEventListeners() during shutdown after broken startup

2009-11-02T08:04:59Z

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

Alexander Klimetschek commented on JCR-2380:
--------------------------------------------

Explicitly throwing NPE earlier in constructor as it is done for other parameters as well in revision 831934.

Keeping the bug open to look for a "full" solution as Jukka suggested in JCR-2378. Although I guess the NPE is a result of a non-stable startup.

> NPE in ObservationManagerImpl.getRegisteredEventListeners() during shutdown after broken startup
> ------------------------------------------------------------------------------------------------
>
> Key: JCR-2380
> URL: https://issues.apache.org/jira/browse/JCR-2380
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0-alpha11
> Reporter: Alexander Klimetschek
> Assignee: Alexander Klimetschek
> Priority: Minor
>
> See JCR-2378. The variable "dispatcher" is passed as null in the constructor.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (JCR-2380) NPE in ObservationManagerImpl.getRegisteredEventListeners() during shutdown after broken startup

2009-11-02T08:04:59Z

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

Alexander Klimetschek reassigned JCR-2380:
------------------------------------------

Assignee: (was: Alexander Klimetschek)

> NPE in ObservationManagerImpl.getRegisteredEventListeners() during shutdown after broken startup
> ------------------------------------------------------------------------------------------------
>
> Key: JCR-2380
> URL: https://issues.apache.org/jira/browse/JCR-2380
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0-alpha11
> Reporter: Alexander Klimetschek
> Priority: Minor
>
> See JCR-2378. The variable "dispatcher" is passed as null in the constructor.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.