[OCM] reorganise the subproject
Hi all, This week, I would like to reorganise the OCM contrib project (see http://www.mail-archive.com/dev@jackrabbit.apache.org/msg07554.html). Is it ok for everybody ? br, Christophe
[jira] Assigned: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
[
https://issues.apache.org/jira/browse/JCR-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned JCR-1099:
---
Assignee: Julian Reschke (was: angela)
> jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
>
>
> Key: JCR-1099
> URL: https://issues.apache.org/jira/browse/JCR-1099
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
>Reporter: David Rauschenbach
>Assignee: Julian Reschke
> Attachments: repository.xml
>
>
> The jcr2spi NodeEntryImpl class contains logic that causes getIndex() to call
> itself.
> Calling code:
> Session sess = repo.login(creds);
> Node inboxNode = sess.getRootNode().getNode("Inbox");
> inboxNode.getPath(); <== blows stack
> Tracing reveals:
> 1. NodeEntryImpl.getPath() ultimately calls getIndex()
> 2. getIndex() calls NodeState.getDefinition()
> 3. which calls ItemDefinitionProviderImpl.getQNodeDefinition(...)
> 4. which catches a RepositoryException then calls
> NodeEntryImpl.getWorkspaceId()
> 5. which calls NodeEntryImpl.getWorkspaceIndex()
> 6. which calls getIndex() (back to step 2, ad infinitum)
> Configuration:
> 1. A configuration is loaded specifying in-memory persist manager
> 2. Config is wrapped in TransientRepository
> 3. that's wrapped in spi2jcr's RepositoryService using default
> BatchReadConfig
> 4. a jcr2spi provider is instantiated that directly couples to spi2jcr
> 5. Node in question is created as follows:
> Session sess = repo.login(creds);
> sess.getRootNode().addNode("Inbox", "nt:folder");
> sess.save();
> I guess that's about it.
> David
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
[
https://issues.apache.org/jira/browse/JCR-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-1099:
Assignee: (was: Julian Reschke)
OK, the problem can be relatively easily reproduced by changing
ItemDefinitionProviderImpl.getQNodeDefinition() to
public QNodeDefinition getQNodeDefinition(NodeState nodeState) throws
RepositoryException {
if (nodeState.getHierarchyEntry().getParent() == null) {
return getRootNodeDefinition();
}
QNodeDefinition definition;
try {
// TEST
throw new ConstraintViolationException();
} catch (RepositoryException e) {
definition = service.getNodeDefinition(sessionInfo,
nodeState.getNodeEntry().getWorkspaceId());
} catch (NodeTypeConflictException e) {
definition = service.getNodeDefinition(sessionInfo,
nodeState.getNodeEntry().getWorkspaceId());
}
return definition;
}
I think we need to fix this, but I'm not sure where in the recursion the fix
needs to take place.
> jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
>
>
> Key: JCR-1099
> URL: https://issues.apache.org/jira/browse/JCR-1099
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
>Reporter: David Rauschenbach
> Attachments: repository.xml
>
>
> The jcr2spi NodeEntryImpl class contains logic that causes getIndex() to call
> itself.
> Calling code:
> Session sess = repo.login(creds);
> Node inboxNode = sess.getRootNode().getNode("Inbox");
> inboxNode.getPath(); <== blows stack
> Tracing reveals:
> 1. NodeEntryImpl.getPath() ultimately calls getIndex()
> 2. getIndex() calls NodeState.getDefinition()
> 3. which calls ItemDefinitionProviderImpl.getQNodeDefinition(...)
> 4. which catches a RepositoryException then calls
> NodeEntryImpl.getWorkspaceId()
> 5. which calls NodeEntryImpl.getWorkspaceIndex()
> 6. which calls getIndex() (back to step 2, ad infinitum)
> Configuration:
> 1. A configuration is loaded specifying in-memory persist manager
> 2. Config is wrapped in TransientRepository
> 3. that's wrapped in spi2jcr's RepositoryService using default
> BatchReadConfig
> 4. a jcr2spi provider is instantiated that directly couples to spi2jcr
> 5. Node in question is created as follows:
> Session sess = repo.login(creds);
> sess.getRootNode().addNode("Inbox", "nt:folder");
> sess.save();
> I guess that's about it.
> David
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen reopened JCR-953: Doesn't quite work yet, because SessionXAResource is not available remotely. Will provide easy and small fix in next attached patch. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: (was: test.zip) > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: patch Minor patch to earlier changes, as the ServerXAResource needs to be a remote object. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen updated JCR-953: --- Attachment: test.zip Changes to test application to take into account that the XASession has been moved to JackRabbit API iso. core jar. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526142 ] Berry van Halderen commented on JCR-953: I think that my minor patch from earlier today can be applied without modifications. I've tested with the test application and then it seems to work fine. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
(JCR-905) Clustering: race condition may cause duplicate entries in search index
Does anyone is interested to collaborate in solving this bug? To use cluster in a production environment is very important to solve that, 'cause duplicated nodes aren't a good behaviour. Any suggestion or help is very pleased. Thanks in advance to all. -- View this message in context: http://www.nabble.com/%28JCR-905%29-Clustering%3A-race-condition-may-cause-duplicate-entries-in-search-index-tf4414118.html#a12591434 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] Created: (JCR-1117) Bundle cache is not rolled back when the storage of a ChangeLog fails
Bundle cache is not rolled back when the storage of a ChangeLog fails - Key: JCR-1117 URL: https://issues.apache.org/jira/browse/JCR-1117 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Reporter: Martijn Hendriks The bundle cache in the bundle persistence managers is not restored to its old state when the AbstractBundlePersistenceManager.store(ChangeLog changeLog) method throws an exception. If, for instance, the storage of references fails then the AbstractBundlePersistenceManager.putBundle(NodePropBundle bundle) method has already been called for all modified bundles. Because of the connection rollback, the bundle cache will be out-of-sync with the persistent state. The SharedItemStateManager$Update.cancel() method uses these invalid bundle data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OCM] reorganise the subproject
Hi, On 9/10/07, Christophe Lombart <[EMAIL PROTECTED]> wrote: > This week, I would like to reorganise the OCM contrib project (see > http://www.mail-archive.com/dev@jackrabbit.apache.org/msg07554.html). > Is it ok for everybody ? +1 Please go ahead. I had some thoughts on your previous message, but I've been quite busy travelling the last few days so I didn't yet have time to respond. BR, Jukka Zitting
Re: [OCM] reorganise the subproject
+1 Regards Felix Am Montag, den 10.09.2007, 11:33 +0200 schrieb Christophe Lombart: > Hi all, > > This week, I would like to reorganise the OCM contrib project (see > http://www.mail-archive.com/dev@jackrabbit.apache.org/msg07554.html). > Is it ok for everybody ? > > br, > Christophe
Re: [OCM] Reorganize the contrib
Hi, On 9/5/07, Christophe Lombart <[EMAIL PROTECTED]> wrote: > Following the issue on the jackrabbit core dependency ( > http://issues.apache.org/jira/browse/JCR-1115) and seeing other dependency > issues, I would like to reorganize the OCM contrib. Sounds good. Would you mind doing JCR-995 (moving the core part outside contrib) as well while you're at it? > Is it make sense for you if we reorganize the ocm contrib with the following > subprojects : > 1/ core ( now called jcr-mapping). How about calling it jackrabbit-ocm or jackrabbit-jcr-ocm for consistency with the other release subprojects? > 2/ mapper (which will contains different subprojects / one per Mapper impl > (digester, annotation, ...) Do we need to have the different mapper implementations in separate subprojects? If they don't add too much overhead (complexity, extra dependencies, etc.) then I'd keep them inside the core project just like we keep a number of alternative persistence managers within jackrabbit-core. > 3/ nodemanagement (now called jcr-nodemanagement). It will contains > different subprojects / one per JCR repo impl. Note that we may want to encourage other repository implementations to host their own extension components. For example we can't do Alfresco extensions due to the license mismatch. > Last point, I would like to use the same unit tests for the different mapper > impl. I don't want to write duplicate unit tests. I don't know how we can > avoid this situation. still thinking about that ... Something like jackrabbit-jcr-tests? Or simply you put all mapper implementations inside the core project as suggested above. BR, Jukka Zitting
[jira] Resolved: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-953. --- Resolution: Fixed Ah, obviously! Thanks for the tip, fixed in revision 574273. I made ServerXAResource extend UnicastRemoteObject directly instead of through ServerObject since it doesn't need to instantiated new adapters or throw RepositoryExceptions. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berry van Halderen closed JCR-953. -- Verified, works. Thanks a bunch. > Support for transactions when using JCR over RMI. > - > > Key: JCR-953 > URL: https://issues.apache.org/jira/browse/JCR-953 > Project: Jackrabbit > Issue Type: Improvement > Components: rmi >Reporter: Berry van Halderen >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: patch, patch, test.zip > > > At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory > do not implement the methods for the XASession. Therefor the RMI access > layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-912) OverlappingFileLockException with JRE 1.6
[
https://issues.apache.org/jira/browse/JCR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526186
]
Stefan Guggisberg commented on JCR-912:
---
steve:
please note that this issue refers to the fact that
java.nio.channels.OverlappingFileLockException was not caught in jackrabbit <
1.3.1.
this has been fixed in 1.3.1.
however, your 'error' indicates that the specified repository home is already
in use, i.e. there's already a Jackrabbit instance running in the same home
directory. that's a legitimate error condition and not a bug.
> OverlappingFileLockException with JRE 1.6
> -
>
> Key: JCR-912
> URL: https://issues.apache.org/jira/browse/JCR-912
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3
> Environment: Linux + Java6; however, per
> http://blogs.sun.com/DaveB/date/200612, this may be a problem on all Java6
> platforms
>Reporter: Patrick Haggood
>Assignee: Stefan Guggisberg
> Fix For: 1.3.1
>
>
> Per email discussion:
> On Mon, 2007-02-26 at 10:26 +0100, Marcel Reutegger wrote:
> > > just my 2c, I didn't really investigated this issue in more detail...
> > >
> > > according to the javadoc of FileChannel.tryLock() the
> > > OverlappingFileLockException is thrown if the JVM already holds a lock on
> > > the
> > > channel.
> > >
> > > in contrast, the current check in the repository startup method primarily
> > > focuses on the situation where *two* JVMs start a repository on the same
> > > home
> > > directory.
> > >
> > > I'd say the OverlappingFileLockException is thrown because two repository
> > > instances are startup within the *same* JVM using the same repository home
> > > directory.
> > >
> > > I suggest we add a catch clause, which also covers
> > > OverlappingFileLockException
> > > in addition to IOException.
> > >
> > > regards
> > > marcel
> > >
> > > Stefan Guggisberg wrote:
> > > > btw, afaik OverlappingFileLockException is only thrown on linux,
> > > > FileChannel#getLock on windows e.g. returns null in the same situation.
> > > >
> > > > you might want to test on a different platform to further isolate the
> > > > issue.
> > > > you could also place a breakpoint at the top of the
> > > > RepositoryImpl#acquireRepositoryLock
> > > > method, step through the code, verify the contents of your fs etc.
> > >
> >
> === Original email
> On 2/19/07, Patrick Haggood wrote:
> I'm using Linux, Sun Java 6 and Jackrabbit 1.3 with Derby persistance.
> I have a putNode(object) function that's giving the above error in unit
> tests. It always fails after the second update, even when I swap tests
> (i.e. save user doc then save user). Prior to each test, I delete the
> repository directory.
> Do I need to set explicit locks before/after each session.save()?
> *** Unit Test
> DBConn dbc;
> public SessionUtilTest(String testName) {
> super(testName);
> dbc = new DBConn();
> }
> // Note - putUser and putDocument both use putNode after determining
> which rootnode will be used
>/**
> * Test of putUnityUser method, of class unityjsr170.jr.SessionUtil.
> */
> public void testPutUnityUser() {
> System.out.println("putUnityUser");
> UnityUser usr = usr1;
> SessionUtil instance = dbc.getSutil();
> String result = instance.putUnityUser(usr1);
> assertNotNull(result);
> usr = (UnityUser) instance.getUnityUserByID(result);
> assertEquals(usr1.getName(),usr.getName());
> }
>
> /**
> * Test of putUnityDocument method, of class
> unityjsr170.jr.SessionUtil.
> */
> public void testPutUnityDocument() {
> System.out.println("putUnityDocument");
> UnityDocument udoc = adr1;
> SessionUtil instance = dbc.getSutil();
> String result = instance.putUnityDocument(udoc); < File
> Lock Error
> assertNotNull(result);
> udoc = (UnityDocument) instance.getUnityDocumentByID(result);
> assertEquals(adr1.getName(),udoc.getName());
> }
> * Here's where I setup my repository connection
> public DBConn(){
> sutil = null;
> try {
> rp = new TransientRepository();
> sutil= new SessionUtil(rp);
> } catch (IOException ex) {
> ex.printStackTrace();
> }
> }
>
> public void shutdown(){
> sutil.closeAll();
> }
>
> public SessionUtil getSutil(){
> return sutil;
> }
> SessionUtil
> public SessionUtil(Repository rp){
> try {
> session = rp.login(new
> SimpleCredentials("username","password".toCharArray()));
>
> } catch (LoginException ex) {
> ex.printStackTrace();
> }
[jira] Commented: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
[
https://issues.apache.org/jira/browse/JCR-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526314
]
David Rauschenbach commented on JCR-1099:
-
I have identified and resolved the trigger of this problem. In my SPI, my
NodeTypeDefinition "propertyDefs" were not being populated.
Fixing this bug is not a pressing issue for me now, and could probably be a low
priority, since it is now only a matter of defensive programming, and
preventing bad data from crashing the JVM, and also an issue of the stack
overflow obscuring and complicating the problem solving process.
Thx again, Angela and Julian.
> jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
>
>
> Key: JCR-1099
> URL: https://issues.apache.org/jira/browse/JCR-1099
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
>Reporter: David Rauschenbach
> Attachments: repository.xml
>
>
> The jcr2spi NodeEntryImpl class contains logic that causes getIndex() to call
> itself.
> Calling code:
> Session sess = repo.login(creds);
> Node inboxNode = sess.getRootNode().getNode("Inbox");
> inboxNode.getPath(); <== blows stack
> Tracing reveals:
> 1. NodeEntryImpl.getPath() ultimately calls getIndex()
> 2. getIndex() calls NodeState.getDefinition()
> 3. which calls ItemDefinitionProviderImpl.getQNodeDefinition(...)
> 4. which catches a RepositoryException then calls
> NodeEntryImpl.getWorkspaceId()
> 5. which calls NodeEntryImpl.getWorkspaceIndex()
> 6. which calls getIndex() (back to step 2, ad infinitum)
> Configuration:
> 1. A configuration is loaded specifying in-memory persist manager
> 2. Config is wrapped in TransientRepository
> 3. that's wrapped in spi2jcr's RepositoryService using default
> BatchReadConfig
> 4. a jcr2spi provider is instantiated that directly couples to spi2jcr
> 5. Node in question is created as follows:
> Session sess = repo.login(creds);
> sess.getRootNode().addNode("Inbox", "nt:folder");
> sess.save();
> I guess that's about it.
> David
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: master plan for jsr 283 query implementation
Marcel Reutegger wrote: well, those are actually just my thoughts how I think we should implement the query enhancements specified in JSR 283. there are basically three major blocks that we need to implement: - JQOM, allows you to programmatically create a query - JCR-SQL2, the new SQL query syntax - additional query features (joins, etc.) In a first step I already introduced temporary interfaces for the JQOM and implementing classes. I'd like to keep the current design of the query sub system for a while until we are ready to switch to the new JQOM as the basis for syntax independent query representation. That is, in a first phase my suggestion is the following: XPath---+ +--->AQT+ SQL-+ +>LuceneQuery | SQL2--->JQOM+ AQT: abstract query tree And once the path SQL2->JQOM->LuceneQuery is stable: XPath---+ AQT (deprecated) | SQL-+>JQOM->LuceneQuery | SQL2+ Comments and suggestions are welcome. +1. Sounds reasonable. Do you want to use javacc for SQL2 parsing? Cheers, Christoph
Re: master plan for jsr 283 query implementation
Christoph Kiehl wrote: Marcel Reutegger wrote: well, those are actually just my thoughts how I think we should implement the query enhancements specified in JSR 283. there are basically three major blocks that we need to implement: - JQOM, allows you to programmatically create a query - JCR-SQL2, the new SQL query syntax - additional query features (joins, etc.) In a first step I already introduced temporary interfaces for the JQOM and implementing classes. I'd like to keep the current design of the query sub system for a while until we are ready to switch to the new JQOM as the basis for syntax independent query representation. That is, in a first phase my suggestion is the following: XPath---+ +--->AQT+ SQL-+ +>LuceneQuery | SQL2--->JQOM+ AQT: abstract query tree And once the path SQL2->JQOM->LuceneQuery is stable: XPath---+ AQT (deprecated) | SQL-+>JQOM->LuceneQuery | SQL2+ Comments and suggestions are welcome. +1. Sounds reasonable. Do you want to use javacc for SQL2 parsing? Looks good to me as well (sorry, somehow missed the original post). Best regards, Julian
