Re: Smaller and Quicker Releases
Hi, > Think about Jackrabbit 1.4 and tell me how a better test suite would have > noticeably expedited the release? I didn't actually answer your question. Let me give you an example: "Refactor DBMS support for JNDI datasources": http://issues.apache.org/jira/browse/JCR-1309 This feature was very simple to implement, and it is committed in the trunk already. Unfortunately, it just missed the 1.4 'deadline'. Who wants to use it will have to wait for Jackrabbit 1.5 (unless they use 'nightlies', which is dangerous). Having a better test suite would allow shorter release cycles. If we had a two week release cycle, JCR-1309 would be available next week. Maybe this particular feature would still be marked 'experimental', but it would be included in a release. Regards, Thomas
Re: The Jackrabbit wiki is immutable
Hi, On Jan 28, 2008 10:49 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > I just say that the Jackrabbit wiki is now 'immutable' for me. I don't > remember having to log in to edit the wiki. Is this new? Is it going > to stay like that? http://wiki.apache.org/jackrabbit/FrontPage You've always had to register and login to edit the wiki. The "immutable" label is shown when you're not logged in. I guess your login cookie expired or some other change caused the login to be dropped. Just login again and you should have your write access back. BR, Jukka Zitting
The Jackrabbit wiki is immutable
Hi, I just say that the Jackrabbit wiki is now 'immutable' for me. I don't remember having to log in to edit the wiki. Is this new? Is it going to stay like that? http://wiki.apache.org/jackrabbit/FrontPage Regards, Thomas
Checkstyle improvements
Hi, As may have seen from the commit notifications, I've spent some time improving the Checkstyle conformance of Jackrabbit. I focused mostly on jackrabbit-core, where the Checkstyle warning count is now down from about 25k to just 250 issues. Most of the remaining warnings serve as good pointers for places where refactoring or additional documentation is needed. Use "mvn checkstyle:checkstyle" in jackrabbit-core to run Checkstyle with Maven. The report gets stored in target/site/checkstyle.html. BR, Jukka Zitting
Re: [continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR-RMI - Build Def: Jackrabbit build with Java 1.4
Hi, On Jan 28, 0008 12:55 PM, Jackrabbit Continuum <[EMAIL PROTECTED]> wrote: > Build statistics: > State: Failed Wohoo, it actually got through to this list! I'll check what's wrong... BR, Jukka Zitting
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR-RMI - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2135&projectId=8 Build statistics: State: Failed Previous State: Failed Started at: Mon 28 Jan 2008 17:22:07 + Finished at: Mon 28 Jan 2008 17:23:00 + Total time: 53s Build Trigger: Schedule Build Number: 111 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: Changed: jukka @ Mon 28 Jan 2008 16:56:15 + Comment: JCR-1343: Replace use of Xerces by JAXP to implement SAX DocumentHandler - Improved test case, previous one was throwing an NPE because of the null attributes argument to startElement() Files changed: /jackrabbit/trunk/jackrabbit-jcr-rmi/src/test/java/org/apache/jackrabbit/rmi/xml/ImportContentHandlerTest.java ( 615950 ) Dependencies Changes: org.apache.jackrabbit:jackrabbit-api:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 0 Failures: 0 Total time: 0.0
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR-RMI - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2154&projectId=8 Build statistics: State: Failed Previous State: Failed Started at: Mon 28 Jan 2008 18:21:39 + Finished at: Mon 28 Jan 2008 18:22:29 + Total time: 49s Build Trigger: Schedule Build Number: 111 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: No files changed Dependencies Changes: org.apache.jackrabbit:jackrabbit-api:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 22 Failures: 1 Total time: 1.027 Test Failures: ImportContentHandlerTest testImportContentHandler : junit.framework.AssertionFailedError junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.jackrabbit.rmi.xml.ImportContentHandlerTest.testImportContentHandler(ImportContentHandlerTest.java:45)
[jira] Commented: (JCR-876) ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
[
https://issues.apache.org/jira/browse/JCR-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563246#action_12563246
]
Sebastian Gomez commented on JCR-876:
-
Hi.
You face the same problem as I did. After using my patch it seems to work. It's
attatched to my issue, in case you want to use it:
https://issues.apache.org/jira/browse/JCR-1325
> ManageableCollectionUtil should not throw "unsupported" JcrMapping exception
>
>
> Key: JCR-876
> URL: https://issues.apache.org/jira/browse/JCR-876
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-ocm
> Environment: All
>Reporter: Dan Connelly
>
> Many times, the object model'd code cannot be altered for ocm.
> To avoid the "unsupported" exception in almost all such cases, use a
> delegating wrapper class to encapsulate a Collection.The wrapper class
> implements MaangeableCollection.
> Since delegation is a performance hit, make the test below the last resort
> for *object* conversion in the method:
> public static ManageableCollection getManageableCollection(Object object)
> Proposed "catchall" test and program action:
> if (object instanceof Collection) {
> return new ManageableCollectionImpl((Collection)object);
> }
--
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-1325) Problems mapping custom collections
[ https://issues.apache.org/jira/browse/JCR-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563243#action_12563243 ] sgomez edited comment on JCR-1325 at 1/28/08 10:48 AM: Added patch that resolves the issue. was (Author: sgomez): Patch that resolves the issue. > Problems mapping custom collections > --- > > Key: JCR-1325 > URL: https://issues.apache.org/jira/browse/JCR-1325 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Sebastian Gomez > Attachments: ManageableCollectionUtil.java.patch > > > When using a custom list that extends from java.util.AbstractList, > ManageableCollectionUtil.getManageableCollection raises a JcrMappingException > because it does not consider the custom list to be a java.util.List. This is > because it uses "if (object.getClass().equals(List.class))" instead of "if > (object instanceof List)". The same thing will probably happen when using a > custom Collection, a custom ArrayList, etc. This is the stack trace: > org.apache.jackrabbit.ocm.exception.JcrMappingException: Unsupported > collection > type : *** (MyCustomList class) > at > org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableColle > ctionUtil.getManageableCollection(ManageableCollectionUtil.java:153) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insertCollectionFields(ObjectConverterImpl.java:780) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:221) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:146) > at > org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.inser > t(ObjectContentManagerImpl.java:407) > I have come up to this bug using a MyCustomList, with MyCustomList > extending java.util.AbstractList. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1325) Problems mapping custom collections
[ https://issues.apache.org/jira/browse/JCR-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Gomez updated JCR-1325: - Comment: was deleted > Problems mapping custom collections > --- > > Key: JCR-1325 > URL: https://issues.apache.org/jira/browse/JCR-1325 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Sebastian Gomez > Attachments: ManageableCollectionUtil.java.patch > > > When using a custom list that extends from java.util.AbstractList, > ManageableCollectionUtil.getManageableCollection raises a JcrMappingException > because it does not consider the custom list to be a java.util.List. This is > because it uses "if (object.getClass().equals(List.class))" instead of "if > (object instanceof List)". The same thing will probably happen when using a > custom Collection, a custom ArrayList, etc. This is the stack trace: > org.apache.jackrabbit.ocm.exception.JcrMappingException: Unsupported > collection > type : *** (MyCustomList class) > at > org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableColle > ctionUtil.getManageableCollection(ManageableCollectionUtil.java:153) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insertCollectionFields(ObjectConverterImpl.java:780) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:221) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:146) > at > org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.inser > t(ObjectContentManagerImpl.java:407) > I have come up to this bug using a MyCustomList, with MyCustomList > extending java.util.AbstractList. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1325) Problems mapping custom collections
[ https://issues.apache.org/jira/browse/JCR-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Gomez updated JCR-1325: - Attachment: ManageableCollectionUtil.java.patch Patch that resolves the issue. > Problems mapping custom collections > --- > > Key: JCR-1325 > URL: https://issues.apache.org/jira/browse/JCR-1325 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Sebastian Gomez > Attachments: ManageableCollectionUtil.java.patch > > > When using a custom list that extends from java.util.AbstractList, > ManageableCollectionUtil.getManageableCollection raises a JcrMappingException > because it does not consider the custom list to be a java.util.List. This is > because it uses "if (object.getClass().equals(List.class))" instead of "if > (object instanceof List)". The same thing will probably happen when using a > custom Collection, a custom ArrayList, etc. This is the stack trace: > org.apache.jackrabbit.ocm.exception.JcrMappingException: Unsupported > collection > type : *** (MyCustomList class) > at > org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableColle > ctionUtil.getManageableCollection(ManageableCollectionUtil.java:153) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insertCollectionFields(ObjectConverterImpl.java:780) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:221) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:146) > at > org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.inser > t(ObjectContentManagerImpl.java:407) > I have come up to this bug using a MyCustomList, with MyCustomList > extending java.util.AbstractList. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1325) Problems mapping custom collections
[ https://issues.apache.org/jira/browse/JCR-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Gomez updated JCR-1325: - Attachment: (was: ManageableCollectionUtil.java.patch) > Problems mapping custom collections > --- > > Key: JCR-1325 > URL: https://issues.apache.org/jira/browse/JCR-1325 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Sebastian Gomez > > When using a custom list that extends from java.util.AbstractList, > ManageableCollectionUtil.getManageableCollection raises a JcrMappingException > because it does not consider the custom list to be a java.util.List. This is > because it uses "if (object.getClass().equals(List.class))" instead of "if > (object instanceof List)". The same thing will probably happen when using a > custom Collection, a custom ArrayList, etc. This is the stack trace: > org.apache.jackrabbit.ocm.exception.JcrMappingException: Unsupported > collection > type : *** (MyCustomList class) > at > org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableColle > ctionUtil.getManageableCollection(ManageableCollectionUtil.java:153) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insertCollectionFields(ObjectConverterImpl.java:780) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:221) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:146) > at > org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.inser > t(ObjectContentManagerImpl.java:407) > I have come up to this bug using a MyCustomList, with MyCustomList > extending java.util.AbstractList. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1350) Add a serializing content handler
Add a serializing content handler - Key: JCR-1350 URL: https://issues.apache.org/jira/browse/JCR-1350 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons, xml Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 1.5 Both JCR-1310 and JCR-1343 need XML serialization functionality and we've also previously (JCR-367, JCR-1086) implemented something similar. It would be good to centralize such code, and so I'd like to use the already referenced code from Cocoon [1] as the basis for a SerializingContentHandler class in jackrabbit-jcr-commons. [1] https://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/serialization/AbstractTextSerializer.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR-RMI - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2142&projectId=8 Build statistics: State: Failed Previous State: Failed Started at: Mon 28 Jan 2008 17:30:40 + Finished at: Mon 28 Jan 2008 17:31:16 + Total time: 36s Build Trigger: Forced Build Number: 111 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: Changed: jukka @ Mon 28 Jan 2008 17:26:20 + Comment: JCR-1343: Replace use of Xerces by JAXP to implement SAX DocumentHandler - Bugger, no Java 5 methods... Files changed: /jackrabbit/trunk/jackrabbit-jcr-rmi/src/test/java/org/apache/jackrabbit/rmi/xml/ImportContentHandlerTest.java ( 615962 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 22 Failures: 1 Total time: 0.773 Test Failures: ImportContentHandlerTest testImportContentHandler : junit.framework.AssertionFailedError junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.jackrabbit.rmi.xml.ImportContentHandlerTest.testImportContentHandler(ImportContentHandlerTest.java:45)
[jira] Updated: (JCR-1322) Cluster information is not persisted to database when connected to case sensitive MS SQL Server 2005
[
https://issues.apache.org/jira/browse/JCR-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijai Kalyan updated JCR-1322:
--
Affects Version/s: (was: 1.3.3)
1.4
You are correct. The revision number should be 1.4. Our local version is 1.3.3
patched with the various changes.
I am referring to the following lines in DatabaseJournal.java
(http://svn.apache.org/repos/asf/jackrabbit/tags/1.4/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/journal/DatabaseJournal.java)
updateGlobalStmtSQL =
"update " + schemaObjectPrefix + "GLOBAL_REVISION " +
"set revision_id = revision_id + 1";
selectGlobalStmtSQL =
"select revision_id " +
Note the lower case column names for 'revision_id'. These are created in upper
case however.
> Cluster information is not persisted to database when connected to case
> sensitive MS SQL Server 2005
>
>
> Key: JCR-1322
> URL: https://issues.apache.org/jira/browse/JCR-1322
> Project: Jackrabbit
> Issue Type: Bug
> Components: clustering
>Affects Versions: 1.4
> Environment: Microsoft SQL Server 2005 on Windows Server. Database is
> setup to be case-sensitive.
>Reporter: Vijai Kalyan
>
> After a call to Session::save, we observed that cluster information was not
> written to the ${schemaObjectPrefix}JOURNAL and
> ${schemaObjectPrefix}GLOBAL_REVISION tables. We tested against Oracle 10
> database servers and MS Sql Server 2005 servers. The problem was noticed only
> with MS Sql Server 2005.
> Initially, the problem was masked since the test was written as part of our
> unit test environment and the exceptions generated by JDBC were not showing
> up in the logs. A separate test with was carried out as shown by the code
> below
>
> import java.io.FileInputStream;
> import javax.jcr.Node;
> import javax.jcr.Repository;
> import javax.jcr.Session;
> import javax.jcr.SimpleCredentials;
> import org.apache.jackrabbit.core.TransientRepository;
> import org.apache.jackrabbit.core.config.RepositoryConfig;
> public class Main
> {
> public static void main(String[] args)
> throws Exception
> {
> System.setProperty("org.apache.jackrabbit.core.cluster.node_id",
> "testid");
>
> RepositoryConfig config = RepositoryConfig.create(new
> FileInputStream("repository.xml"), "repository");
>
> Repository repository = new TransientRepository();
>
> Session session = repository.login(new SimpleCredentials("username",
> "password".toCharArray()));
>
> Node root = session.getRootNode();
>
> root.addNode("node1");
> root.addNode("node2");
> root.addNode("node3");
>
> session.save();
> }
> }
>
> The configuration file used to configure the repository is attached.
> After debugging this, we obtained the exceptions that were previously not
> visible. Note that, JackRabbit continues to run (is that because the cluster
> code is running in a separate thread?) even after this exception. The problem
> was that the 'revision_id' field did not exist. The mssql.ddl schema file
> sets up the table names in capitals. However, at least two of the SQL
> statements in DatabaseJournal use lower case table names. For example:-
>
> updateGlobalStmt = con.prepareStatement(
> "update " + schemaObjectPrefix + "global_revision " +
> "set revision_id = revision_id + 1");
> selectGlobalStmt = con.prepareStatement(
> "select revision_id " +
> "from " + schemaObjectPrefix + "global_revision");
>
> An additional error is that the mssql.ddl file is missing the following:
>
> # Inserting the one and only revision counter record now helps avoiding race
> conditions
> insert into ${schemaObjectPrefix}GLOBAL_REVISION VALUES(0)
>
> Fixing the above two issues, fixed the problem with MS SQL Server 2005.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1325) Problems mapping custom collections
[ https://issues.apache.org/jira/browse/JCR-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Gomez updated JCR-1325: - Attachment: ManageableCollectionUtil.java.patch Patch that resolves the issue > Problems mapping custom collections > --- > > Key: JCR-1325 > URL: https://issues.apache.org/jira/browse/JCR-1325 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Sebastian Gomez > > When using a custom list that extends from java.util.AbstractList, > ManageableCollectionUtil.getManageableCollection raises a JcrMappingException > because it does not consider the custom list to be a java.util.List. This is > because it uses "if (object.getClass().equals(List.class))" instead of "if > (object instanceof List)". The same thing will probably happen when using a > custom Collection, a custom ArrayList, etc. This is the stack trace: > org.apache.jackrabbit.ocm.exception.JcrMappingException: Unsupported > collection > type : *** (MyCustomList class) > at > org.apache.jackrabbit.ocm.manager.collectionconverter.ManageableColle > ctionUtil.getManageableCollection(ManageableCollectionUtil.java:153) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insertCollectionFields(ObjectConverterImpl.java:780) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:221) > at > org.apache.jackrabbit.ocm.manager.objectconverter.impl.ObjectConverte > rImpl.insert(ObjectConverterImpl.java:146) > at > org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.inser > t(ObjectContentManagerImpl.java:407) > I have come up to this bug using a MyCustomList, with MyCustomList > extending java.util.AbstractList. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1316) ID Field Descriptor is not inherited as is the case with UUID Field Descriptor
[ https://issues.apache.org/jira/browse/JCR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1316. - Resolution: Fixed Fix Version/s: (was: 1.4.1) 1.5 Patch is applied. Thanks > ID Field Descriptor is not inherited as is the case with UUID Field Descriptor > -- > > Key: JCR-1316 > URL: https://issues.apache.org/jira/browse/JCR-1316 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Nimesh Muley >Assignee: Christophe Lombart > Fix For: 1.5 > > Attachments: InheritedIDFieldDescriptor.patch > > > ID Field descriptor when defined in the base class in jcr-mapping is not > inherited. The child class also has to define it again. A patch for the same > is attached herewith. Patch is on similar lines of UUID Field Descriptor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1343) Replace xerces for serialization by JAXP
[ https://issues.apache.org/jira/browse/JCR-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1343. Resolution: Fixed Resolved the namespace declaration issue in revision 616082 by leveraging the new SerializingContentHandler class from JCR-1350. > Replace xerces for serialization by JAXP > > > Key: JCR-1343 > URL: https://issues.apache.org/jira/browse/JCR-1343 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-jcr-rmi >Affects Versions: 1.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 1.5 > > > The org.apache.jackrabbit.rmi.xml.ImportContentHandler class currently uses > Xerces to implement the SAX DocumentHandler and serialize XML into a byte[]. > This dependency should be dropped and JAXP be used instead for this > functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1316) ID Field Descriptor is not inherited as is the case with UUID Field Descriptor
[ https://issues.apache.org/jira/browse/JCR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1316: --- Assignee: Christophe Lombart > ID Field Descriptor is not inherited as is the case with UUID Field Descriptor > -- > > Key: JCR-1316 > URL: https://issues.apache.org/jira/browse/JCR-1316 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Nimesh Muley >Assignee: Christophe Lombart > Fix For: 1.4.1 > > Attachments: InheritedIDFieldDescriptor.patch > > > ID Field descriptor when defined in the base class in jcr-mapping is not > inherited. The child class also has to define it again. A patch for the same > is attached herewith. Patch is on similar lines of UUID Field Descriptor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-873) JCR Mapping Documentation
[ https://issues.apache.org/jira/browse/JCR-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-873: -- Assignee: Christophe Lombart > JCR Mapping Documentation > - > > Key: JCR-873 > URL: https://issues.apache.org/jira/browse/JCR-873 > Project: Jackrabbit > Issue Type: Task > Components: jackrabbit-ocm >Reporter: Christophe Lombart >Assignee: Christophe Lombart > > Add documentation and tutorial on JCR Mapping : > - API Overview > - Map simple fields > - Map bean fields > - Map collection > - How to mofigy the Collection mapping strategy > - Use any kind of Collection with the ManageableCollections > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR to SPI - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2184&projectId=17 Build statistics: State: Failed Previous State: Ok Started at: Mon 28 Jan 2008 23:17:24 + Finished at: Mon 28 Jan 2008 23:19:28 + Total time: 2m 3s Build Trigger: Schedule Build Number: 83 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: No files changed Dependencies Changes: org.apache.jackrabbit:jackrabbit-spi:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-tests:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi2jcr:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-rmi:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 1347 Failures: 0 Total time: 98.89099
[jira] Resolved: (JCR-1350) Add a serializing content handler
[ https://issues.apache.org/jira/browse/JCR-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1350. Resolution: Fixed Resolved in revision 616030. > Add a serializing content handler > - > > Key: JCR-1350 > URL: https://issues.apache.org/jira/browse/JCR-1350 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-jcr-commons, xml >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > > Both JCR-1310 and JCR-1343 need XML serialization functionality and we've > also previously (JCR-367, JCR-1086) implemented something similar. > It would be good to centralize such code, and so I'd like to use the already > referenced code from Cocoon [1] as the basis for a SerializingContentHandler > class in jackrabbit-jcr-commons. > [1] > https://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-impl/src/main/java/org/apache/cocoon/serialization/AbstractTextSerializer.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit Core - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2177&projectId=6 Build statistics: State: Failed Previous State: Ok Started at: Mon 28 Jan 2008 23:10:03 + Finished at: Mon 28 Jan 2008 23:13:18 + Total time: 3m 14s Build Trigger: Schedule Build Number: 106 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: No files changed Dependencies Changes: org.apache.jackrabbit:jackrabbit-api:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-text-extractors:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-tests:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 1264 Failures: 0 Total time: 125.256
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit Core - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2195&projectId=6 Build statistics: State: Failed Previous State: Failed Started at: Tue 29 Jan 2008 00:12:41 + Finished at: Tue 29 Jan 2008 00:18:05 + Total time: 5m 24s Build Trigger: Schedule Build Number: 106 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: No files changed Dependencies Changes: org.apache.jackrabbit:jackrabbit-api:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-text-extractors:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-tests:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 1264 Failures: 0 Total time: 128.762
[continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR to SPI - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=2202&projectId=17 Build statistics: State: Failed Previous State: Failed Started at: Tue 29 Jan 2008 00:23:07 + Finished at: Tue 29 Jan 2008 00:25:43 + Total time: 2m 35s Build Trigger: Schedule Build Number: 83 Exit code: 1 Building machine hostname: jackrabbit.zones Operating system : SunOS(unknown) Java Home version : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_06 OS name: "sunos" version: "5.10" arch: "x86" SCM Changes: No files changed Dependencies Changes: org.apache.jackrabbit:jackrabbit-spi:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-tests:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-spi2jcr:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit-jcr-rmi:1.5-SNAPSHOT org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode --non-recursive -DuniqueVersion=false Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4 Description: Jackrabbit build with Java 1.4 Test Summary: Tests: 1347 Failures: 0 Total time: 126.560005
