Re: Tommaso Teofili has joined ManifoldCF as a new mentor!
welcome Tommaso! On Sun, May 15, 2011 at 4:41 PM, Karl Wright daddy...@gmail.com wrote: Please join me in thanking Tommaso for taking on this responsibility! Karl
Re: Reopened CONNECTORS-148; should we spin an RC9?
Just my opinion: 1. release the artifacts that are voted on... its 0.1 and a lot of people will likely be still in evaluation stage (likely with derby?). Obviously there are bugs, even ones that aren't known, but I think its just fine to release with known bugs... better at this stage to get the release out there and possibly draw in more people (who might find more bugs). 2. start working on the next release. besides this bug, for example there is the related issue open for improved postgresql testing, etc: personally I think this is great, maybe expanding on that idea could uncover even more bugs. the known bugs are documented in jira anyway, but workarounds or whatever could be put in the wiki in the meantime too. I don't think the next release needs to be rushed out to fix the bug quickly, either. Its not the end of the world at this point if people hit the bug and are drawn into mailing lists/svn/jira/whatever On Mon, Jan 31, 2011 at 5:37 PM, Karl Wright daddy...@gmail.com wrote: There is a workaround, but given the fact that a complex workaround is needed to execute what should be a simple deployment, I'd wonder if we have our priorities straight in releasing 0.1 in this condition. But it's your call. The release process is easy for me, except the pain needed to get everyone to have a look at the artifact and sign off on it, and I can see no particular rush either. If we do have another RC, I would also like to add Postgresql-based tests into RC9. I've got them just about ready, and will be committing to trunk shortly. Karl On Mon, Jan 31, 2011 at 4:19 PM, Grant Ingersoll gsing...@apache.org wrote: Is there a workaround for the issue? Can't the user create it by hand? On Jan 31, 2011, at 1:51 AM, Karl Wright wrote: You can read the details in CONNECTORS-148. I hesitate to ask this because getting the votes for RC8 just finished, and took the better part of a month, but should we produce an RC9? This issue was considered a blocker for release, and since it appears to not have been fixed, I really think we have no choice. Effectively this prevents people from using PostgreSQL with ManifoldCF, unless they take manual measures, and I doubt many people will be willing to do that. Karl
Re: Release?
On Mon, Dec 6, 2010 at 7:45 PM, Karl Wright daddy...@gmail.com wrote: Since quoteSQLString uses ' as it's quotation mark, and properly escapes ' characters within the string, I claim that the method is properly written and cannot be used for a sql attack. If you disagree, provide me a string that breaks the escaping that it does. Just so you know Karl, security issues shouldn't be treated like 'regular bugs'. Users/developers shouldnt need to write 'test cases' when code is obviously insecure, we should instead write code securely, and specify parameters as parameters so that we know they aren't going to be interpreted as syntax. That being said, my examples were just fine, examples. For postgresql an example problem is that ' can also be escaped with a \. (http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html) Thus, in some situations its possible for me to bypass your escaping by using the sequence \', which you will escape into \'', giving me an unescaped single quote. This is just *an example*, as i said before to demonstrate why escaping is dangerous, I'm not going to go back-and-forth with you on this as to whether or not manifoldcf has a problem in any particular circumstances. Someone motivated will always bypass escaping. We should make parameters, parameters.
Re: Release?
i took a quick look, i definitely agree we need to document all 3rd party dependencies in notice.txt and include licenses with them. separately, i have an additional concern, and that is i'm really concerned about a release going out with some of the database interface code looking very prone to sql injection attacks. On Mon, Dec 6, 2010 at 6:45 PM, Karl Wright daddy...@gmail.com wrote: Robert has expressed a willingness to chip in on the remaining issues later this week, when he's no longer being buried alive. Thanks, Robert! Karl On Mon, Dec 6, 2010 at 6:02 PM, Karl Wright daddy...@gmail.com wrote: Ok, this too has been done. Still no takers for (2) and (3). Going thrice... Karl On Mon, Dec 6, 2010 at 3:48 PM, Grant Ingersoll gsing...@apache.org wrote: Typically, the practice is that the name of the file is the name of the directory, but I don't know that it has to be. Just easier, since you only need one Ant variable. -Grant On Dec 6, 2010, at 3:10 PM, Karl Wright wrote: Does this also apply to the top-level directory in the tar or zip as well? or can that be left as apache-manifoldcf-0.1? Karl On Mon, Dec 6, 2010 at 3:05 PM, Grant Ingersoll gsing...@apache.org wrote: FYI, I think the package name needs to have the words incubating in it too, as in manifoldcf-0.1-incubating.tar.gz -Grant On Dec 6, 2010, at 8:55 AM, Karl Wright wrote: ... going twice ... Karl On Sun, Dec 5, 2010 at 11:42 AM, Karl Wright daddy...@gmail.com wrote: I'm done with (1), (4), and (5). Still waiting for help with (2) and (3)... going once Karl On Thu, Dec 2, 2010 at 10:02 PM, Karl Wright daddy...@gmail.com wrote: OK, so I will do the appropriate things to make (1), (4), and maybe (5) happen. Does anyone want to help with (2), (3), and (8)? Karl On Thu, Dec 2, 2010 at 9:59 PM, Grant Ingersoll gsing...@apache.org wrote: On Dec 2, 2010, at 9:54 PM, Karl Wright wrote: Hi Grant, In offline conversation you clarified that for (1) you are looking for the top level dir in the zip/tar to be named apache-manifoldcf-0.1. You also seem to be asking for a number of other fixes that are specific to a release, that I presume would NOT be in sources on trunk (e.g. CHANGES.txt). Are you envisioning that we make these specific changes in the release branch only? It's perfectly fine for CHANGES.txt to be on trunk. You make the change marking it as 0.1. Once the release is out, you add a new section at the top for trunk again. Later, as we mature, we will likely have branches, etc. for this stuff, but for now let's just assume trunk is under code freeze and the only changes that can be made are those related to release. Karl On Thu, Dec 2, 2010 at 9:45 PM, Grant Ingersoll gsing...@apache.org wrote: We're close, but I think we've got a few more things to do. I did get it to compile. Notes: 1. We should package the stuff all under apache-manifold-0.1 so that when we unzip it's all in one folder. 2. Many of the libs require an entry in the NOTICE.txt file 3. All licenses for those libs need to be appended on to the end of the LICENSE.txt file (See Solr's for instance) 4. The CHANGES.txt file should reflect that it is a release and not trunk (not critical to fix) 5. Is there anyway to make the package smaller? Maybe we don't need to ship both PDF and HTML for the docs. Anything else we can trim? 6. What's json/org/json all about? 7. I still see Memex stuff in connectors dir. I didn't check other places. 8. We should hook in RAT (see Solr's build file) to verify that all source files have appropriate license headers Other than that, some other eyes on it would be good. -Grant On Dec 2, 2010, at 8:51 PM, Karl Wright wrote: Done Karl On Thu, Dec 2, 2010 at 8:49 PM, Karl Wright daddy...@gmail.com wrote: ok - I might move it there Karl On Thu, Dec 2, 2010 at 8:31 PM, Grant Ingersoll gsing...@apache.org wrote: Weird, ~kwright doesn't resolve for me on people.a.o, but I can get to /x1/home/kwright FWIW, if you have a public_html directory in your directory and then place the files there, everyone can download them and check them out at http://people.apache.org/~kwright/ -Grant On Nov 23, 2010, at 1:00 PM, Karl Wright wrote: While I was looking for a solution, an upload attempt succeeded! So there is now an RC0 out on people.apache.org/~kwright: [kwri...@minotaur:~]$ ls -lt manifoldcf-0.1.* -rw-r--r-- 1 kwright kwright 63 Nov 23 17:57 manifoldcf-0.1.tar.gz.md5 -rw-r--r-- 1 kwright kwright 60 Nov 23 17:57 manifoldcf-0.1.zip.md5 -rw-r--r-- 1 kwright kwright 158734230 Nov 23 17:55 manifoldcf-0.1.zip -rw-r--r-- 1 kwright kwright 156742315 Nov 23 17:06 manifoldcf-0.1.tar.gz [kwri...@minotaur:~]$ Please let me know what you think. Karl On Tue, Nov 23, 2010 at 11:25 AM, Karl Wright daddy...@gmail.com wrote: The upload has failed repeatedly for
Re: Release?
On Mon, Dec 6, 2010 at 7:18 PM, Karl Wright daddy...@gmail.com wrote: As for the sql injection question, please elaborate. There is no UI ability to do sql injection that I am aware of, because all the strings you might enter are properly escaped before being incorporated into queries. This includes queries that come via the API and Authority Service. So I guess I need an example of how you might cause a sql injection given the current code. Escaping tends to only thwart casual attackers, not motivated ones or even automated tools. For example the escaping i see used here: e.g. quoteSQLString seems to only quote single-quote characters. There are a number of techniques to workaround this type of escaping, some are listed here: http://www.slideshare.net/inquis/sql-injection-not-only-and-11 In my opinion all variables should be explicitly bound via PreparedStatements.
[jira] Commented: (CONNECTORS-116) Possibly remove memex connector depending upon legal resolution
[ https://issues.apache.org/jira/browse/CONNECTORS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12922118#action_12922118 ] Robert Muir commented on CONNECTORS-116: Grant, thanks for reporting back. I will remove the memex connector shortly unless there are objections. Possibly remove memex connector depending upon legal resolution --- Key: CONNECTORS-116 URL: https://issues.apache.org/jira/browse/CONNECTORS-116 Project: ManifoldCF Issue Type: Task Components: Memex connector Reporter: Robert Muir Assignee: Robert Muir Apparently there is an IP problem with the memex connector code. Depending upon what apache legal says, we will take any action under this issue publicly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONNECTORS-116) Possibly remove memex connector depending upon legal resolution
[ https://issues.apache.org/jira/browse/CONNECTORS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved CONNECTORS-116. Resolution: Fixed Committed revision 1023998. Possibly remove memex connector depending upon legal resolution --- Key: CONNECTORS-116 URL: https://issues.apache.org/jira/browse/CONNECTORS-116 Project: ManifoldCF Issue Type: Task Components: Memex connector Reporter: Robert Muir Assignee: Robert Muir Apparently there is an IP problem with the memex connector code. Depending upon what apache legal says, we will take any action under this issue publicly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: hsqldb deadlock
maybe the problem is indicative of a bug in LCF? I think its strange that there are locking problems with Derby, too. That being said, maybe as a quick fix you could try SET DATABASE TRANSACTION CONTROL MVCC or SET DATABASE TRANSACTION CONTROL MVLOCKS, since i see you are using two phase locking: http://hsqldb.org/doc/2.0/guide/sessions-chapt.html#sqlgeneral_trans_cc-sect On Sun, Oct 10, 2010 at 9:18 AM, karl.wri...@nokia.com wrote: Does anybody have experience with hsqldb? I'm getting a java thread deadlock within about 10 seconds of running a job. I want to know if anyone has seen this before, or has used hsqldb in a massively multithreaded environment. Found one Java-level deadlock: = Thread-745: waiting for ownable synchronizer 0x293b0b70, (a java.util.concurrent.locks.Ree ntrantReadWriteLock$NonfairSync), which is held by Thread-725 Thread-725: waiting to lock monitor 0x04614284 (object 0x2927b550, a org.hsqldb.persist.Lo bManager), which is held by Thread-732 Thread-732: waiting for ownable synchronizer 0x293b0b70, (a java.util.concurrent.locks.Ree ntrantReadWriteLock$NonfairSync), which is held by Thread-725 Java stack information for the threads listed above: === Thread-745: at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x293b0b70 (a java.util.concurrent.locks.Reentr antReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1178) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen trantReadWriteLock.java:807) at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.executeDirectStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) - locked 0x23dc38d0 (a org.hsqldb.Session) at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source) - locked 0x23dc6fc0 (a org.hsqldb.jdbc.JDBCStatement) at org.apache.manifoldcf.core.database.Database.execute(Database.java:52 6) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D atabase.java:381) Thread-725: at org.hsqldb.persist.LobManager.adjustUsageCount(Unknown Source) - waiting to lock 0x2927b550 (a org.hsqldb.persist.LobManager) at org.hsqldb.SessionData.adjustLobUsageCount(Unknown Source) at org.hsqldb.TransactionManagerCommon.persistCommit(Unknown Source) at org.hsqldb.TransactionManager2PL.commitTransaction(Unknown Source) at org.hsqldb.Session.commit(Unknown Source) - locked 0x23ca46f0 (a org.hsqldb.Session) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) - locked 0x23ca46f0 (a org.hsqldb.Session) at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown Source) - locked 0x23ca8038 (a org.hsqldb.jdbc.JDBCPreparedStatement) at org.apache.manifoldcf.core.database.Database.execute(Database.java:56 6) at org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(D atabase.java:381) Thread-732: at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x293b0b70 (a java.util.concurrent.locks.Reentr antReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt errupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A bstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac tQueuedSynchronizer.java:1178) at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen trantReadWriteLock.java:807) at org.hsqldb.TransactionManager2PL.beginAction(Unknown Source) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.persist.LobManager.createClob(Unknown Source) - locked 0x2927b550 (a org.hsqldb.persist.LobManager) at org.hsqldb.Session.createClob(Unknown Source) at org.hsqldb.jdbc.JDBCPreparedStatement.performPreExecute(Unknown Sourc e) at
Re: [VOTE] Pick your preferred name
you can ignore my vote really :) but i was thinking from a practical perspective, this one involves the least code changes. plus, with existing projects named things like apache DB and apache http server, i don't understand the fuss. On Tue, Aug 31, 2010 at 8:03 PM, Karl Wright daddy...@gmail.com wrote: Well, you've made your feelings clear. ;-) Karl On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir rcm...@gmail.com wrote: Apache Connectors Framework Apache Connectors Framework Apache Connectors Framework (sorry) On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl -- Robert Muir rcm...@gmail.com -- Robert Muir rcm...@gmail.com
[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902838#action_12902838 ] Robert Muir commented on CONNECTORS-92: --- I am the last person to comment about maven, but i noticed tika has a maven build that builds a large single jar that contains all classes from dependencies Perhaps it would be a useful example if you want to do this 'jar coalescing' Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Attachments: move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-95) add svn:ignore properties for files that shouldnt be committed
[
https://issues.apache.org/jira/browse/CONNECTORS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir reassigned CONNECTORS-95:
-
Assignee: Robert Muir
add svn:ignore properties for files that shouldnt be committed
--
Key: CONNECTORS-95
URL: https://issues.apache.org/jira/browse/CONNECTORS-95
Project: Apache Connectors Framework
Issue Type: Task
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Attachments: CONNECTORS-95.patch
I noticed after running tests and a few other ant tasks that lots of files
showed up in 'svn status'.
I think it would be good to add svn:ignores to prevent any of these from
being accidentally committed
This is what 'svn status' shows for me:
{noformat}
? .project
? bin
? modules\build
? modules\test-output
? modules\connectors\filesystem\build
? modules\connectors\filesystem\dist
? modules\connectors\filesystem\doc
? modules\connectors\filesystem\lib
? modules\connectors\filesystem\test-output
? modules\connectors\nulloutput\build
? modules\connectors\nulloutput\dist
? modules\connectors\nulloutput\doc
? modules\connectors\nulloutput\lib
? modules\connectors\sharepoint\lib
? modules\framework\build
? modules\framework\dist
? modules\framework\doc
? modules\framework\lib
? modules\framework\test-output
? modules\framework\crawler-ui\WEB-INF\web-generated.xml
{noformat}
The .project and bin are from eclipse, but these (and any files ides like
IDEA generate) are probably good candidates also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-93) add contributors to CHANGES.txt
[ https://issues.apache.org/jira/browse/CONNECTORS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902429#action_12902429 ] Robert Muir commented on CONNECTORS-93: --- Karl: sounds good. I'll commit this part shortly, but leave this issue open until we are happy with CHANGES.txt I'll look at the wiki page and see if theres anything that comes to mind, good idea. add contributors to CHANGES.txt --- Key: CONNECTORS-93 URL: https://issues.apache.org/jira/browse/CONNECTORS-93 Project: Apache Connectors Framework Issue Type: Task Components: Documentation Reporter: Robert Muir Attachments: CONNECTORS-93.patch As mentioned on the connectors-dev@ list (change the format of CHANGES.txt), I propose we modify CHANGES.txt to give credit to contributors who have given bug reports, comments, patches, etc. I'll volunteer to go thru the mail archives and jira issues that are marked 'resolved' and upload a patch here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-93) add contributors to CHANGES.txt
[ https://issues.apache.org/jira/browse/CONNECTORS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12902431#action_12902431 ] Robert Muir commented on CONNECTORS-93: --- Committed revision 989087. add contributors to CHANGES.txt --- Key: CONNECTORS-93 URL: https://issues.apache.org/jira/browse/CONNECTORS-93 Project: Apache Connectors Framework Issue Type: Task Components: Documentation Reporter: Robert Muir Attachments: CONNECTORS-93.patch As mentioned on the connectors-dev@ list (change the format of CHANGES.txt), I propose we modify CHANGES.txt to give credit to contributors who have given bug reports, comments, patches, etc. I'll volunteer to go thru the mail archives and jira issues that are marked 'resolved' and upload a patch here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
change the format of CHANGES.txt
Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. -- Robert Muir rcm...@gmail.com
Re: change the format of CHANGES.txt
ok I created https://issues.apache.org/jira/browse/CONNECTORS-93 https://issues.apache.org/jira/browse/CONNECTORS-93I can start going thru mail archives and issues that are resolved and look for contributors. If you have some free time and want to help, please feel free and just comment/upload on the issue. I think this is really important before any release happens. On Mon, Aug 23, 2010 at 4:31 PM, Simon Willnauer simon.willna...@googlemail.com wrote: +1 On Mon, Aug 23, 2010 at 10:18 PM, Grant Ingersoll gsing...@apache.org wrote: On Aug 23, 2010, at 4:04 PM, Robert Muir wrote: Hello, I wanted to suggest that we slightly alter the format of CHANGES.txt. Most important I think is to add the names of non-committers who contribute any patches, JIRA comments, reports of bugs on the user list, etc to the issue. This is how the CHANGES.txt is formulated for Lucene and Solr and I think it encourages contributors to come back, because they get some credit for their contributions. Any thoughts? I think it would be really good to add all contributors to any jira issues before the first release especially. +1. We definitely should be giving credit to those who help. -- Robert Muir rcm...@gmail.com
Re: Basic core testing infrastructure
Hi Karl, Just a question, I read all the warnings about how dependent LCF is on postgres, but how much of this is really only about performance? When I look at the code it seems like there is enough abstraction you could add support for say, hsqldb or similar, even if its only for testing purposes? This way you could create a 'new world' for each test, rather than worrying about cleaning up the database etc. I admit I don't know if what I am saying is even close to practical as far as how dependent things are on postgres, but it might be an idea to make testing simpler. On Mon, May 24, 2010 at 9:49 AM, karl.wri...@nokia.com wrote: To all you lurking Solr committers out there, I would like to throw some cycles towards at least getting Solr-style unit tests set up for LCF, running under Junit or something like it. My thoughts were as follows: (1) We presume a blank, already-installed version of Postgresql, configured to listen on port 5432, with a standard superuser name and password; (2) We do not attempt to test the UI at this time, because that would involve presuming an app server was installed, and would also require me to port my simple browser simulator from python to Java. Or maybe we can do this later? (3) The filesystem connector only would be used by the core tests. The question is, does this fit well with the Solr testing infrastructure? Is there a document describing that infrastructure and how to most effectively write tests for it? What are the standard pre/post-test cleanup semantics for the Solr tests, for instance? (The MetaCarta tests do a preclean stage, which removes any crap leftover from a previous failure of the same test, for instance, and also always clean up after themselves upon success.) I know the projects are quite different, but if I understand the assumptions and the how to's for Solr, it will help me enormously I think... Thanks, Karl -- Robert Muir rcm...@gmail.com
Re: Basic core testing infrastructure
On Mon, May 24, 2010 at 3:54 PM, karl.wri...@nokia.com wrote: Obviously an end-to-end test would be the best, though. But something is better than nothing. Karl I agree with this, but I think for unit tests, its best to have a very simple new clean world for each test. I think testing the postgres integration is not really unit tests at all but something else, and we could make it a separate test module. -- Robert Muir rcm...@gmail.com
