[jira] Commented: (JCR-1349) JNDIDatabasePersistenceManager calls commit
[ https://issues.apache.org/jira/browse/JCR-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565163#action_12565163 ] Marcel May commented on JCR-1349: -- Deploy Jackrabbit using the JCA adapter and configure an unmanaged datasource (For JBoss: no-tx-datasource/). JNDIDatabasePersistenceManager calls commit --- Key: JCR-1349 URL: https://issues.apache.org/jira/browse/JCR-1349 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.4 Reporter: Jarle B. Hjortland It is not possible to configure either JNDIDatabasePersistenceManager or BundleDbPersistenceManager to use a Managed Datasource. Methods like setAutoCommit, commit and rollback should not be called on managed connections. Try to run Jackrabbit within JBOSS or Apache Geronimo and you should face the same problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1305) JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException
[ https://issues.apache.org/jira/browse/JCR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557994#action_12557994 ] Marcel May commented on JCR-1305: -- It seems that for app server environment (eg JBoss) it works with a user/pwd in both app server datasource configuration and redundantly in the JK PM configuration. The only problem that remains is that for a corporate production environment and as an application provider, I often do not get the production db settings - only a configured datasource. So, this issue remains critical for me as I'd have to go for patching JK myself. I can provide this trivial patch as Thomas suggested. JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException Key: JCR-1305 URL: https://issues.apache.org/jira/browse/JCR-1305 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor When using the org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory, the BundleDbPersistenceManager can not open a database connection via JNDI because the method DataSource.getConnection(user, password) is not supported. Instead, DataSource.getConnection() must be used for this to work. ConnectionFactory.getConnection should be changed to call this method if user name and password are empty. -- 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.4
-1 (non binding): Bundled DB PM + JNDI issue 1305 (https://issues.apache.org/jira/browse/JCR-1305) This causes troubles in an application server environment and only requires a very small fix as suggested in the issue. It would be great if we could get this fixed for 1.4 release. Cheers, Marcel
[jira] Commented: (JCR-1305) JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException
[ https://issues.apache.org/jira/browse/JCR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557692#action_12557692 ] Marcel May commented on JCR-1305: -- Using JK in an app server environment with managed connections, I'm not sure about how the app server will respond to getConnection(user,pwd). The connection from the pool is already authenticated. Guess the app server might not like it at all. Has anyone tested JK+JNDI Bundle conf in any application server? Can we get this fix into 1.4? We've been really looking forward to JNDI support :-) JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException Key: JCR-1305 URL: https://issues.apache.org/jira/browse/JCR-1305 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor When using the org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory, the BundleDbPersistenceManager can not open a database connection via JNDI because the method DataSource.getConnection(user, password) is not supported. Instead, DataSource.getConnection() must be used for this to work. ConnectionFactory.getConnection should be changed to call this method if user name and password are empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: master plan for jsr 283 query implementation
Marcel Reutegger wrote: Thomas Mueller wrote: use javacc for SQL2 parsing I would use a hand-written recursive descent parser. I know I'm probably the only one suggesting this... what are the advantages of a hand-written parser over a generated one? probably performance, but are there other? - Extensibility and easier maintenance - ANTLR/JavaCC are more or less 'standards' - Don't reinvent the wheel :-) It's nice to write your own parser and lexer, but why do that if you get a perfectly generated one? You'll be faster, too, in terms of performance and implementation time. The generated lexer/parser are proven to work in many other projects. - You need to define the grammar anyway, and eg JavaCC can generate Javadoc like grammar documentation using JJDoc regards marcel Cheers, Marcel
[jira] Created: (JCR-1077) Changelog not persisted during two phase commit in prepare phase
Changelog not persisted during two phase commit in prepare phase - Key: JCR-1077 URL: https://issues.apache.org/jira/browse/JCR-1077 Project: Jackrabbit Issue Type: Bug Components: jca Affects Versions: 1.3.1 Reporter: Marcel May Currently, in a XA TX the changelog is only kept in memory in the prepare phase and therefore potentially lost before the final commit phase finishes. A successful prepare() guarantees the persistence of the changes so that in the following commit() phase the changes are made public. Solution could be serializing the ChangeLog between the phases and a final guaranteed deletion upon commit (other ideas?) See previous discussion at http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06525.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Multiple connections (Was: Jackrabbit, the database)
Thomas Mueller wrote: avoid the synchronization on the PreparedStatements I don't think that synchronization on prepared statements is a bottleneck. But you can prove that I am wrong. If writing the changelog is synchronized (not sure if it is), that would be a bottleneck. Thomas The 'synchronization' can also be described as serialization of all DB acccess. A single DB connection can only process a single operation at a time. Jackrabbit locks up completely while storing (example: a larger binary) - not only for reading but also for writing. There has been some improvements AFAIK, but it still applies for write operations. A simple insert of 10MB will look up JR for few seconds, this is quite a problem IMO. Another advantage is that jdbc pools can health check connections. This reduces the complex firewall- or database- 'closed connection reconnect' logic ... if not making it redunant. This improves stability. Also nice: pools usually are often monitorable, most app servers support this. Cheers, Marcel
Re: Jackrabbit, the database
Padraic Hannon wrote: I concur, relational semantics should be buried within the persistence managers. However, I think that one can still delegate transaction handling using JTA to the container rather than using synchronization and connection.autocommit(false). Jackrabbit must support JTA if it wants to support TXs according to the JCR Spec (see previous discussion, http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06525.html). At the moment, this is a spec violation IMO: JR says it supports TXs but w/o JTA support. Should a ticket be opened for this, BTW? Solution would be either JTA support, or not supporting TX. Obviously this should be configurable. Regardless of wether Jackrabbit wraps an underlying RDBMS or not transaction management, esp. in a clustered environment, being handled via the facilities available from one's container should reduce application complexity. Otherwise, one has to go to jgroups or some other project and embed that code which makes configuration/management more difficult in a production environment. I suppose one could write an admin console or expose via JMX admin functionality, however, some of this would be duplicative of the configuration of the container. -paddy Jukka Zitting wrote: Hi, On 8/20/07, Thomas Mueller [EMAIL PROTECTED] wrote: management won't. political reasons. won't move to Jackrabbit *if* Jackrabbit cannot store it in oracle. I agree. My guess is about 50% of larger organizations want a databases as the backend, even if databases are slower. So about 50% don't really care. Agreed, that's my understanding as well. I don't mind things like the current database persistence managers (as long as the persistence interface doesn't require a database), but I strongly feel that suggestions about pushing relational semantics or other similar database concepts higher up in the Jackrabbit architecture would be taking us to the wrong direction. Even though existing relational databases do provide a solution to many of the currently missing or partially implemented pieces in Jackrabbit (backup, clustering, etc., most notably a huge user and administrator base), a relational database will never be an optimal storage for the hierarchical content model in JCR. Essentially, in 5-10 years when we hopefully will start seriously optimizing for performance and scalability, I don't want us in a situation where we need to change the whole underlying architecture to reach real performance gains. BR, Jukka Zitting
Re: [jira] Commented: (JCR-1050) Remove synchronization from JNDI data sources
Stefan Guggisberg (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520257 ] Stefan Guggisberg commented on JCR-1050: discussion on the dev list: -- Forwarded message -- From: Thomas Mueller [EMAIL PROTECTED] Date: Aug 2, 2007 9:33 AM Subject: Re: [jira] Created: (JCR-1050) Remove synchronization from JNDI data sources To: dev@jackrabbit.apache.org Hi, I'm not sure if I understand this request for improvement. Using datasources So you suggest to use DataSource.getConnection(..) instead of DriverManager.getConnection(..)? How do you get / create the datasource object, using JNDI? What about embedded applications where JNDI is not available? I really would like to see Jackrabbit to support DataSource and JNDI. This simplifies the usage in an application server and corporate environments (corporate = the AS admins configure the datasource in the AS and will ask questions why you got a JEE app which can not use the Jdbc Pool for connections ... no chance that in your role as a 'application provider' you will the the production DB password!). How about - Use commons-dbcp for creating and managing datasource - All DB backed PM/FS only use an 'injected' DataSource to get a single connection for now. This greatly reduces the redundant create-connection-from-driver-manager logic from FS, PM and for all implementation types (bundled, simple, ...). Reconnects fetch a fresh connection from the data source. - Create a JNDI PM/FS wrapper for datasource based PM/FS which would fetch the data source from JNDI and inject it into the wrapped PM/FS. one should be able to rely on the application server to manage PreparedStatement caches Do you suggest to create a new PreparedStatement for each request? As already mentioned before in this thread: a JEE datasource pool handles PrepStat caching nicely (nice article: http://www.theserverside.com/tt/articles/article.tss?l=Prepared-Statments) I'm not sure if commons-dbcp would do that, too ... ??? therefore pre-creating and holding onto the connection for long periods of time should not be needed. Could you explain the advantages of 'not holding onto the connection'? I know that MySQL closes connections after 8 hours idle time, are there any other advantages? The mysql idle timeout can be configured on the server side. Also, some firewalls close idle connections. Connection pools can 'health' check the connections before handing one to the application (eg JR). Most DB vendors provide optimized health checking utils (eg for mysql when configuring a datasource on JBoss). This relates to improvement JCR-313, however, that change did not address the benefits one could see in using an application server controlled datasource. What are those benefits? 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. In what way would removal of the synchronization be a benefit? Do you think it would be faster without synchronization? How would you make sure statements are executed in the right order? Thanks, Thomas 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 Reporter: Padraic Hannon Attachments: JNDI_Datasource_Changes.diff 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.
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Cris Daniluk wrote: The changelog is filled with the operations BEFORE the transaction is committed, and its contents is part of the logical view, as far as node traversal is concerned. In other words, before the transaction is committed, you will be the only one seeing those changes, and after commit, everyone will. However, if JR crashes before the changelog has been saved to the RDBMS, the changelog will be lost, as it is memory-based. This is where our concern comes in. Based on your explanation, Jackrabbit is not honoring the JTA spec, nor the general ACID transaction principals (durability, notably). The fact that the committed transaction rolls into the logical view is great, but the fact that there is no flush to permanent storage is not. The JTA spec is bound to the X/Open DTP standard, available at http://www.opengroup.org/onlinepubs/009680699/toc.pdf I think the spec clearly sets the expectation for transaction permanence, and I believe that Jackrabbit clearly misses that, so while I think that the JTA support offered is valuable, it is not truly compliant--probably in a way that would be surprising to most JTA users. I'm no XA expert either but agree with Chris: If Jackrabbit is not storing the ChangeLog in phase one (prepare), the changes can be potentially lost before phase 2 (commit) succeeds. Succeeding a phase one prepare guarantees that no changes are lost. So, for phase one the ChangeLog must be persisted IMO (Jackrabbit would resume after whatever failure and finish the XA TX by executing the recored ChangeLog). If the XA includes Jackrabbit AND the RDBMS AND any other outside participants that may be relevant, it could not be rolled back without Jackrabbit knowing. I'm not sure I understand where Jackrabbit could be left out of the loop on a rollback? I just have some concerns about the flow of control: what JR is supposed to do with its associated JDBC connection when a XA TX is prepared, committed or rolled back. Do I get your point here: instead of using a changelog, continuously write changes made by the client via XA capable JDBC connection to the database, using the fact that uncommitted changes are only visible to that user? If the DBMS supports the two-phase transaction (I believe Postgres does), then you could just use a JTA-enabled version of the JDBC driver and register the DB transaction to the existing XA. Then, while you execute the SQL directly to the RDBMS, it would not be visible as it is not committed. When the global transaction is committed, the DBMS would receive the two-phase commit request(s) and do the right thing automatically. The only other option is to persist the changelog, effectively converting it into a journal. However, I think bringing the DBMS into the XA is probably the quickest way to solve this problem.. - Cris This would be a nice solution I guess. As a result of this discussion, should we open an JIRA issue for JR/JCA? I think no issue exists for this? Thanks alot, Chris and Dominique! This discussion was very helpful for my Jackrabbit internal understanding. Cheers, Marcel
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Hi Dominique! Dominique Pfister wrote: Hi Marcel, On 7/9/07, Marcel May [EMAIL PROTECTED] wrote: I have two questions about Jackrabbit and tx handling. 1) Using Jackrabbit deployed as resource adapter (JCA) and using a BundlePersistenceManager, I wonder if it is XA compliant: The persistence manager BundleDbPersistenceManager invokes setAutoCommit() and commit() on the db connection in the store(ChangeLog) method. This is illegal for managed connections (JTA and XA), right? So what is the right PM/FS for JCA when I want XA? Is it possible at all? The JDBC connection Jackrabbit uses is not a shared resource, managed by some external component, but opened/used/closed by Jackrabbit itself. Therefore, I don't consider this behaviour as being illegal in terms of JTA/XA. Please correct me, if I'm wrong. If there's no JTA/XA support, the only szenario for deploying Jackrabbit as a JCA Resource would be for sharing it across applications in the application server (=ok). I thought you would use Jackrabbit JCA to get Jackrabbit participating in a distributed transaction (XA). It says XA is supported by Jackrabbit if the JCA adapter is used. Quote from the jackrabbit site http://jackrabbit.apache.org/doc/deploy.html: This setup also allows to take advantage of the XA facilities of the Application Server and could use the application servers single sign-on mechanisms that are provided as part of the J2EE framework. So here it is wrongly mentioned that Jackrabbit JCA brings you JTA/XA support? 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. 2) I wonder if the current Jackrabbit impl. is specification conform. I see a conflict with the JCR spec, chapter 8.1 about TXs and JCR implementations: A compliant content repository may support transactions. If it does so, it must adhere to the Java Transaction API (JTA) specification (see http://java.sun.com/products/jta/index.html). Whether a particular implementation supports transactions can be determined by querying the repository descriptor table with Repository.getDescriptor(OPTION_TRANSACTIONS_SUPPORTED) The return value of session.getRepository().getDescriptor(option.transactions.supported) is true, but no JTA is used (again, look at the persistence manager implementations like BundlePersistenceManager, where TX operations are performed directly on the database connection instead handled by a transaction manager). I'm not sure if I get you there: should Jackrabbit return false because of your first argument above? Yes. Spec says a JCR impl can support TXs, and if it supports TXs it must support JTA. Right? Can some Spec expert on the mailing list comment on this? 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. I understand transaction as on eg Workspace level, not PM or FS level. Kind regards Dominique Dominique, thanks alot for your comments. I really would like to clarify on this. My understanding of Jackrabbit internals is not that great, but the individual connections in FS and PM for a Workspace confuse me as how a tx for two connections is handled correctly. And I'd really like to use Jackrabbit JCA with XA support, for which I have these concerns. Cheers, and thx a million - Marcel P.S.: I'd be willing to provide a documentation patch at the end of this discussion :-)
Questions about TX in Jackrabbit, JTA and Spec compliance
I have two questions about Jackrabbit and tx handling. 1) Using Jackrabbit deployed as resource adapter (JCA) and using a BundlePersistenceManager, I wonder if it is XA compliant: The persistence manager BundleDbPersistenceManager invokes setAutoCommit() and commit() on the db connection in the store(ChangeLog) method. This is illegal for managed connections (JTA and XA), right? So what is the right PM/FS for JCA when I want XA? Is it possible at all? 2) I wonder if the current Jackrabbit impl. is specification conform. I see a conflict with the JCR spec, chapter 8.1 about TXs and JCR implementations: A compliant content repository may support transactions. If it does so, it must adhere to the Java Transaction API (JTA) specification (see http://java.sun.com/products/jta/index.html). Whether a particular implementation supports transactions can be determined by querying the repository descriptor table with Repository.getDescriptor(OPTION_TRANSACTIONS_SUPPORTED) The return value of session.getRepository().getDescriptor(option.transactions.supported) is true, but no JTA is used (again, look at the persistence manager implementations like BundlePersistenceManager, where TX operations are performed directly on the database connection instead handled by a transaction manager). I'm really confused ... did I misunderstand the JCR Spec and JTA/XA? Thanks, Marcel
[jira] Commented: (JCR-1013) Connection.setAutoCommit(...) fails if connection is managed for JNDIDatabasePersistenceManager
[ https://issues.apache.org/jira/browse/JCR-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511201 ] Marcel May commented on JCR-1013: -- Yes, thanks. For DatabasePersistenceManager there is no auto commit enabled, for DatabaseFileSystem auto commit is enabled. I wrote the other day a mail to the dev list about TX handling and JTA as some impl parts and the spec are confusing me (see http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200707.mbox/[EMAIL PROTECTED]). Connection.setAutoCommit(...) fails if connection is managed for JNDIDatabasePersistenceManager --- Key: JCR-1013 URL: https://issues.apache.org/jira/browse/JCR-1013 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.3 Environment: JBoss, Jackrabbit 1.3, JNDIDatabasePersistenceManager Reporter: Marcel May Attachments: patch.txt Invoking setAutoCommit() on a db connection fails if the connection is managed. I propose as a workaround to check if the auto commit must be set previous to setting it (a trivial patch will be provided). This can happen eg. if you use JNDI (eg JNDIDatabasePersistenceManager) to fetch the connection on JBoss, and the persistent manager tries to reconnect (see stack trace below). 05 Jul 09:54:24 ERROR sePersistenceManager| failed to re-establish connection java.sql.SQLException: You cannot set autocommit during a managed transaction! at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcAutoCommit(BaseWrapperManagedConnection.java:482) at org.jboss.resource.adapter.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:322) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.initConnection(DatabasePersistenceManager.java:731) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.reestablishConnection(DatabasePersistenceManager.java:806) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:852) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.exists(DatabasePersistenceManager.java:647) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1102) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:289) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:174) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1013) Connection.setAutoCommit(...) fails if connection is managed for JNDIDatabasePersistenceManager
[ https://issues.apache.org/jira/browse/JCR-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel May updated JCR-1013: - Attachment: patch.txt Patch for DatabasePersistenceManager and DatabaseFileSystem.java Connection.setAutoCommit(...) fails if connection is managed for JNDIDatabasePersistenceManager --- Key: JCR-1013 URL: https://issues.apache.org/jira/browse/JCR-1013 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.3 Environment: JBoss, Jackrabbit 1.3, JNDIDatabasePersistenceManager Reporter: Marcel May Attachments: patch.txt Invoking setAutoCommit() on a db connection fails if the connection is managed. I propose as a workaround to check if the auto commit must be set previous to setting it (a trivial patch will be provided). This can happen eg. if you use JNDI (eg JNDIDatabasePersistenceManager) to fetch the connection on JBoss, and the persistent manager tries to reconnect (see stack trace below). 05 Jul 09:54:24 ERROR sePersistenceManager| failed to re-establish connection java.sql.SQLException: You cannot set autocommit during a managed transaction! at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcAutoCommit(BaseWrapperManagedConnection.java:482) at org.jboss.resource.adapter.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:322) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.initConnection(DatabasePersistenceManager.java:731) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.reestablishConnection(DatabasePersistenceManager.java:806) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:852) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.exists(DatabasePersistenceManager.java:647) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1102) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:289) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:174) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-987) Deploy JCA JAR file to maven repository
Deploy JCA JAR file to maven repository --- Key: JCR-987 URL: https://issues.apache.org/jira/browse/JCR-987 Project: Jackrabbit Issue Type: Task Components: jca Reporter: Marcel May Priority: Trivial Please deploy the JCA JAR file to the maven repository (ibiblio) whenever deploying the RAR artifact. The JAR is need for non managed usage of the Jackrabbit JCA, eg. for embedding the resource adapter in your application with Spring JCA in order to use XA for Jackrabbit. It would be nice if this could be done starting at the current 1.3 version (and for future versions, too). Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-988) Configure the maven build for IDE project generation for IDEA and Eclipse
Configure the maven build for IDE project generation for IDEA and Eclipse - Key: JCR-988 URL: https://issues.apache.org/jira/browse/JCR-988 Project: Jackrabbit Issue Type: Improvement Components: maven Reporter: Marcel May Priority: Trivial Can we add a plugin configuration for the maven-idea-plugin and maven-eclipse-plugin, with JDK version set for IDEA and configured source download of dependencies? Simplifies project regeneration and working with IDEA or Eclipse. I'll add a patch. Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-988) Configure the maven build for IDE project generation for IDEA and Eclipse
[ https://issues.apache.org/jira/browse/JCR-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel May updated JCR-988: Attachment: patch.txt Patch for idea and eclipse plugin configuration Configure the maven build for IDE project generation for IDEA and Eclipse - Key: JCR-988 URL: https://issues.apache.org/jira/browse/JCR-988 Project: Jackrabbit Issue Type: Improvement Components: maven Reporter: Marcel May Priority: Trivial Attachments: patch.txt Can we add a plugin configuration for the maven-idea-plugin and maven-eclipse-plugin, with JDK version set for IDEA and configured source download of dependencies? Simplifies project regeneration and working with IDEA or Eclipse. I'll add a patch. Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (JCR-951) OracleFileSystem uses getClass().getResourceAsStream to load schema file
Hi Stefan! Thanks alot, that was fast. Another question - the wiki pages (http://wiki.apache.org/jackrabbit/JackRabbitOnTomcat) mention org.apache.jackrabbit.core.fs.db.JNDIOracleDatabaseFileSystem and org.apache.jackrabbit.core.state.db.JNDIOracleDatabasePersistenceManager . It seems theses classes do not exist in the trunk. Would you accept those implementations, or was there a decision against these implementations? I could open an issue for these and provide a patch, too. Cheers, Marcel Stefan Guggisberg (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-951. --- Resolution: Fixed thanks for the patch! fixed as suggested and applied same change to DatabaseFileSystem BundleDbPersistenceManager as well. fixed in svn r542831. OracleFileSystem uses getClass().getResourceAsStream to load schema file Key: JCR-951 URL: https://issues.apache.org/jira/browse/JCR-951 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Marcel May Assignee: Stefan Guggisberg Priority: Minor Fix For: 1.3.1 Attachments: jackrabbit.542562.patch.txt org.apache.jackrabbit.core.fs.db.OracleFileSystem loads the schema via getClass().getResourceAsStream(...). This makes it impossible to extend the class without either copying the schema ddl file, or overwriting checkSchema(...), as the schema file is not accessible. The solution is to use OracleFilesystem.class.getResourceAsStream(...). See JCR-595 which fixed this already for org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.
[jira] Updated: (JCR-951) OracleFileSystem uses getClass().getResourceAsStream to load schema file
[ https://issues.apache.org/jira/browse/JCR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel May updated JCR-951: Attachment: jackrabbit.542562.patch.txt Patch for OracleFileSystem OracleFileSystem uses getClass().getResourceAsStream to load schema file Key: JCR-951 URL: https://issues.apache.org/jira/browse/JCR-951 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Marcel May Priority: Minor Fix For: 1.3.1 Attachments: jackrabbit.542562.patch.txt org.apache.jackrabbit.core.fs.db.OracleFileSystem loads the schema via getClass().getResourceAsStream(...). This makes it impossible to extend the class without either copying the schema ddl file, or overwriting checkSchema(...), as the schema file is not accessible. The solution is to use OracleFilesystem.class.getResourceAsStream(...). See JCR-595 which fixed this already for org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
