It occurred to me that a classloader plug-in reader for LCF would not achieve
the goal of allowing a fully prebuilt LCF with connector add-ons. The reason,
which should have been obvious from the beginning, is because each connector
consists not only of the Java implementation, but also a UI
Good point. LCF is a bit more complex than Solr in that sense.
Maybe a separate class is needed that has methods to retrieve the crawl and
UI components of a connector.
Or a small XML file with whatever info about the connector is needed. Or
maybe it is simple enough for a properties file.
A naming convention is what is used now. This is described in the
documentation.
The problem is complicated because a precompiled JSP class will not fly - the
package name is going to be different from application server to application
server. So, either:
- we abandon the thought of
The observation about JSPs is exactly what I was alluding to.
Does the entire UI have to be converted to Velocity for this approach to work?
There's an intermediate path that would involve converting only the connector
portions, which might be viable.
Karl
-Original Message-
From:
Velocity is just a simple templating engine, so it could be used in
the intermediate fashion to produce only snippets that mesh into the
rest of the built-in UI, no problem.
Erik
On Jun 2, 2010, at 8:04 AM, karl.wri...@nokia.com karl.wri...@nokia.com
wrote:
Does the entire UI
I've just spelunked through what I could find online, and it seems at least
plausible to use Velocity for various LCF HTML templating needs. The major
concern that I have is that the mix of inline java to HTML in the LCF stuff is
weighted heavily towards inline java - which doesn't seem to be
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
Yeah, definitely embedded Java (ala JSP's %% stuff) isn't how
Velocity works. It can call Java code just fine via tools (Java
objects) that are injected into the Velocity context. Any
sophisticated business logic can be distilled from the existing plugin
JSPs and migrated to Java
I've entered a ticket CONNECTORS-40 for this work. What I propose is that this
gets done before first official LCF release, because of the potential
backwards-compatibility issues involved. It is, however, quite a heavy lift -
I can't imagine getting it done in less than a couple of weeks
Totally reasonable. We'll try to devote some cycles to this too, of
course, but probably not for a couple of weeks.
Erik
On Jun 2, 2010, at 9:00 AM, karl.wri...@nokia.com karl.wri...@nokia.com
wrote:
I've entered a ticket CONNECTORS-40 for this work. What I propose
is that
Add hooks to output connectors for receiving event notifications, specifically
job start, job end, etc.
---
Key: CONNECTORS-41
URL:
Sounds good to me, assuming that LCF remains relatively stable. I am
presuming that a fair number of people can and will be using LCF for various
purposes well before actual formal first release anyway. The point being
that delaying the formal release shouldn't slow most people from using LCF
People who write connectors for LCF before this change occurs will need to
revamp them completely afterwards. That is, unless they contribute them to the
LCF code stream before the work begins...
Second, since there is no Q/A infrastructure yet, there's a very good chance
that stuff will get
[
https://issues.apache.org/jira/browse/CONNECTORS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-39.
---
Resolution: Fixed
Database abstraction layer does not abstract from transactions
[
https://issues.apache.org/jira/browse/CONNECTORS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-35.
---
Resolution: Fixed
Have decided that the current functionality is adequate, and no further
15 matches
Mail list logo
