You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by ka...@nokia.com on 2010/05/28 11:48:00 UTC
Proposal for simple LCF deployment model
The current LCF standard deployment model requires a number of moving parts, which are probably necessary in some cases, but simply introduce complexity in others. It has occurred to me that it may be possible to provide an alternate deployment model involving Jetty, which would reduce the number of moving parts by one (by eliminating Tomcat). A simple LCF deployment could then, in principle, look pretty much like Solr's.
In order for this to work, the following has to be true:
(1) jetty's basic JSP support must be comparable to Tomcat's.
(2) the class loader that jetty uses for webapp's must provide class isolation similar to Tomcat's. If this condition is not met, we'd need to build both a Tomcat and a Jetty version of each webapp.
The overall set of changes that would be required would be the following:
(a) An alternative "start" entry point would need to be coded, which would start Jetty running the lcf-crawler-ui and lcf-authority-service webapps before bringing up the agents engine.
(b) The alternative starting point should probably autocreate the database, and should also autoregister all connectors. This will require a list, somewhere, of the connectors and authorities that are included, and their preferred UI names for that installation. This could come from the configuration information, or from some other place. Any ideas?
(c) There would need to an additional jar produced by the build process, which would be the equivalent of the solr start.jar, so as to make running the whole stack trivial.
(d) An "LCF API" web application, which provides access to all of the current LCF commands, would also be an obvious requirement to go forward with this model.
What are the disadvantages? Well, I think that the main problem would be security. This deployment model, though simple, does not control access to LCF is any way. You'd need to introduce another moving part to do that.
Bear in mind that this change would still not allow LCF to run using only one process. There are still separate RMI-based processes needed for some connectors (Documentum and FileNet). Although these could in theory be started up using Java Activation, a main reason for a separate process in Documentum's case is that DFC randomly crashes the JVM under which it runs, and thus needs to be independently restarted if and when it dies. If anyone has experience with Java Activation and wants to contribute their time to develop infrastructure that can deal with that problem, please let me know.
Finally, there is no way around the fact that LCF requires a well-performing database, which constitutes an independent moving part of its own. This proposal does nothing to change that at all.
Please note that I'm not proposing that the current model go away, but rather that we support both.
Thoughts?
Karl
Re: Proposal for simple LCF deployment model
Posted by Jack Krupansky <ja...@lucidimagination.com>.
A simple deployment ala Solr is a good goal. Integrating Jetty with the LCF
deployment will go a long way towards that goal. The database software
deployment (PostgreSQL) is the other half of the hassle with deploying LCF.
I think there are three distinct goals here: 1) A super-easy Solr-style
deployment for initial evaluation of LCF, 2) deployment of the LCF
components for full-blown application development where app server and
database might need to be different from the initial evaluation, and 3)
deployment of LCF components for production deployment of the full
application.
Right now, evaluation of LCF requires deployment of the source code and
building artifacts - Solr evaluation does not require that step. Eliminated
the source and build step will certainly help simplify the evaluation
process.
Another possible consideration is that although some of us are especially
interested in integration with Solr and doing so easily and robustly, Solr
is just one of the output connections and LCF could be deployed for
applications that do not involve Solr at all. So, maybe there should be an
extra deployment wiki page for Solr guys that focuses on use of LCF with
Solr and related issues. Whether that should be the default presentation in
the doc is a matter for debate. Right now, I see no harm with a Solr bias.
At least it is a convenient way to demonstrate end-to-end use of LCF.
-- Jack Krupansky
--------------------------------------------------
From: <ka...@nokia.com>
Sent: Friday, May 28, 2010 5:48 AM
To: <co...@incubator.apache.org>
Subject: Proposal for simple LCF deployment model
> The current LCF standard deployment model requires a number of moving
> parts, which are probably necessary in some cases, but simply introduce
> complexity in others. It has occurred to me that it may be possible to
> provide an alternate deployment model involving Jetty, which would reduce
> the number of moving parts by one (by eliminating Tomcat). A simple LCF
> deployment could then, in principle, look pretty much like Solr's.
>
> In order for this to work, the following has to be true:
>
> (1) jetty's basic JSP support must be comparable to Tomcat's.
> (2) the class loader that jetty uses for webapp's must provide class
> isolation similar to Tomcat's. If this condition is not met, we'd need to
> build both a Tomcat and a Jetty version of each webapp.
>
> The overall set of changes that would be required would be the following:
> (a) An alternative "start" entry point would need to be coded, which would
> start Jetty running the lcf-crawler-ui and lcf-authority-service webapps
> before bringing up the agents engine.
> (b) The alternative starting point should probably autocreate the
> database, and should also autoregister all connectors. This will require
> a list, somewhere, of the connectors and authorities that are included,
> and their preferred UI names for that installation. This could come from
> the configuration information, or from some other place. Any ideas?
> (c) There would need to an additional jar produced by the build process,
> which would be the equivalent of the solr start.jar, so as to make running
> the whole stack trivial.
> (d) An "LCF API" web application, which provides access to all of the
> current LCF commands, would also be an obvious requirement to go forward
> with this model.
>
> What are the disadvantages? Well, I think that the main problem would be
> security. This deployment model, though simple, does not control access
> to LCF is any way. You'd need to introduce another moving part to do
> that.
>
> Bear in mind that this change would still not allow LCF to run using only
> one process. There are still separate RMI-based processes needed for some
> connectors (Documentum and FileNet). Although these could in theory be
> started up using Java Activation, a main reason for a separate process in
> Documentum's case is that DFC randomly crashes the JVM under which it
> runs, and thus needs to be independently restarted if and when it dies.
> If anyone has experience with Java Activation and wants to contribute
> their time to develop infrastructure that can deal with that problem,
> please let me know.
>
> Finally, there is no way around the fact that LCF requires a
> well-performing database, which constitutes an independent moving part of
> its own. This proposal does nothing to change that at all.
>
> Please note that I'm not proposing that the current model go away, but
> rather that we support both.
>
> Thoughts?
> Karl
Re: Proposal for simple LCF deployment model
Posted by Jack Krupansky <ja...@lucidimagination.com>.
Okay, so LCF has a "config" file it loads on startup of the agents process
to set a small number of keyword/value parameters. The config file I
proposed would be used to "initialize" the LCF database. That would
initialize/re-initialize the "configuration" (connector classes,
connections, authorities, jobs, et al) from that "saved configuration" file.
So, the use case would be to set up an initial configuration of LCF, save it
to a file (presumably XML for readability and manual edit), and then the
deployment of LCF can be driven from that saved configuration file which
would initialize the connector classes and connections, et al in the
database.
This "initialize database from saved configuration file" operation could be
used for an evaluation deployment of LCF itself or for deployment of an
application that includes LCF.
The other use case which I previously mentioned is that users can upload
such a saved configuration file when they are requesting assistance.
Similarly, support staff for applications could also request that saved
configuration file from their customers to assist in tracking down issues.
So, all of the LCF "objects" would indeed live in the database, but the
saved configuration file would be a usable form for offsite examination and
recreation of the configuration that lives in the database.
-- Jack Krupansky
--------------------------------------------------
From: <ka...@nokia.com>
Sent: Friday, May 28, 2010 2:20 PM
To: <co...@incubator.apache.org>
Subject: RE: Proposal for simple LCF deployment model
> I already posted a response to this, but since it didn't seem to appear
> I'm going to try again.
>
> LCF already has dump and restore commands, but they don't currently write
> XML, they write binary data. Providing a way to write and read XML would
> be relatively straightforward. But this is *not* the same thing as
> defining everything in a global configuration file. LCF's connection,
> authority, and job definitions belong in the database.
>
> Another proposal that would be much more Solr-like would be to allow you
> to define such things through a servlet API. This is the approach I'd
> thought would work the best for the most people.
>
> Note that this is a very different question to the question of registering
> connectors and authorities. The latter operation is more akin to database
> initialization, and would be done in lieu of the current series of
> connector registration commands that you need to do to install connectors
> into LCF. It may even be that the proper answer is still not to do this
> step at all on the quick start, although I personally think the ideal
> would be some kind of automatic registration of all connectors and
> authorities that had been built during the last build step.
>
> Given this analysis, can you clarify your request? I'd also like to see
> use cases because without them we're just shooting the breeze.
>
> Karl
>
> -----Original Message-----
> From: ext Jack Krupansky [mailto:jack.krupansky@lucidimagination.com]
> Sent: Friday, May 28, 2010 10:33 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Proposal for simple LCF deployment model
>
>> (b) The alternative starting point should probably autocreate the
>> database,
>> and should also autoregister all connectors. This will require a list,
>> somewhere,
>> of the connectors and authorities that are included, and their preferred
>> UI
>> names for that installation. This could come from the configuration
>> information, or from some other place. Any ideas?
>
> I would like to see two things: 1) A way to request LCF to "dump" all
> configuration parameters, including parameters for all output connections,
> repositories, jobs, et al to an "LCF config file", and 2) The ability to
> start from scratch with a fresh deployment of LCF and feed it that config
> file to then create all of the output connections, repository connections,
> and jobs to match the LCF configuration state desired.
>
> Now, whether that config file is simple XML ala solrconfig.xml can be a
> matter for debate. Whether it is a separate file from the current config
> file can also be a matter for debate.
>
> But, in short, the answer to your question would be that there would be an
> LCF config file (not just the simple keyword/value file that LCF has for
> global configuration settings) to see the initial output connections,
> repository connections, et al.
>
> Maybe this config file is a little closer to the Solr schema file. I think
> it feels that way. OTOH, the list of registered connectors, as opposed to
> the user-created connections that use those connectors, seems more like
> Solr
> request handlers that are in solrconfig.xml, so maybe the initial
> "configuration" would be split into two separate files as in Solr. Or,
> maybe, the Solr guys have a better proposal for how they would have
> managed
> that split in Solr if they had it to do all over again. My preference
> would
> be one file for the whole configuration.
>
> Another advantage of such a config file is that it is easier for people to
> post problem reports that show exactly how they set up LCF.
>
> -- Jack Krupansky
>
> --------------------------------------------------
> From: <ka...@nokia.com>
> Sent: Friday, May 28, 2010 5:48 AM
> To: <co...@incubator.apache.org>
> Subject: Proposal for simple LCF deployment model
>
>> The current LCF standard deployment model requires a number of moving
>> parts, which are probably necessary in some cases, but simply introduce
>> complexity in others. It has occurred to me that it may be possible to
>> provide an alternate deployment model involving Jetty, which would reduce
>> the number of moving parts by one (by eliminating Tomcat). A simple LCF
>> deployment could then, in principle, look pretty much like Solr's.
>>
>> In order for this to work, the following has to be true:
>>
>> (1) jetty's basic JSP support must be comparable to Tomcat's.
>> (2) the class loader that jetty uses for webapp's must provide class
>> isolation similar to Tomcat's. If this condition is not met, we'd need
>> to
>> build both a Tomcat and a Jetty version of each webapp.
>>
>> The overall set of changes that would be required would be the following:
>> (a) An alternative "start" entry point would need to be coded, which
>> would
>> start Jetty running the lcf-crawler-ui and lcf-authority-service webapps
>> before bringing up the agents engine.
>> (b) The alternative starting point should probably autocreate the
>> database, and should also autoregister all connectors. This will require
>> a list, somewhere, of the connectors and authorities that are included,
>> and their preferred UI names for that installation. This could come from
>> the configuration information, or from some other place. Any ideas?
>> (c) There would need to an additional jar produced by the build process,
>> which would be the equivalent of the solr start.jar, so as to make
>> running
>> the whole stack trivial.
>> (d) An "LCF API" web application, which provides access to all of the
>> current LCF commands, would also be an obvious requirement to go forward
>> with this model.
>>
>> What are the disadvantages? Well, I think that the main problem would be
>> security. This deployment model, though simple, does not control access
>> to LCF is any way. You'd need to introduce another moving part to do
>> that.
>>
>> Bear in mind that this change would still not allow LCF to run using only
>> one process. There are still separate RMI-based processes needed for
>> some
>> connectors (Documentum and FileNet). Although these could in theory be
>> started up using Java Activation, a main reason for a separate process in
>> Documentum's case is that DFC randomly crashes the JVM under which it
>> runs, and thus needs to be independently restarted if and when it dies.
>> If anyone has experience with Java Activation and wants to contribute
>> their time to develop infrastructure that can deal with that problem,
>> please let me know.
>>
>> Finally, there is no way around the fact that LCF requires a
>> well-performing database, which constitutes an independent moving part of
>> its own. This proposal does nothing to change that at all.
>>
>> Please note that I'm not proposing that the current model go away, but
>> rather that we support both.
>>
>> Thoughts?
>> Karl
>
RE: Proposal for simple LCF deployment model
Posted by ka...@nokia.com.
I already posted a response to this, but since it didn't seem to appear I'm going to try again.
LCF already has dump and restore commands, but they don't currently write XML, they write binary data. Providing a way to write and read XML would be relatively straightforward. But this is *not* the same thing as defining everything in a global configuration file. LCF's connection, authority, and job definitions belong in the database.
Another proposal that would be much more Solr-like would be to allow you to define such things through a servlet API. This is the approach I'd thought would work the best for the most people.
Note that this is a very different question to the question of registering connectors and authorities. The latter operation is more akin to database initialization, and would be done in lieu of the current series of connector registration commands that you need to do to install connectors into LCF. It may even be that the proper answer is still not to do this step at all on the quick start, although I personally think the ideal would be some kind of automatic registration of all connectors and authorities that had been built during the last build step.
Given this analysis, can you clarify your request? I'd also like to see use cases because without them we're just shooting the breeze.
Karl
-----Original Message-----
From: ext Jack Krupansky [mailto:jack.krupansky@lucidimagination.com]
Sent: Friday, May 28, 2010 10:33 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Proposal for simple LCF deployment model
> (b) The alternative starting point should probably autocreate the
> database,
> and should also autoregister all connectors. This will require a list,
> somewhere,
> of the connectors and authorities that are included, and their preferred
> UI
> names for that installation. This could come from the configuration
> information, or from some other place. Any ideas?
I would like to see two things: 1) A way to request LCF to "dump" all
configuration parameters, including parameters for all output connections,
repositories, jobs, et al to an "LCF config file", and 2) The ability to
start from scratch with a fresh deployment of LCF and feed it that config
file to then create all of the output connections, repository connections,
and jobs to match the LCF configuration state desired.
Now, whether that config file is simple XML ala solrconfig.xml can be a
matter for debate. Whether it is a separate file from the current config
file can also be a matter for debate.
But, in short, the answer to your question would be that there would be an
LCF config file (not just the simple keyword/value file that LCF has for
global configuration settings) to see the initial output connections,
repository connections, et al.
Maybe this config file is a little closer to the Solr schema file. I think
it feels that way. OTOH, the list of registered connectors, as opposed to
the user-created connections that use those connectors, seems more like Solr
request handlers that are in solrconfig.xml, so maybe the initial
"configuration" would be split into two separate files as in Solr. Or,
maybe, the Solr guys have a better proposal for how they would have managed
that split in Solr if they had it to do all over again. My preference would
be one file for the whole configuration.
Another advantage of such a config file is that it is easier for people to
post problem reports that show exactly how they set up LCF.
-- Jack Krupansky
--------------------------------------------------
From: <ka...@nokia.com>
Sent: Friday, May 28, 2010 5:48 AM
To: <co...@incubator.apache.org>
Subject: Proposal for simple LCF deployment model
> The current LCF standard deployment model requires a number of moving
> parts, which are probably necessary in some cases, but simply introduce
> complexity in others. It has occurred to me that it may be possible to
> provide an alternate deployment model involving Jetty, which would reduce
> the number of moving parts by one (by eliminating Tomcat). A simple LCF
> deployment could then, in principle, look pretty much like Solr's.
>
> In order for this to work, the following has to be true:
>
> (1) jetty's basic JSP support must be comparable to Tomcat's.
> (2) the class loader that jetty uses for webapp's must provide class
> isolation similar to Tomcat's. If this condition is not met, we'd need to
> build both a Tomcat and a Jetty version of each webapp.
>
> The overall set of changes that would be required would be the following:
> (a) An alternative "start" entry point would need to be coded, which would
> start Jetty running the lcf-crawler-ui and lcf-authority-service webapps
> before bringing up the agents engine.
> (b) The alternative starting point should probably autocreate the
> database, and should also autoregister all connectors. This will require
> a list, somewhere, of the connectors and authorities that are included,
> and their preferred UI names for that installation. This could come from
> the configuration information, or from some other place. Any ideas?
> (c) There would need to an additional jar produced by the build process,
> which would be the equivalent of the solr start.jar, so as to make running
> the whole stack trivial.
> (d) An "LCF API" web application, which provides access to all of the
> current LCF commands, would also be an obvious requirement to go forward
> with this model.
>
> What are the disadvantages? Well, I think that the main problem would be
> security. This deployment model, though simple, does not control access
> to LCF is any way. You'd need to introduce another moving part to do
> that.
>
> Bear in mind that this change would still not allow LCF to run using only
> one process. There are still separate RMI-based processes needed for some
> connectors (Documentum and FileNet). Although these could in theory be
> started up using Java Activation, a main reason for a separate process in
> Documentum's case is that DFC randomly crashes the JVM under which it
> runs, and thus needs to be independently restarted if and when it dies.
> If anyone has experience with Java Activation and wants to contribute
> their time to develop infrastructure that can deal with that problem,
> please let me know.
>
> Finally, there is no way around the fact that LCF requires a
> well-performing database, which constitutes an independent moving part of
> its own. This proposal does nothing to change that at all.
>
> Please note that I'm not proposing that the current model go away, but
> rather that we support both.
>
> Thoughts?
> Karl
RE: Proposal for simple LCF deployment model
Posted by ka...@nokia.com.
I already posted a response to this, but since it didn't seem to appear I'm going to try again.
LCF already has dump and restore commands, but they don't currently write XML, they write binary data. Providing a way to write and read XML would be relatively straightforward. But this is *not* the same thing as defining everything in a global configuration file. LCF's connection, authority, and job definitions belong in the database.
Another proposal that would be much more Solr-like would be to allow you to define such things through a servlet API. This is the approach I'd thought would work the best for the most people.
Note that this is a very different question to the question of registering connectors and authorities. The latter operation is more akin to database initialization, and would be done in lieu of the current series of connector registration commands that you need to do to install connectors into LCF. It may even be that the proper answer is still not to do this step at all on the quick start, although I personally think the ideal would be some kind of automatic registration of all connectors and authorities that had been built during the last build step.
Given this analysis, can you clarify your request? I'd also like to see use cases because without them we're just shooting the breeze.
Karl
-----Original Message-----
From: ext Jack Krupansky [mailto:jack.krupansky@lucidimagination.com]
Sent: Friday, May 28, 2010 10:33 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Proposal for simple LCF deployment model
> (b) The alternative starting point should probably autocreate the
> database,
> and should also autoregister all connectors. This will require a list,
> somewhere,
> of the connectors and authorities that are included, and their preferred
> UI
> names for that installation. This could come from the configuration
> information, or from some other place. Any ideas?
I would like to see two things: 1) A way to request LCF to "dump" all
configuration parameters, including parameters for all output connections,
repositories, jobs, et al to an "LCF config file", and 2) The ability to
start from scratch with a fresh deployment of LCF and feed it that config
file to then create all of the output connections, repository connections,
and jobs to match the LCF configuration state desired.
Now, whether that config file is simple XML ala solrconfig.xml can be a
matter for debate. Whether it is a separate file from the current config
file can also be a matter for debate.
But, in short, the answer to your question would be that there would be an
LCF config file (not just the simple keyword/value file that LCF has for
global configuration settings) to see the initial output connections,
repository connections, et al.
Maybe this config file is a little closer to the Solr schema file. I think
it feels that way. OTOH, the list of registered connectors, as opposed to
the user-created connections that use those connectors, seems more like Solr
request handlers that are in solrconfig.xml, so maybe the initial
"configuration" would be split into two separate files as in Solr. Or,
maybe, the Solr guys have a better proposal for how they would have managed
that split in Solr if they had it to do all over again. My preference would
be one file for the whole configuration.
Another advantage of such a config file is that it is easier for people to
post problem reports that show exactly how they set up LCF.
-- Jack Krupansky
--------------------------------------------------
From: <ka...@nokia.com>
Sent: Friday, May 28, 2010 5:48 AM
To: <co...@incubator.apache.org>
Subject: Proposal for simple LCF deployment model
> The current LCF standard deployment model requires a number of moving
> parts, which are probably necessary in some cases, but simply introduce
> complexity in others. It has occurred to me that it may be possible to
> provide an alternate deployment model involving Jetty, which would reduce
> the number of moving parts by one (by eliminating Tomcat). A simple LCF
> deployment could then, in principle, look pretty much like Solr's.
>
> In order for this to work, the following has to be true:
>
> (1) jetty's basic JSP support must be comparable to Tomcat's.
> (2) the class loader that jetty uses for webapp's must provide class
> isolation similar to Tomcat's. If this condition is not met, we'd need to
> build both a Tomcat and a Jetty version of each webapp.
>
> The overall set of changes that would be required would be the following:
> (a) An alternative "start" entry point would need to be coded, which would
> start Jetty running the lcf-crawler-ui and lcf-authority-service webapps
> before bringing up the agents engine.
> (b) The alternative starting point should probably autocreate the
> database, and should also autoregister all connectors. This will require
> a list, somewhere, of the connectors and authorities that are included,
> and their preferred UI names for that installation. This could come from
> the configuration information, or from some other place. Any ideas?
> (c) There would need to an additional jar produced by the build process,
> which would be the equivalent of the solr start.jar, so as to make running
> the whole stack trivial.
> (d) An "LCF API" web application, which provides access to all of the
> current LCF commands, would also be an obvious requirement to go forward
> with this model.
>
> What are the disadvantages? Well, I think that the main problem would be
> security. This deployment model, though simple, does not control access
> to LCF is any way. You'd need to introduce another moving part to do
> that.
>
> Bear in mind that this change would still not allow LCF to run using only
> one process. There are still separate RMI-based processes needed for some
> connectors (Documentum and FileNet). Although these could in theory be
> started up using Java Activation, a main reason for a separate process in
> Documentum's case is that DFC randomly crashes the JVM under which it
> runs, and thus needs to be independently restarted if and when it dies.
> If anyone has experience with Java Activation and wants to contribute
> their time to develop infrastructure that can deal with that problem,
> please let me know.
>
> Finally, there is no way around the fact that LCF requires a
> well-performing database, which constitutes an independent moving part of
> its own. This proposal does nothing to change that at all.
>
> Please note that I'm not proposing that the current model go away, but
> rather that we support both.
>
> Thoughts?
> Karl
Re: Proposal for simple LCF deployment model
Posted by Jack Krupansky <ja...@lucidimagination.com>.
> (b) The alternative starting point should probably autocreate the
> database,
> and should also autoregister all connectors. This will require a list,
> somewhere,
> of the connectors and authorities that are included, and their preferred
> UI
> names for that installation. This could come from the configuration
> information, or from some other place. Any ideas?
I would like to see two things: 1) A way to request LCF to "dump" all
configuration parameters, including parameters for all output connections,
repositories, jobs, et al to an "LCF config file", and 2) The ability to
start from scratch with a fresh deployment of LCF and feed it that config
file to then create all of the output connections, repository connections,
and jobs to match the LCF configuration state desired.
Now, whether that config file is simple XML ala solrconfig.xml can be a
matter for debate. Whether it is a separate file from the current config
file can also be a matter for debate.
But, in short, the answer to your question would be that there would be an
LCF config file (not just the simple keyword/value file that LCF has for
global configuration settings) to see the initial output connections,
repository connections, et al.
Maybe this config file is a little closer to the Solr schema file. I think
it feels that way. OTOH, the list of registered connectors, as opposed to
the user-created connections that use those connectors, seems more like Solr
request handlers that are in solrconfig.xml, so maybe the initial
"configuration" would be split into two separate files as in Solr. Or,
maybe, the Solr guys have a better proposal for how they would have managed
that split in Solr if they had it to do all over again. My preference would
be one file for the whole configuration.
Another advantage of such a config file is that it is easier for people to
post problem reports that show exactly how they set up LCF.
-- Jack Krupansky
--------------------------------------------------
From: <ka...@nokia.com>
Sent: Friday, May 28, 2010 5:48 AM
To: <co...@incubator.apache.org>
Subject: Proposal for simple LCF deployment model
> The current LCF standard deployment model requires a number of moving
> parts, which are probably necessary in some cases, but simply introduce
> complexity in others. It has occurred to me that it may be possible to
> provide an alternate deployment model involving Jetty, which would reduce
> the number of moving parts by one (by eliminating Tomcat). A simple LCF
> deployment could then, in principle, look pretty much like Solr's.
>
> In order for this to work, the following has to be true:
>
> (1) jetty's basic JSP support must be comparable to Tomcat's.
> (2) the class loader that jetty uses for webapp's must provide class
> isolation similar to Tomcat's. If this condition is not met, we'd need to
> build both a Tomcat and a Jetty version of each webapp.
>
> The overall set of changes that would be required would be the following:
> (a) An alternative "start" entry point would need to be coded, which would
> start Jetty running the lcf-crawler-ui and lcf-authority-service webapps
> before bringing up the agents engine.
> (b) The alternative starting point should probably autocreate the
> database, and should also autoregister all connectors. This will require
> a list, somewhere, of the connectors and authorities that are included,
> and their preferred UI names for that installation. This could come from
> the configuration information, or from some other place. Any ideas?
> (c) There would need to an additional jar produced by the build process,
> which would be the equivalent of the solr start.jar, so as to make running
> the whole stack trivial.
> (d) An "LCF API" web application, which provides access to all of the
> current LCF commands, would also be an obvious requirement to go forward
> with this model.
>
> What are the disadvantages? Well, I think that the main problem would be
> security. This deployment model, though simple, does not control access
> to LCF is any way. You'd need to introduce another moving part to do
> that.
>
> Bear in mind that this change would still not allow LCF to run using only
> one process. There are still separate RMI-based processes needed for some
> connectors (Documentum and FileNet). Although these could in theory be
> started up using Java Activation, a main reason for a separate process in
> Documentum's case is that DFC randomly crashes the JVM under which it
> runs, and thus needs to be independently restarted if and when it dies.
> If anyone has experience with Java Activation and wants to contribute
> their time to develop infrastructure that can deal with that problem,
> please let me know.
>
> Finally, there is no way around the fact that LCF requires a
> well-performing database, which constitutes an independent moving part of
> its own. This proposal does nothing to change that at all.
>
> Please note that I'm not proposing that the current model go away, but
> rather that we support both.
>
> Thoughts?
> Karl