[jira] Commented: (JCR-1892) Unique ID for org.apache.jackrabbit.value.BinaryValue
[ https://issues.apache.org/jira/browse/JCR-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661972#action_12661972 ] Thomas Mueller commented on JCR-1892: - expectations about the string length Sure, what about The string is normally about 50 characters long. With the current definition the implementation could simply return the base64 encoding of the entire binary value! For very short binaries it may make sense to do that. Do we need the DataStore.hasRecord() method? No. Currently, DbDataStore.getRecord() throws an exception if the record doesn't exist, I wanted to avoid that. race conditions with the garbage collection Good point! What about getRecordIfStored()? getRecord() would then just call that method and throw an exception if it returns null. BinaryValueImpl.getContentIdentity() I'd use blob.getDataIdentifier().toString() Ups, that was my plan... not call getContentIdentity() internally You are right of course. Unique ID for org.apache.jackrabbit.value.BinaryValue - Key: JCR-1892 URL: https://issues.apache.org/jira/browse/JCR-1892 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Thomas Mueller Assignee: Thomas Mueller Attachments: JackrabbitValue-api.patch, JackrabbitValue-core.patch BinaryValue should have a method get the unique identifier (if one is available). That way an application may not have to read the stream if that value is already processed. When the DataStore is used, a unique identifier is available, so probably this feature is quite simple to implement. See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html (but please don't reply to this thread from now on - instead add comments to this issue). Another feature is getFileName() to get the file name if it is stored in the file system. This method may need a security mechanism, for example getFileName(Session s) so that the system can check it. In any case the file should not be modified, but maybe knowing the file name is already too dangerous in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1892) Unique ID for org.apache.jackrabbit.value.BinaryValue
[ https://issues.apache.org/jira/browse/JCR-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1892: Attachment: JackrabbitValue-api.patch Proposed JackrabbitValue interface Unique ID for org.apache.jackrabbit.value.BinaryValue - Key: JCR-1892 URL: https://issues.apache.org/jira/browse/JCR-1892 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Thomas Mueller Assignee: Thomas Mueller Attachments: JackrabbitValue-api.patch BinaryValue should have a method get the unique identifier (if one is available). That way an application may not have to read the stream if that value is already processed. When the DataStore is used, a unique identifier is available, so probably this feature is quite simple to implement. See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html (but please don't reply to this thread from now on - instead add comments to this issue). Another feature is getFileName() to get the file name if it is stored in the file system. This method may need a security mechanism, for example getFileName(Session s) so that the system can check it. In any case the file should not be modified, but maybe knowing the file name is already too dangerous in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1892) Unique ID for org.apache.jackrabbit.value.BinaryValue
[ https://issues.apache.org/jira/browse/JCR-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1892: Attachment: JackrabbitValue-core.patch Implementation and tests for the JackrabbitValue. Additionally, values already stored in the repository are not spooled again if the value is stored again. Unique ID for org.apache.jackrabbit.value.BinaryValue - Key: JCR-1892 URL: https://issues.apache.org/jira/browse/JCR-1892 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Thomas Mueller Assignee: Thomas Mueller Attachments: JackrabbitValue-api.patch, JackrabbitValue-core.patch BinaryValue should have a method get the unique identifier (if one is available). That way an application may not have to read the stream if that value is already processed. When the DataStore is used, a unique identifier is available, so probably this feature is quite simple to implement. See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html (but please don't reply to this thread from now on - instead add comments to this issue). Another feature is getFileName() to get the file name if it is stored in the file system. This method may need a security mechanism, for example getFileName(Session s) so that the system can check it. In any case the file should not be modified, but maybe knowing the file name is already too dangerous in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1920) Upgrade from 1.4.5 to 1.5 creates exception for LDAP authentication
[
https://issues.apache.org/jira/browse/JCR-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661079#action_12661079
]
Thomas Mueller commented on JCR-1920:
-
What about adding a 'lenient' field to BeanConfig?
The LoginModule would enable lenient processing, meaning
unknown settings are ignored. By default unknown settings
will still throw an exception.
Upgrade from 1.4.5 to 1.5 creates exception for LDAP authentication
---
Key: JCR-1920
URL: https://issues.apache.org/jira/browse/JCR-1920
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core, security
Affects Versions: 1.5.0
Environment: Windows XP SP2 Java
Reporter: David Izatt
Priority: Critical
Fix For: 1.5.1
Upgrading Jackrabbit from 1.4.5 to 1.5 has created an LDAP exception. The
configuration file which has not changed (except for the adding the new
SimpleSecurityManager as required) is the default with the following
substituted for the LoginModule:
LoginModule class=com.sun.security.auth.module.LdapLoginModule
param name=userProvider
value=ldap://localhost/ou=people,dc=example,dc=com; /
param name=userFilter
value=(amp;(uid={USERNAME})(objectClass=inetOrgPerson)) /
param name=authzIdentity value={USERNAME} /
param name=debug value=true /
/LoginModule
This configuration worked correctly and I was able to authenticate properly
with Jackrabbit 1.4.5
The same configuration with 1.5 throws the following exception:
javax.jcr.LoginException: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1414)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.openSession(JCAManagedConnectionFactory.java:140)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:176)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:168)
at
com.sun.enterprise.resource.ConnectorAllocator.createResource(ConnectorAllocator.java:136)
at
com.sun.enterprise.resource.AbstractResourcePool.createSingleResource(AbstractResourcePool.java:891)
at
com.sun.enterprise.resource.AbstractResourcePool.createResourceAndAddToPool(AbstractResourcePool.java:1752)
at
com.sun.enterprise.resource.AbstractResourcePool.createResources(AbstractResourcePool.java:917)
at
com.sun.enterprise.resource.AbstractResourcePool.initPool(AbstractResourcePool.java:225)
at
com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(AbstractResourcePool.java:516)
at
com.sun.enterprise.resource.AbstractResourcePool.getResource(AbstractResourcePool.java:443)
at
com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
at
com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:337)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:98)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:89)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:73)
at com.threesl.Sapphire.CradleJCR.login(CradleJCR.java:44)
try {
InitialContext ctx = new InitialContext();
repository = (Repository) ctx.lookup(jcr/repository);
session = repository.login(credentials);
} catch (Exception e) {
at com.threesl.Sapphire.CradleWS.doLogin(CradleWS.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
[jira] Commented: (JCR-1920) Upgrade from 1.4.5 to 1.5 creates exception for LDAP authentication
[
https://issues.apache.org/jira/browse/JCR-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661107#action_12661107
]
Thomas Mueller commented on JCR-1920:
-
Javadocs: directly rough the should be directly through the
Is disabling validation really required for SearchConfig? You wrote
'SearchIndex uses getParameters()' but I couldn't find it (maybe I am using the
wrong versions, 1.4 and 1.6?)
Upgrade from 1.4.5 to 1.5 creates exception for LDAP authentication
---
Key: JCR-1920
URL: https://issues.apache.org/jira/browse/JCR-1920
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core, security
Affects Versions: 1.5.0
Environment: Windows XP SP2 Java
Reporter: David Izatt
Assignee: Jukka Zitting
Priority: Critical
Fix For: 1.5.1
Attachments: JCR-1920.patch
Upgrading Jackrabbit from 1.4.5 to 1.5 has created an LDAP exception. The
configuration file which has not changed (except for the adding the new
SimpleSecurityManager as required) is the default with the following
substituted for the LoginModule:
LoginModule class=com.sun.security.auth.module.LdapLoginModule
param name=userProvider
value=ldap://localhost/ou=people,dc=example,dc=com; /
param name=userFilter
value=(amp;(uid={USERNAME})(objectClass=inetOrgPerson)) /
param name=authzIdentity value={USERNAME} /
param name=debug value=true /
/LoginModule
This configuration worked correctly and I was able to authenticate properly
with Jackrabbit 1.4.5
The same configuration with 1.5 throws the following exception:
javax.jcr.LoginException: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1414)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.openSession(JCAManagedConnectionFactory.java:140)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:176)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:168)
at
com.sun.enterprise.resource.ConnectorAllocator.createResource(ConnectorAllocator.java:136)
at
com.sun.enterprise.resource.AbstractResourcePool.createSingleResource(AbstractResourcePool.java:891)
at
com.sun.enterprise.resource.AbstractResourcePool.createResourceAndAddToPool(AbstractResourcePool.java:1752)
at
com.sun.enterprise.resource.AbstractResourcePool.createResources(AbstractResourcePool.java:917)
at
com.sun.enterprise.resource.AbstractResourcePool.initPool(AbstractResourcePool.java:225)
at
com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(AbstractResourcePool.java:516)
at
com.sun.enterprise.resource.AbstractResourcePool.getResource(AbstractResourcePool.java:443)
at
com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
at
com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:337)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:98)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:89)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:73)
at com.threesl.Sapphire.CradleJCR.login(CradleJCR.java:44)
try {
InitialContext ctx = new InitialContext();
repository = (Repository) ctx.lookup(jcr/repository);
session = repository.login(credentials);
} catch (Exception e) {
at com.threesl.Sapphire.CradleWS.doLogin(CradleWS.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
[jira] Created: (JCR-1922) Validate the SearchIndex configuration
Validate the SearchIndex configuration -- Key: JCR-1922 URL: https://issues.apache.org/jira/browse/JCR-1922 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.6.0 The validation of the configuration (repository.xml / workspace.xml) was enabled in JCR-1462, unfortunately a problem with the LoginModule and SearchIndex was found (see JCR-1920), so it was later disabled for those two modules. Validation for SearchIndex is possible but needs some more changes. To avoid problems, those changes should be done in a major version and not in a minor version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1920) Upgrade from 1.4.5 to 1.5 creates exception for LDAP authentication
[
https://issues.apache.org/jira/browse/JCR-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661136#action_12661136
]
Thomas Mueller commented on JCR-1920:
-
Thanks Jukka! I agree we shouldn't enable validation for the SearchIndex module
in 1.5.1. I have opened a new bug, JCR-1922, to fix this in 1.6.
Upgrade from 1.4.5 to 1.5 creates exception for LDAP authentication
---
Key: JCR-1920
URL: https://issues.apache.org/jira/browse/JCR-1920
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core, security
Affects Versions: 1.5.0
Environment: Windows XP SP2 Java
Reporter: David Izatt
Assignee: Jukka Zitting
Priority: Critical
Fix For: 1.5.1
Attachments: JCR-1920.patch
Upgrading Jackrabbit from 1.4.5 to 1.5 has created an LDAP exception. The
configuration file which has not changed (except for the adding the new
SimpleSecurityManager as required) is the default with the following
substituted for the LoginModule:
LoginModule class=com.sun.security.auth.module.LdapLoginModule
param name=userProvider
value=ldap://localhost/ou=people,dc=example,dc=com; /
param name=userFilter
value=(amp;(uid={USERNAME})(objectClass=inetOrgPerson)) /
param name=authzIdentity value={USERNAME} /
param name=debug value=true /
/LoginModule
This configuration worked correctly and I was able to authenticate properly
with Jackrabbit 1.4.5
The same configuration with 1.5 throws the following exception:
javax.jcr.LoginException: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider: com.sun.security.auth.module.LdapLoginModule does
not support 'userProvider
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1414)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.openSession(JCAManagedConnectionFactory.java:140)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:176)
at
org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:168)
at
com.sun.enterprise.resource.ConnectorAllocator.createResource(ConnectorAllocator.java:136)
at
com.sun.enterprise.resource.AbstractResourcePool.createSingleResource(AbstractResourcePool.java:891)
at
com.sun.enterprise.resource.AbstractResourcePool.createResourceAndAddToPool(AbstractResourcePool.java:1752)
at
com.sun.enterprise.resource.AbstractResourcePool.createResources(AbstractResourcePool.java:917)
at
com.sun.enterprise.resource.AbstractResourcePool.initPool(AbstractResourcePool.java:225)
at
com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(AbstractResourcePool.java:516)
at
com.sun.enterprise.resource.AbstractResourcePool.getResource(AbstractResourcePool.java:443)
at
com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
at
com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:337)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:98)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:89)
at
org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:73)
at com.threesl.Sapphire.CradleJCR.login(CradleJCR.java:44)
try {
InitialContext ctx = new InitialContext();
repository = (Repository) ctx.lookup(jcr/repository);
session = repository.login(credentials);
} catch (Exception e) {
at com.threesl.Sapphire.CradleWS.doLogin(CradleWS.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
[jira] Resolved: (JCR-1366) DbDataStore: tablePrefix not accomodated during init test for existing DATASTORE table
[ https://issues.apache.org/jira/browse/JCR-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1366. - Resolution: Fixed Committed in revision 727376 DbDataStore: tablePrefix not accomodated during init test for existing DATASTORE table -- Key: JCR-1366 URL: https://issues.apache.org/jira/browse/JCR-1366 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.4 Environment: jdk 1.6, win xp, SQL SERVER 2007, jTDS jdbc driver Reporter: Tyson Norris Priority: Minor Attachments: datastore_prefix.patch we are providing a test db deployment with prepopulated data, including jackrabbit DataStore. I tried specifying the tablePrefix when creating the initial repository, and tables are created properly. However, when a clean installation is run with a fresh database that has an existing DataStore (stored at JACKRABBIT_DS_DATASTORE table), the startup fails, because during init, the meta data only checks for tables name matching the tableSQL property: ResultSet rs = meta.getTables(null, null, tableSQL, null); but the tableSQL property is never modified based on the tablePrefix property (other uses of tableSQL modify queries based on the prefix). I think the init method should modify the tested table name based on the tablePrefix. Note: I assume different JDBC drivers may handle this differently (we are using SQL Server 2007 and jTDS driver), since the DatabaseMetaData is API is unclear on the parameter to getTables being a tableNamePattern - should wildcards work? Or should a specific table be specified? My DataStore config is below: DataStore class=org.apache.jackrabbit.core.data.db.DbDataStore param name=className value=org.apache.jackrabbit.core.data.db.DbDataStore/ param name=url value=jdbc:jtds:SQLServer://localhost:1433/nga_admin;prepareSQL=2;responseBuffering=adaptive/ param name=user value=sa/ param name=password value=/ param name=databaseType value=sqlserver/ param name=driver value=net.sourceforge.jtds.jdbc.Driver/ !-- a bug in jackrabbit makes tablePrefix not work -- param name=tablePrefix value=JACKRABBIT_DS_ param name=minRecordLength value=1/ param name=maxConnections value=2/ param name=copyWhenReading value=true/ /DataStore -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1838) Garbage collection deletes temporary files in FileDataStore
[ https://issues.apache.org/jira/browse/JCR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1838. - Resolution: Fixed Assignee: Thomas Mueller Committed in revision 727402 Garbage collection deletes temporary files in FileDataStore --- Key: JCR-1838 URL: https://issues.apache.org/jira/browse/JCR-1838 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6 Environment: Solaris 10, JDK 1.6.0_03 Reporter: Peter Dettman Assignee: Thomas Mueller Priority: Minor Attachments: jcr1838.diff In FileDataStore.addRecord(InputStream), a temporary file is created. The data is written to the file and then it is moved to its final location (based on the contents hash). If the garbage collector runs whilst this temp file is present, it deletes it (on Solaris 10 at least), and the addRecord fails at the attempt to rename the now non-existent temp file. I am attaching a minimal patch that prevents these temp files being deleted by deleteOlderRecursive(..), regardless of their lastModified() value. I have made this a Minor priority, since there is the obvious workaround of disabling the GC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1907) ClassCastException when using OracleFileSystem with JBoss JNDI
[
https://issues.apache.org/jira/browse/JCR-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655648#action_12655648
]
Thomas Mueller commented on JCR-1907:
-
Could you try using org.apache.jackrabbit.core.fs.db.DatabaseFileSystem? Newer
Oracle version should work with that (but I didn't actually test it). If it
doesn't work for you, what version of Oracle (database and drivers) do you use,
and what is the exception (message and stack trace)?
ClassCastException when using OracleFileSystem with JBoss JNDI
--
Key: JCR-1907
URL: https://issues.apache.org/jira/browse/JCR-1907
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.0
Environment: - WindowsXP, JBoss AS 4.2.0.GA, JackRabbit 1.5.0, Oracle
Driver : ojdbc14_10g.jar
Reporter: Eduardo Andrade
Priority: Minor
When using OracleFilesystem with JNDI connection on JBOSS, the JBoss gives a
org.jboss.resource.adapter.jdbc.WrappedConnection instance and oracle driver
code expects a oracle.jdbc.OracleConnection instance.
To avoid the exception : java.lang.ClassCastException:
org.jboss.resource.adapter.jdbc.WrappedConnection cannot be cast to
oracle.jdbc.OracleConnection,
couldn't it be done something like this ? :
public static Connection getConnection(Connection conn) {
if (conn instanceof WrappedConnection) {
return ((WrappedConnection) conn).getUnderlyingConnection();
}
return conn;
}
Here are the relevant repository.xml config and the Exception thrown :
FileSystem class=org.apache.jackrabbit.core.fs.db.OracleFileSystem
param name=driver value=javax.naming.InitialContext /
param name=url value=java:jdbc/SiagRepo /
param name=schema value=oracle /
param name=tableSpace value=USERS /
/FileSystem
13:07:33,827 ERROR [RepositoryImpl] failed to start Repository: failed to
load repository properties: failed to persist repository properties: null
javax.jcr.RepositoryException: failed to load repository properties: failed
to persist repository properties: null: failed to persist repository
properties: null: null
at
org.apache.jackrabbit.core.RepositoryImpl.loadRepProps(RepositoryImpl.java:1291)
at
org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:276)
at
org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
at
pt.gedi.ecm.services.RepositorioImpExp_ServiceImpl.iniciaRepositorio(RepositorioImpExp_ServiceImpl.java:123)
at
pt.gedi.ecm.utils.ECMCodeForBase.iniciaRepositorio(ECMCodeForBase.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at pt.gedi.base.utils.ECMCodeForBase.callMethod(ECMCodeForBase.java:33)
at
pt.gedi.base.services.StartupServiceImpl.startup(StartupServiceImpl.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1413)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1374)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1334)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
[jira] Commented: (JCR-1907) ClassCastException when using OracleFileSystem with JBoss JNDI
[
https://issues.apache.org/jira/browse/JCR-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655675#action_12655675
]
Thomas Mueller commented on JCR-1907:
-
Hi,
I understand the problem now. Jackrabbit wants to store an empty string to
FSENTRY_NAME, but for Oracle an empty string is the same as NULL. And the
column is defined NOT NULL, so Oracle throws an exception... Oracle is the only
database I know that thinks an empty string is the same as NULL.
I'm not sure what is the best solution for this problem. The most simple
solution is what Stefan proposed: Extends OracleFileSystem and override the
getConnection() method.
ClassCastException when using OracleFileSystem with JBoss JNDI
--
Key: JCR-1907
URL: https://issues.apache.org/jira/browse/JCR-1907
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.0
Environment: - WindowsXP, JBoss AS 4.2.0.GA, JackRabbit 1.5.0, Oracle
Driver : ojdbc14_10g.jar
Reporter: Eduardo Andrade
Priority: Minor
When using OracleFilesystem with JNDI connection on JBOSS, the JBoss gives a
org.jboss.resource.adapter.jdbc.WrappedConnection instance and oracle driver
code expects a oracle.jdbc.OracleConnection instance.
To avoid the exception : java.lang.ClassCastException:
org.jboss.resource.adapter.jdbc.WrappedConnection cannot be cast to
oracle.jdbc.OracleConnection,
couldn't it be done something like this ? :
public static Connection getConnection(Connection conn) {
if (conn instanceof WrappedConnection) {
return ((WrappedConnection) conn).getUnderlyingConnection();
}
return conn;
}
Here are the relevant repository.xml config and the Exception thrown :
FileSystem class=org.apache.jackrabbit.core.fs.db.OracleFileSystem
param name=driver value=javax.naming.InitialContext /
param name=url value=java:jdbc/SiagRepo /
param name=schema value=oracle /
param name=tableSpace value=USERS /
/FileSystem
13:07:33,827 ERROR [RepositoryImpl] failed to start Repository: failed to
load repository properties: failed to persist repository properties: null
javax.jcr.RepositoryException: failed to load repository properties: failed
to persist repository properties: null: failed to persist repository
properties: null: null
at
org.apache.jackrabbit.core.RepositoryImpl.loadRepProps(RepositoryImpl.java:1291)
at
org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:276)
at
org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
at
pt.gedi.ecm.services.RepositorioImpExp_ServiceImpl.iniciaRepositorio(RepositorioImpExp_ServiceImpl.java:123)
at
pt.gedi.ecm.utils.ECMCodeForBase.iniciaRepositorio(ECMCodeForBase.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at pt.gedi.base.utils.ECMCodeForBase.callMethod(ECMCodeForBase.java:33)
at
pt.gedi.base.services.StartupServiceImpl.startup(StartupServiceImpl.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1413)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1374)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1334)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at
[jira] Resolved: (JCR-1883) Moved node disappears
[
https://issues.apache.org/jira/browse/JCR-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-1883.
-
Resolution: Fixed
Assignee: Thomas Mueller
Fixed in revision 725292. The unit tests succeed, but I'm not sure if we should
backport this fix yet - it may have some unwanted side effects.
Moved node disappears
-
Key: JCR-1883
URL: https://issues.apache.org/jira/browse/JCR-1883
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
Moving a node and then refreshing it can make it disappear.
deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node root = session.getRootNode();
Node a = root.addNode(a);
Node b = a.addNode(b);
session.save();
session.move(/a/b, /b);
b.refresh(false);
// session.save(); // no effect
for (NodeIterator it = root.getNodes(); it.hasNext();) {
Node n = it.nextNode();
System.out.println(n.getName());
for (NodeIterator it2 = n.getNodes(); it2.hasNext();) {
System.out.println( + it2.nextNode().getName());
}
}
In the trunk, the node 'b' is not listed after the refresh (not under the
root page, and not under a). The output is:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Jackrabbit 1.4.x throws an exception:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Exception in thread main javax.jcr.RepositoryException: failed to resolve
name of acee31c4-c33b-4ed4-b1b5-39db6f17fb09
at
org.apache.jackrabbit.core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451)
at
org.apache.jackrabbit.core.CachingHierarchyManager.getName(CachingHierarchyManager.java:287)
at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java:1931)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.test(TestMoveRemoveRefresh.java:33)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.main(TestMoveRemoveRefresh.java:15)
void deleteDirectory(File file) {
if (file.isDirectory()) {
File[] list = file.listFiles();
for(int i=0; ilist.length; i++) {
deleteDirectory(list[i]);
}
}
file.delete();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1883) Moved node disappears
[
https://issues.apache.org/jira/browse/JCR-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654836#action_12654836
]
Thomas Mueller commented on JCR-1883:
-
There are multiple solutions to the problem.
One is, refresh will undo the move operation. But that would also change the
old parent node, which may not be expected.
Another solution is to reject refreshing this node. This is what I have
implemented. Here is a proposed patch. I also want to add a test case for this
issue.
Index: src/main/java/org/apache/jackrabbit/core/ItemImpl.java
===
--- src/main/java/org/apache/jackrabbit/core/ItemImpl.java (revision
722453)
+++ src/main/java/org/apache/jackrabbit/core/ItemImpl.java (working copy)
@@ -1171,10 +1171,19 @@
switch (transientState.getStatus()) {
case ItemState.STATUS_STALE_MODIFIED:
case ItemState.STATUS_STALE_DESTROYED:
-case ItemState.STATUS_EXISTING_MODIFIED:
// add this item's state to the list
list.add(transientState);
break;
+
+case ItemState.STATUS_EXISTING_MODIFIED:
+if (!transientState.getParentId().equals(
+transientState.getOverlayedState().getParentId()))
{
+throw new RepositoryException(
+Cannot refresh a moved item: + this +
+ - possible solution: refresh the parent);
+}
+list.add(transientState);
+break;
case ItemState.STATUS_NEW:
throw new RepositoryException(
Moved node disappears
-
Key: JCR-1883
URL: https://issues.apache.org/jira/browse/JCR-1883
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Priority: Minor
Moving a node and then refreshing it can make it disappear.
deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node root = session.getRootNode();
Node a = root.addNode(a);
Node b = a.addNode(b);
session.save();
session.move(/a/b, /b);
b.refresh(false);
// session.save(); // no effect
for (NodeIterator it = root.getNodes(); it.hasNext();) {
Node n = it.nextNode();
System.out.println(n.getName());
for (NodeIterator it2 = n.getNodes(); it2.hasNext();) {
System.out.println( + it2.nextNode().getName());
}
}
In the trunk, the node 'b' is not listed after the refresh (not under the
root page, and not under a). The output is:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Jackrabbit 1.4.x throws an exception:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Exception in thread main javax.jcr.RepositoryException: failed to resolve
name of acee31c4-c33b-4ed4-b1b5-39db6f17fb09
at
org.apache.jackrabbit.core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451)
at
org.apache.jackrabbit.core.CachingHierarchyManager.getName(CachingHierarchyManager.java:287)
at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java:1931)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.test(TestMoveRemoveRefresh.java:33)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.main(TestMoveRemoveRefresh.java:15)
void deleteDirectory(File file) {
if (file.isDirectory()) {
File[] list = file.listFiles();
for(int i=0; ilist.length; i++) {
deleteDirectory(list[i]);
}
}
file.delete();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1896) Persistence Manager Issue
[
https://issues.apache.org/jira/browse/JCR-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-1896.
-
Resolution: Invalid
You have a typo:
org.apache.jackrabbit.core.
instead of
com.iorga.jackrabbit.core.
Persistence Manager Issue
-
Key: JCR-1896
URL: https://issues.apache.org/jira/browse/JCR-1896
Project: Jackrabbit
Issue Type: Bug
Affects Versions: core 1.4.5
Environment: Windows Server 2003
Tomcat Apache
Reporter: Norman Sheriff
?xml version=1.0 encoding=UTF-8?
!DOCTYPE Repository PUBLIC -//The Apache Software Foundation//DTD
Jackrabbit 1.2//EN http://jackrabbit.apache.org/dtd/repository-1.2.dtd;
Repository
FileSystem class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path value=${rep.home}/repository /
/FileSystem
Security appName=Jackrabbit
AccessManager
class=org.apache.jackrabbit.core.security.SimpleAccessManager/AccessManager
LoginModule
class=org.apache.jackrabbit.core.security.SimpleLoginModule
param name=anonymousId value=anonymous /
/LoginModule
/Security
Workspaces rootPath=${rep.home}/workspaces
defaultWorkspace=default /
Workspace name=default
FileSystem
class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path value=${wsp.home}/default /
/FileSystem
PersistenceManager
class=com.iorga.jackrabbit.core.persistence.db.PooledJNDIDatabasePersistenceManager
param name=dataSourceLocation
value=java:comp/env/jdbc/magnolia/public/
param name=checkValidConnectionSQL
value=select 0 from dual /
param name=schemaObjectPrefix
value=${wsp.name}_/
param name=externalBLOBs value=false/
param name=schema value=oracle /
/PersistenceManager
SearchIndex
class=org.apache.jackrabbit.core.query.lucene.SearchIndex
param name=path value=${wsp.home}/index /
param name=useCompoundFile value=true /
param name=minMergeDocs value=100 /
param name=volatileIdleTime value=3 /
param name=maxMergeDocs value=10 /
param name=mergeFactor value=10 /
param name=maxFieldLength value=1 /
param name=bufferSize value=10 /
param name=cacheSize value=1000 /
param name=forceConsistencyCheck value=false /
param name=autoRepair value=true /
param name=analyzer
value=org.apache.lucene.analysis.standard.StandardAnalyzer /
param name=queryClass
value=org.apache.jackrabbit.core.query.QueryImpl /
param name=respectDocumentOrder value=true /
param name=resultFetchSize value=2147483647 /
param name=extractorPoolSize value=3 /
param name=extractorTimeout value=100 /
param name=extractorBackLogSize value=100 /
param name=textFilterClasses
value=org.apache.jackrabbit.extractor.MsWordTextExtractor,
org.apache.jackrabbit.extractor.MsExcelTextExtractor,
org.apache.jackrabbit.extractor.MsPowerPointTextExtractor,
org.apache.jackrabbit.extractor.PdfTextExtractor,
org.apache.jackrabbit.extractor.OpenOfficeTextExtractor,
org.apache.jackrabbit.extractor.RTFTextExtractor,
org.apache.jackrabbit.extractor.HTMLTextExtractor,
org.apache.jackrabbit.extractor.PlainTextExtractor,
org.apache.jackrabbit.extractor.XMLTextExtractor /
/SearchIndex
/Workspace
Versioning rootPath=${rep.home}/version
FileSystem
class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path
value=${rep.home}/workspaces/version /
/FileSystem
PersistenceManager
class=com.iorga.jackrabbit.core.persistence.db.PooledJNDIDatabasePersistenceManager
param name=dataSourceLocation
value=java:comp/env/jdbc/magnolia/public/
[jira] Resolved: (JCR-1900) java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
[ https://issues.apache.org/jira/browse/JCR-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1900. - Resolution: Invalid NoClassDefFoundError is usually not a problem of Jackrabbit. See http://mindprod.com/jgloss/runerrormessages.html#CLASSNOTFOUNDEXCEPTION and http://www.jroller.com/sjivan/entry/difference_between_classnotfoundexception_and_noclassdeffounderror for details. java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory --- Key: JCR-1900 URL: https://issues.apache.org/jira/browse/JCR-1900 Project: Jackrabbit Issue Type: Bug Reporter: Narender Dec 5, 2008 11:35:10 AM org.springframework.web.context.ContextLoader initWebApplicationContext SEVERE: Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jcrConfiguration' defined in ServletContext resource [/WEB-INF/appicationContext.xml]: Instantiation of bean failed; nested exception is java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory Caused by: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory at org.apache.jackrabbit.core.config.RepositoryConfig.clinit(RepositoryConfig.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:118) at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:315) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:758) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:712) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:386) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:279) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:360) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:241) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) at org.springframework.web.context.ContextLoaderServlet.init(ContextLoaderServlet.java:82) at javax.servlet.GenericServlet.init(GenericServlet.java:212) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4364) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Dec 5, 2008 11:35:10 AM org.apache.catalina.core.ApplicationContext log SEVERE: StandardWrapper.Throwable
[jira] Resolved: (JCR-1899) Cannot instantiate persistence manager org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager: Access denied for user 'root'@'localhost' (using password: NO)
[
https://issues.apache.org/jira/browse/JCR-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-1899.
-
Resolution: Invalid
Caused by: java.sql.SQLException: Access denied for user 'root'@'localhost'
(using password: NO)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
Cannot instantiate persistence manager
org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager: Access
denied for user 'root'@'localhost' (using password: NO): Access denied for
user 'root'@'localhost' (using password: NO)
Key: JCR-1899
URL: https://issues.apache.org/jira/browse/JCR-1899
Project: Jackrabbit
Issue Type: Bug
Reporter: Narender
pls help me
am integrate jackrabbit+spring
while reading the repository.xml file am getting error .
Context file
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:util=http://www.springframework.org/schema/util;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.0.xsd;
bean id=repository
class=org.springmodules.jcr.jackrabbit.RepositoryFactoryBean
property name=configuration value=classpath:repository.xml/
property name=homeDir value=file:/foo/repository/
/bean
bean id=jcrSessionFactory
class=org.springmodules.jcr.JcrSessionFactory
property name=repository ref=repository/
property name=credentials
bean class=javax.jcr.SimpleCredentials
constructor-arg index=0 value=user/
constructor-arg index=1
bean factory-bean=password factory-method=toCharArray/
/constructor-arg
/bean
/property
/bean
bean id=password class=java.lang.String
constructor-arg index=0 value=password/
/bean
bean id=jcrTemplate class=org.springmodules.jcr.JcrTemplate
property name=sessionFactory ref=jcrSessionFactory/
property name=allowCreate value=true/
/bean
bean id=barrepository class=com.mycompany.myapp.barrepositoryImpl
property name=repository ref=repository/
/bean
/beans
Repository file
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE Repository PUBLIC -//The Apache Software Foundation//DTD
Jackrabbit 1.2//EN http://jackrabbit.apache.org/dtd/repository-1.2.dtd;
Repository
FileSystem class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path value=${rep.home}/content/
/FileSystem
Security appName=Jackrabbit
AccessManager
class=org.apache.jackrabbit.core.security.SimpleAccessManager
/AccessManager
LoginModule
class=org.apache.jackrabbit.core.security.SimpleLoginModule
param name=anonymous value=anonymous/
/LoginModule
/Security
Workspaces rootPath=${rep.home}/workspaces defaultWorkspace=default/
Workspace name=${wsp.name}
FileSystem class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path value=${wsp.home}/
/FileSystem
PersistenceManager
class=org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager
param name=driver value=com.mysql.jdbc.Driver/
param name=url value=jdbc:mysql://localhost:3306/spark/
param name=user value=root/
param name=password value=mysql/
param name=schemaObjectPrefix value=con_/
/PersistenceManager
!-- dont want a SearchIndex, setup for Indexing --
/Workspace
Versioning rootPath=${rep.home}/version
FileSystem class=org.apache.jackrabbit.core.fs.local.LocalFileSystem
param name=path value=${rep.home}/version/
/FileSystem
PersistenceManager
class=org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager
param name=driver value=com.mysql.jdbc.Driver/
param name=url value=jdbc:mysql://localhost:3306/spark/
param name=user value=root/
param name=password value=mysql/
param name=schemaObjectPrefix value=ver_/
/PersistenceManager
/Versioning
!-- Dont want SearchIndex for searching --
/Repository
ERROR
Exception in thread main
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'repository' defined in class path resource
[appicationContext.xml]: Invocation of init method failed; nested exception
is javax.jcr.RepositoryException: Cannot instantiate persistence manager
[jira] Created: (JCR-1892) Unique ID for org.apache.jackrabbit.value.BinaryValue
Unique ID for org.apache.jackrabbit.value.BinaryValue - Key: JCR-1892 URL: https://issues.apache.org/jira/browse/JCR-1892 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Thomas Mueller Assignee: Thomas Mueller BinaryValue should have a method get the unique identifier (if one is available). That way an application may not have to read the stream if that value is already processed. When the DataStore is used, a unique identifier is available, so probably this feature is quite simple to implement. See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html (but please don't reply to this thread from now on - instead add comments to this issue). Another feature is getFileName() to get the file name if it is stored in the file system. This method may need a security mechanism, for example getFileName(Session s) so that the system can check it. In any case the file should not be modified, but maybe knowing the file name is already too dangerous in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1836) Persistence: support property databaseType
[ https://issues.apache.org/jira/browse/JCR-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1836. - Resolution: Fixed Committed in revision 722463 (trunk) Persistence: support property databaseType -- Key: JCR-1836 URL: https://issues.apache.org/jira/browse/JCR-1836 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: databaseType.patch In persistence managers and cluster journal the term 'schema' is used to mean 'database type'. Using the term 'schema' for that is actually quite confusing (in my view): The definition of schema http://en.wikipedia.org/wiki/Database_schema is the schema defines the tables, the fields in each table, and the relationships between fields and tables. Additionally in most databases a schema is is a name space within a database: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DatabaseMetaData.html#getSchemas() . I suggest to support the property 'databaseType' in addition to 'schema' for the persistence managers and the cluster journal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1883) Moved node disappears
Moved node disappears
-
Key: JCR-1883
URL: https://issues.apache.org/jira/browse/JCR-1883
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Priority: Minor
Moving a node and then refreshing it can make it disappear.
deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node root = session.getRootNode();
Node a = root.addNode(a);
Node b = a.addNode(b);
session.save();
session.move(/a/b, /b);
b.refresh(false);
// session.save(); // no effect
for (NodeIterator it = root.getNodes(); it.hasNext();) {
Node n = it.nextNode();
System.out.println(n.getName());
for (NodeIterator it2 = n.getNodes(); it2.hasNext();) {
System.out.println( + it2.nextNode().getName());
}
}
In the trunk, the node 'b' is not listed after the refresh (not under the root
page, and not under a). The output is:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Jackrabbit 1.4.x throws an exception:
jcr:system
jcr:versionStorage
jcr:nodeTypes
a
Exception in thread main javax.jcr.RepositoryException: failed to resolve
name of acee31c4-c33b-4ed4-b1b5-39db6f17fb09
at
org.apache.jackrabbit.core.HierarchyManagerImpl.getName(HierarchyManagerImpl.java:451)
at
org.apache.jackrabbit.core.CachingHierarchyManager.getName(CachingHierarchyManager.java:287)
at org.apache.jackrabbit.core.NodeImpl.getName(NodeImpl.java:1931)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.test(TestMoveRemoveRefresh.java:33)
at
org.apache.jackrabbit.core.fuzz.TestMoveRemoveRefresh.main(TestMoveRemoveRefresh.java:15)
void deleteDirectory(File file) {
if (file.isDirectory()) {
File[] list = file.listFiles();
for(int i=0; ilist.length; i++) {
deleteDirectory(list[i]);
}
}
file.delete();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1879) Directory was previously created with a different LockFactory when open, close, delete a repository in a loop
Directory was previously created with a different LockFactory when open,
close, delete a repository in a loop
---
Key: JCR-1879
URL: https://issues.apache.org/jira/browse/JCR-1879
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Environment: Mac OS X
Reporter: Thomas Mueller
Priority: Minor
Opening a TransientRepository in a loop throws the exception Directory was
previously created with a different LockFactory instance.
Test case:
for (int i = 0; i 3; i++) {
FileUtils.deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
session.logout();
}
The problem seems to be that org.apache.lucene.store.FSDirectory.DIRECTORIES is
not cleared (FSDirectory.close() is not called?).
Stack trace:
Exception in thread main javax.jcr.RepositoryException: Directory was
previously created with a different LockFactory instance; please pass null as
the lockFactory instance and use setLockFactory to change it: Directory was
previously created with a different LockFactory instance; please pass null as
the lockFactory instance and use setLockFactory to change it: Directory was
previously created with a different LockFactory instance; please pass null as
the lockFactory instance and use setLockFactory to change it
at
org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:555)
at
org.apache.jackrabbit.core.SearchManager.init(SearchManager.java:239)
at
org.apache.jackrabbit.core.RepositoryImpl.getSystemSearchManager(RepositoryImpl.java:688)
at
org.apache.jackrabbit.core.RepositoryImpl.access$3(RepositoryImpl.java:681)
at
org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1780)
at
org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:667)
at
org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:480)
at
org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:321)
at
org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
at
org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:241)
at
org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:261)
Caused by: java.io.IOException: Directory was previously created with a
different LockFactory instance; please pass null as the lockFactory instance
and use setLockFactory to change it
at
org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:192)
at
org.apache.jackrabbit.core.query.lucene.directory.FSDirectoryManager.getDirectory(FSDirectoryManager.java:64)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.init(MultiIndex.java:227)
at
org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:477)
at
org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1880) Same name sibling: Jackrabbit behaves differently when calling Node.getPath()
Same name sibling: Jackrabbit behaves differently when calling Node.getPath()
-
Key: JCR-1880
URL: https://issues.apache.org/jira/browse/JCR-1880
Project: Jackrabbit
Issue Type: Bug
Reporter: Thomas Mueller
Priority: Minor
The following test case behaves differently when calling Node.getPath() versus
not calling it:
void test(boolean index) throws Exception {
FileUtils.deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node test = session.getRootNode().addNode(test);
Node a = test.addNode(a);
Node b = a.addNode(b);
session.save();
session.move(/test/a/b, /test/a);
if (index) {
b.getPath();
}
session.move(/test/a, /test/a);
System.out.println(a: + a.getPath());
System.out.println(b: + b.getPath());
session.logout();
}
test(true) prints:
a: /test/a[2]
b: /test/a
test(false) prints:
a: /test/a
b: /test/a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1880) Same name sibling: Jackrabbit behaves differently when calling Node.getPath()
[
https://issues.apache.org/jira/browse/JCR-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650564#action_12650564
]
Thomas Mueller commented on JCR-1880:
-
A related problem: the following test case prints Expected: /test/a/x got: /x:
FileUtils.deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node test = session.getRootNode().addNode(test);
Node a = test.addNode(a);
a.addNode(b);
session.save();
session.move(/test/a/b, /test/a);
session.move(/test/a, /test/a);
Node x = a.addNode(x);
session.save();
String path = x.getPath();
if (!/test/a/x.equals(path)) {
System.out.println(Expected: /test/a/x got: + path);
}
Same name sibling: Jackrabbit behaves differently when calling Node.getPath()
-
Key: JCR-1880
URL: https://issues.apache.org/jira/browse/JCR-1880
Project: Jackrabbit
Issue Type: Bug
Reporter: Thomas Mueller
Priority: Minor
The following test case behaves differently when calling Node.getPath()
versus not calling it:
void test(boolean index) throws Exception {
FileUtils.deleteDirectory(new File(repository));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials(, new char[0]));
Node test = session.getRootNode().addNode(test);
Node a = test.addNode(a);
Node b = a.addNode(b);
session.save();
session.move(/test/a/b, /test/a);
if (index) {
b.getPath();
}
session.move(/test/a, /test/a);
System.out.println(a: + a.getPath());
System.out.println(b: + b.getPath());
session.logout();
}
test(true) prints:
a: /test/a[2]
b: /test/a
test(false) prints:
a: /test/a
b: /test/a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1865) Add the Data Store to the Jackrabbit API
[ https://issues.apache.org/jira/browse/JCR-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1865: Attachment: api.patch Required changes in the Jackrabbit API Add the Data Store to the Jackrabbit API Key: JCR-1865 URL: https://issues.apache.org/jira/browse/JCR-1865 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: api.patch, core.patch Currently, the garbage collection is not part of the Jackrabbit API. However, the data store garbage collection must be used once in a while if the data store is enabled. I propose to add the required interfaces to the Jackrabbit API. This will also allow to call garbage collection using RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1865) Add the Data Store to the Jackrabbit API
Add the Data Store to the Jackrabbit API Key: JCR-1865 URL: https://issues.apache.org/jira/browse/JCR-1865 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Currently, the garbage collection is not part of the Jackrabbit API. However, the data store garbage collection must be used once in a while if the data store is enabled. I propose to add the required interfaces to the Jackrabbit API. This will also allow to call garbage collection using RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1865) Add the Data Store to the Jackrabbit API
[ https://issues.apache.org/jira/browse/JCR-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649062#action_12649062 ] Thomas Mueller commented on JCR-1865: - * MarkEventListener.started(): agreed. I'm not sure if this would be fully backward compatible: existing ScanEventListeners don't implement this method. When calling this method on an old implementation, the JVM would throw a java.lang.AbstractMethodError. This could be caught and ignored. * getPersistenceManagerScan() method to isPersistenceManagerScan(): agreed. * millis parameter to the setSleepBetweenNodes as long: agreed. getSleepBetweenNodes(): agreed. * stopScan(): you are right, it doesn't belong to the interface. It is used for testing only. * mark() and sweep(): agreed. We could still call it getPersistenceManagerScan however * single method gc(): multiple repositories can use the same data store (sharing the data store). In that case, you need to call mark() of all repositories before calling sweep() (on the first repository). Add the Data Store to the Jackrabbit API Key: JCR-1865 URL: https://issues.apache.org/jira/browse/JCR-1865 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: api.patch, core.patch Currently, the garbage collection is not part of the Jackrabbit API. However, the data store garbage collection must be used once in a while if the data store is enabled. I propose to add the required interfaces to the Jackrabbit API. This will also allow to call garbage collection using RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1865) Add the Data Store to the Jackrabbit API
[ https://issues.apache.org/jira/browse/JCR-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649072#action_12649072 ] Thomas Mueller commented on JCR-1865: - client API It is a 'management API'. There is no separate management API section at the moment, we could create a package org.apache.jackrabbit.api.management.data. Also we could create an interface org.apache.jackrabbit.api.management.JackrabbitManagedRepository. Why should we put the client be in control of a server process like garbage collection? I agree it should be a background process. Unfortunately it's not so easy to implement that, specially not when multiple repositories use the same data store. Add the Data Store to the Jackrabbit API Key: JCR-1865 URL: https://issues.apache.org/jira/browse/JCR-1865 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: api.patch, core.patch Currently, the garbage collection is not part of the Jackrabbit API. However, the data store garbage collection must be used once in a while if the data store is enabled. I propose to add the required interfaces to the Jackrabbit API. This will also allow to call garbage collection using RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1864) Database Data Store: clean up the code
Database Data Store: clean up the code -- Key: JCR-1864 URL: https://issues.apache.org/jira/browse/JCR-1864 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor There is some unnecessary code in the DbDataStore that should be removed. Also, some more tests should be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1836) Persistence: support property databaseType
[ https://issues.apache.org/jira/browse/JCR-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1836: Attachment: databaseType.patch Deprecate (but still support) the setting 'schema' and use 'databaseType' instead in DatabaseJournal and BundleDbPersistenceManager. Persistence: support property databaseType -- Key: JCR-1836 URL: https://issues.apache.org/jira/browse/JCR-1836 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: databaseType.patch In persistence managers and cluster journal the term 'schema' is used to mean 'database type'. Using the term 'schema' for that is actually quite confusing (in my view): The definition of schema http://en.wikipedia.org/wiki/Database_schema is the schema defines the tables, the fields in each table, and the relationships between fields and tables. Additionally in most databases a schema is is a name space within a database: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DatabaseMetaData.html#getSchemas() . I suggest to support the property 'databaseType' in addition to 'schema' for the persistence managers and the cluster journal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1822) Patches for previously incompleted patches
[ https://issues.apache.org/jira/browse/JCR-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643157#action_12643157 ] Thomas Mueller commented on JCR-1822: - Hi, Thanks for the patch, but could you change the title please? Usually the title of an issue says what the change is about. If the patch is for two different things, it makes sense to split the patch. Example: MS SQL Server tablespace support DatabaseJournal test case for Oracle Regards, Thomas Patches for previously incompleted patches -- Key: JCR-1822 URL: https://issues.apache.org/jira/browse/JCR-1822 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: core 1.4.6 Reporter: Brian Whipple Attachments: jackrabbit-core.diff This is a patch to complete two earlier patches that were partially patched. JCR-1295 contained patch code for MS SqlServer tablespace support for the filesystem and db persistence manager that was not applied. I have cleaned up the submitted code and it should be applied to be consistent. JCR-1362 was a fix for Oracle schema test that was applied to 1.4 branch from trunk but was incomplete. This is a single patch for both issues. The fix for JCR-1362 only requires updating a single file from the patch: src/main/java/org/apache/jackrabbit/core/journal/DatabaseJournal.java All other files are related to completing JCR-1295. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1838) Garbage collection deletes temporary files in FileDataStore
[ https://issues.apache.org/jira/browse/JCR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643186#action_12643186 ] Thomas Mueller commented on JCR-1838: - Hi, Temporary files are only deleted if they are old. Is there anything special with your use case, for example: do you have a small repository (so that scanning it is very quick), or is streaming the data specially slow? Regards, Thomas Garbage collection deletes temporary files in FileDataStore --- Key: JCR-1838 URL: https://issues.apache.org/jira/browse/JCR-1838 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6 Environment: Solaris 10, JDK 1.6.0_03 Reporter: Peter Dettman Priority: Minor Attachments: jcr1838.diff In FileDataStore.addRecord(InputStream), a temporary file is created. The data is written to the file and then it is moved to its final location (based on the contents hash). If the garbage collector runs whilst this temp file is present, it deletes it (on Solaris 10 at least), and the addRecord fails at the attempt to rename the now non-existent temp file. I am attaching a minimal patch that prevents these temp files being deleted by deleteOlderRecursive(..), regardless of their lastModified() value. I have made this a Minor priority, since there is the obvious workaround of disabling the GC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1825) DBDataStore doesn't support concurrent reads
[ https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1825. - Resolution: Fixed Committed in revision 708598. DBDataStore doesn't support concurrent reads Key: JCR-1825 URL: https://issues.apache.org/jira/browse/JCR-1825 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Fix For: 1.5.0 Attachments: patch.txt, patch2.txt My understanding is that setting parameter copyWhenReading to true should allow concurrent reads by spooling binary property to temporary file and free database resources (connection) immediately to make it available for other threads. After applying patch for JCR-1388, DBDataStore doesn't support concurrent reads anymore, resultSet is kept open and db connection is blocked until the stream is read and closed. When copyWhenReading is set to true db connection should be released immediately, this is the reason i guess why temporary file is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1835) Database Data Store: support database type 'mssql'
Database Data Store: support database type 'mssql' -- Key: JCR-1835 URL: https://issues.apache.org/jira/browse/JCR-1835 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor MS SQL Server is referred to with the schema name 'mssql' in the persistence managers and the cluster journal. For the DbDataStore it is called 'sqlserver'. This is not consistent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1835) Database Data Store: support database type 'mssql'
[ https://issues.apache.org/jira/browse/JCR-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1835. - Resolution: Fixed Implemented in revision 707630 Database Data Store: support database type 'mssql' -- Key: JCR-1835 URL: https://issues.apache.org/jira/browse/JCR-1835 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor MS SQL Server is referred to with the schema name 'mssql' in the persistence managers and the cluster journal. For the DbDataStore it is called 'sqlserver'. This is not consistent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1836) Persistence: support property databaseType
Persistence: support property databaseType -- Key: JCR-1836 URL: https://issues.apache.org/jira/browse/JCR-1836 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor In persistence managers and cluster journal the term 'schema' is used to mean 'database type'. Using the term 'schema' for that is actually quite confusing (in my view): The definition of schema http://en.wikipedia.org/wiki/Database_schema is the schema defines the tables, the fields in each table, and the relationships between fields and tables. Additionally in most databases a schema is is a name space within a database: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DatabaseMetaData.html#getSchemas() . I suggest to support the property 'databaseType' in addition to 'schema' for the persistence managers and the cluster journal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1825) DBDataStore doesn't support concurrent reads
[ https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641362#action_12641362 ] Thomas Mueller commented on JCR-1825: - Hi, You are right, this part of the code doesn't do any more what it's supposed to do. There is another problem: it doesn't work if the stream is null. Also some of the DbResources methods are not not used and should be removed. I am currently working on another patch, I will attach it in an hour or so to this bug. Thanks for finding this problem! Regards, Thomas DBDataStore doesn't support concurrent reads Key: JCR-1825 URL: https://issues.apache.org/jira/browse/JCR-1825 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Fix For: 1.5.0 My understanding is that setting parameter copyWhenReading to true should allow concurrent reads by spooling binary property to temporary file and free database resources (connection) immediately to make it available for other threads. After applying patch for JCR-1388, DBDataStore doesn't support concurrent reads anymore, resultSet is kept open and db connection is blocked until the stream is read and closed. When copyWhenReading is set to true db connection should be released immediately, this is the reason i guess why temporary file is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1825) DBDataStore doesn't support concurrent reads
[ https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1825: Attachment: patch.txt Here is my first patch. I didn't test it yet; I post it just so that others can have a look at it. DBDataStore doesn't support concurrent reads Key: JCR-1825 URL: https://issues.apache.org/jira/browse/JCR-1825 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Fix For: 1.5.0 Attachments: patch.txt My understanding is that setting parameter copyWhenReading to true should allow concurrent reads by spooling binary property to temporary file and free database resources (connection) immediately to make it available for other threads. After applying patch for JCR-1388, DBDataStore doesn't support concurrent reads anymore, resultSet is kept open and db connection is blocked until the stream is read and closed. When copyWhenReading is set to true db connection should be released immediately, this is the reason i guess why temporary file is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1825) DBDataStore doesn't support concurrent reads
[ https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1825: Attachment: patch2.txt New patch (I still didn't test it however). 'DbResources' should be renamed to 'DbResource', I will do that later. DBDataStore doesn't support concurrent reads Key: JCR-1825 URL: https://issues.apache.org/jira/browse/JCR-1825 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Fix For: 1.5.0 Attachments: patch.txt, patch2.txt My understanding is that setting parameter copyWhenReading to true should allow concurrent reads by spooling binary property to temporary file and free database resources (connection) immediately to make it available for other threads. After applying patch for JCR-1388, DBDataStore doesn't support concurrent reads anymore, resultSet is kept open and db connection is blocked until the stream is read and closed. When copyWhenReading is set to true db connection should be released immediately, this is the reason i guess why temporary file is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1801) Support Online Backup
Support Online Backup - Key: JCR-1801 URL: https://issues.apache.org/jira/browse/JCR-1801 Project: Jackrabbit Issue Type: New Feature Components: clustering, jackrabbit-core Reporter: Thomas Mueller Priority: Minor There is no 'good' way to create an online backup for Jackrabbit. Currently you need to basically stop the repository before backing up the data, or at least make sure in the application that nobody writes to the repository. One solution is to add a feature to block write access to the repository until the backup is complete. Example configuration: database persistence manager, Lucene index, data store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637456#action_12637456
]
Thomas Mueller commented on JCR-1788:
-
Hi Stephane,
I couldn't find out where Maven 2.1.0-M1 uses the term 'wsp.name'. Do you have
a link?
Regards,
Thomas
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: Leopard, maven 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-1788:
Environment: maven 2.0.9, 2.1.0-M1 (was: Leopard, maven 2.1.0-M1)
The same problem occurs with Maven 2.0.9 and Windows XP. The 'wsp' prefix
doesn't seem to be the problem:
Even ${abc.name} is replaced with the project name. However ${jr.wsp.name} is
not replaced.
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: maven 2.0.9, 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637473#action_12637473
]
Thomas Mueller commented on JCR-1788:
-
I'm not a Maven 'specialist', and I can't find the documentation in Maven about
filtering.
Does somebody with better Maven knowledge have some insight why this happens,
if there is a workaround (maybe an escape sequence), or if this is a Maven bug?
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: maven 2.0.9, 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1572) DbDataStore connection does not always reconnect
[ https://issues.apache.org/jira/browse/JCR-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1572. - Resolution: Fixed Fix Version/s: 1.5 Committed in revision 701154 DbDataStore connection does not always reconnect Key: JCR-1572 URL: https://issues.apache.org/jira/browse/JCR-1572 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Moshe Immerman Assignee: Thomas Mueller Fix For: 1.5 Attachments: jackrabbit-trunk.patch, jackrabbit1.4.patch If a DbDataStore connection is closed due to an error all subsequent addRecord calls will fail with 'connection has been closed and autoReconnect == false' after getRecord is called and the connection is reconnected addRecord will succeed. the connection should be validated before setting autoReconnect = false or on retrieval from the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1462. - Resolution: Fixed Committed in revision 701158: only log a warning when not using a DTD repository.xml: throw an exception on error --- Key: JCR-1462 URL: https://issues.apache.org/jira/browse/JCR-1462 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.5 Attachments: configPatch.txt, JCR-1462-dynamic.patch Currently, unsupported parameters in repository.xml and workspace.xml are ignored. To find problems earlier, such problems should result in an exception, and starting such a repository should not be possible. The same should happen for unsupported values. For currently unavailable options (such as text extraction filter classes if the class is not in the classpath), at least a warning should be written to the error log, or an error should be thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1572) DbDataStore connection does not always reconnect
[
https://issues.apache.org/jira/browse/JCR-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634424#action_12634424
]
Thomas Mueller commented on JCR-1572:
-
Sorry for the delay. I can now reproduce the problem, re-connect is disabled at
the wrong time. I don't actually see why auto-reconnect should be disabled at
all: autoCommit is never disabled. I suggest to simply remove those lines:
Index:
jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/db/DbDataStore.java
===
---
jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/db/DbDataStore.java
(revision 698167)
+++
jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/data/db/DbDataStore.java
(working copy)
@@ -285,7 +285,6 @@
TempFileInputStream fileInput = null;
ConnectionRecoveryManager conn = getConnection();
try {
-conn.setAutoReconnect(false);
String id = null, tempId = null;
long now;
for (int i = 0; i ConnectionRecoveryManager.TRIALS; i++) {
@@ -362,7 +362,6 @@
}
usesIdentifier(identifier);
DbDataRecord record = new DbDataRecord(this, identifier, length,
now);
-conn.setAutoReconnect(true);
return record;
} catch (Exception e) {
throw convert(Can not insert new record, e);
I tested it and it works, and I don't see a reason why it shouldn't. Unless
somebody sees a problem I will commit it to the trunk.
DbDataStore connection does not always reconnect
Key: JCR-1572
URL: https://issues.apache.org/jira/browse/JCR-1572
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Moshe Immerman
Assignee: Thomas Mueller
Attachments: jackrabbit-trunk.patch, jackrabbit1.4.patch
If a DbDataStore connection is closed due to an error all subsequent
addRecord calls will fail with 'connection has been closed and autoReconnect
== false'
after getRecord is called and the connection is reconnected addRecord will
succeed.
the connection should be validated before setting autoReconnect = false or on
retrieval from the pool.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634118#action_12634118 ] Thomas Mueller commented on JCR-1462: - how much we are actually gaining by enabling DTD validation DTD validation is the easiest solution to detect typos in top level elements. Compatibility: Jackrabbit 1.5 will not work with 1.4 repository.xml files because of JCR-1472 (SecurityManager). If we want to make the repository.xml backward compatible, we should have a look at that as well. factory.setFeature(http://apache.org/xml/features/validation/dynamic;, true) is not supported in JDK 1.4 (JDK 1.5 is required). I guess we will anyway switch to JDK 1.5 soon, we could wait until then. What about only log (not throw) the exception until we can enable 'dynamic validation'? I would just print warnings in the log file: 24.09.2008 12:17:11 *WARN * [main] ConfigurationErrorHandler: Error parsing the configuration at line 23 using system id file:/C:/data/jackrabbit/jackrabbit-core/repository.xml: org.xml.sax.SAXParseException: Document root element Repository, must match DOCTYPE root null. (ConfigurationErrorHandler.java, line 44) 24.09.2008 12:17:11 *WARN * [main] ConfigurationErrorHandler: Error parsing the configuration at line 23 using system id file:/C:/data/jackrabbit/jackrabbit-core/repository.xml: org.xml.sax.SAXParseException: Document is invalid: no grammar found. (ConfigurationErrorHandler.java, line 44) repository.xml: throw an exception on error --- Key: JCR-1462 URL: https://issues.apache.org/jira/browse/JCR-1462 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.5 Attachments: configPatch.txt, JCR-1462-dynamic.patch Currently, unsupported parameters in repository.xml and workspace.xml are ignored. To find problems earlier, such problems should result in an exception, and starting such a repository should not be possible. The same should happen for unsupported values. For currently unavailable options (such as text extraction filter classes if the class is not in the classpath), at least a warning should be written to the error log, or an error should be thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-1216:
Attachment: softReferencePatch.txt
This patch uses SoftReference instead of WeakReference, so leaks are detected a
bit later. This patch passes the unit tests on my machine. Still it's not very
nice, as I don't know what kind of ItemStateListener are registered in
StateChangeDispatcher. Is there always a hard reference to required listeners?
Unreferenced sessions should get garbage collected
--
Key: JCR-1216
URL: https://issues.apache.org/jira/browse/JCR-1216
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: softReferencePatch.txt, userSessionPatch.txt,
weakReferencePatch.txt
If an application opens many sessions and doesn't close them, they are never
garbage collected. After some time, the virtual machine will run out of
memory. This code will run out of memory after a few thousand logins:
Repository rep = new TransientRepository();
for (int i = 0; ; i++) {
rep.login(new SimpleCredentials(, new char[0]));
}
Using a finalizer to close SessionImpl doesn't work, because it seems there
are references from the (hard referenced part of the cache) to the
SessionImpl objects. Maybe it is possible to remove those references, or
change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-1216:
Attachment: userSessionPatch.txt
This patch adds a UserSessionImpl (user facing session) that acts as a
proxy/wrapper for a SessionImpl. The patch is just for reference. I don't plan
to commit it, because there are some problems. For example if a session is not
referenced any longer, but one of its nodes is, then the session can still get
garbage (but should not).
I will try the original idea: Instead of referencing SessionImpl directly, use
WeakReference objects.
Unreferenced sessions should get garbage collected
--
Key: JCR-1216
URL: https://issues.apache.org/jira/browse/JCR-1216
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Thomas Mueller
Attachments: userSessionPatch.txt
If an application opens many sessions and doesn't close them, they are never
garbage collected. After some time, the virtual machine will run out of
memory. This code will run out of memory after a few thousand logins:
Repository rep = new TransientRepository();
for (int i = 0; ; i++) {
rep.login(new SimpleCredentials(, new char[0]));
}
Using a finalizer to close SessionImpl doesn't work, because it seems there
are references from the (hard referenced part of the cache) to the
SessionImpl objects. Maybe it is possible to remove those references, or
change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned JCR-1216:
---
Assignee: Thomas Mueller
Unreferenced sessions should get garbage collected
--
Key: JCR-1216
URL: https://issues.apache.org/jira/browse/JCR-1216
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: userSessionPatch.txt
If an application opens many sessions and doesn't close them, they are never
garbage collected. After some time, the virtual machine will run out of
memory. This code will run out of memory after a few thousand logins:
Repository rep = new TransientRepository();
for (int i = 0; ; i++) {
rep.login(new SimpleCredentials(, new char[0]));
}
Using a finalizer to close SessionImpl doesn't work, because it seems there
are references from the (hard referenced part of the cache) to the
SessionImpl objects. Maybe it is possible to remove those references, or
change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1718) repository-1.5.dtd: change order of main elements
[ https://issues.apache.org/jira/browse/JCR-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1718. - Resolution: Fixed Committed in revision 697708 repository-1.5.dtd: change order of main elements - Key: JCR-1718 URL: https://issues.apache.org/jira/browse/JCR-1718 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: dtdPatch.txt Original Estimate: 0h Remaining Estimate: 0h Currently the order of elements in repository.xml is: !ELEMENT Repository (FileSystem,Security,Workspaces,Workspace,Versioning,SearchIndex?,Cluster?,DataStore?) I would like to change it to !ELEMENT Repository (Cluster?,FileSystem,DataStore?,Security,Workspaces,Workspace,Versioning,SearchIndex?) because I think that makes more sense. Currently XML validation is disabled, and therefore the order of elements in the DTD does not need to match the repository.xml file. However as soon as XML validation is enabled, repository.xml files that use the wrong order will no longer work (the repository can not be started). There is a request to enable XML validation at http://issues.apache.org/jira/browse/JCR-1462 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1462. - Resolution: Fixed Committed in revision 697708 repository.xml: throw an exception on error --- Key: JCR-1462 URL: https://issues.apache.org/jira/browse/JCR-1462 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.5 Attachments: configPatch.txt Currently, unsupported parameters in repository.xml and workspace.xml are ignored. To find problems earlier, such problems should result in an exception, and starting such a repository should not be possible. The same should happen for unsupported values. For currently unavailable options (such as text extraction filter classes if the class is not in the classpath), at least a warning should be written to the error log, or an error should be thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633175#action_12633175 ] tmueller edited comment on JCR-1462 at 9/22/08 1:47 AM: -- Committed in revision 697709 was (Author: tmueller): Committed in revision 697708 repository.xml: throw an exception on error --- Key: JCR-1462 URL: https://issues.apache.org/jira/browse/JCR-1462 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.5 Attachments: configPatch.txt Currently, unsupported parameters in repository.xml and workspace.xml are ignored. To find problems earlier, such problems should result in an exception, and starting such a repository should not be possible. The same should happen for unsupported values. For currently unavailable options (such as text extraction filter classes if the class is not in the classpath), at least a warning should be written to the error log, or an error should be thrown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1703) Oracle JNDI DataSource support
[
https://issues.apache.org/jira/browse/JCR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-1703.
-
Resolution: Fixed
Fix Version/s: 1.5
Committed in revision 697717 (trunk).
I'm not sure if it should be applied to 1.4.6 as well.
Oracle JNDI DataSource support
--
Key: JCR-1703
URL: https://issues.apache.org/jira/browse/JCR-1703
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Stephane Landelle
Assignee: Thomas Mueller
Fix For: 1.5
Original Estimate: 0.08h
Remaining Estimate: 0.08h
When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory
tries to get a connection from a JNDI Datasource without login and pasword,
if no user/password are specified, they re retrieved as empty strings, not
null, so it tries to do a ds.getConnection(user, password), which fails.
Please complete the test line 66 as :
if ((user == null || user.length() 0) (password == null ||
password.length() 0)) {
Sincerely,
Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-1216:
Attachment: weakReferencePatch.txt
This is a prove-of-concept patch that solves the problem.
It uses weak references to SessionImpl in
TransientRepository.sessions,
StateChangeDispatcher.listeners, and
StateChangeDispatcher.nsListeners.
The StateChangeDispatcher changes are a bit ugly,
and SessionImpl.finalize needs to be changed.
The following test case works now:
Repository rep = new TransientRepository();
while(true) {
SimpleCredentials sc = new SimpleCredentials(, new char[0]);
rep.login(sc);
}
Unreferenced sessions should get garbage collected
--
Key: JCR-1216
URL: https://issues.apache.org/jira/browse/JCR-1216
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: userSessionPatch.txt, weakReferencePatch.txt
If an application opens many sessions and doesn't close them, they are never
garbage collected. After some time, the virtual machine will run out of
memory. This code will run out of memory after a few thousand logins:
Repository rep = new TransientRepository();
for (int i = 0; ; i++) {
rep.login(new SimpleCredentials(, new char[0]));
}
Using a finalizer to close SessionImpl doesn't work, because it seems there
are references from the (hard referenced part of the cache) to the
SessionImpl objects. Maybe it is possible to remove those references, or
change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1742) CacheManager resizeAll is slow
CacheManager resizeAll is slow -- Key: JCR-1742 URL: https://issues.apache.org/jira/browse/JCR-1742 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor CacheManager.resizeAll calls log.debug with a complex constructed log message. The message is immediately discarded except when using the debug log level. To improve performance, log.isDebugEnabled() should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1742) CacheManager resizeAll is slow
[ https://issues.apache.org/jira/browse/JCR-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1742. - Resolution: Fixed Fix Version/s: 1.5 Assignee: Thomas Mueller Fixed in revision 696672 CacheManager resizeAll is slow -- Key: JCR-1742 URL: https://issues.apache.org/jira/browse/JCR-1742 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.5 CacheManager.resizeAll calls log.debug with a complex constructed log message. The message is immediately discarded except when using the debug log level. To improve performance, log.isDebugEnabled() should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1703) Oracle JNDI DataSource support
[
https://issues.apache.org/jira/browse/JCR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned JCR-1703:
---
Assignee: Thomas Mueller
Oracle JNDI DataSource support
--
Key: JCR-1703
URL: https://issues.apache.org/jira/browse/JCR-1703
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Stephane Landelle
Assignee: Thomas Mueller
Original Estimate: 0.08h
Remaining Estimate: 0.08h
When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory
tries to get a connection from a JNDI Datasource without login and pasword,
if no user/password are specified, they re retrieved as empty strings, not
null, so it tries to do a ds.getConnection(user, password), which fails.
Please complete the test line 66 as :
if ((user == null || user.length() 0) (password == null ||
password.length() 0)) {
Sincerely,
Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1703) Oracle JNDI DataSource support
[
https://issues.apache.org/jira/browse/JCR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12629422#action_12629422
]
Thomas Mueller commented on JCR-1703:
-
I think you are right. I propose the following change:
===
---
jackrabbit-core/src/main/java/org/apache/jackrabbit/core/fs/db/OracleFileSystem.java
(revision 693399)
+++
jackrabbit-core/src/main/java/org/apache/jackrabbit/core/fs/db/OracleFileSystem.java
(working copy)
@@ -100,8 +100,6 @@
schema = oracle;
driver = oracle.jdbc.OracleDriver;
schemaObjectPrefix = ;
-user = ;
-password = ;
initialized = false;
}
Oracle JNDI DataSource support
--
Key: JCR-1703
URL: https://issues.apache.org/jira/browse/JCR-1703
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Stephane Landelle
Original Estimate: 0.08h
Remaining Estimate: 0.08h
When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory
tries to get a connection from a JNDI Datasource without login and pasword,
if no user/password are specified, they re retrieved as empty strings, not
null, so it tries to do a ds.getConnection(user, password), which fails.
Please complete the test line 66 as :
if ((user == null || user.length() 0) (password == null ||
password.length() 0)) {
Sincerely,
Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1456) Database connection pooling
[ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12629423#action_12629423 ] Thomas Mueller commented on JCR-1456: - Hi Dave, The connection properties you described are unrelated to Database connection pooling, right? If yes then I suggest to open another issue. Regards, Thomas Database connection pooling --- Key: JCR-1456 URL: https://issues.apache.org/jira/browse/JCR-1456 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Fix For: 1.5 Attachments: patch-1456-1.txt, patch-1456-2.txt, patch-1456-3.txt Jackrabbit should use database connection pools instead of a single connection per persistence manager, cluster journal, or database data store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1718) repository-1.5.dtd: change order of main elements
[ https://issues.apache.org/jira/browse/JCR-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12629466#action_12629466 ] Thomas Mueller commented on JCR-1718: - I understand the concern. In this case the best solution is probably: !ELEMENT Repository (Cluster|FileSystem|DataStore|Security|Workspaces|Workspace|Versioning|SearchIndex)* repository-1.5.dtd: change order of main elements - Key: JCR-1718 URL: https://issues.apache.org/jira/browse/JCR-1718 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Original Estimate: 0h Remaining Estimate: 0h Currently the order of elements in repository.xml is: !ELEMENT Repository (FileSystem,Security,Workspaces,Workspace,Versioning,SearchIndex?,Cluster?,DataStore?) I would like to change it to !ELEMENT Repository (Cluster?,FileSystem,DataStore?,Security,Workspaces,Workspace,Versioning,SearchIndex?) because I think that makes more sense. Currently XML validation is disabled, and therefore the order of elements in the DTD does not need to match the repository.xml file. However as soon as XML validation is enabled, repository.xml files that use the wrong order will no longer work (the repository can not be started). There is a request to enable XML validation at http://issues.apache.org/jira/browse/JCR-1462 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1718) repository-1.5.dtd: change order of main elements
[ https://issues.apache.org/jira/browse/JCR-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1718: Attachment: dtdPatch.txt repository-1.5.dtd: change order of main elements - Key: JCR-1718 URL: https://issues.apache.org/jira/browse/JCR-1718 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: dtdPatch.txt Original Estimate: 0h Remaining Estimate: 0h Currently the order of elements in repository.xml is: !ELEMENT Repository (FileSystem,Security,Workspaces,Workspace,Versioning,SearchIndex?,Cluster?,DataStore?) I would like to change it to !ELEMENT Repository (Cluster?,FileSystem,DataStore?,Security,Workspaces,Workspace,Versioning,SearchIndex?) because I think that makes more sense. Currently XML validation is disabled, and therefore the order of elements in the DTD does not need to match the repository.xml file. However as soon as XML validation is enabled, repository.xml files that use the wrong order will no longer work (the repository can not be started). There is a request to enable XML validation at http://issues.apache.org/jira/browse/JCR-1462 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1462) repository.xml: throw an exception on error
[ https://issues.apache.org/jira/browse/JCR-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1462: Attachment: configPatch.txt This patch enables validation, and detects duplicate entries. Before this patch is applied, the patch for bug https://issues.apache.org/jira/browse/JCR-1718 must be applied. repository.xml: throw an exception on error --- Key: JCR-1462 URL: https://issues.apache.org/jira/browse/JCR-1462 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.5 Attachments: configPatch.txt Currently, unsupported parameters in repository.xml and workspace.xml are ignored. To find problems earlier, such problems should result in an exception, and starting such a repository should not be possible. The same should happen for unsupported values. For currently unavailable options (such as text extraction filter classes if the class is not in the classpath), at least a warning should be written to the error log, or an error should be thrown. -- 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=12629184#action_12629184
]
Thomas Mueller commented on JCR-1305:
-
Hi,
From the stack trace looks like you are not using Jackrabbit 1.4.5:
java.lang.UnsupportedOperationException
at
org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:116)
at
org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:554)
at
org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory.getConnection(ConnectionFactory.java:60)
...
Line 60 of ConnectionFactory.java in Jackrabbit 1.4.5 does not call
getConnection:
if (user == null password == null) {
That means you are using an old version of Jackrabbit core.
Could you check that there is no old jackrabbit-core in your classpath?
Regards,
Thomas
JNDI data sources with BundleDbPersistenceManager:
UnsupportedOperationException
Key: JCR-1305
URL: https://issues.apache.org/jira/browse/JCR-1305
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.4
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
Fix For: 1.3.4, core 1.4.1
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.
[jira] Commented: (JCR-1456) Database connection pooling
[
https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626376#action_12626376
]
Thomas Mueller commented on JCR-1456:
-
Thanks for the patch!
It's really not complicated at all. There is one class
(ThreadLocalConnectionProviderAdapter...
This class does look complicated to me. To avoid ThreadLocal, what about:
BundleDbPersistenceManager {
Connection currentConnection
synchronized store(..) {
try {
currentConnection = ...
super.store(..)
} finally {
currentConnection = null
}
}
the patch hasn't been heavily tested in real world
I have already said, manual tests and real world tests are a maintenance
problem. If there is no automated test, each change is big risk. Maintaining
and improving the code is very hard in this case.
Database connection pooling
---
Key: JCR-1456
URL: https://issues.apache.org/jira/browse/JCR-1456
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Jukka Zitting
Fix For: 1.5
Attachments: patch-1456-1.txt, patch-1456-2.txt, patch-1456-3.txt
Jackrabbit should use database connection pools instead of a single
connection per persistence manager, cluster journal, or database data store.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1725) DbDataStore init fails if tablePrefix specified
[ https://issues.apache.org/jira/browse/JCR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1725. - Resolution: Duplicate Duplicate of JCR-1366 DbDataStore init fails if tablePrefix specified --- Key: JCR-1725 URL: https://issues.apache.org/jira/browse/JCR-1725 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.5 Reporter: Stephane Landelle Original Estimate: 168h Remaining Estimate: 168h In DbDataStore, init method checks if the table exists and otherwise creates it. However, the test only take the table name and not the optional table name prefix. Please modify : ResultSet rs = meta.getTables(null, null, tableSQL, null); as : ResultSet rs = meta.getTables(null, null, tablePrefix + tableSQL, null); Sincerely, Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1725) DbDataStore init fails if tablePrefix specified
[ https://issues.apache.org/jira/browse/JCR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626380#action_12626380 ] Thomas Mueller commented on JCR-1725: - You are not the first to stumble across this problem: see https://issues.apache.org/jira/browse/JCR-1366 We probably need to improve this, but let's discuss what to do on the issue 1366. DbDataStore init fails if tablePrefix specified --- Key: JCR-1725 URL: https://issues.apache.org/jira/browse/JCR-1725 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.5 Reporter: Stephane Landelle Original Estimate: 168h Remaining Estimate: 168h In DbDataStore, init method checks if the table exists and otherwise creates it. However, the test only take the table name and not the optional table name prefix. Please modify : ResultSet rs = meta.getTables(null, null, tableSQL, null); as : ResultSet rs = meta.getTables(null, null, tablePrefix + tableSQL, null); Sincerely, Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1722) Data Store backup: need a way to delay deleting files (garbage collection)
Data Store backup: need a way to delay deleting files (garbage collection) -- Key: JCR-1722 URL: https://issues.apache.org/jira/browse/JCR-1722 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.5 During a backup, objects in the data store must not be modified or deleted. Otherwise the backup is consistent. Objects in the data store are never modified. The only problem is if objects are deleted while the backup is running. The data store garbage collection is the only place where objects are deleted. There should be a way for a backup tool to 'flag' the data store (file data store and database data store) to not delete entries. For the file data store, this could be done by placing a specially named file in the root folder. For the database data store a specially named entry could be used. Another idea is to use an in-memory state only, however this solution doesn't work if multiple repositories share the same data store. To support shared data stores, the specially named file name / object name should consist of a fixed part (for example the prefix 'stopdelete') and a unique id (for example a UUID). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1703) Oracle JNDI DataSource support
[
https://issues.apache.org/jira/browse/JCR-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623409#action_12623409
]
Thomas Mueller commented on JCR-1703:
-
If we do that, then an empty () user name and password are not supported any
longer.
if no user/password are specified, they re retrieved as empty strings, not
null
I could not reproduce this. In my test case, both the user name and password
are null:
DataStore class=org.apache.jackrabbit.core.data.db.DbDataStore
param name=url value=jdbc:h2:~/db/datastore/
/DataStore
Could you provide a test case where user name and password are an empty string
in this method, without setting the user name and password properties in the
repository.xml / workspace.xml?
Oracle JNDI DataSource support
--
Key: JCR-1703
URL: https://issues.apache.org/jira/browse/JCR-1703
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Reporter: Stephane Landelle
Original Estimate: 0.08h
Remaining Estimate: 0.08h
When org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory
tries to get a connection from a JNDI Datasource without login and pasword,
if no user/password are specified, they re retrieved as empty strings, not
null, so it tries to do a ds.getConnection(user, password), which fails.
Please complete the test line 66 as :
if ((user == null || user.length() 0) (password == null ||
password.length() 0)) {
Sincerely,
Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1456) Database connection pooling
[ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623419#action_12623419 ] Thomas Mueller commented on JCR-1456: - What about doing that for DbDataStore first? The patch would be much smaller. attaching active connection to current thread, so that the nested calls would always obtain the active connection That sounds too complicated, too tricky, and too slow for me. For store(ChangeLog), why not simply pass the connection object to the nested calls? require lot of testing Just to make sure: You mean automated tests, right? Manual tests is a maintenance problem. Database connection pooling --- Key: JCR-1456 URL: https://issues.apache.org/jira/browse/JCR-1456 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Fix For: 1.5 Attachments: patch-1456-1.txt, patch-1456-2.txt Jackrabbit should use database connection pools instead of a single connection per persistence manager, cluster journal, or database data store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1718) repository-1.5.dtd: change order of main elements
[ https://issues.apache.org/jira/browse/JCR-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623466#action_12623466 ] Thomas Mueller commented on JCR-1718: - !ELEMENT Repository (Cluster|FileSystem|DataStore|Security|Workspaces|Workspace|Versioning|SearchIndex)* This would allow same name siblings, for example multiple Cluster elements in the same repository.xml. I'd rather not break things for people who may be validating the repository.xml. While I don't have any numbers, I don't think many people do validate the repository.xml. Remember also we already broke all existing (old) repository.xml configurations by adding SecurityManager in Security. I agree, the order of elements does not seem to be important, but I would rather have a strict order than not detecting typos (as we do now). We can still spit out warnings/errors in Jackrabbits configuration parser if required elements are missing - or is that already the case? Yes, that already works: I have removed the top FileSystem element, and got the exception javax.jcr.RepositoryException: Invalid repository configuration: repository.xml: Configuration element FileSystem not found in Repository.: Configuration element FileSystem not found in Repository. At least a change like this requires an update to the DTD version. I don't think we did that in the past. Jackrabbit 1.4 uses repository-1.4.dtd. repository-1.5.dtd is only used in the Jackrabbt trunk. I don't think changes in the unreleased Jackrabbit 1.5 requires an update in the DTD version. Using repository-1.6.dtd for Jackrabbit 1.5 would be confusing. So, I still like to change it to: !ELEMENT Repository (Cluster?,FileSystem,DataStore?,Security,Workspaces,Workspace,Versioning,SearchIndex?) What do you think? repository-1.5.dtd: change order of main elements - Key: JCR-1718 URL: https://issues.apache.org/jira/browse/JCR-1718 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Currently the order of elements in repository.xml is: !ELEMENT Repository (FileSystem,Security,Workspaces,Workspace,Versioning,SearchIndex?,Cluster?,DataStore?) I would like to change it to !ELEMENT Repository (Cluster?,FileSystem,DataStore?,Security,Workspaces,Workspace,Versioning,SearchIndex?) because I think that makes more sense. Currently XML validation is disabled, and therefore the order of elements in the DTD does not need to match the repository.xml file. However as soon as XML validation is enabled, repository.xml files that use the wrong order will no longer work (the repository can not be started). There is a request to enable XML validation at http://issues.apache.org/jira/browse/JCR-1462 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1718) repository-1.5.dtd: change order of main elements
repository-1.5.dtd: change order of main elements - Key: JCR-1718 URL: https://issues.apache.org/jira/browse/JCR-1718 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Currently the order of elements in repository.xml is: !ELEMENT Repository (FileSystem,Security,Workspaces,Workspace,Versioning,SearchIndex?,Cluster?,DataStore?) I would like to change it to !ELEMENT Repository (Cluster?,FileSystem,DataStore?,Security,Workspaces,Workspace,Versioning,SearchIndex?) because I think that makes more sense. Currently XML validation is disabled, and therefore the order of elements in the DTD does not need to match the repository.xml file. However as soon as XML validation is enabled, repository.xml files that use the wrong order will no longer work (the repository can not be started). There is a request to enable XML validation at http://issues.apache.org/jira/browse/JCR-1462 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1570) [PATCH] better exception messages when generating schema
[ https://issues.apache.org/jira/browse/JCR-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1570. - Resolution: Fixed [PATCH] better exception messages when generating schema Key: JCR-1570 URL: https://issues.apache.org/jira/browse/JCR-1570 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Dave Brosius Assignee: Thomas Mueller Priority: Trivial Fix For: 1.5 Attachments: better_schema_ex_messages.patch When a statement fails to execute generating the schema, patch outputs the statement that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1713) attempting to combine Tuscany photo-gallery app and Jackrabbit FirstHops style app
[
https://issues.apache.org/jira/browse/JCR-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-1713.
-
Resolution: Invalid
You wrote When run in the Tuscany app, none of the strings printed.
That would mean the constructor was never called?
So I guess it's not a bug in Jackrabbit?
attempting to combine Tuscany photo-gallery app and Jackrabbit FirstHops
style app
--
Key: JCR-1713
URL: https://issues.apache.org/jira/browse/JCR-1713
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Environment: Windows Vista
Eclipse 3.3.0
Java 1.6.0_03
Reporter: Angela Cymbalak
Priority: Minor
The Tuscany init method fires which is supposed to call the
TransientRepository() constructor. The repository is never created and the
application never finishes the init method once the contrstuctor is called.
I put System.out statements throughout the TransientRepository(final String,
final String) constructor to narrow down where the issue was. In the
FirstHops app, the strings printed as expected. When run in the Tuscany app,
none of the strings printed.
Code:
public TransientRepository(final String config, final String home)
throws IOException {
this(new RepositoryFactory() {
public RepositoryImpl getRepository() throws RepositoryException {
try {
// Make sure that the repository configuration file exists
System.out.println(1);
File configFile = new File(config);
System.out.println(2);
if (!configFile.exists()) {
System.out.println(3);
logger.info(Copying default configuration to +
config);
System.out.println(4);
OutputStream output = new
FileOutputStream(configFile);
try {
System.out.println(5);
InputStream input =
TransientRepository.class.getResourceAsStream(
DEFAULT_REPOSITORY_XML);
System.out.println(6);
byte[] buffer = new byte[BUFFER_SIZE];
System.out.println(7);
try {
System.out.println(8);
int n = input.read(buffer);
System.out.println(9);
while (n != -1) {
System.out.println(10);
output.write(buffer, 0, n);
System.out.println(11);
n = input.read(buffer);
System.out.println(12);
}
System.out.println(13);
} finally {
System.out.println(14);
input.close();
}
} finally {
System.out.println(15);
output.close();
}
}
// Make sure that the repository home directory exists
System.out.println(16);
File homeDir = new File(home);
System.out.println(17);
if (!homeDir.exists()) {
System.out.println(18);
logger.info(Creating repository home directory +
home);
System.out.println(19);
homeDir.mkdirs();
}
// Load the configuration and create the repository
System.out.println(20);
RepositoryConfig rc = RepositoryConfig.create(config,
home);
System.out.println(21);
return RepositoryImpl.create(rc);
} catch (IOException e) {
System.out.println(22);
throw new RepositoryException(
Automatic repository configuration failed, e);
} catch (ConfigurationException e) {
System.out.println(23);
throw new RepositoryException(
Invalid repository configuration: + config, e);
}
}
});
}
This is also listed as a
[jira] Created: (JCR-1711) Download: improve user experience
Download: improve user experience - Key: JCR-1711 URL: https://issues.apache.org/jira/browse/JCR-1711 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller The download section at http://jackrabbit.apache.org/downloads.html contains many files. The number of files should be reduced. Some of them contain other files, for example the .rar files, and the .war files. The file jackrabbit-jca-1.4.rar contains an old version of jackrabbit-core: jackrabbit-core-1.4.jar - however the newest version of jackrabbit-core is jackrabbit-core-1.4.5.jar This often leads to 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-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616938#action_12616938
]
Thomas Mueller commented on JCR-1216:
-
Another idea is: Split SessionImpl into a 'end user class' and an 'core class'
to allow garbage collection:
class SessionImpl implements Session {
private InternalJackrabbitSession session;
private Exception openStackTrace;
SessionImpl(..) {
session = ...
openStackTrace = new Exception(Stack Trace);
}
public void finalize() {
if (!closed) {
LOG.error(Session not closed, openStackTrace);
close();
}
}
}
class SessionCore implements InternalJackrabbitSession {
... basically what is now SessionImpl ...
}
Only SessionCore would be kept in the map, not SessionImpl. The
InternalJackrabbitSession interface would be simpler than the Session
interface. There could be multiple InternalJackrabbitSession implementations (a
embedded implementation, a client-server implementation, a clustering
implementation).
This split of 'user facing session' and 'internal session' is probably what we
want to achieve with the 'Jackrabbit SPI' as well.
Unreferenced sessions should get garbage collected
--
Key: JCR-1216
URL: https://issues.apache.org/jira/browse/JCR-1216
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Thomas Mueller
If an application opens many sessions and doesn't close them, they are never
garbage collected. After some time, the virtual machine will run out of
memory. This code will run out of memory after a few thousand logins:
Repository rep = new TransientRepository();
for (int i = 0; ; i++) {
rep.login(new SimpleCredentials(, new char[0]));
}
Using a finalizer to close SessionImpl doesn't work, because it seems there
are references from the (hard referenced part of the cache) to the
SessionImpl objects. Maybe it is possible to remove those references, or
change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1216) Unreferenced sessions should get garbage collected
[
https://issues.apache.org/jira/browse/JCR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616500#action_12616500
]
Thomas Mueller commented on JCR-1216:
-
The problem seems to be TransientRepository.session, which is a HashSet.
Unreferenced sessions should get garbage collected
--
Key: JCR-1216
URL: https://issues.apache.org/jira/browse/JCR-1216
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Thomas Mueller
If an application opens many sessions and doesn't close them, they are never
garbage collected. After some time, the virtual machine will run out of
memory. This code will run out of memory after a few thousand logins:
Repository rep = new TransientRepository();
for (int i = 0; ; i++) {
rep.login(new SimpleCredentials(, new char[0]));
}
Using a finalizer to close SessionImpl doesn't work, because it seems there
are references from the (hard referenced part of the cache) to the
SessionImpl objects. Maybe it is possible to remove those references, or
change them to weak references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1681) DbDataStore: improve error message when init fails
DbDataStore: improve error message when init fails -- Key: JCR-1681 URL: https://issues.apache.org/jira/browse/JCR-1681 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor When initialization of the database data store fails, the error message does not contain enough data to analyze the problem: Driver: Oracle JDBC driver / 10.2.0.1.0 could not execute statement, reason: ORA-00902: invalid datatype, state/code: 42000/902 Can not init data store, driver=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@localhost:1521:orcl user=JACKRABBIT Additionally the create table statement should be logged, and the table name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1681) DbDataStore: improve error message when init fails
[ https://issues.apache.org/jira/browse/JCR-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1681. - Resolution: Fixed Fixed in revision 677312 (trunk) DbDataStore: improve error message when init fails -- Key: JCR-1681 URL: https://issues.apache.org/jira/browse/JCR-1681 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor When initialization of the database data store fails, the error message does not contain enough data to analyze the problem: Driver: Oracle JDBC driver / 10.2.0.1.0 could not execute statement, reason: ORA-00902: invalid datatype, state/code: 42000/902 Can not init data store, driver=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@localhost:1521:orcl user=JACKRABBIT Additionally the create table statement should be logged, and the table name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1674) Provide means for exception handling for QueryNodeVisitor implementations
[ https://issues.apache.org/jira/browse/JCR-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612146#action_12612146 ] Thomas Mueller commented on JCR-1674: - +1 for this patch. I think using checked exceptions is a good solution. I would use unchecked exceptions only if Jackrabbit as a whole also uses unchecked exceptions. It would be inconsistent to use unchecked exceptions in some places and checked exceptions in others. Communicating the error state using the data object doesn't sound like a good solution: you would have to check the error state everywhere. Provide means for exception handling for QueryNodeVisitor implementations - Key: JCR-1674 URL: https://issues.apache.org/jira/browse/JCR-1674 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-spi-commons Reporter: Michael Dürig Priority: Minor Attachments: QueryNodeVisitor.patch Currently the methods of QueryNodeVisitor do not declare any exceptions. Even though the query tree might be syntactically correct, an implementation might reach a point where it cannot continue (i.e. if it does not support one of the optional query features). For such cases there are currently two solution: 1. throw an unchecked exception or 2. communicate the error state through the visitor using the data object passed along. While I don't like 2. it is still an option. For 1. I'm not sure if this is the right way to go. It might be better to actually throw a checked exception. I therefore created a patch which declares RepositoryException on all visit methods of QueryNodeVisitor. Although the necessary changes in classes using QueryNodeVisitor are trivial, there are quite many of them. Any opinions on checked exception with probably breaking (trivially) existing code vs. using not checked exceptions? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1675) Provide names for constants in QueryConstants
[ https://issues.apache.org/jira/browse/JCR-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612169#action_12612169 ] Thomas Mueller commented on JCR-1675: - I saw that QueryConstants uses a rather tricky way to define constants int OPERATION_NE_VALUE = OPERATION_EQ_GENERAL + 1; This is really hard for debugging because you can't easily map a number to a constant. Is this what you mean? If yes I suggest to assign explicit values, as in: int OPERATION_EQ_VALUE = 11; int OPERATION_EQ_GENERAL = 12; ... An alternative would be to use the 'enum pattern' (using singleton objects rather than int constants) but that's more tricky in JDK 1.4 as 'enum' is not supported. By the way, the main advantage of int constants (the ability to use switch / case) is never used in the code - if else if else everywhere. Provide names for constants in QueryConstants - Key: JCR-1675 URL: https://issues.apache.org/jira/browse/JCR-1675 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-spi-commons Reporter: Michael Dürig Priority: Minor For debugging, logging, and user interaction purposes QueryConstants should include descriptive names for the constants it provides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1673) Date comparitons are backwards in Queries
[
https://issues.apache.org/jira/browse/JCR-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611675#action_12611675
]
Thomas Mueller commented on JCR-1673:
-
You need to mark the literal value as a date, otherwise the query will
default to string comparison
This sounds logical, but... how does the string representation of a date look
like? I would have guessed that the string representation of
xs:dateTime('2008-07-08T15:10:07.125+10:00') is
'2008-07-08T15:10:07.125+10:00'? But if that would be the case, then
'2008-07-08T15:10:07.125+10:00' '2008-07-09T14:55:29.774+10:00' should not
return true...
Of course you should use the correct data types (because of timezone problems
and so on), but I don't understand the example above.
Date comparitons are backwards in Queries
-
Key: JCR-1673
URL: https://issues.apache.org/jira/browse/JCR-1673
Project: Jackrabbit
Issue Type: Bug
Components: query
Affects Versions: core 1.4.1, core 1.4.4
Reporter: Michael Neale
Assignee: Jukka Zitting
Priority: Critical
Imagine there is a node with jcr:created of:
2008-07-08T15:10:07.125+10:00
The following query:
SELECT ... FROM WHERE jcr:created '2009-07-08T15:10:07.125+10:00'
should return it, but it doesn't. However, if you put:
SELECT ... FROM WHERE jcr:created '2009-07-08T15:10:07.125+10:00'
then it does return it. Whoops.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1663) REFERENCE properties produce duplicate strings in memory
[ https://issues.apache.org/jira/browse/JCR-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611685#action_12611685 ] Thomas Mueller commented on JCR-1663: - Hi, This patch looks good, but there is a flaw. Not a bug, but it might lead to a bug later on when somebody (for whatever reason) changes the code later on. See http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2707.pdf page 38ff. I don't want to spoil it in case you like to solve the puzzle yourself... By the way, I can highly recommend the book Java Puzzlers. Something completely different: did you know that % (mod) is slower than (bitwise and)? Also the following wouldn't require Math.abs. You _need_ to use a power of 2 size then, but you could document that as follows: private final static int SIZE_POWER_OF_2 = 1 10; private final Name[] names = new Name[SIZE_POWER_OF_2]; ... int position = name.hashCode() (SIZE_POWER_OF_2 - 1); Regards, Thomas REFERENCE properties produce duplicate strings in memory Key: JCR-1663 URL: https://issues.apache.org/jira/browse/JCR-1663 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, jackrabbit-spi-commons Affects Versions: 1.4, core 1.4.5 Reporter: Roman Puchkovskiy Attachments: JCR-1663.patch When reference property is loaded from PM, Serializer.deserialize(NodeReferences, InputStream) is called, which calls PropertyId.valueOf(String), which in turn calls NameFactoryImpl.create(String) which finally splits a full property name to namespace and local name. Namespace is internalized, but local name is not (comments say that this is done to avoid perm space overfilling). So, in the end, a new String instance is created for local name. This leads to considerable memory waste when repository has a lot of nodes with REFERENCE properties. It seems that local name part could be internalized here too because in the most repositories it's not allowed to create properties with arbitrary names, so the danger of perm space exhaust does not seem to be an argument. As for ways to resolve this, maybe a new NameFactory implementation could be created which would be used for properties only (and, possibly, mainly in the PropertyId.valueOf(String)) which would extend an existing NameFactoryImpl overriding its create(String) method. What do you think about all this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1660) Consistency check / fix skips system nodes
Consistency check / fix skips system nodes
--
Key: JCR-1660
URL: https://issues.apache.org/jira/browse/JCR-1660
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Priority: Minor
BundleDbPersistenceManager.checkBundleConsistency skips the consistency check
and fix for some nodes:
// skip check for system nodes (root, system root, version storage, node types)
if (entry.getId().toString().endsWith(babecafebabe)) {
continue;
}
if (id.toString().endsWith(babecafebabe)) {
continue;
}
The reason is (as far as I understand) that some system nodes refer to child
nodes in another workspace. But probably this check should be more specific so
that real inconsistencies in the system nodes are still fixed.
Also, it is not nice to hardcode babecafebabe here: a constant should be
used, or some other solution that does not rely on a fixed system node id.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1605) RepositoryLock does not work on NFS sometimes
[ https://issues.apache.org/jira/browse/JCR-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599299#action_12599299 ] Thomas Mueller commented on JCR-1605: - A configurable lock mechanism will also help support a 'file system less' repository (where no files are stored at all). Use cases: database-based repository; in-memory repository (for example for testing) RepositoryLock does not work on NFS sometimes - Key: JCR-1605 URL: https://issues.apache.org/jira/browse/JCR-1605 Project: Jackrabbit Issue Type: Bug Reporter: Thomas Mueller Assignee: Thomas Mueller The RepositoryLock mechanism currently used in Jackrabbit uses FileLock. This doesn't work on some NFS file system. It looks like only NFS version 4 and newer supports locking. Older implementations may throw a IOException No locks available, which means the NFS does not support byte-range locking. I propose to add a second locking mechanism, and add a configuration option to use it. For example: FileLocking class=acme /. This second locking mechanism is a cooperative locking protocol that uses a background (watchdog) thread and only uses regular file operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1625) The repository-1.5.dtd is not well formed
[ https://issues.apache.org/jira/browse/JCR-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599485#action_12599485 ] Thomas Mueller commented on JCR-1625: - So line 173 should be: !ATTLIST AccessControlProvider class CDATA #REQUIRED Is this correct? The repository-1.5.dtd is not well formed - Key: JCR-1625 URL: https://issues.apache.org/jira/browse/JCR-1625 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.5 Environment: Any / XML Validator Reporter: Sébastien MIGNIOT Priority: Blocker Original Estimate: 0.02h Remaining Estimate: 0.02h The repository-1.5.dtd file at http://jackrabbit.apache.org/dtd/repository-1.5.dtd is not well formed at the time of this writing 200/05/23 19:30GMT 1. It looks like a #REQUIRED is missing at line 173 2. Detected this while trying the 5minutes with ocm tutorial Hope this helps, S. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1602) DbDatastore: Problems indexing pdf file
DbDatastore: Problems indexing pdf file --- Key: JCR-1602 URL: https://issues.apache.org/jira/browse/JCR-1602 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller As reported by Claus Köll: When importing a pdf file into a repository configured with a DbDataStore the following exception occurs. This happens only when using the DbDataStore with copyWhenReading=true java.io.IOException: Stream closed at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:156) at java.io.BufferedInputStream.read(BufferedInputStream.java:315) at org.apache.jackrabbit.core.data.db.TempFileInputStream.read(TempFileInputStream.java:107) at java.io.BufferedInputStream.read1(BufferedInputStream.java:265) at java.io.BufferedInputStream.read(BufferedInputStream.java:324) at java.io.BufferedInputStream.fill(BufferedInputStream.java:229) at java.io.BufferedInputStream.read(BufferedInputStream.java:246) at java.io.FilterInputStream.read(FilterInputStream.java:89) at java.io.PushbackInputStream.read(PushbackInputStream.java:141) at org.pdfbox.io.PushBackInputStream.peek(PushBackInputStream.java:71) at org.pdfbox.io.PushBackInputStream.isEOF(PushBackInputStream.java:88) at org.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:370) at org.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:176) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1602) DbDatastore: Problems indexing pdf file
[ https://issues.apache.org/jira/browse/JCR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597132#action_12597132 ] Thomas Mueller commented on JCR-1602: - Test case committed in revision 656664. DbDatastore: Problems indexing pdf file --- Key: JCR-1602 URL: https://issues.apache.org/jira/browse/JCR-1602 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.4 Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.4 As reported by Claus Köll: When importing a pdf file into a repository configured with a DbDataStore the following exception occurs. This happens only when using the DbDataStore with copyWhenReading=true java.io.IOException: Stream closed at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:156) at java.io.BufferedInputStream.read(BufferedInputStream.java:315) at org.apache.jackrabbit.core.data.db.TempFileInputStream.read(TempFileInputStream.java:107) at java.io.BufferedInputStream.read1(BufferedInputStream.java:265) at java.io.BufferedInputStream.read(BufferedInputStream.java:324) at java.io.BufferedInputStream.fill(BufferedInputStream.java:229) at java.io.BufferedInputStream.read(BufferedInputStream.java:246) at java.io.FilterInputStream.read(FilterInputStream.java:89) at java.io.PushbackInputStream.read(PushbackInputStream.java:141) at org.pdfbox.io.PushBackInputStream.peek(PushBackInputStream.java:71) at org.pdfbox.io.PushBackInputStream.isEOF(PushBackInputStream.java:88) at org.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:370) at org.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:176) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1605) RepositoryLock does not work on NFS sometimes
RepositoryLock does not work on NFS sometimes - Key: JCR-1605 URL: https://issues.apache.org/jira/browse/JCR-1605 Project: Jackrabbit Issue Type: Bug Reporter: Thomas Mueller Assignee: Thomas Mueller The RepositoryLock mechanism currently used in Jackrabbit uses FileLock. This doesn't work on some NFS file system. It looks like only NFS version 4 and newer supports locking. Older implementations may throw a IOException No locks available, which means the NFS does not support byte-range locking. I propose to add a second locking mechanism, and add a configuration option to use it. For example: FileLocking class=acme /. This second locking mechanism is a cooperative locking protocol that uses a background (watchdog) thread and only uses regular file operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1598) Problematic exception handling in Jackrabbit WebApp
Problematic exception handling in Jackrabbit WebApp
---
Key: JCR-1598
URL: https://issues.apache.org/jira/browse/JCR-1598
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-webapp
Reporter: Thomas Mueller
Priority: Minor
In this project, the cause of the exception is often ignored, and only the
message of the cause is used, as in:
} catch (Exception e) {
log.error(Error in configuration: {}, e.toString());
throw new ServletException(Error in configuration: + e.toString());
}
An additional problem is that when using ServletException(String message,
Throwable rootCause), the rootCause is not used in printStackTrace(), that
means the cause is not logged. See also:
http://closingbraces.net/2007/11/27/servletexceptionrootcause/
It is therefore better to convert
throw new ServletException(Unable to create RMI repository. jcr-rmi.jar
might be missing., e);
to
ServletException s = new ServletException(Unable to create RMI repository.
jcr-rmi.jar might be missing.);
s.initCause(e);
throw s;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1572) DbDataStore connection does not always reconnect
[ https://issues.apache.org/jira/browse/JCR-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595479#action_12595479 ] Thomas Mueller commented on JCR-1572: - Hi, Validation is a good idea, what about a query of the form SELECT * FROM DATASTORE WHERE 1=0. What I want to avoid is hiding a real problem, so I think this validation should be optional. I still think it's more important to understand the real problem first: why did you get a CommunicationException, why did the link go down temporarily? What version of MySQL (server and JDBC client) do you use? When I have tested it with MySQL, I found out that the objects must fit in memory. Is this the case for you as well? Regards, Thomas DbDataStore connection does not always reconnect Key: JCR-1572 URL: https://issues.apache.org/jira/browse/JCR-1572 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Moshe Immerman Assignee: Thomas Mueller If a DbDataStore connection is closed due to an error all subsequent addRecord calls will fail with 'connection has been closed and autoReconnect == false' after getRecord is called and the connection is reconnected addRecord will succeed. the connection should be validated before setting autoReconnect = false or on retrieval from the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-619) CacheManager (Memory Management in Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595488#action_12595488 ] Thomas Mueller commented on JCR-619: Hi, Is it possible to use the Caching softwares on top of Jackrabbit Yes, sure. Maybe you want to cache on the application side. CacheManager (Memory Management in Jackrabbit) -- Key: JCR-619 URL: https://issues.apache.org/jira/browse/JCR-619 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Stefan Guggisberg Fix For: 1.2.1 Attachments: cacheManager.txt, cacheManager2.txt, cacheManager5.txt, cacheManager6.txt, cacheManager7.txt, jackrabbit-cachemanager-config.patch, stack.txt Jackrabbit can run out of memory because the the combined size of the various caches is not managed. The biggest problem (for me) is the combined size of the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create a few (?) of those caches, and each one is limited to 4 MB by default. I have implemented a dynamic (cache-) memory management service that distributes a fixed amount of memory dynamically to all those caches. Here is the patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1562) JNDI data sources with various PersistenceManager: wrong default values
[ https://issues.apache.org/jira/browse/JCR-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595221#action_12595221 ] Thomas Mueller commented on JCR-1562: - Can you please advise an alternative You could patch the classes yourself as long as there is no new version available. Otherwise I don't have an alternative I am afraid. For Oracle, a user name and password is required in any case. But it's provided by the datasource, so it shouldn't be mandatory (or have a default value) at the PM's configuration level, right ? Yes. The Oracle JDBC driver requires user name and password. If that's configured in the data source then that's OK. JNDI data sources with various PersistenceManager: wrong default values --- Key: JCR-1562 URL: https://issues.apache.org/jira/browse/JCR-1562 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.2 Reporter: Sven Rieckhoff Attachments: bundleDbNoDefaultUserPassword.txt With JCR-1305 Jackrabbit supports creating a connection throug a JNDI Datasource and without configuring user and password. This works for some but not all provided PersistenceManagers. Some of them - like the Oracle-specific BundleDBPersistenceManager - sets default values for user and password if none are provided in the jackrabbit config. This way its impossible to use such PersistenceManagers with the plain JNDI DS. This concerns the following BundleDbPersistenceManagers: OraclePersistenceManager, DerbyPersistenceManager, H2PersistenceManager. There also might be other PMs (perhaps some special SimpleDbPersistenceManagers) with similar behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1562) JNDI data sources with various PersistenceManager: wrong default values
[ https://issues.apache.org/jira/browse/JCR-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595224#action_12595224 ] Thomas Mueller commented on JCR-1562: - Fixed in revision 654514 JNDI data sources with various PersistenceManager: wrong default values --- Key: JCR-1562 URL: https://issues.apache.org/jira/browse/JCR-1562 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.2 Reporter: Sven Rieckhoff Attachments: bundleDbNoDefaultUserPassword.txt With JCR-1305 Jackrabbit supports creating a connection throug a JNDI Datasource and without configuring user and password. This works for some but not all provided PersistenceManagers. Some of them - like the Oracle-specific BundleDBPersistenceManager - sets default values for user and password if none are provided in the jackrabbit config. This way its impossible to use such PersistenceManagers with the plain JNDI DS. This concerns the following BundleDbPersistenceManagers: OraclePersistenceManager, DerbyPersistenceManager, H2PersistenceManager. There also might be other PMs (perhaps some special SimpleDbPersistenceManagers) with similar behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1562) JNDI data sources with various PersistenceManager: wrong default values
[ https://issues.apache.org/jira/browse/JCR-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1562. - Resolution: Fixed JNDI data sources with various PersistenceManager: wrong default values --- Key: JCR-1562 URL: https://issues.apache.org/jira/browse/JCR-1562 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.2 Reporter: Sven Rieckhoff Attachments: bundleDbNoDefaultUserPassword.txt With JCR-1305 Jackrabbit supports creating a connection throug a JNDI Datasource and without configuring user and password. This works for some but not all provided PersistenceManagers. Some of them - like the Oracle-specific BundleDBPersistenceManager - sets default values for user and password if none are provided in the jackrabbit config. This way its impossible to use such PersistenceManagers with the plain JNDI DS. This concerns the following BundleDbPersistenceManagers: OraclePersistenceManager, DerbyPersistenceManager, H2PersistenceManager. There also might be other PMs (perhaps some special SimpleDbPersistenceManagers) with similar behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1180) DatabaseFileSystem and DatabasePersistenceManager don't allow choice of db schema
[ https://issues.apache.org/jira/browse/JCR-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594811#action_12594811 ] Thomas Mueller commented on JCR-1180: - something that works within the scope of the existing schemaObjectPrefix option I think splitting schemaObjectPrefix in 'schema name' 'dot' 'table name prefix' is an ugly hack: Any database identifier can contain spaces and dots if it's quoted. Correct parsing and splitting the schemaObjectPrefix would be really ugly and database dependent (MS SQL Server supports [] quotes, MySQL backticks; but most database use double quotes, which need to be escaped in XML). I think it's better to use a distinct case sensitive property 'schemaName' as in the java.sql.DatabaseMetaData.getColumns and so forth. In my view, the schemaObjectPrefix should be kept as is (tableNamePrefix would actually be the right name). DatabaseFileSystem and DatabasePersistenceManager don't allow choice of db schema - Key: JCR-1180 URL: https://issues.apache.org/jira/browse/JCR-1180 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Environment: All Reporter: Kev Jackson Assignee: Thomas Mueller Priority: Minor Attachments: jackrabbit-core.patch I have a need to store my repository objects under a different db schema than the default for the rdbms (I'm using postgresql, so in my case the default is 'public') The current implementation of the DatabasePersistenceManager and DatabaseFileSystem do not support changing the schema. Problems: - schemaObjectPrefix allows the user to add a table prefix, but you cannot use this to set a schema ie schema.table, as the . is stripped out and replaced with an escaped version - schema param currently refers to a ddl resource, not what people would naturally think is the param to set the schema for the repository Fix: - rename the current schema - schemaDDL - add an optional schema param which allows the user to select which schema they want to use - improve error messages so that when an incorrect schemaDDL is chosen the user doesn't have to dig through nabble etc to find an answer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1551) TransientRepository: application doesn't exit quickly
[
https://issues.apache.org/jira/browse/JCR-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-1551.
-
Resolution: Fixed
Fixed in revision 654078
TransientRepository: application doesn't exit quickly
-
Key: JCR-1551
URL: https://issues.apache.org/jira/browse/JCR-1551
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
When using the TransientRepository, the repository should be closed when the
last session logs out. This works, but in some cases there is a very long (60
seconds) delay between closing the last session and closing the repository.
Test case:
public static void main(String[] args) throws Exception {
Repository repository = new TransientRepository();
Session session = repository.login(new SimpleCredentials(, new
char[0]));
session.getRootNode().setProperty(a, 0);
session.save(); // very quick logout without this line
session.logout();
System.out.println(Logout...);
final long time = System.currentTimeMillis();
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
System.out.println(End after: +
(System.currentTimeMillis() - time));
}
});
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1572) DbDataStore connection does not always reconnect
[ https://issues.apache.org/jira/browse/JCR-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594498#action_12594498 ] Thomas Mueller commented on JCR-1572: - Hi, I think it makes sense to solve the original problem instead of trying to work around it. I was searching for MySQL max_packet_size error and found this: http://www.mysqltalk.org/maxpacketsize-info-vt112883.html I had to set this an actually it is a setting in the server side mysql config file like this: set-variable = max_allowed_packet=16M This is a known bug (check http://bugs.mysql.com/) that was a regression in 3.0. It is fixed (to be released in 3.0.9) What version of MySQL (server and JDBC client) do you use? How big was your largest object? Did you set max_allowed_packet? When I tested it, it worked without any special settings. I have tested with MySQL 5.0.27-community-nt on Windows XP (2007-12-11) and found out that the objects must fit in memory. It would be great if this problem could be solved as well. DbDataStore connection does not always reconnect Key: JCR-1572 URL: https://issues.apache.org/jira/browse/JCR-1572 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Moshe Immerman Assignee: Thomas Mueller If a DbDataStore connection is closed due to an error all subsequent addRecord calls will fail with 'connection has been closed and autoReconnect == false' after getRecord is called and the connection is reconnected addRecord will succeed. the connection should be validated before setting autoReconnect = false or on retrieval from the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1562) JNDI data sources with various PersistenceManager: wrong default values
[
https://issues.apache.org/jira/browse/JCR-1562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594509#action_12594509
]
Thomas Mueller commented on JCR-1562:
-
if (getSchema() == null) {
setSchema(oracle);
}
shouldn't that be removed too?
No. The term 'schema' is a bit misleading: here the schema property controls
what .ddl file to use to create the tables. For Oracle, the file
src/main/resources/org/apache/jackrabbit/core/persistence/bundle/oracle.ddl
file is used. It doesn't have to do with the database schema.
See also http://issues.apache.org/jira/browse/JCR-1180
JNDI data sources with various PersistenceManager: wrong default values
---
Key: JCR-1562
URL: https://issues.apache.org/jira/browse/JCR-1562
Project: Jackrabbit
Issue Type: Bug
Affects Versions: core 1.4.2
Reporter: Sven Rieckhoff
Attachments: bundleDbNoDefaultUserPassword.txt
With JCR-1305 Jackrabbit supports creating a connection throug a JNDI
Datasource and without configuring user and password. This works for some but
not all provided PersistenceManagers. Some of them - like the Oracle-specific
BundleDBPersistenceManager - sets default values for user and password if
none are provided in the jackrabbit config. This way its impossible to use
such PersistenceManagers with the plain JNDI DS.
This concerns the following BundleDbPersistenceManagers:
OraclePersistenceManager, DerbyPersistenceManager, H2PersistenceManager.
There also might be other PMs (perhaps some special
SimpleDbPersistenceManagers) with similar behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1563) Data Store: UTFDataFormatException when using large minRecordLength
[ https://issues.apache.org/jira/browse/JCR-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594152#action_12594152 ] Thomas Mueller commented on JCR-1563: - we already have a procedure for detecting the type of the data Do you mean the property type? The listed types are not property types, it's always PropertyType.BINARY. I'm not sure if you read my comment above: That's true, it was a mistake to use writeUTF. I can try to change it to write the raw bytes in BundleBinding. Data using the new format will have the prefix '-3' (so far we have '-1' and '-2'). I will introduce constants for those magic numbers. However this change is more complex than simply capping minRecordLength to 32000. Data Store: UTFDataFormatException when using large minRecordLength --- Key: JCR-1563 URL: https://issues.apache.org/jira/browse/JCR-1563 Project: Jackrabbit Issue Type: Bug Reporter: Thomas Mueller Priority: Minor If using a value larger than 33000 for minRecordLength, and then trying to store a value with 33000 bytes, the following exception is thrown: UTFDataFormatException. The reason is that values are serialized using DataOutputStream.writeUTF. There is size limitation of 65 K when using this method. Small entries are hex encoded, and there is a prefix, so the limitation for minRecordLength should be 32000. This is a problem for both FileDataStore and DbDataStore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1180) DatabaseFileSystem and DatabasePersistenceManager don't allow choice of db schema
[ https://issues.apache.org/jira/browse/JCR-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-1180: --- Assignee: Thomas Mueller DatabaseFileSystem and DatabasePersistenceManager don't allow choice of db schema - Key: JCR-1180 URL: https://issues.apache.org/jira/browse/JCR-1180 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Environment: All Reporter: Kev Jackson Assignee: Thomas Mueller Priority: Minor Attachments: jackrabbit-core.patch I have a need to store my repository objects under a different db schema than the default for the rdbms (I'm using postgresql, so in my case the default is 'public') The current implementation of the DatabasePersistenceManager and DatabaseFileSystem do not support changing the schema. Problems: - schemaObjectPrefix allows the user to add a table prefix, but you cannot use this to set a schema ie schema.table, as the . is stripped out and replaced with an escaped version - schema param currently refers to a ddl resource, not what people would naturally think is the param to set the schema for the repository Fix: - rename the current schema - schemaDDL - add an optional schema param which allows the user to select which schema they want to use - improve error messages so that when an incorrect schemaDDL is chosen the user doesn't have to dig through nabble etc to find an answer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1570) [PATCH] better exception messages when generating schema
[ https://issues.apache.org/jira/browse/JCR-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-1570: --- Assignee: Thomas Mueller [PATCH] better exception messages when generating schema Key: JCR-1570 URL: https://issues.apache.org/jira/browse/JCR-1570 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: core 1.4.2 Reporter: Dave Brosius Assignee: Thomas Mueller Priority: Trivial Fix For: core 1.4.4 Attachments: better_schema_ex_messages.patch When a statement fails to execute generating the schema, patch outputs the statement that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
