[ http://issues.apache.org/jira/browse/JCR-600?page=all ]
Marcel Reutegger reopened JCR-600:
--
You are right. My test didn't involve a login. I simply re-deployed the
jackrabbit-server.war.
There is still a commit log thread local which holds
just a wild guess, you are using same name siblings?
regards
marcel
Nicolas wrote:
Hi,
As you know, I am still fairly new to Jackrabbit and its internals. I think
there is something I didn't understand correctly. Can you please help me?
I am trying to fetch all direct children of the root no
[ http://issues.apache.org/jira/browse/JCR-600?page=all ]
Marcel Reutegger resolved JCR-600.
--
Fix Version/s: 1.1.1
Resolution: Fixed
Second attempt ;)
Fixed in revision: http://svn.apache.org/viewvc?view=rev&revision=469412
> Repository does no
Nicolas napisal(a):
Hi,
As you know, I am still fairly new to Jackrabbit and its internals. I think
there is something I didn't understand correctly. Can you please help me?
I am trying to fetch all direct children of the root node from a repository
with 3 nodes I have put in. When I write root
Hi Dan,
can you please create a jira issue with exact information how to reproduce this
issue.
regards
marcel
Dan Connelly wrote:
I do not define any structured nodes: nt:unstructured is good enough
for this UC.
I import the following (legitimate) XML file into a Workspace:
http://www.om
Actually they have different names, but the same name sibling is a use case
I should be taking care of.
Do you have an idea why with same name sibling this behaviour happens?
BR
Nico
my blog! http://www.deviant-abstraction.net !!
On 10/31/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
just a
Hi Szymon,
Rereading my email, there is something important I forgot to write: the
snippet of code is the following:
itemOps = new a BatchedItemOperations(...);
NodeState root = itemOps.getNodeState(nodeInfo.getId());
root.getChildNodeEntries();
As you can see root is not an instance of Node bu
Hi,
On 10/31/06, Nicolas <[EMAIL PROTECTED]> wrote:
Actually they have different names, but the same name sibling is a use case
I should be taking care of.
Do you have an idea why with same name sibling this behaviour happens?
You've probably run code like the following a few times over:
[ http://issues.apache.org/jira/browse/JCR-569?page=all ]
Jukka Zitting reopened JCR-569:
---
Reopening this issue since a regression was introduced by the WorkspaceImporter
change. I've now reverted (revision 469441) the class back to what it was
Hi Jukka,
Thanks, you are totally right.
(for the little story, it comes from a temporary unit test.)
Nico
On 10/31/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 10/31/06, Nicolas <[EMAIL PROTECTED]> wrote:
> Actually they have different names, but the same name sibling is a use
case
[
http://issues.apache.org/jira/browse/JCR-600?page=comments#action_12445875 ]
Torgeir Veimo commented on JCR-600:
---
It still doesn't work. Are there other classes that needs modification in
jackrabbit 1.1? I've seen that there are threads used
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445876 ]
Przemo Pakulski commented on JCR-595:
-
DatabasePersistenceManagers kept for compatibility (in old
org.apache.jackrabbit.core.state.db package) doesn't work longe
Yes I have met the same problem with it .How to solve it ?
2006/10/31, Przemo Pakulski (JIRA) <[EMAIL PROTECTED]>:
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445876]
Przemo Pakulski commented on JCR-595:
-
DatabasePersistenc
[ http://issues.apache.org/jira/browse/JCR-605?page=all ]
Marcel Reutegger reopened JCR-605:
--
Assignee: Marcel Reutegger
The fix still tries to store the jcr:system node state in the regular workspace
persistence manager.
> Error when r
[ http://issues.apache.org/jira/browse/JCR-605?page=all ]
Marcel Reutegger resolved JCR-605.
--
Resolution: Fixed
The jcr:system node is now created within the same method as the root node of
the workspace: SharedItemStateManager.createRootNodeState().
[ http://issues.apache.org/jira/browse/JCR-612?page=all ]
Jukka Zitting updated JCR-612:
--
Fix Version/s: 1.2
> Restructure the Jackrabbit source tree
> --
>
> Key: JCR-612
> URL: http://iss
[ http://issues.apache.org/jira/browse/JCR-352?page=all ]
Jukka Zitting updated JCR-352:
--
Fix Version/s: 1.2
> Upgrade to Lucene 2.0
> -
>
> Key: JCR-352
> URL: http://issues.apache.org/jira/browse/JCR-352
[ http://issues.apache.org/jira/browse/JCR-578?page=all ]
Jukka Zitting updated JCR-578:
--
Fix Version/s: (was: 1.1.1)
> QueryParser.parse(...) parses wrong the "[EMAIL PROTECTED] and @b=3 or @c=3]"
> XPath statement.
> -
[ http://issues.apache.org/jira/browse/JCR-592?page=all ]
Jukka Zitting updated JCR-592:
--
Fix Version/s: (was: 1.1.1)
> Use only the standard Maven repository for dependencies
> ---
>
>
[ http://issues.apache.org/jira/browse/JCR-564?page=all ]
Jukka Zitting updated JCR-564:
--
Issue Type: Improvement (was: Bug)
Priority: Minor (was: Critical)
> Remove geronimo JTA as a runtime dependency
> ---
Hi,
This is an early version of the Apache Jackrabbit 1.2 release plan.
The 1.2 release will contain a number of upgrades and restructurings
as illustrated by the list of key issues below. I believe that we can
have the release ready by the end of this year, but I will rather
postpone the release
[ http://issues.apache.org/jira/browse/JCR-595?page=all ]
Jukka Zitting updated JCR-595:
--
Fix Version/s: 1.2
(was: 1.1.1)
Affects Version/s: (was: 1.1.1)
> Refactoring of the Persistence Managers
>
[ http://issues.apache.org/jira/browse/JCR-546?page=all ]
Jukka Zitting updated JCR-546:
--
Priority: Major (was: Critical)
> Deadlock during checkin
> ---
>
> Key: JCR-546
> URL: http://issues.apache.org/j
[ http://issues.apache.org/jira/browse/JCR-585?page=all ]
Jukka Zitting updated JCR-585:
--
Fix Version/s: 1.2
> Create jackrabbit-api(.jar) and the respective jackrabbit-rmi extensions
> ---
I just update the version to 469481 ,The problem still exist
2006/10/31, Jukka Zitting (JIRA) <[EMAIL PROTECTED]>:
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445896]
Jukka Zitting commented on JCR-595:
---
> Configuration erro
[ http://issues.apache.org/jira/browse/JCR-610?page=all ]
Jukka Zitting updated JCR-610:
--
Fix Version/s: 1.2
> Upgrade to Derby 10.2
> -
>
> Key: JCR-610
> URL: http://issues.apache.org/jira/browse/JCR-610
[ http://issues.apache.org/jira/browse/JCR-332?page=all ]
Jukka Zitting updated JCR-332:
--
Fix Version/s: 1.2
> Upgrade to Maven 2
> --
>
> Key: JCR-332
> URL: http://issues.apache.org/jira/browse/JCR-332
>
[ http://issues.apache.org/jira/browse/JCR-606?page=all ]
Jukka Zitting updated JCR-606:
--
Component/s: rmi
Fix Version/s: 1.1.1
Affects Version/s: 0.9
1.0
1.0.1
1.1
> RMI
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445896 ]
Jukka Zitting commented on JCR-595:
---
> Configuration error: unknown schema 'derby'
This was caused by the use of getClass().getResourceAsStream() to load the DDL
[ http://issues.apache.org/jira/browse/JCR-562?page=all ]
Jukka Zitting updated JCR-562:
--
Component/s: xpath
(was: core)
Fix Version/s: 1.1.1
Affects Version/s: 0.9
1.0
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445902 ]
Jukka Zitting commented on JCR-595:
---
Wendy Lee on the mailing list:
> I just update the version to 469481 ,The problem still exist
You're right. In fact there a
[ http://issues.apache.org/jira/browse/JCR-578?page=all ]
Jukka Zitting updated JCR-578:
--
Component/s: xpath
(was: query)
Fix Version/s: 1.1.1
Affects Version/s: 0.9
1.0
> QueryParser.parse
Angela Schreiber schrieb:
yes. the idea:
i quickly hacked the assertAvailability in to have
a reminder. it doesn't work anyway and i didn't commit
the latest changes.
and yes, it was obvious, that you are trying to use
the spi. but you have to live with completely instable
code at the moment. i
Hi,
I did mention that I'm working on an SPI implementation for an existing
store, and trying to get it up with jcr2spi, right?
Anyway, in the meantime I can login to my store, and get the root node;
so far, so good.
If I now try hasNodes(), I'm getting the ClassCastException below...:
jav
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445968 ]
Jukka Zitting commented on JCR-595:
---
The "unknown schema" problem should now really be fixed as of revision 469571.
The compatibility classes in o.a.j.core.state.db
yes. the idea:
i quickly hacked the assertAvailability in to have
a reminder. it doesn't work anyway and i didn't commit
the latest changes.
and yes, it was obvious, that you are trying to use
the spi. but you have to live with completely instable
code at the moment. it's not finished yet and
as
[ http://issues.apache.org/jira/browse/JCR-598?page=all ]
Jukka Zitting updated JCR-598:
--
Fix Version/s: 1.1.1
Affects Version/s: 0.9
1.0
1.0.1
1.1
> DateValue.equals() relies on C
Hi,
We already have a number of notable issues and fixes after the 1.1
release, so I've decided to start preparing for a 1.1.1 patch release
in mid-November. Since we have a few structural changes in progress in
trunk, I will be merging any 1.1.1 fixes from the trunk to the 1.1
branch and creatin
[ http://issues.apache.org/jira/browse/JCR-594?page=all ]
Jukka Zitting updated JCR-594:
--
Fix Version/s: 1.1.1
> It's not possible to register event listeners that filters on mixin supertypes
> ---
[ http://issues.apache.org/jira/browse/JCR-569?page=all ]
Jukka Zitting updated JCR-569:
--
Fix Version/s: (was: 1.1.1)
> WorkspaceImporter Refactoring
> -
>
> Key: JCR-569
> URL: http://issues.a
[ http://issues.apache.org/jira/browse/JCR-606?page=all ]
Jukka Zitting reopened JCR-606:
---
Reopening to set properties before the 1.1.1 release.
> RMI-DateValue does not support full ISO8601 format
> --
[ http://issues.apache.org/jira/browse/JCR-606?page=all ]
Jukka Zitting resolved JCR-606.
---
Resolution: Fixed
> RMI-DateValue does not support full ISO8601 format
> --
>
> Key: JCR-606
>
[
http://issues.apache.org/jira/browse/JCR-600?page=comments#action_12445904 ]
Marcel Reutegger commented on JCR-600:
--
What operations do you perform before you re-deploy the web application?
It works for me when I do a login, read a couple
That's great ,The bug has been fixed .Thank you.
2006/11/1, Jukka Zitting (JIRA) <[EMAIL PROTECTED]>:
[
http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445968]
Jukka Zitting commented on JCR-595:
---
The "unknown schema" problem should n
44 matches
Mail list logo
