Jackrabbit trunk is now 1.5-SNAPSHOT
Hi, After branching 1.4 yesterday, I have now (revision 608821) updated the Jackrabbit trunk version number to 1.5-SNAPSHOT. BR, Jukka Zitting
[jira] Resolved: (JCR-1226) ServerQuery does not use RemoteAdapterFactory for creating ServerQueryResult
[
https://issues.apache.org/jira/browse/JCR-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-1226.
Resolution: Fixed
Fixed as suggested in revision 608836. Merged to the 1.4 branch in revision
608837.
ServerQuery does not use RemoteAdapterFactory for creating ServerQueryResult
Key: JCR-1226
URL: https://issues.apache.org/jira/browse/JCR-1226
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-jcr-rmi
Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3,
1.3.1, 1.3.3
Reporter: Vladimir Bayanov
Assignee: Jukka Zitting
Priority: Minor
Fix For: 1.4
The ServerQuery sould use the Factory for creating ServerQueryResult.
Siehe the method ServerQuery.execute():
{code}
public RemoteQueryResult execute() throws RepositoryException,
RemoteException {
return new ServerQueryResult(query.execute(), getFactory());
}
{code}
it should be:
{code}
public RemoteQueryResult execute() throws RepositoryException,
RemoteException {
return getFactory().getRemoteQueryResult(this.query.execute());
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1289) Error reporting page for jackrabbit-webapp
Error reporting page for jackrabbit-webapp -- Key: JCR-1289 URL: https://issues.apache.org/jira/browse/JCR-1289 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-webapp Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor The Jackrabbit webapp should have an error reporting page that would help users collect all relevant environment and log information for inclusion in bug reports. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1226) ServerQuery does not use RemoteAdapterFactory for creating ServerQueryResult
[
https://issues.apache.org/jira/browse/JCR-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-1226:
---
Fix Version/s: 1.4
Assignee: Jukka Zitting
Priority: Minor (was: Major)
Affects Version/s: 0.9
1.0
1.0.1
1.1
1.1.1
1.2.1
1.2.2
1.2.3
1.3.1
1.3.3
ServerQuery does not use RemoteAdapterFactory for creating ServerQueryResult
Key: JCR-1226
URL: https://issues.apache.org/jira/browse/JCR-1226
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-jcr-rmi
Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3,
1.3.1, 1.3.3
Reporter: Vladimir Bayanov
Assignee: Jukka Zitting
Priority: Minor
Fix For: 1.4
The ServerQuery sould use the Factory for creating ServerQueryResult.
Siehe the method ServerQuery.execute():
{code}
public RemoteQueryResult execute() throws RepositoryException,
RemoteException {
return new ServerQueryResult(query.execute(), getFactory());
}
{code}
it should be:
{code}
public RemoteQueryResult execute() throws RepositoryException,
RemoteException {
return getFactory().getRemoteQueryResult(this.query.execute());
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Utility code for filtering and packaging trees [JCR-1259]
Hi, On Jan 4, 2008 9:40 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: I've updated the patch according to your suggestions. WDYT? Looks better, thanks. I was thinking of including the code to jackrabbit-jcr-commons. Would you care to do a patch against the latest trunk (I'll take care of merging it to 1.4)? Also, I think it would be better to rename the filtering packages and classes as follows: org.apache.jackrabbit.commons.predicate NamePredicate IsNodePredicate ... org.apache.jackrabbit.commons.visitor FilteringItemVisitor I would also turn the DepthItemFilter base class into a standalone DepthPredicate that could be combined (composition over inheritance) with other predicates. If you agree, I can also take care of these changes. BR, Jukka Zitting
[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages
[ https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1043: --- Component/s: (was: jackrabbit-ocm) Priority: Minor (was: Blocker) Affects Version/s: (was: 1.3) Package names for spring project do not match update ocm packages - Key: JCR-1043 URL: https://issues.apache.org/jira/browse/JCR-1043 Project: Jackrabbit Issue Type: Bug Environment: All environments Reporter: Padraic Hannon Assignee: Christophe Lombart Priority: Minor Attachments: spring-mvn2.patch, spring.patch The spring package and tests reference the old graffitto package naming scheme. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Utility code for filtering and packaging trees [JCR-1259]
Jukka Zitting wrote: Looks better, thanks. :) I was thinking of including the code to jackrabbit-jcr-commons. Would you care to do a patch against the latest trunk (I'll take care of merging it to 1.4)? Also, I think it would be better to rename the filtering packages and classes as follows: org.apache.jackrabbit.commons.predicate NamePredicate IsNodePredicate ... org.apache.jackrabbit.commons.visitor FilteringItemVisitor I would also turn the DepthItemFilter base class into a standalone DepthPredicate that could be combined (composition over inheritance) with other predicates. If you agree, I can also take care of these changes. Oh, yes, I forgot to change the package names :( I think the only problem with directly putting it into jcr commons is the junit test which starts the repository for testing. But apart from that, I'm +1 on your suggestion :) Now, it would be great if you could do this - if not, I'll come up with a new patch next week. Many thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Resolved: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1218. Resolution: Won't Fix The RepositoryUtil class is IMHO outside the scope of OCM, and thus shouldn't be included in src/main. Resolving this as Won't Fix. RepositoryUtil moved outside of main source tree Key: JCR-1218 URL: https://issues.apache.org/jira/browse/JCR-1218 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.3.3 Reporter: Padraic Hannon Priority: Blocker Attachments: move-repositoryutil.patch It appears that the RepositoryUtil class was moved from src/main to src/test. This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reopened JCR-1218: The issue is not to _add_ RepositoryUtil to src/main but to remove it, because we all agree, that it does not belong there :-) RepositoryUtil moved outside of main source tree Key: JCR-1218 URL: https://issues.apache.org/jira/browse/JCR-1218 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.3.3 Reporter: Padraic Hannon Priority: Blocker Fix For: 1.4 Attachments: move-repositoryutil.patch It appears that the RepositoryUtil class was moved from src/main to src/test. This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed JCR-1218. -- Resolution: Fixed Fix Version/s: 1.4 Assignee: Christophe Lombart Actually, this has been done by Christophe (therefore I assign this issue to him) in Rev. 578997. So I close this issue fixed. RepositoryUtil moved outside of main source tree Key: JCR-1218 URL: https://issues.apache.org/jira/browse/JCR-1218 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.3.3 Reporter: Padraic Hannon Assignee: Christophe Lombart Priority: Blocker Fix For: 1.4 Attachments: move-repositoryutil.patch It appears that the RepositoryUtil class was moved from src/main to src/test. This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1218) RepositoryUtil moved outside of main source tree
[ https://issues.apache.org/jira/browse/JCR-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555994#action_12555994 ] Padraic Hannon commented on JCR-1218: - The problem with there is that the spring part of the ocm project relies on the repository util class. If we do not want this class to exist we need to refactor the spring code and then remove it. RepositoryUtil moved outside of main source tree Key: JCR-1218 URL: https://issues.apache.org/jira/browse/JCR-1218 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.3.3 Reporter: Padraic Hannon Assignee: Christophe Lombart Priority: Blocker Fix For: 1.4 Attachments: move-repositoryutil.patch It appears that the RepositoryUtil class was moved from src/main to src/test. This class is used by the ocm-spring project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
QueryRootNode constructor
Hi all. I was wandering why the QueryRootNode was made protected, instead of public like it used to be. In our application we have our own LuceneQueryProvider that contains a QueryRootNode field, but this doesn't work anymore with 1.4. How can I work around this? Regards, Esteban Franqueiro [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
