[jira] Resolved: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-388. Resolution: Fixed committed changes with rev. 559335 add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: JCR-388_2007_07_19.patch, patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-984) [PATCH] Make DocViewImportHandler more robust against broken Attributes.getURI() method
[ https://issues.apache.org/jira/browse/JCR-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-984. Resolution: Won't Fix [PATCH] Make DocViewImportHandler more robust against broken Attributes.getURI() method --- Key: JCR-984 URL: https://issues.apache.org/jira/browse/JCR-984 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Bertrand Delacretaz Priority: Trivial Attachments: DocViewImportHandler.patch DocViewImportHandler throws NullPointerException when the XML parser (incorrectly) returns null for the Attributes.getURI() call. This small patch makes it more robust against this. Whether this is a good idea is debatable - failing loudly on a broken parser might be more desirable - let's see what people think. The problem happened during testing when an old version of the XPP parser (http://www.extreme.indiana.edu/xgws/xsoap/xpp/) found its way in our webapp's war file (pull-parser-2.jar, md5sum=1a1a909825c1bfd9b0cdfa3b29969438). It might be useful to log some info about which parser is being used, I'll see if I can contribute something for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Hi Marcel, On 7/24/07, Marcel May [EMAIL PROTECTED] wrote: Jackrabbit JCA basically wraps Jackrabbit Core, but still all the Core PersistenceManager and FileSystem implementations are used. These, as you mentioned as well, use and manager their own JDBC connections and therefore can never be JTA/XA compliant: - JTA/XA requires using a (distributed) transaction manager - Jackrabbit directly invokes setAutoCommit/commit/rollback without a transaction manager (illegal in JTA/XA terms!) - Jackrabbit Workspace with a DB FileSystem and DB PersistenceManager have two separate configured connections w/o a transaction manager. Example: - If Jackrabbit rolls back a TX directly on a connection, the distributed transaction will not know about this. - If the distributed TX is rolled back, Jackrabbit might already have invoked con.commit() ... therefore no rollback is possible. When using Jackrabbit JCA, every repository operation made on behalf of a distributed transaction is recorded in a change log, something not associated with the JDBC connection used normally. This change log will not be persisted on invididual save calls, but only when the respective method calls on the XAResource interface, exposed by Jackrabbit JCA, are invoked. Therefore, I don't think the situations you describe are actually encountered. Spec says a JCR impl can support TXs, and if it supports TXs it must support JTA. Right? I'd say so. The Jackrabbit impl. can not be transactional on workspace level if internally a database PersistenceManager and a databasse FileSystem each have their own database connection: An operation spawns the persistence manager (=pm) and the filesystem (=fm), right? If one part (fm/pm) succeeds and is commited, the other part (fm/pm) might fail and therefore violate the ACID principle? How do the two db connections of PM and FS work together? This IMO can only be managed by JTA/XA. AFAIK, the FS is mainly used for configuration purposes and therefore plays an important role on startup. PM, on the other side, is the one used when it comes to saving content in the repository. You're right, that a combination of PM/FS operations is conceivable where one side reports success and the other doesn't, but that shouldn't happen in real life. Again, when using Jackrabbit JCA, every operation that could potentially end up in a JDBC call writing some data, is rather logged to some internal storage and only executed when the distributed transaction is committed. It is only at that point in time, that all changes are written at one time using the PM's JDBC connection. Cheers Dominique P.S.: I'd be willing to provide a documentation patch at the end of this discussion :-) Always happy to find some volunteers :-)
[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515276 ] Ed Burnette commented on JCR-388: - Thanks! add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: JCR-388_2007_07_19.patch, patch_16JUL07.txt, patch_16JUL07.zip, patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1034) Unable to save session after saving a renamed node
Unable to save session after saving a renamed node
--
Key: JCR-1034
URL: https://issues.apache.org/jira/browse/JCR-1034
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Edgar Poce
Priority: Minor
TransientRepository repo = new TransientRepository(
applications/test/repository.xml,
applications/test);
Session s = repo.login(new SimpleCredentials(test,
.toCharArray()));
if (s.getRootNode().hasNode(parent)) {
s.getRootNode().getNode(parent).remove();
s.save();
}
// create parent node
Node parent = s.getRootNode().addNode(parent);
// create node to rename
parent.addNode(newnode);
s.save();
// rename node
s.move(/parent/newnode, /parent/renamedNewNode);
// save renamed node
s.getRootNode().getNode(parent/renamedNewNode).save();
// try to save session -- FAILS
s.save();
s.logout();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1035) Jackrabbit JCA - The client can bypass the managed connection and get the underlying JCR Session
Jackrabbit JCA - The client can bypass the managed connection and get the underlying JCR Session Key: JCR-1035 URL: https://issues.apache.org/jira/browse/JCR-1035 Project: Jackrabbit Issue Type: Bug Components: jca Reporter: Edgar Poce Priority: Minor By using Item.getSession() the client can access the underlying jcr session, eventually close the connection and generate a session leak. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1034) Unable to save session after saving a renamed node
[
https://issues.apache.org/jira/browse/JCR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned JCR-1034:
--
Assignee: Stefan Guggisberg
Unable to save session after saving a renamed node
--
Key: JCR-1034
URL: https://issues.apache.org/jira/browse/JCR-1034
Project: Jackrabbit
Issue Type: Bug
Components: core
Reporter: Edgar Poce
Assignee: Stefan Guggisberg
Priority: Minor
TransientRepository repo = new TransientRepository(
applications/test/repository.xml,
applications/test);
Session s = repo.login(new SimpleCredentials(test,
.toCharArray()));
if (s.getRootNode().hasNode(parent)) {
s.getRootNode().getNode(parent).remove();
s.save();
}
// create parent node
Node parent = s.getRootNode().addNode(parent);
// create node to rename
parent.addNode(newnode);
s.save();
// rename node
s.move(/parent/newnode, /parent/renamedNewNode);
// save renamed node
s.getRootNode().getNode(parent/renamedNewNode).save();
// try to save session -- FAILS
s.save();
s.logout();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1036) JCR2SPI; setProperty(name, date-string) fails when property is added and property type is PropertyType.DATE.
JCR2SPI; setProperty(name, date-string) fails when property is added and
property type is PropertyType.DATE.
Key: JCR-1036
URL: https://issues.apache.org/jira/browse/JCR-1036
Project: Jackrabbit
Issue Type: Bug
Components: SPI
Reporter: Julian Reschke
Example code:
Node l_parent = (Node)session.getItem(this.m_path);
Node l_test = l_parent.addNode(createcontenttest, nt:file);
Node l_content = l_test.addNode(jcr:content, nt:resource);
l_content.setProperty(jcr:encoding, UTF-8);
l_content.setProperty(jcr:mimeType, text/plain);
l_content.setProperty(jcr:data, new
ByteArrayInputStream(foobar.getBytes()));
l_content.setProperty(jcr:lastModified, 2007-07-25T17:04:00.000Z);
// TODO: this should work as well, bug in JCR2SPI?
session.save();
This will fail when the property is defined as DATE, what should happen is that
a value comparison is attempted (note that it works when the property already
exists and just is overwritten).
The exception is:
javax.jcr.nodetype.ConstraintViolationException: no matching property
definition found for {http://www.jcp.org/jcr/1.0}lastModified
at
org.apache.jackrabbit.jcr2spi.nodetype.ItemDefinitionProviderImpl.getQPropertyDefinition(ItemDefinitionProviderImpl.java:269)
at
org.apache.jackrabbit.jcr2spi.nodetype.ItemDefinitionProviderImpl.getQPropertyDefinition(ItemDefinitionProviderImpl.java:159)
at
org.apache.jackrabbit.jcr2spi.NodeImpl.getApplicablePropertyDefinition(NodeImpl.java:1672)
at
org.apache.jackrabbit.jcr2spi.NodeImpl.createProperty(NodeImpl.java:1369)
at org.apache.jackrabbit.jcr2spi.NodeImpl.setProperty(NodeImpl.java:264)
at org.apache.jackrabbit.jcr2spi.NodeImpl.setProperty(NodeImpl.java:345)
at org.apache.jackrabbit.jcr2spi.NodeImpl.setProperty(NodeImpl.java:336)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Jackrabbit 1.3.1
[X] +1 Release the packages as Apache Jackrabbit 1.3.1 2007/7/21, Jukka Zitting [EMAIL PROTECTED]: Hi, I have posted a candidate for the Apache Jackrabbit 1.3.1 release at http://people.apache.org/~jukka/jackrabbit/1.3.1/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The release was made from the 1.3 branch after merging in all the changes listed in the release notes. The release candidate consists of the traditional source and binary packages as well as a staged Maven repository that contains the 1.3.1 release artifacts. Please vote on releasing these packages as Apache Jackrabbit 1.3.1. The vote passes if at least three +1 votes are cast. [ ] +1 Release the packages as Apache Jackrabbit 1.3.1 [ ] -1 Do not release the packages because... Here's my +1, compiled and tested on Ubuntu Linux with Java 5 and on Windows XP with Java 6. BR, Jukka Zitting -- Alexandre Costa Martins CESAR - Recife Center for Advanced Studies and Systems Software Engineer and Software Reuse Researcher MSc Candidate at Federal University of Pernambuco RiSE Member - http://www.rise.com.br Sun Certified Programmer for Java 5.0 (SCPJ5.0) E-mail: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] GTalk: [EMAIL PROTECTED] Skype: xandecmartins Mobile: +55 (81) 9929-9548 Office: +55 (81) 3425-4763 Fax: +55 (81) 3425-4701
