If you guys need help, maybe you guys should expand your committer list? "product speaks well for itself so far", from what I have heard, losta people are just branching off the code-base and making changes and do merges every release. I really don't want to do that here, but I am being forced down that road. What I think should be avoided what happened to Linux, where there are different versions of the kernel, e.g. there are different version of lucene projects.
Don't get me wrong, I think it is one of the best projects out there. But sometimes I think you guys should listen to the community a bit more, instead of presuming how the product is used. Anyway, thanks for looking into those issues. -John On Tue, Dec 2, 2008 at 4:11 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > I worked on getting both of thoses issues resolved :) Sorry, can't please > everyone. If it helps, I'll commit that second one soon now that I can. It's > lazy consensus around here man. Mabye it's not ideal, but I think the > product speaks well for itself so far. I've never met a more accomadating > group of guys myself. It is a large part volunteer effort. > > - Mark > > On Dec 2, 2008, at 7:02 PM, "John Wang" <[EMAIL PROTECTED]> wrote: > > I have described our use-case in good detail. I think it is a common > architecture. And we are not using RemoteSearcher. This problem is not tied > to RemoteSearcher, and we are not using RMI. Serialized java objects can be > used at places other than RMI. > "sometime you IMp serializable for RMI but you don't want to fully support > it. Mabye it's not great java, but it's common enough, and makes sense to me > in certain instances." - does not make sense to me. There are lotsa bugs > that are common, e.g. thread-safety, dead-lock, memory leak, and they are > bad java, doesn't mean they should not be addressed. > > Pardon me for being blunt, but this is really a bug: the expected behavior > stated by the API is not honored. It would have been avoided if the same > compiler was used for the release, with Java being WORA, this smells like a > bug to me. > > My frustration is not unfounded, here are some examples I personally ran > into: > > <https://issues.apache.org/jira/browse/LUCENE-1246> > https://issues.apache.org/jira/browse/LUCENE-1246: simple 1 line null > check, over 8 months, and still being "discussed" > > <https://issues.apache.org/jira/browse/SOLR-243> > https://issues.apache.org/jira/browse/SOLR-243: with 4 votes, also few > lines of change with the patch was originally done, over 18months, and still > being "discussed" > > -John > > On Tue, Dec 2, 2008 at 3:43 PM, Mark Miller < <[EMAIL PROTECTED]> > [EMAIL PROTECTED]> wrote: > >> Woah! I think you got the wrong impression. I think Doug said basically >> what I was thinking (if not a bit more clearly than I was thinking it). I >> think we are all open to any good patches. It's nice to understand and >> discuss them first though. >> >> To reiterate what doug mentioned, sometime you IMp serializable for RMI >> but you don't want to fully support it. Mabye it's not great java, but it's >> common enough, and makes sense to me in certain instances. >> >> - Mark >> >> >> >> On Dec 2, 2008, at 6:30 PM, "John Wang (JIRA)" < <[EMAIL PROTECTED]> >> [EMAIL PROTECTED]> wrote: >> >> >>> [ >>> <https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652594#action_12652594> >>> https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652594#action_12652594 >>> ] >>> >>> John Wang commented on LUCENE-1473: >>> ----------------------------------- >>> >>> the fact an object implements Serializable implies this object can be >>> serialized. It is a known good java programming practice to include a suid >>> to the class (as a static variable) when the object declares itself to be >>> Serializable. If it is not meant to be serialized, why did it implement >>> Serializable. Furthermore, what is the reason to avoid it being serialized? >>> I find the reason being the cost of support kinda ridiculous, seems this >>> reason can be applied to any bug fix, because this at the end of the day, it >>> is a bug. >>> >>> I don't understand the issue of "extra bytes" to the term dictionary if >>> the Term instance is not actually serialized to the index (at least I really >>> hope that is not done) >>> >>> The serialVersionUID (suid) is a long because it is a java thing. Here is >>> a link to some information on the subject: >>> <http://java.sun.com/developer/technicalArticles/Programming/serialization/> >>> http://java.sun.com/developer/technicalArticles/Programming/serialization/ >>> >>> Use case: deploying lucene in a distributed environment, we have a >>> broker/server architecture. (standard stuff), we want roll out search >>> servers with lucene 2.4 instance by instance. The problem is that the broker >>> is sending a Query object to the searcher via java serialization at the >>> server level, and the broker is running 2.3. And because of specifically >>> this problem, 2.3 brokers cannot to talk to 2.4 search servers even when the >>> Query object was not changed. >>> >>> To me, this is a very valid use-case. The problem was two different >>> people did the release with different compilers. >>> >>> At the risk of pissing off the Lucene powerhouse, I feel I have to >>> express some candor. I am growing more and more frustrated with the lack of >>> the open source nature of this project and its unwillingness to work with >>> the developer community. This is a rather trivial issue, and it is taking 7 >>> back-and-forth's to reiterate some standard Java behavior that has been >>> around for years. >>> >>> Lucene is a great project and has enjoyed great success, and I think it >>> is to everyone's interest to make sure Lucene grows in a healthy >>> environment. >>> >>> >>> >>> Implement Externalizable in main top level searcher classes >>>> ----------------------------------------------------------- >>>> >>>> Key: LUCENE-1473 >>>> URL: <https://issues.apache.org/jira/browse/LUCENE-1473> >>>> https://issues.apache.org/jira/browse/LUCENE-1473 >>>> Project: Lucene - Java >>>> Issue Type: Bug >>>> Components: Search >>>> Affects Versions: 2.4 >>>> Reporter: Jason Rutherglen >>>> Priority: Minor >>>> Attachments: LUCENE-1473.patch >>>> >>>> >>>> To maintain serialization compatibility between Lucene versions, major >>>> classes can implement Externalizable. This will make Serialization faster >>>> due to no reflection required and maintain backwards compatibility. >>>> >>> >>> -- >>> This message is automatically generated by JIRA. >>> - >>> You can reply to this email to add a comment to the issue online. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: <[EMAIL PROTECTED]> >>> [EMAIL PROTECTED] >>> For additional commands, e-mail: <[EMAIL PROTECTED]> >>> [EMAIL PROTECTED] >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: <[EMAIL PROTECTED]> >> [EMAIL PROTECTED] >> For additional commands, e-mail: <[EMAIL PROTECTED]> >> [EMAIL PROTECTED] >> >> >
