Re: [jira] Commented: (JCR-1039) Bundle Persistence Manager error - failing to read bundle the first time
Hi, As Stefan already wrote, the exception 40XD0: Container has been closed is related to Derby. However, the stack trace you posted does not include Derby... Could you please check if there is some more stack trace (the root cause) and post that as well? So is there any fix that I can use for now? I think it will take a day or two until a 'real' patch is available. In my view it is important to have a reproducible test case as well. I suggest to try out the following (unfortunately, I can't test it at the moment): BundleDbPersistenceManager.java: +import java.io.BufferedInputStream; ... protected synchronized NodePropBundle loadBundle(NodeId id) ... Blob b = rs.getBlob(1); -TrackingInputStream cin = new TrackingInputStream(b.getBinaryStream()); +int size = (int) b.length(); +InputStream in = new BufferedInputStream(b.getBinaryStream(), size); +TrackingInputStream cin = new TrackingInputStream(in); din = new DataInputStream(cin); ... Thanks, Thomas
Creation of Repository and Workspace Directories
Hi, Does Jackrabbit always create the directory structure for repository and workspace? Is there some way I can set my own repository.xml and workspace.xml programmatically and if I'm using a Database for storage, can I prevent Jackrabbit from creating the directory structure. Thanks. Regards Kaizer MASTEK Making a valuable difference Mastek in NASSCOM's 'India Top 20' Software Service Exporters List. In the US, we're called MAJESCOMASTEK ~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from all computers. ~~
[jira] Created: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails
Non-versionable children of a versionable node should not be updated when a merge fails --- Key: JCR-1046 URL: https://issues.apache.org/jira/browse/JCR-1046 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.3 Reporter: Bob Wieler The JCR specification (JSR-170) includes a merge algorithm that is inconsistent with the functionality described elsewhere in the JCR specification. Specifically from JSR-170 section 8.2.10 Merge: In either case, (regardless of whether bestEffort is true or false) for each non-versionable node (including both referenceable and non-referenceable), if the merge result of its nearest versionable ancestor is update, or if it has no versionable ancestor, then it is updated to reflect the state of its corresponding node. Otherwise, it is left unchanged. The algorithm presented in 8.2.10.1 of the specification goes against the above statement as it does not take into consideration the merge result of the nearest versionable ancestor. One solution would be to have the doLeave(n) call that dofail(n, v') calls altered to only perform a merge on the versionable children rather than all of the children. The merging of all children (versionable and non-versionable) should only be done if the nearest parent is not in a failed merge state regardless of whether the failure occurred from the current merge operation or a previous merge operation. I will attach a patch file that makes what I think is the required change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails
[ https://issues.apache.org/jira/browse/JCR-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Wieler updated JCR-1046: Attachment: jcr1046.diff Proposed fix for this issue. This is a diff from the trunk branch of jackrabbit (1.4-snapshot). Non-versionable children of a versionable node should not be updated when a merge fails --- Key: JCR-1046 URL: https://issues.apache.org/jira/browse/JCR-1046 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.3 Reporter: Bob Wieler Attachments: jcr1046.diff The JCR specification (JSR-170) includes a merge algorithm that is inconsistent with the functionality described elsewhere in the JCR specification. Specifically from JSR-170 section 8.2.10 Merge: In either case, (regardless of whether bestEffort is true or false) for each non-versionable node (including both referenceable and non-referenceable), if the merge result of its nearest versionable ancestor is update, or if it has no versionable ancestor, then it is updated to reflect the state of its corresponding node. Otherwise, it is left unchanged. The algorithm presented in 8.2.10.1 of the specification goes against the above statement as it does not take into consideration the merge result of the nearest versionable ancestor. One solution would be to have the doLeave(n) call that dofail(n, v') calls altered to only perform a merge on the versionable children rather than all of the children. The merging of all children (versionable and non-versionable) should only be done if the nearest parent is not in a failed merge state regardless of whether the failure occurred from the current merge operation or a previous merge operation. I will attach a patch file that makes what I think is the required change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1047) Update link for javadocs from 1.0 to 1.3
Update link for javadocs from 1.0 to 1.3 Key: JCR-1047 URL: https://issues.apache.org/jira/browse/JCR-1047 Project: Jackrabbit Issue Type: Bug Components: site Reporter: Stephen More On this page: http://jackrabbit.apache.org/doc/arch/overview/jcrlevels.html You see this link: Browse current Jackrabbit API: http://jackrabbit.apache.org/api-1/index.html This should point to the latest javadoc version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1048) JNDIDatabaseFileSystem was not woring in tomcat webapp
JNDIDatabaseFileSystem was not woring in tomcat webapp
--
Key: JCR-1048
URL: https://issues.apache.org/jira/browse/JCR-1048
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.3
Reporter: Stephen More
The new method should look like this:
protected Connection getConnection() throws NamingException, SQLException {
InitialContext ic = new InitialContext();
DataSource dataSource = null;
try
{
dataSource = (DataSource) ic.lookup(dataSourceLocation);
}
catch( javax.naming.NameNotFoundException e )
{
// Now lets try it this way
javax.naming.Context envCtx = (javax.naming.Context)ic.lookup(
java:comp/env );
dataSource = (DataSource) envCtx.lookup(dataSourceLocation);
}
return dataSource.getConnection();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Sling Proposal
Hi, I have read the documention but I am still confuse on the purpose and benefit of sling, can you please give me a brief explanation of what is does and where it applicable, say a usecase scenario. Thanks Felix Meschberger [EMAIL PROTECTED] wrote: Hi all, You may have noticed, that I started adding pages to the Jackrabbit Wiki on a new project called Sling ([1]). The main features of Sling may be summarized as follows: * Uses a JCR Repository as its data store * Uses Jackrabbit OCM to map Repository Items to Java Objects * Internally deals with Java Objects * Built as OSGi Bundles supporting any compliant OSGi framework * Provides integration into Apache Felix for launching and OSGi services support * Componentized data model allowing flexible web application building * Based on standard Servlet API * Open to allow support for web application complying with REST architectural style * Each Node for which a valid Jackrabbit OCM mapping exists may be addressed by URL Sling has been developed at Day to provide a common Web Application Development Framework for future products based on Java Content Repositories. During this development we realized that such a framework would be of benefit not only to Day but also to the Community at large. For this reason, we decided to offer Sling to the community at Apache. We envision to submit the project to the Incubator under the name Sling with the final goal to make Sling a sub project of the Jackrabbit project. As part of the submission process we have to put together a Project Proposal for the Incubator describing the project and nominating a set of initial commiters and a sponsoring entity. An initial draft of this proposal may be found at [2]. As we are heading to have Sling as a subproject in Jackrabbit, we propose to have the Jackrabbit PMC be the sponsoring entity for the Sling poddling (subject to a successful vote). In the next few days I will be adding more documentation of Sling to the Jackrabbit Wiki such that you may gain some initial insight into Sling. In the meantime, I invite you to read through the material and comment on it as you see fit. Additionally, I am also looking forward for any people interested to be initial commiters to express their interest. Regards Felix [1] http://wiki.apache.org/jackrabbit/ApacheSling [2] http://wiki.apache.org/jackrabbit/SlingProposal Ransford Segu-Baffoe [EMAIL PROTECTED] https://serenade.dev.java.net/ http://www.noqturnalmediasystems.com/ - Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
[jira] Created: (JCR-1049) mysql.ddl works for mysql5 but not mysql 4.1.20
mysql.ddl works for mysql5 but not mysql 4.1.20 --- Key: JCR-1049 URL: https://issues.apache.org/jira/browse/JCR-1049 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.3 Environment: MySQL 4.1.20 ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes Reporter: Stephen More Perhaps a new column ( primary key ) could get added to the table called uid, which is actually an md5checksum of FSENTRY_PATH and FSENTRY_NAME. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1050) Remove synchronization from JNDI data sources
Remove synchronization from JNDI data sources - Key: JCR-1050 URL: https://issues.apache.org/jira/browse/JCR-1050 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3, 1.2.3, 1.2.2, 1.2.1, 1.1.1, 1.1, 1.0.1, 1.0, 0.9, 1.3.1, 1.4, 2.0 Reporter: Padraic Hannon Using datasources one should be able to rely on the application server to manage PreparedStatement caches therefore pre-creating and holding onto the connection for long periods of time should not be needed. This relates to improvement JCR-313, however, that change did not address the benefits one could see in using an application server controlled datasource. Even if jackrabbit does aim to use an embedded database such a system could be configured to use datasources and could benefit from the removal of the synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
