[
http://issues.apache.org/jira/browse/JCR-690?page=comments#action_12460966 ]
Jukka Zitting commented on JCR-690:
---
The JSR 283 early draft only allows XML charactes in JCR names to solve this
issue.
I think we should adopt the same policy al
[ http://issues.apache.org/jira/browse/JCR-690?page=all ]
Jukka Zitting updated JCR-690:
--
Component/s: JSR 283
Priority: Minor (was: Major)
> Nodes' and properties' names with invalid XML characters export as invalid XML
> --
[ http://issues.apache.org/jira/browse/JCR-674?page=all ]
Jukka Zitting updated JCR-674:
--
Component/s: JCR 1.0.1
Priority: Minor (was: Major)
> String properties with invalid XML characters export as invalid XML
> ---
Hi,
I've added the "JCR 1.0.1" and "JCR 2.0" components in the Jackrabbit
issue tracker to better track changes related to the JSR 170
maintenance release and the JSR 283 specification.
The spec component tags should always be associated with a structural
tag that identifies the functional area
Hi Jukka,
So far I thought 'values' is quite a simple concept, and with some
exceptions (for example the problems with streams) I thought it should
be possible to implement it in a simple way. To tell you the truth, I
don't understand the class diagram. For me, it is very complex, I'm
confused. F
Hi,
On 12/27/06, Thomas Mueller <[EMAIL PROTECTED]> wrote:
So far I thought 'values' is quite a simple concept, and with some
exceptions (for example the problems with streams) I thought it should
be possible to implement it in a simple way. To tell you the truth, I
don't understand the class di
[ http://issues.apache.org/jira/browse/JCR-680?page=all ]
Jukka Zitting updated JCR-680:
--
Attachment: GenericValue.patch
Attached GenericValue.patch, that implements only the State pattern part of the
proposed change. The patch is against Jackrabbit trunk,
[ http://issues.apache.org/jira/browse/JCR-688?page=all ]
Jukka Zitting updated JCR-688:
--
Attachment: JCR-688.LocalCache.patch
Attached JCR-688.LocalCache.patch (against jackrabbit-core) that replaces the
CachingNamespaceResolver in NamespaceRepository wit
[
http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12461041 ]
Julian Reschke commented on JCR-688:
If we know that name prefix resolution causes this amount of pain, shouldn't we
consider adding QName-based addressing in JSR
[
http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12461047 ]
Jukka Zitting commented on JCR-688:
---
> If we know that name prefix resolution causes this amount of pain,
> shouldn't we consider adding QName-based addressing in JS
Hi Yaqeen,
String name = "rmi://192.168.1.6:1099/AcopianRep";
This is not a correct URL to use for the
ClientRepositoryFactory.getRepository(String url) method. The URL must be
without the scheme, that is " //192.168.1.6:1099/AcopianRep" in your case.
Hope this helps.
Regards
Felix
Let NameException extend RepositoryException
Key: JCR-691
URL: http://issues.apache.org/jira/browse/JCR-691
Project: Jackrabbit
Issue Type: Improvement
Components: core
Repor
[ http://issues.apache.org/jira/browse/JCR-691?page=all ]
Jukka Zitting updated JCR-691:
--
Attachment: NameException.patch
Attached NameException.patch (against trunk) that implements the proposed
change and adjusts the code in jackrabbit-core accordingly.
The newest version has two exception in SQLPathTest.
---
testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest)
junit.framework.AssertionFailedError: /testd
14 matches
Mail list logo