tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Where can I store data files in a tomcat war
Date Tue, 01 Jul 2014 15:16:16 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 6/30/14, 4:23 PM, Mark Eggers wrote:
> Chris,
> 
> On 6/30/2014 12:10 PM, Christopher Schultz wrote:
>> Mark,
> 
>> On 6/27/14, 4:40 PM, Mark Eggers wrote:
>>> Paul,
> 
>>> On 6/27/2014 1:25 PM, Paul Taylor wrote:
>>>> On 27/06/2014 19:59, Christopher Schultz wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>> 
>>>>> Paul,
>>>>> 
>>>>> On 6/27/14, 8:34 AM, Paul Taylor wrote:
>>>>>> I have a simple WAR based web application that uses
>>>>>> lucene created indexes to provide search results in a
>>>>>> xml format, the location of the indexes (outside of the
>>>>>> war) are referred in the web.xml.
>>>>>> 
>>>>>> It works fine locally but I want to deploy it using
>>>>>> Elastic Beanstalk within Amazon Webservices but for it to
>>>>>> work I need the data files within the war, then I can
>>>>>> allow EB to create new instances when load
>>>>>> balancing/scaling and it will work because the data
>>>>>> fields are included in the war at deployment time. I have
>>>>>> checked that EB does unjar the war so that when my code
>>>>>> comes to use the files they will be real files not still
>>>>>> contained within the War.
>>>>>> 
>>>>>> With that in mind where could i put the data files so
>>>>>> they not considered  by tomcat as java classes , and 
>>>>>> supplementary question how do I modify my pom file to do
>>>>>>  this with maven
>>>>> What?
>>>>> 
>>>>> Java won't try to load random files as .class files.
>>>> I tried putting the files into the resources directory of my
>>>>  maven project, when I deployed the resulting war it would 
>>>> start (did previously) and opening the war found the files
>>>> were added under WEB-INF/classes, that is what I meant. So I
>>>> need to put them somewhere else.
> 
> 
>>> It sounds like you're not building these within the deployed 
>>> application, but adding them at build time.
> 
>>> Why can't your application read the files from WEB-INF/classes
>>>  with getResourceAsStream?
> 
>> I think the issue is that Lucene reads a bunch of files to manage
>>  its index, and there is not (currently) an implementation that
>> can ready them out of a ZIP archive.
> 
>> So I think Paul needs to expand the assets to the disk and then 
>> use the Lucene classes that do understand the disk.
> 
>> I know you can use a RDBMS to back a Lucene index, so I'm 
>> surprised there isn't anything (that I could see on my quick 
>> review) to support loading from a ZIP resource.
> 
>> -chris
> 
> I guess I'm a little confused as to what this means.
> 
> I have a simple WAR based web application that uses Lucene created
> indexes to provide search results in a xml format.
> 
> Especially given the following context:
> 
> and supplementary question how do I modify my pom file to do this
> with maven
> 
> I was under the impression that Paul was building a separate 
> application using Lucene during the build stage to create the
> indexes, but then using an application - specific mechanism to use
> those indexes.

That's what I thought, too.

> If Paul is using Lucene API (Document, DirectoryReader, etc.),
> then accessing them if they're packed in a JAR or WAR will be a
> bit difficult. Apparently Lucene requires random access to the
> directory listing, which isn't available (I think) with the normal
> JAR utilities.

Right: that's why I suggested that his application extract the indexes
to regular files on the disk in order to read them using Lucene.

> If the Lucene API is used, then writing a servlet context listener 
> that digs out the initial indexes and places them in java.io.tmpdir
> in a known subdirectory is probably the way to go. This ensures
> that even if a WAR file is not exploded, the Lucene DirectoryReader
> API can get to the files.

That's precisely what I was suggesting.

> Another way to approach this is to extend DirectoryReader and 
> implement something like TrueVFS, but that seems to be way more
> work than it's worth.

Yes, I think it is more work than necessary. Extracting to the fs will
be the simplest solution IMO.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTstC7AAoJEBzwKT+lPKRYoKAQAKLAzj3hway9z6jhDvt1XCP1
dGk7h5/6iO4p6Rn49GYZzQmkMEQ1rVqYcmj4L/PX10UP18A3D6nAmEVCoZDCEl8H
khCXkLUPsWU/zNe175eC9OLidoKuCsgDlypNR/6x2WltbEK8Vcv13XfJocCPf2Qw
wSGp0+C7/bKljDg59uDmM/zMQH6kDT/n0uMiz2Y8TO7vi9rD1el0TcMg5t/ZcXqO
qctXB6oWCXixdWp45U8PkZEEQML7m7bh/AbrXq9CtahVTdX2QHvEP4SzFPhoFpTC
SIiGfs01B7shWMTgr0yoUVPr9BYYtxU2u1YhQM1dGCYLvQvd12gqoVo5uHQS9506
fEKGuIiLZkDDWNCQXqK7o3R6mJnThrvy8f0EPy4KSI9Glfnb42FrFkFn+W0PGBjc
VDs2iJX6Bp/4Bk0YWvJyPQPAfCbnYSQow0SqK+hlraK6tMh6wRZLkqgkRAErd6h/
5eQOg4oCrJXBm3+GZlqYl1FUUgzY9TmCoptV2G5L0Sjo7ieAkBDz6ZdE+DNJQnjV
lL+JkfeHlK/zcGYr9eNP32dWglATIFw8HFUku4dgsVjecP5frPC1dVHf868RQDLt
1JxccdedEp+gYOPRCyDb8+NlQqmcTpF7gafjzr54mYrLU2MFvOGaSEXX02Ore1XG
949GyjZ3wloBB3aD3Js1
=wvlO
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message