[jira] Assigned: (JCR-543) DocViewSAXEventGenerator produces invalid SAX stream
[ http://issues.apache.org/jira/browse/JCR-543?page=all ]
Stefan Guggisberg reassigned JCR-543:
-
Assignee: Stefan Guggisberg
DocViewSAXEventGenerator produces invalid SAX stream
Key: JCR-543
URL: http://issues.apache.org/jira/browse/JCR-543
Project: Jackrabbit
Issue Type: Bug
Components: xml
Affects Versions: 1.0.1
Reporter: Jaka Jaksic
Assigned To: Stefan Guggisberg
ISO9075.encode() is called twice in DocViewSAXEventGenerator.leaving(), which
produces invalid endElement events.
Faulty block of code (note the encode method called twice):
// encode node name to make sure it's a valid xml name
name = ISO9075.encode(name);
// element name
String elemName;
if (node.getDepth() == 0) {
// root node needs a name
elemName = jcrRoot;
} else {
// encode node name to make sure it's a valid xml name
elemName = ISO9075.encode(name);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-544) JCR-Server: Workspace.restore not mapped correctly
JCR-Server: Workspace.restore not mapped correctly -- Key: JCR-544 URL: http://issues.apache.org/jira/browse/JCR-544 Project: Jackrabbit Issue Type: Bug Reporter: angela Assigned To: angela (issue reported by David Kennedy) Workspace.restore(Version[], boolean) won't work, since versions are not retrieved correctly. The version history that can be access from the request resource, cannot be used to retrieve the versions needed for a workspace.restore call. possible short term fix: From the version-hrefs present in the request body of the UPDATE request, version resources must be built and the corresponding version item retrieved. alternative: find a proper mapping for Workspace.restore(Version[], boolean). having UPDATE on a resource representing a javax.jcr.Node being mapped to a workspace.restore is odd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Multi-version restore withWebDAV VersionControlledItemCollection.update
hi david i opened a new jira issue for this. https://issues.apache.org/jira/browse/JCR-544 JCR-544 JCR-Server: Workspace.restore not mapped correctly regards angela David Kennedy wrote: The WebDAV multi-version restore code in VersionControlledItemCollection.update method is suspicious. The code is trying to restore by label or by name. If multiple version hrefs are supplied or if multiple labels are supplied, the code will use the multi-version restore method of Workspace. The problem is that the versions are all retrieved for the same node and you can't have more than one version of the same node in a workspace. The multi-version restore method is intended for cross node dependencies. To enable the multi-version restore the body needs to support fully qualified version name and labels. You could argue that the version href already does so, however you'd assume the name is the version label and what's preceding it would be the itemPath (currently thrown out) to the actual node. However this would be a bit of a hack. It seems as though the body structure needs to change a bit to truly support multi-version restore. David
Re: jackrabbit-server-1.0.1.war distribution
hi i re-read your description multiple times and i don't manage to interprete, whether your problem is caused by a bug in the server or by a wrong behaviour of your dav-client. the exception insinuates, that the client successfully created a lock on the server. however, a subsequent PUT call cannot be executed: apparently the client is not recognized as lock holder any more. so: please analyse the http conversation. make sure, that your dav-client deals properly with the LOCK that was created (see RFC 2518 for details). if you find out, that dreamweaver behaves properly (and according to the RFC) please provide a description, how we can reproduce the problem with any other dav-client. alternatively, you may provide a conversation log, that allows us to reproduce it. regards angela Shanmugam Gopal wrote: I have deployed jackrabbit-server-1.0.1 in Tomcat 5.5 with JDK 1.4.2. Now I am trying to access the repository from webDAV Client - Dreamweaver and able to get the repository structure in Dreamweaver(using Manage Site option in Dreamweaver.) 1. I created a folder in the repository(right click - New Folder...Ex/; Hello) 2. Checked out this folder to my local machine (right click on folder name - checkout) 3. Got the same folder in my local machine now. 4. Created a text file in that folder(Ex...Hello.txt) 5. Checked in the folder to the repository 6. Now the repository contains a folder called Hello and a file Hello.txt inside the folder. 7. Again I checkout the file to my local machine. 8. After making some changes to the file, trying to check in. 9. But while checking the content of the file in repository, it is not updated. I got the following exception Adding a new file/folder is not a problem. But Check out then check in is the problem in Dreamweaver with Jackrabbit. During checkout, a lock file is created in local folder(filename.LCK). I think this is created by dreamweaver. During Checkin, the addMember method in DavResourceImpl class throws the following exception. org.apache.jackrabbit.webdav.DavException: Locked at org.apache.jackrabbit.webdav.simple.DavResourceImpl.addMember(DavResourceImpl.java:596) at org.apache.jackrabbit.server.AbstractWebdavServlet.doPut(AbstractWebdavServlet.java:666) at org.apache.jackrabbit.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:318) at org.apache.jackrabbit.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:255) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Not able to understand the root cause of the problem. While adding the file for the first time it works fine. But check-out then check-in is not working. As I said earlier in my mail, Dreamweaver always make http calls like PROPFIND, GET, LOCK, PUT. It does not make calls like CHECKIN OR CHECKOUT. May I know whether this war has been tested by using any webdav client like dreamweaver? Please provide detailed response. Regards, Shan From: Angela Schreiber [EMAIL PROTECTED] Reply-To: dev@jackrabbit.apache.org To: dev@jackrabbit.apache.org Subject: Re: jackrabbit-server-1.0.1.war distribution Date: Mon, 14 Aug 2006 08:36:05 +0200 Shanmugam Gopal wrote: By deploying the war distribution in Tomcat 5.5, l am trying to perform checkout, checkin and versiong from any webdav client - Dreamweaver.(Dreamweaver supports webdav and I am trying to access the repository by using Manage site option.) While debugging the code, I found that Dreamweaver makes only calls like OPTIONS, GET, LOCK and PUT. It does not make any http calls like CHECKIN OR CHECKOUT. ah. in this case your discription was misleading. i don't have a dreamweaver installation. so how should i know, what you mean by 'checkin', 'checkout'? please check the HTTP conversation between your client and the dav server. and second, find out, whether the same problem occurs with other dav clients as well. unless you are able to provide a detailed description of what is failing and under which condition, i can't help you. i could imagine, that LOCK on a null resource fails. but this is just a wild guess. angela ps: please. always send messages to the dev list and not to me directly. _ NRIs: Send Money FREE! Go ahead and register now! http://ads.mediaturf.net/event.ng/Type=clickFlightID=20273AdID=65989TargetID=11172Targets=11172Values=202,414,1093,1264,3122Redirect=http:%2F%2Fwww.icicinri.net%2Fmoney2india%2F%3Fm2i%3DBAC-MSN%26att%3DMSNTLM2I18CHAR%26rfr%3DMSNTLM2I18CHAR
[jira] Resolved: (JCR-543) DocViewSAXEventGenerator produces invalid SAX stream
[ http://issues.apache.org/jira/browse/JCR-543?page=all ]
Stefan Guggisberg resolved JCR-543.
---
Resolution: Fixed
fixed in svn r432563
thanks for reporting this isssue!
DocViewSAXEventGenerator produces invalid SAX stream
Key: JCR-543
URL: http://issues.apache.org/jira/browse/JCR-543
Project: Jackrabbit
Issue Type: Bug
Components: xml
Affects Versions: 1.0.1
Reporter: Jaka Jaksic
Assigned To: Stefan Guggisberg
ISO9075.encode() is called twice in DocViewSAXEventGenerator.leaving(), which
produces invalid endElement events.
Faulty block of code (note the encode method called twice):
// encode node name to make sure it's a valid xml name
name = ISO9075.encode(name);
// element name
String elemName;
if (node.getDepth() == 0) {
// root node needs a name
elemName = jcrRoot;
} else {
// encode node name to make sure it's a valid xml name
elemName = ISO9075.encode(name);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reregistering Nodetypes
Hi, currently there are only API methods to register new nodetypes but not to modify aka reregister nodetypes. I would like to add the following methods to JackrabbitNodeTypeManager: NodeType[] registerNodeTypes(InputSource in, boolean reregisterExistent) NodeType[] registerNodeTypes(InputStream in, String contentType, boolean reregisterExistent) If the parameter reregisterExistent is true, already existent nodetypes will be reregistered. What do you think about that? Did I miss anything? Cheers, Christoph
