Menu
▾
▴
exist-development
|
From: Andrzej J. T. <an...@ch...> - 2011-06-13 17:03:32
|
Adam: Why did I know this was going to break things for us? ;-) If you try to use your newest permissions code base to access a remote db (which is still running an older version of eXist without the new permissions stuff) then you get the following NPE: /home/andrzej/coalese/dev/raven/build.xml:656: java.lang.NullPointerException at java.util.Arrays$ArrayList.<init>(Arrays.java:3357) at java.util.Arrays.asList(Arrays.java:3343) at org.exist.xmldb.RemoteCollection.readCollection(RemoteCollection.java:432) at org.exist.xmldb.RemoteCollection.getChildCollection(RemoteCollection.java:159) at org.exist.xmldb.RemoteCollection.getChildCollection(RemoteCollection.java:153) at org.exist.xmldb.DatabaseImpl.readCollection(DatabaseImpl.java:248) at org.exist.xmldb.DatabaseImpl.getRemoteCollection(DatabaseImpl.java:225) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:158) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:151) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.ant.AbstractXMLDBTask.mkcol(AbstractXMLDBTask.java:141) at org.exist.ant.XMLDBStoreTask.execute(XMLDBStoreTask.java:105) This is something we do all the time....we use ant tasks that point to a more or less current SVN copy of eXist to access remote databases to deploy various items (xqueries, create collections, etc.) in the remote DB. Sure would be nice if this was backward compatible in this particular scenario, since this has worked for about 4 years now....but the latest permissions code has broken compatibility. Thanks! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Adam R. <ad...@ex...> - 2011-06-13 14:23:47
|
The XML-RPC API may have changed, personally I am not that concerned about backwards compatibility here because I would rather suggest that you use the same version of the client and the server together. Of course, you are welcome to make suggestions for fixes to the code which will allow the current and previous behaviours to co-exist. On 13 June 2011 16:15, Andrzej Jan Taramina <an...@ch...> wrote: > Adam: > > Why did I know this was going to break things for us? ;-) > > If you try to use your newest permissions code base to access a remote db (which is still running an > older version of eXist without the new permissions stuff) then you get the following NPE: > > /home/andrzej/coalese/dev/raven/build.xml:656: java.lang.NullPointerException > at java.util.Arrays$ArrayList.<init>(Arrays.java:3357) > at java.util.Arrays.asList(Arrays.java:3343) > at org.exist.xmldb.RemoteCollection.readCollection(RemoteCollection.java:432) > at org.exist.xmldb.RemoteCollection.getChildCollection(RemoteCollection.java:159) > at org.exist.xmldb.RemoteCollection.getChildCollection(RemoteCollection.java:153) > at org.exist.xmldb.DatabaseImpl.readCollection(DatabaseImpl.java:248) > at org.exist.xmldb.DatabaseImpl.getRemoteCollection(DatabaseImpl.java:225) > at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:158) > at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:151) > at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) > at org.exist.ant.AbstractXMLDBTask.mkcol(AbstractXMLDBTask.java:141) > at org.exist.ant.XMLDBStoreTask.execute(XMLDBStoreTask.java:105) > > This is something we do all the time....we use ant tasks that point to a more or less current SVN > copy of eXist to access remote databases to deploy various items (xqueries, create collections, > etc.) in the remote DB. > > Sure would be nice if this was backward compatible in this particular scenario, since this has > worked for about 4 years now....but the latest permissions code has broken compatibility. > > Thanks! > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Wolfgang M. <wol...@ex...> - 2011-06-13 16:51:32
|
>> /home/andrzej/coalese/dev/raven/build.xml:656: java.lang.NullPointerException
>> at java.util.Arrays$ArrayList.<init>(Arrays.java:3357)
>> at java.util.Arrays.asList(Arrays.java:3343)
>> at org.exist.xmldb.RemoteCollection.readCollection(RemoteCollection.java:432)
I guess fixing this is just a matter of checking for acl == null after
final Object[] acl = (Object[])collection.get("acl");
in line 431 of RemoteCollection.
Wolfgang
|
|
From: Andrzej J. T. <an...@ch...> - 2011-06-13 17:03:31
|
Adam: > The XML-RPC API may have changed, personally I am not that concerned > about backwards compatibility here because I would rather suggest that > you use the same version of the client and the server together. I would love to....but the attribute replication bug I reported over a month ago is still present, and is precluding us from upgrading our remote systems to a more recent release. I had hoped that Wolfgangs recent fixes for the optimizer would fix this bug, but unfortunately they haven't. So that means we now need to keep multiple versions of the exist distribution around and select the correct one based on the version of the server code we are accessing remotely. That is a real PITA from a management perspective. > Of course, you are welcome to make suggestions for fixes to the code > which will allow the current and previous behaviours to co-exist. Very helpful...thanks. ;-( -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Adam R. <ad...@ex...> - 2011-06-13 14:33:29
|
On 13 June 2011 16:24, Andrzej Jan Taramina <an...@ch...> wrote: > Adam: > >> The XML-RPC API may have changed, personally I am not that concerned >> about backwards compatibility here because I would rather suggest that >> you use the same version of the client and the server together. > > I would love to....but the attribute replication bug I reported over a month ago is still present, > and is precluding us from upgrading our remote systems to a more recent release. I had hoped that > Wolfgangs recent fixes for the optimizer would fix this bug, but unfortunately they haven't. > > So that means we now need to keep multiple versions of the exist distribution around and select the > correct one based on the version of the server code we are accessing remotely. That is a real PITA > from a management perspective. > >> Of course, you are welcome to make suggestions for fixes to the code >> which will allow the current and previous behaviours to co-exist. > > Very helpful...thanks. ;-( Its not that I am being unhelpful here, its that we have different perspectives and responsibilities. My perspective is that I am not concerned with backwards compatibility in the XML-RPC API and believe that that will be fine for the majority of users. Your perspective is that of a user that would prefer to see XML-RPC backward compatibility because its difficult inside your project. Also we are both quite busy people, so I tend to focus on what is important to me. Maintaing backwards compatibility in the XML-RPC API is not important to me personally, I am not personally interested in it and no one is paying me to do that. Conversely, I am sure you focus on what is important to you... So if this is very important to you, then I also know that you have the necessary programming skills to look into this yourself and propose or contribute a fix (if one is possible). Dont get me wrong, I would love to have the resources to take every sensible suggestion on-board and spend time working on everything for free for everyone, but I just dont have the resources at my disposal. > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Andrzej J. T. <an...@ch...> - 2011-06-13 17:03:30
|
Adam: > Its not that I am being unhelpful here, its that we have different > perspectives and responsibilities. My perspective is that I am not > concerned with backwards compatibility in the XML-RPC API and believe > that that will be fine for the majority of users. Your perspective is > that of a user that would prefer to see XML-RPC backward compatibility > because its difficult inside your project. Yup...that sums it up pretty well. > Also we are both quite busy people, so I tend to focus on what is > important to me. Maintaing backwards compatibility in the XML-RPC API > is not important to me personally, I am not personally interested in > it and no one is paying me to do that. Conversely, I am sure you focus > on what is important to you... So if this is very important to you, > then I also know that you have the necessary programming skills to > look into this yourself and propose or contribute a fix (if one is > possible). I would love to....but in this particular case, the new Unix permissions stuff touched nearly a hundred source files. As you point out, there's not enough time for me to try and understand all the intricacies of that code at this time, due to it's breadth and impact on the main code base. What spare time I have, I'm going to try and devote this week to delving into the "duplicate attribute" bug, since that has been tough to replicate with a simple test case, so I'll have to dive into the code to figure out what is causing this. This bug has serious implications on data and code integrity, even though it's obviously a very specific set of circumstances (as yet unknown) that cause it to manifest. Plus fixing that bug means I can probably update our remote instances to the latest SVN version which would resolve the XML-RPC API issue. Because of instabilities, security re-architecture (and bugs), database structure/version changes and the like, we've been unable to upgrade since last July, which is almost a year ago now. The instability of the code base and lack of a 1.5 production capable release has been a concern to me for some time now, since in the past everything was pretty much rock solid. Massive changes that touch the whole code base, such as the recent permissions stuff, worry me since there's a good chance that they will take a while to stabilize/debug (not to mention the testing required and potential impact on existing applications, which I suspect will be great) and thus the code base continues to be unstable. The only reason I had updated our R&D instances to the latest SVN revisions was to be able to test the impact of the permissions stuff on our apps. I've reverted to a revision just prior to the permissions stuff to get our deployment stuff to work again, since that was the easiest path for us. I'll look into managing multiple versions of the eXist code base when we're ready to test the permissions stuff. Given how extensive our app is and our history of finding issues in new code as a result, I suspect that we'll chat again soon. ;-) > Dont get me wrong, I would love to have the resources to take every > sensible suggestion on-board and spend time working on everything for > free for everyone, but I just dont have the resources at my disposal. Same for me....though I think some time will free up soon for me to do more work on the eXist code base, which I have not been able to do for the past few months. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Adam R. <ad...@ex...> - 2011-06-13 15:23:33
|
>> Its not that I am being unhelpful here, its that we have different >> perspectives and responsibilities. My perspective is that I am not >> concerned with backwards compatibility in the XML-RPC API and believe >> that that will be fine for the majority of users. Your perspective is >> that of a user that would prefer to see XML-RPC backward compatibility >> because its difficult inside your project. > > Yup...that sums it up pretty well. > >> Also we are both quite busy people, so I tend to focus on what is >> important to me. Maintaing backwards compatibility in the XML-RPC API >> is not important to me personally, I am not personally interested in >> it and no one is paying me to do that. Conversely, I am sure you focus >> on what is important to you... So if this is very important to you, >> then I also know that you have the necessary programming skills to >> look into this yourself and propose or contribute a fix (if one is >> possible). > > I would love to....but in this particular case, the new Unix permissions stuff touched nearly a > hundred source files. As you point out, there's not enough time for me to try and understand all > the intricacies of that code at this time, due to it's breadth and impact on the main code base. Yes, there were a LOT of changes involved, but you should only have to focus on the classes in org.exist.xmlrpc and org.exist.xmldb - maybe 4 files in total I think. > What spare time I have, I'm going to try and devote this week to delving into the "duplicate > attribute" bug, since that has been tough to replicate with a simple test case, so I'll have to dive > into the code to figure out what is causing this. This bug has serious implications on data and > code integrity, even though it's obviously a very specific set of circumstances (as yet unknown) > that cause it to manifest. Plus fixing that bug means I can probably update our remote instances to > the latest SVN version which would resolve the XML-RPC API issue. Okay cool, it would be great to get a reproducible test case for that one. > Because of instabilities, security re-architecture (and bugs), database structure/version changes > and the like, we've been unable to upgrade since last July, which is almost a year ago now. Yes trunk has seen a lot of churn in the last year. Growing pains ;-) However, it is trunk which is stable for developers, but we dont guarantee stable for production. 1.4 is our production version and 1.4.1 is on the doorstep of being released, a new preview of 1.4.1 is out and in a few weeks if we dont have any reported issues then it will hit the streets. I would expect shortly after 1.4.1 to see a release of 1.6 our new Next Gen version based on 1.5 dev code. > The instability of the code base and lack of a 1.5 production capable release has been a concern to > me for some time now, since in the past everything was pretty much rock solid. Massive changes that > touch the whole code base, such as the recent permissions stuff, worry me since there's a good > chance that they will take a while to stabilize/debug (not to mention the testing required and > potential impact on existing applications, which I suspect will be great) and thus the code base > continues to be unstable. Actually the ACL changes were relatively straight forward and apart from all the glue that had to be modified the core changes are minimal and if you choose not to use the ACL stuff, but stick with the default Unix Style permissions then you should not experience any differences in the core. > The only reason I had updated our R&D instances to the latest SVN revisions was to be able to test > the impact of the permissions stuff on our apps. I've reverted to a revision just prior to the > permissions stuff to get our deployment stuff to work again, since that was the easiest path for us. > I'll look into managing multiple versions of the eXist code base when we're ready to test the > permissions stuff. Given how extensive our app is and our history of finding issues in new code as a > result, I suspect that we'll chat again soon. ;-) Having testers like yourselves is incredibly valuable to us, and we appreciate the feedback you provide, but I am sure you can imagine, that without reproducible test cases life can be very hard for us. >> Dont get me wrong, I would love to have the resources to take every >> sensible suggestion on-board and spend time working on everything for >> free for everyone, but I just dont have the resources at my disposal. > > Same for me....though I think some time will free up soon for me to do more work on the eXist code > base, which I have not been able to do for the past few months. > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X