[jira] Commented: (JCR-367) Remove dependency on Xerces
[ http://issues.apache.org/jira/browse/JCR-367?page=comments#action_12418769 ] Jukka Zitting commented on JCR-367: --- > It is not safe to use code from a JDK, even when that code comes from Apache > originally. Please replace it with the code from Xerces trunk. Replaced in revision 418445. > Remove dependency on Xerces > --- > > Key: JCR-367 > URL: http://issues.apache.org/jira/browse/JCR-367 > Project: Jackrabbit > Type: Improvement > Components: xml > Versions: 0.9, 1.0, 1.0.1 > Reporter: Michael Young > Assignee: Felix Meschberger > Fix For: 1.1 > Attachments: No_Xerces_Patch.fm.20060627.patch > > Classloaders in certain J2EE servers do not play well with the Xerces > requirement -- 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] Updated: (JCR-320) BinaryValue equals fails for two objects with two different byte arrays that contain the same bytes.
[ http://issues.apache.org/jira/browse/JCR-320?page=all ]
Jukka Zitting updated JCR-320:
--
Version: 1.0.1
Piyush, did you get around to creating a patch for this? If not, I'll just take
your code from the above comments and apply it.
> BinaryValue equals fails for two objects with two different byte arrays that
> contain the same bytes.
>
>
> Key: JCR-320
> URL: http://issues.apache.org/jira/browse/JCR-320
> Project: Jackrabbit
> Type: Bug
> Components: core
> Versions: 0.9, 1.0, 1.0.1
> Reporter: Piyush Purang
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 1.1
>
> http://svn.apache.org/repos/asf/incubator/jackrabbit/trunk/jackrabbit/src/main/java/org/apache/jackrabbit/value/BinaryValue.java
> Here is the present implementation
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj instanceof BinaryValue) {
> BinaryValue other = (BinaryValue) obj;
> if (text == other.text && stream == other.stream
> && streamData == other.streamData) {
> return true;
> }
> // stream, streamData and text are mutually exclusive,
> // i.e. only one of them can be non-null
> if (stream != null) {
> return stream.equals(other.stream);
> } else if (streamData != null) {
> return streamData.equals(other.streamData);
> } else {
> return text.equals(other.text);
> }
> }
> return false;
> }
> Here are the problems with the present implementation
> 1. streamData.equals(other.streamData ) will fail miserably.
> 2. too many return statements! I guess no one ran a checkstyle on it.
> 3. return stream.equals(other.stream); will always be false unless both have
> been created with the same InputStream!
> I wrote some testcases in SetValueBinaryTest
> public void testBinaryValueEquals() throws Exception {
> BinaryValue binaryValue1 = null;
> BinaryValue binaryValue2 = null;
> // initialize some binary value
> data = createRandomString(10).getBytes();
> binaryValue1 = (BinaryValue)
> superuser.getValueFactory().createValue(new ByteArrayInputStream(data));
> binaryValue2 = (BinaryValue) superuser.getValueFactory
> ().createValue(new ByteArrayInputStream(data));
> //ideallly setup a test harness that tests all the cases as defined
> by the contract in Object.equals()
> assertTrue( binaryValue1.equals(binaryValue2));
> assertTrue( binaryValue1.equals(binaryValue1));
> assertFalse( binaryValue1.equals(null));
> }
> public void testBinaryValueEquals2() throws Exception {
> String str = createRandomString(10);
> BinaryValue binaryValue1 = new BinaryValue(str.getBytes());
> BinaryValue binaryValue2 = new BinaryValue(str.getBytes());
> assertTrue( binaryValue1.equals(binaryValue2));
> assertTrue( binaryValue1.equals(binaryValue1));
> assertFalse( binaryValue1.equals(null));
> }
>
> public void testBinaryValueEquals3() throws Exception {
> String str1 = "Some string xyz";
> String str2 = new StringBuffer().append("Some string xyz").toString();
> BinaryValue binaryValue1 = new BinaryValue(str1);
> BinaryValue binaryValue2 = new BinaryValue(str2);
> assertTrue( binaryValue1.equals(binaryValue2));
> assertTrue( binaryValue1.equals(binaryValue1));
> assertFalse( binaryValue1.equals(null));
> }
> They were written quickly but with the present implementation the first two
> fail at the very first assert* statement which for stream I can understand
> (as we are basically propogating InputStream's equals contract) but for byte
> arrays I can't agree with this behaviour unless it is so intended. It behaves
> the best when BinaryVlaue wraps a string i.e. testBinaryValueEquals3()
> passes without trouble.
> I propose a new implementation where I am not very convinced with the
> behaviour when we have streams being wrapped. If it should fail for the
> streams then we should change the documentation for the method. As for making
> it work right when streams are involved .. well the streams will have to be
> read and compared.
>
> public boolean equals(Object obj) {
> boolean result = false;
> if (this == obj) {
> result = true;
> } else if (obj instanceof BinaryValue) {
> BinaryValue other = (BinaryValue) obj;
> // only one of text, stream and streamData are set at any given
> point
> if (text != null) {
> result = text.equals(other.text);
> } else if
[jira] Updated: (JCR-433) NodeTypeRegistry could auto-subtype from nt:base
[ http://issues.apache.org/jira/browse/JCR-433?page=all ] Jukka Zitting updated JCR-433: -- Attachment: jackrabbit-ntd-r41844.patch Attached is a possible patch for fixing this. The patch modifies NodeTypeDef.getSupertypes() to return nt:base for all primary types with no explicitly set supertypes. This should cover not only CND, but all tools and code that work on node types. > NodeTypeRegistry could auto-subtype from nt:base > > > Key: JCR-433 > URL: http://issues.apache.org/jira/browse/JCR-433 > Project: Jackrabbit > Type: Improvement > Components: nodetype > Versions: 1.0, 1.0.1, 0.9 > Reporter: Tobias Bocanegra > Assignee: Jukka Zitting > Priority: Minor > Fix For: 1.1 > Attachments: jackrabbit-ntd-r41844.patch > > when tying to register a (primary) nodetype that does not extend from nt:base > the following error is > thrown: > "all primary node types except nt:base itself must be (directly or > indirectly) derived from nt:base" > since the registry is able to detect this error, it would be easy to > auto-subtype all nodetypes from nt:base. imo it's pointless to explzitely add > the nt:base to every supperclass set. as an analogy, you don't need to > 'extend from java.lang.Object' explicitely - the compiler does that > automatically for your. -- 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] Assigned: (JCR-467) CompactNodeTypeReader fails to explain why valid JCR names cause errors
[ http://issues.apache.org/jira/browse/JCR-467?page=all ]
Jukka Zitting reassigned JCR-467:
-
Assign To: Jukka Zitting
> CompactNodeTypeReader fails to explain why valid JCR names cause errors
> ---
>
> Key: JCR-467
> URL: http://issues.apache.org/jira/browse/JCR-467
> Project: Jackrabbit
> Type: Improvement
> Versions: 1.0, 1.0.1
> Reporter: Brian Ewins
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 1.1
>
> for example, you cannot use underscores in node type definitions:
> [my:example_breaks2]
> In fact only A-Z, a-z, 0-9, : are allowed, unless you quote the name. The
> error message you see when you make this mistake doesn't give any hint:
> Missing ']' delimiter for end of node type name (nodetypes.cnd, line 8)
> and the documentation on the website and the javadoc for
> CompactNodeTypeDefReader both just say:
> * unquoted_string ::= ...a string...
> ... not helpful. If you made this mistake, you end up needing to look at the
> source to figure out what you've done wrong.
> A few suggested solutions:
> - change the documentation to say unquoted string is '[A-Za-z0-9:]+'
> - change the error message to mention the token causing the problem, eg:
> if (!currentTokenEquals(Lexer.END_NODE_TYPE_NAME)) {
> lexer.fail("Missing '" + Lexer.END_NODE_TYPE_NAME + "' delimiter
> for end of node type name, found " + currentToken);
> }
> - add "st.wordChars('_','_');" to the lexer, its probably going to be the
> most common cause, and doesnt conflict with other rules.
--
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] Resolved: (JCR-467) CompactNodeTypeReader fails to explain why valid JCR names cause errors
[ http://issues.apache.org/jira/browse/JCR-467?page=all ]
Jukka Zitting resolved JCR-467:
---
Resolution: Fixed
Fixed as suggested in revision 418446. Thanks a lot for the excellent bug
report with an accurate fix!
> CompactNodeTypeReader fails to explain why valid JCR names cause errors
> ---
>
> Key: JCR-467
> URL: http://issues.apache.org/jira/browse/JCR-467
> Project: Jackrabbit
> Type: Improvement
> Versions: 1.0, 1.0.1
> Reporter: Brian Ewins
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 1.1
>
> for example, you cannot use underscores in node type definitions:
> [my:example_breaks2]
> In fact only A-Z, a-z, 0-9, : are allowed, unless you quote the name. The
> error message you see when you make this mistake doesn't give any hint:
> Missing ']' delimiter for end of node type name (nodetypes.cnd, line 8)
> and the documentation on the website and the javadoc for
> CompactNodeTypeDefReader both just say:
> * unquoted_string ::= ...a string...
> ... not helpful. If you made this mistake, you end up needing to look at the
> source to figure out what you've done wrong.
> A few suggested solutions:
> - change the documentation to say unquoted string is '[A-Za-z0-9:]+'
> - change the error message to mention the token causing the problem, eg:
> if (!currentTokenEquals(Lexer.END_NODE_TYPE_NAME)) {
> lexer.fail("Missing '" + Lexer.END_NODE_TYPE_NAME + "' delimiter
> for end of node type name, found " + currentToken);
> }
> - add "st.wordChars('_','_');" to the lexer, its probably going to be the
> most common cause, and doesnt conflict with other rules.
--
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] Commented: (JCR-415) Enhance indexing of binary content
[ http://issues.apache.org/jira/browse/JCR-415?page=comments#action_12418774 ] Jukka Zitting commented on JCR-415: --- See a related email thread at http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/7609 > Enhance indexing of binary content > -- > > Key: JCR-415 > URL: http://issues.apache.org/jira/browse/JCR-415 > Project: Jackrabbit > Type: Improvement > Components: indexing > Versions: 1.0, 1.0.1, 0.9 > Reporter: Marcel Reutegger > Priority: Minor > Fix For: 1.1 > > Indexing of binary content should be enhanced in order to allow either > configuration what fields are indexed or provide better support for custom > NodeIndexer implementations. > The current design has a couple of flaws that should be addressed at the same > time: > - Reader instances are requested from the text filters even though the reader > might never be used > - only jcr:data properties of nt:resource nodes are fulltext indexed > - It is up to the text filter implementation to decide the lucene field name > for the text representation, responsibility should be moved to the > NodeIndexer. A text filter should only provide a Reader instance. > With those changes a custom NodeIndexer can then decide if a binary property > has one or more representations in the index. -- 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] Assigned: (JCR-413) JCA will not compile with J2EE1.3 classes
[ http://issues.apache.org/jira/browse/JCR-413?page=all ]
Jukka Zitting reassigned JCR-413:
-
Assign To: Jukka Zitting
> JCA will not compile with J2EE1.3 classes
> -
>
> Key: JCR-413
> URL: http://issues.apache.org/jira/browse/JCR-413
> Project: Jackrabbit
> Type: Bug
> Components: jca
> Versions: 1.0, 1.0.1
> Environment: JDK1.4.2
> SunOne AppServer 7
> Reporter: Ross Black
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 1.1
>
> In JCAManagedConnectionFactory, the constructor invoked to throw
> ResourceException does not exist under J2EE1.3 / JCA1.1 classes.
> throw new ResourceException(e) - line 136 and line 277.
> Instead the code needs to do something like:
> ResourceException exception = new ResourceException("Failed to
> create session");
> exception.setLinkedException(e);
> throw exception;
> This will allow it to compile/run under J2EE1.3
--
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] Resolved: (JCR-413) JCA will not compile with J2EE1.3 classes
[ http://issues.apache.org/jira/browse/JCR-413?page=all ]
Jukka Zitting resolved JCR-413:
---
Resolution: Fixed
Fixed in revision 418448. Thanks for reporting this!
> JCA will not compile with J2EE1.3 classes
> -
>
> Key: JCR-413
> URL: http://issues.apache.org/jira/browse/JCR-413
> Project: Jackrabbit
> Type: Bug
> Components: jca
> Versions: 1.0, 1.0.1
> Environment: JDK1.4.2
> SunOne AppServer 7
> Reporter: Ross Black
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 1.1
>
> In JCAManagedConnectionFactory, the constructor invoked to throw
> ResourceException does not exist under J2EE1.3 / JCA1.1 classes.
> throw new ResourceException(e) - line 136 and line 277.
> Instead the code needs to do something like:
> ResourceException exception = new ResourceException("Failed to
> create session");
> exception.setLinkedException(e);
> throw exception;
> This will allow it to compile/run under J2EE1.3
--
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
Accessing Jackrabbit repository from WebDAV Client(Dreamweaver, FrontPage 2003)
Dear All, I am trying to access jackrabbit repository from Microsoft FrontPage 2003 through the remote website option. But after giving the correct URL, username and password, the remote website doesn't display the repository contents. But the same works fine for Macromedia Dreamweaver 8. Can anyone help me on this? Regards, Shanmugam G _ Who will win Bollywoods most coveted IIFA awards? You decide! Cast your vote! http://server1.msn.co.in/sp06/IIFA2006/static/weekend.asp
Planning for Jackrabbit 1.1
Hi, As you've probably noticed, I started grooming Jira for the upcoming 1.1 release and took care of some low hanging fruits in the issue list. I'll start working on a more detailed release plan for Jackrabbit 1.1. I'd like to have the release out during Q3. Please feel free to add, remove or comment on issues targeted for the release. As of now the issue list for 1.1 in Jira should be considered an early (and relatively optimistic) approximation. Some highlights from the initial issue list include Maven 2.0 and Lucene 2.0 support. I'll start working on the already contributed (thanks, Fabrizio!) Maven 2 poms, and it would be nice if someone could take a quick look at Lucene 2.0. As discussed before, the 1.1 release will not contain any backwards-incompatible changes to the exposed client interfaces (JCR and o.a.j.api), but may contain internal changes and can require manual upgrade procedures. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Unable to Checkin file to Jackrabbit repository from webdav Client
Dear All, I have configured my Dreamweaver to access Jackravbbit repository using Mangaesite Options. Here are the activities I have done...! Let us say I have a folder called "Sample" in Jackrabbit repository 1) Checked out Sample folde to my local folder(Say D:\LocalRepository) using checkout option ofDreamweaver. 2) Now a folder is created in my local folder.(D:\LocalRepository\Sample). 3) I added a file called Hello.txt to the above folder(D:\LocalRepository\Sample\Hello.txt). 4) I checked in the folder Sample. 5) Now the file is added properly to the Repository.( Cross checked this). 6) Again I checked out the file Hello.txt 7) A lock file is created in my local folder. 8) After making some changes to the Hello.txt, I am trying to check in. Now I got the following error. org.apache.jackrabbit.webdav.DavException: Locked at org.apache.jackrabbit.webdav.simple.DavResourceImpl.addMember(DavResourceImpl.java:586) at org.apache.jackrabbit.server.AbstractWebdavServlet.doPut(AbstractWebdavServlet.java:659) at org.apache.jackrabbit.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:317) at org.apache.jackrabbit.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:255) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:536) It says that the resource is locked... But the checkin/checkout of Dreamweaver(Manage sites) works fine for other repositories(Local network). I have added the mixins "mix:versionable" and "mix:lockable" to the repository folder. I don't know whether the problem is with Jackrabbit or Dreamweaver. Can anybody help me on this? Regards, Shan _ Shah Rukh fan? Know all about the Baadshah of Bollywood. On MSN Search http://server1.msn.co.in/profile/shahrukh.asp
Unable to checkout/checkin file from Jackrabbit repository using Dreamweaver
Dear All, Using Dreamweaver Manage site options, I am able to access Jackrabbit repository. I am getting the repository content correctly. But, while trying to checkout/checkin, it's not happening properly. After making some changes to the file which is checked out, I am trying to checkin the same. But the changes are not reflected correctly. I am not able to find out the root cause of the problem. Can anyone help on this? Regards, Shanmugam G _ NRIs: Send Money FREE! Go ahead and register now! http://ads.mediaturf.net/event.ng/Type=click&FlightID=20273&AdID=65989&TargetID=11172&Targets=11172&Values=202,414,1093,1264,3122&Redirect=http:%2F%2Fwww.icicinri.net%2Fmoney2india%2F%3Fm2i%3DBAC-MSN%26att%3DMSNTLM2I18CHAR%26rfr%3DMSNTLM2I18CHAR
[jira] Subscription: open issues
Issue Subscription Filter: open issues (54 issues) Open Issues for Apache Jackrabbit Subscriber: jackrabbitdev Key Summary JCR-472 Wrap IllegalArgumentException from UUID when bad ID passed to Session.getNodeByUUID http://issues.apache.org/jira/browse/JCR-472 JCR-468 Item.isSame() may return true for 2 nodes from different workspaces. http://issues.apache.org/jira/browse/JCR-468 JCR-465 Provide a method to rename workspace http://issues.apache.org/jira/browse/JCR-465 JCR-464 Prevent out of memory errors http://issues.apache.org/jira/browse/JCR-464 JCR-463 Uncommitted changes or connection leak with Container Managed Transactions http://issues.apache.org/jira/browse/JCR-463 JCR-446 Prevent logins during repository shutdown http://issues.apache.org/jira/browse/JCR-446 JCR-442 Implement a backup tool http://issues.apache.org/jira/browse/JCR-442 JCR-441 Session logout doesn't release locks acquired using addLockToken http://issues.apache.org/jira/browse/JCR-441 JCR-435 Node.update() does not work correct for SNS http://issues.apache.org/jira/browse/JCR-435 JCR-433 NodeTypeRegistry could auto-subtype from nt:base http://issues.apache.org/jira/browse/JCR-433 JCR-427 thread local variable commitLog not dispose http://issues.apache.org/jira/browse/JCR-427 JCR-419 Request for other RMI binding options in RepositoryStartupServlet http://issues.apache.org/jira/browse/JCR-419 JCR-418 .NET build scripts for Jackrabbit http://issues.apache.org/jira/browse/JCR-418 JCR-417 Splitting Jcr-Server http://issues.apache.org/jira/browse/JCR-417 JCR-416 Webdav Simple: Delegate PROPPATCH to (extended) IOHandlers http://issues.apache.org/jira/browse/JCR-416 JCR-415 Enhance indexing of binary content http://issues.apache.org/jira/browse/JCR-415 JCR-406 If header evaluation compliance provlems http://issues.apache.org/jira/browse/JCR-406 JCR-402 release module jackrabbit-bdb 1.0 http://issues.apache.org/jira/browse/JCR-402 JCR-399 DBFileSystem database connections strings stored in database http://issues.apache.org/jira/browse/JCR-399 JCR-397 Webdav Library: MultiStatusResponse calls DavResource#getProperties() in case of PROPFIND by property. http://issues.apache.org/jira/browse/JCR-397 JCR-394 WebDAV Library: Define method-set constants that reflect the feature set. http://issues.apache.org/jira/browse/JCR-394 JCR-392 Accessing element by number does not work http://issues.apache.org/jira/browse/JCR-392 JCR-390 Move text extraction into a background thread http://issues.apache.org/jira/browse/JCR-390 JCR-388 add support for RFC 3253 to the simple server http://issues.apache.org/jira/browse/JCR-388 JCR-387 NPE in classes of OJB-PM http://issues.apache.org/jira/browse/JCR-387 JCR-385 ClassCastExeption when executing union queries http://issues.apache.org/jira/browse/JCR-385 JCR-372 Consistently refer to "Apache Jackrabbit" in docs and site http://issues.apache.org/jira/browse/JCR-372 JCR-352 Upgrade to Lucene 2.0 http://issues.apache.org/jira/browse/JCR-352 JCR-350 WebDAV: add support for RFC 3744 http://issues.apache.org/jira/browse/JCR-350 JCR-332 maven2 pom contribution http://issues.apache.org/jira/browse/JCR-332 JCR-324 Create a mechanism allowing Jackrabbit to automatically install custom nodes when it creates a repository http://issues.apache.org/jira/browse/JCR-324 JCR-322 Support node type modification and removal http://issues.apache.org/jira/browse/JCR-322 JCR-320 BinaryValue equals fails for two objects with two different byte arrays that contain the same bytes. http://issues.apache.org/jira/browse/JCR-320 JCR-314 Fine grained locking in SharedItemStateManager http://issues.apache.org/jira/browse/JCR-314 JCR-299 errors in text filters can cause indexing to fail without warning the client http://issues.apache.org/jira/browse/JCR-299 JCR-272 Removal of versions throws javax.jcr.ReferentialIntegrityException http://issues.apache.org/jira/browse/JCR-272 JCR-269 Support other than equality comparisons for the XPath position() function http://issues.apache.org/jira/browse/JCR-269 JCR-263 HibernatePersistenceManager fails to store NodeReferences http://issues.apache.org/jira/browse/JCR-263 JCR-260 Implement the count( ) function in XPATH query http://issues.apache.org/jira/browse/JCR-260 JCR-247 Child axis support for XPath predicates http://issues.apache.org/jira/browse/JCR-247 JCR-
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch.txt I have updated the code as seen through the mailing list. I am more available now that most of my exams are over (only one remaining on Friday - crossing fingers). If everybody's OK with this work. I will continue working on the methods body (see methods started but commented). I am waiting for your feedback :) > Implement a backup tool > --- > > Key: JCR-442 > URL: http://issues.apache.org/jira/browse/JCR-442 > Project: Jackrabbit > Type: New Feature > Reporter: Jukka Zitting > Attachments: patch, patch.txt > > Issue for tracking the progress of the Google Summer of Code project assigned > to Nicolas Toper. The original project requirements are: > "Implement a tool for backing up and restoring content in an Apache > Jackrabbit content repository. In addition to the basic content hierarchies, > the tool should be able to efficiently manage binary content, node version > histories, custom node types, and namespace mappings. Incremental or > selective backups would be a nice addition, but not strictly necessary." -- 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
