[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-tabpanel&focusedCommentId=12920542#action_12920542 ] Mark Miller commented on CONNECTORS-116: Indeed - my impression is that we are all happy to see this code be pulled if that's what the original contributors want (or what they are legally bound to want) - we just think that process should be public before the code is silently taken out back and shot ;) > 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] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908561#action_12908561
]
Mark Miller commented on CONNECTORS-98:
---
I agree - I think the best REST is sticking by most of the general practices as
you can / makes sense - but more importantly, just be consistent. While it can
be nice to stick to the http spec / REST gospel when you can, sometimes it just
makes sense to be a little different.
bq. (2) HTTP states that PUT should generate a 201 return when the resource is
being created.
Both PUT and POST can be used to create according to HTTP.
bq. (3) Use of plural/singular. I don't really care much. Pick something and
let me know and we'll stick with it.
I agree - it's only important to be consistant internally here - otherwise, who
cares.
> API should be "pure" RESTful with the API verb represented using the HTTP
> GET/PUT/POST/DELETE methods
> -
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
>Affects Versions: LCF Release 0.5
>Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the
> API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
> input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> What we have today is certainly workable, but just not as "pure" as some
> might desire. It would be better to take care of this before the initial
> release so that we never have to answer the question of why it wasn't done as
> a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can
> process the DELETE and PUT methods (using the doDelete and doPut method
> overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have
> large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-56) All features should be accessible through an API
[ https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902940#action_12902940 ] Mark Miller commented on CONNECTORS-56: --- bq. HTTP methods other than GET or PUT are in fact poorly supported in many HTTP clients, including Apache Commons HTTPClient. That's untrue. bq. I am also unsure of whether Jetty supports the DELETE method at the servlet level. Jetty has no issues with DELETE, POST, PUT, or GET. Nor does Tomcat or any other container I have seen. bq. I therefore think your suggestion would potentially cause a great deal of headache for no tangible benefit. Again, I don't agree - it would cause less headaches, as REST is somewhat of a standard rather than an ad hoc api. There are many advantages to having a consistent RESTful api. > All features should be accessible through an API > > > Key: CONNECTORS-56 > URL: https://issues.apache.org/jira/browse/CONNECTORS-56 > Project: Apache Connectors Framework > Issue Type: Sub-task > Components: Framework core >Reporter: Jack Krupansky >Assignee: Karl Wright > > LCF consists of a full-featured crawling engine and a full-featured user > interface to access the features of that engine, but some applications are > better served with a full API that lets the application control the crawling > engine, including creation and editing of connections and creation, editing, > and control of jobs. Put simply, everything that a user can accomplish via > the LCF UI should be doable through an LCF API. All LCF objects should be > queryable through the API. > A primary use case is Solr applications which currently use Aperture for > crawling, but would prefer the full-featured capabilities of LCF as a > crawling engine over Aperture. > I do not wish to over-specify the API in this initial description, but I > think the LCF API should probably be a traditional REST API., with some of > the API elements specified via the context path, some parameters via URL > query parameters, and complex, detailed structures as JSON (or similar.). The > precise details of the API are beyond the scope of this initial description > and will be added incrementally once the high-level approach to the API > becomes reasonably settled. > A job status and event reporting scheme is also needed in conjunction with > the LCF API. That requirement has already been captured as CONNECTORS-41. > The intention for the API is to create, edit, access, and control all of the > objects managed by LCF. The main focus is on repositories, jobs, and status, > and less about document-specific crawling information, but there may be some > benefit to querying crawling status for individual documents as well. > Nothing in this proposal should in any way limit or constrain the features > that will be available in the LCF UI. The intent is that LCF should continue > to have a full-featured UI, but in addition to a full-featured API. > Note: This issue is part of Phase 2 of the CONNECTORS-50 umbrella issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902941#action_12902941
]
Mark Miller commented on CONNECTORS-98:
---
bq. Also, POST should be usable as an alternative to PUT for API calls that
have large volumes of data.
That shouldn't be necessary at all.
> API should be "pure" RESTful with the API verb represented using the HTTP
> GET/PUT/POST/DELETE methods
> -
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
>Affects Versions: LCF Release 0.5
>Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the
> API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
> input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> What we have today is certainly workable, but just not as "pure" as some
> might desire. It would be better to take care of this before the initial
> release so that we never have to answer the question of why it wasn't done as
> a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can
> process the DELETE and PUT methods (using the doDelete and doPut method
> overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have
> large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-55) Bundle database server with LCF packaged product
[ https://issues.apache.org/jira/browse/CONNECTORS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886718#action_12886718 ] Mark Miller commented on CONNECTORS-55: --- If it's now that easy, then fantastic! The last quick start guide I saw was like many thousands of words, so it's nice to see it boiled down to like a dozen ;) That is exactly what I was leaning towards - but what kind of hobbled state are you in with derby? You said you have to run the db and ui one at a time or something? And that many sql queries don't work with derby - that has all been addressed already? Anyhow, you asked what my goal was for pushing getting a working java db - and this is exactly it. > Bundle database server with LCF packaged product > > > Key: CONNECTORS-55 > URL: https://issues.apache.org/jira/browse/CONNECTORS-55 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jack Krupansky > > The current requirement that the user install and deploy a PostgreSQL server > complicates the installation and deployment of LCF for the user. Installation > and deployment of LCF should be as simple as Solr itself. QuickStart is great > for the low-end and basic evaluation, but a comparable level of simplified > installation and deployment is still needed for full-blown, high-end > environments that need the full performance of a ProstgreSQL-class database > server. So, PostgreSQL should be bundled with the packaged release of LCF so > that installation and deployment of LCF will automatically install and deploy > a subset of the full PostgreSQL distribution that is sufficient for the needs > of LCF. Starting LCF, with or without the LCF UI, should automatically start > the database server. Shutting down LCF should also shutdown the database > server process. > A typical use case would be for a non-developer who is comfortable with Solr > and simply wants to crawl documents from, for example, a SharePoint > repository and feed them into Solr. QuickStart should work well for the low > end or in the early stages of evaluation, but the user would prefer to > evaluate "the real thing" with something resembling a production crawl of > thousands of documents. Such a user might not be a hard-core developer or be > comfortable fiddling with a lot of software components simply to do one > conceptually simple operation. > It should still be possible for the user to supply database server settings > to override the defaults, but the LCF package should have all of the > best-practice settings deemed appropriate for use with LCF. > One downside is that installation and deployment will be platform-specific > since there are multiple processes and PostgreSQL itself requires a > platform-specific installation. > This proposal presumes that PostgreSQL is the best option for the foreseeable > future, but nothing here is intended to preclude support for other database > servers in futures releases. > This proposal should not have any impact on QuickStart packaging or > deployment. > Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-55) Bundle database server with LCF packaged product
[ https://issues.apache.org/jira/browse/CONNECTORS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886715#action_12886715 ] Mark Miller commented on CONNECTORS-55: --- bq. Jack, for example, was extremely surprised to learn that embedded Derby would not allow more than one process to access the database at a time You can switch to a mode that allows multiple connections - I've started with one and moved to the other in the past - its been too long so I'd have to go look, but its entirely possible to use very similar code and run in a server mode. bq. so that we could understand your true goal here. To make trying out and installing LCF much easier - the bar on this thing as a user and a dev is just kind of ridiculous at the moment. I know a lot of improvements are being made, but having to install a separate postgres db just to get going - just to try LCF out - is something I'd like to see go away. A java db would allow us to get to a point where you download the thing and launch it - that would really get this project going. It will be helpful to attract both users and a community of devs. There are at least half a dozen or more committers that signed up for this project, but the bar is so high to even 'do anything', that I suspect thats why most of them have yet to contribute even a comment - they don't have the time or motivation to go through that huge 'running LCF' doc - its a bear just to skim, say nothing about go through the steps. In general, I like to think of all that work as something the computer can do for me ;) Baby steps though - I'm just pushing in that direction - I know there would be a long, long path to get there. > Bundle database server with LCF packaged product > > > Key: CONNECTORS-55 > URL: https://issues.apache.org/jira/browse/CONNECTORS-55 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jack Krupansky > > The current requirement that the user install and deploy a PostgreSQL server > complicates the installation and deployment of LCF for the user. Installation > and deployment of LCF should be as simple as Solr itself. QuickStart is great > for the low-end and basic evaluation, but a comparable level of simplified > installation and deployment is still needed for full-blown, high-end > environments that need the full performance of a ProstgreSQL-class database > server. So, PostgreSQL should be bundled with the packaged release of LCF so > that installation and deployment of LCF will automatically install and deploy > a subset of the full PostgreSQL distribution that is sufficient for the needs > of LCF. Starting LCF, with or without the LCF UI, should automatically start > the database server. Shutting down LCF should also shutdown the database > server process. > A typical use case would be for a non-developer who is comfortable with Solr > and simply wants to crawl documents from, for example, a SharePoint > repository and feed them into Solr. QuickStart should work well for the low > end or in the early stages of evaluation, but the user would prefer to > evaluate "the real thing" with something resembling a production crawl of > thousands of documents. Such a user might not be a hard-core developer or be > comfortable fiddling with a lot of software components simply to do one > conceptually simple operation. > It should still be possible for the user to supply database server settings > to override the defaults, but the LCF package should have all of the > best-practice settings deemed appropriate for use with LCF. > One downside is that installation and deployment will be platform-specific > since there are multiple processes and PostgreSQL itself requires a > platform-specific installation. > This proposal presumes that PostgreSQL is the best option for the foreseeable > future, but nothing here is intended to preclude support for other database > servers in futures releases. > This proposal should not have any impact on QuickStart packaging or > deployment. > Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-55) Bundle database server with LCF packaged product
[ https://issues.apache.org/jira/browse/CONNECTORS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886494#action_12886494 ] Mark Miller commented on CONNECTORS-55: --- All the more reason to get LCF working completely with other Java databases. > Bundle database server with LCF packaged product > > > Key: CONNECTORS-55 > URL: https://issues.apache.org/jira/browse/CONNECTORS-55 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jack Krupansky > > The current requirement that the user install and deploy a PostgreSQL server > complicates the installation and deployment of LCF for the user. Installation > and deployment of LCF should be as simple as Solr itself. QuickStart is great > for the low-end and basic evaluation, but a comparable level of simplified > installation and deployment is still needed for full-blown, high-end > environments that need the full performance of a ProstgreSQL-class database > server. So, PostgreSQL should be bundled with the packaged release of LCF so > that installation and deployment of LCF will automatically install and deploy > a subset of the full PostgreSQL distribution that is sufficient for the needs > of LCF. Starting LCF, with or without the LCF UI, should automatically start > the database server. Shutting down LCF should also shutdown the database > server process. > A typical use case would be for a non-developer who is comfortable with Solr > and simply wants to crawl documents from, for example, a SharePoint > repository and feed them into Solr. QuickStart should work well for the low > end or in the early stages of evaluation, but the user would prefer to > evaluate "the real thing" with something resembling a production crawl of > thousands of documents. Such a user might not be a hard-core developer or be > comfortable fiddling with a lot of software components simply to do one > conceptually simple operation. > It should still be possible for the user to supply database server settings > to override the defaults, but the LCF package should have all of the > best-practice settings deemed appropriate for use with LCF. > One downside is that installation and deployment will be platform-specific > since there are multiple processes and PostgreSQL itself requires a > platform-specific installation. > This proposal presumes that PostgreSQL is the best option for the foreseeable > future, but nothing here is intended to preclude support for other database > servers in futures releases. > This proposal should not have any impact on QuickStart packaging or > deployment. > Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879182#action_12879182 ] Mark Miller commented on CONNECTORS-40: --- bq. could you summarize what you are up to with this issue? To clarify, I mean could you summarize the approach you are taking with the current work you have done on the branch. > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879107#action_12879107 ] Mark Miller edited comment on CONNECTORS-40 at 6/15/10 7:32 PM: FYI: http://search.lucidimagination.com/search/document/1b60f001fc0a0a98/branch_for_ticket_connectors_40 This issue is being developed on a branch at http://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-40 was (Author: markrmil...@gmail.com): FYI: http://search.lucidimagination.com/search/document/1b60f001fc0a0a98/branch_for_ticket_connectors_40 > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879178#action_12879178 ] Mark Miller commented on CONNECTORS-40: --- >From >http://search.lucidimagination.com/search/document/760aeaa785116e3b/beginning_of_connectors_40_work > : Hi all (and especially Eric), I began work on CONNECTORS-40 in the agreed-upon branch. So far, I've checked in the modifications needed to pull output connector UI out of JSP, and also did the conversion of the gts output connector from JSP. This looks reasonably good to me, other than the somewhat-more-obtuse syntax required to represent HTML from within the java connector classes. But it would be good to hear any comments before I go further in the conversion process. Thanks, Karl Mark: you can find a link to the diffs ref'd here: http://mail-archives.apache.org/mod_mbox/incubator-connectors-commits/201006.mbox/%3c20100615191345.6a2072388...@eris.apache.org%3e > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879174#action_12879174 ] Mark Miller commented on CONNECTORS-40: --- Hey Karl - To lower the bar for contributers (say those with ideas but not the time to jump into code), could you summarize what you are up to with this issue? It also is difficult to casually follow along with this issue especially as it is broken up over the mailing list, a branch, and JIRA. Ideally everything one would want to follow along would be in the JIRA issue itself. In that spirit, I'll post some more useful info. > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879107#action_12879107 ] Mark Miller commented on CONNECTORS-40: --- FYI: http://search.lucidimagination.com/search/document/1b60f001fc0a0a98/branch_for_ticket_connectors_40 > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CONNECTORS-43) Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
---
Key: CONNECTORS-43
URL: https://issues.apache.org/jira/browse/CONNECTORS-43
Project: Lucene Connector Framework
Issue Type: Bug
Reporter: Mark Miller
Priority: Trivial
{code}
nextString.trim();
{code}
should likely be:
{code}
nextString = nextString.trim();
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONNECTORS-42) Impossible cast in org.apache.lcf.core.database.Database
Impossible cast in org.apache.lcf.core.database.Database
Key: CONNECTORS-42
URL: https://issues.apache.org/jira/browse/CONNECTORS-42
Project: Lucene Connector Framework
Issue Type: Bug
Reporter: Mark Miller
Priority: Minor
{code}
if (x instanceof TimeMarker)
{
ps.setTimestamp(i+1,new java.sql.Timestamp(((Long)x).longValue()));
}
{code}
should likely be:
{code}
if (x instanceof TimeMarker)
{
ps.setTimestamp(i+1,new
java.sql.Timestamp(((TimeMarker)x).longValue()));
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
