For the cache, I initially implement a reproducable long url -> short
url using a CRC32 + shortfilename (which it still does), but I later
added a serialized hash for faster lookups + to make startup easier.
The cache impl is not really the issue here, it just tickles the real
problem.
The main issue that I have is that our deployment system is pushing on
the edge of OS compatiblity by using these really long file names...
where it does not appear that we need to do so
I think we should either revert to number incremented (or new
UID().toString() prefixed filenames) or some other simple and shorter
reproducable mapping system.
Perhaps providing a mgmnt operation to reverse the maping is ok? This
can simply be an in memory map, since the tmp/deploy stuff does not live
beyond the life of the VM.
If all we are using full url filenames for is for developer convienece,
then scew it, we don't need to be convienent at the expense of being
compatible. If there is a real problem concering security policies,
then lets look into what our options are to solving that with out using
long filesnames.
Is there any issue short of developer conveience which motivated us to
use long filenames?
--jason
David Jencks wrote:
>We had it working for a while with unique file names, namely an incremented
>number/short-jar-name. I don't care, going back to this is fine with me.
>Many people liked being able to find the deployed copy.
>
>This however is not reproducible, and I would expect that your cache would
>need reproducible mappings. If I am wrong, wonderful. Otherwise I can't
>think of much except a mapping file, maybe properties
>url=number
>to identify where the copy is.
>
>
>david jencks
>
>On 2002.04.03 17:58:02 -0500 Jason Dillon wrote:
>
>>>
>>>What is this problem? I think any reproducible 1-1 mapping will work,
>>>
>>but I
>>
>>>don't know of any other than using the whole URL.
>>>david jencks
>>>
>>The problem is that on windows (ick) it limits the length of a filename
>>unreasonabily. This problem shows up with the currently deployment
>>scheme of taking the entire URL of a deployment and using that as the
>>path under the ${jboss.server.home.dir}/tmp/deploy directory. This
>>means that the length of the filename is now
>>"${jboss.server.home.dir}/tmp/deploy".length + url.toString.length. If
>>this is > then the giving crappy limit on win32 we are hosed.
>>
>>It would be *safer* to employ a different method for the url suffix
>>bits, as the first part is a sunk cost. Sure we can tell users to run
>>from a different directory, using a shorter name, but we can't really
>>control the URLs that come in for deployment.
>>
>>I personally have the following setup (which I don not think
>>unreasonable):
>>
>> base project dir: /home/jason/workspace/jboss/jboss-all (prefixed by
>>c:\cygwin for winblows)
>>
>>This means that the final value for ${jboss.server.home.dir} is:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default
>>
>>Now the deployments live under conf/ and deploy/ relative to this path,
>>longest filename currently seems to be:
>>
>>new-hsqldb-default-service.xml
>>
>>which makes the actual deployment file:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
>>
>>Now this full path will be constructed under:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy
>>
>>making the full deployed filename:
>>
>>C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\tmp\deploy\C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2\server\default\deploy\new-hsqldb-default-service.xml
>>
>>with translations applied, I am too lazy for this at the moment.
>>
>>Now in comes the cache repository. If I employed the same scheme, then
>>the deployment URL which is given to MainDeployer would be about as long
>>as the tmp\deploy version... which would then become even longer once it
>>was copied to tmp\deploy.
>>
>>See what I mean? If this is all because of security policies, then I
>>suggest we need to find another way to implement the policy, perhaps
>>even punting easier configuration until 1.4 is the defacto. If not
>>please explain why we need this, cause I just don't understand.
>>
>>These insanely long filenames are going to bite us... they have already
>>bitten me several times.
>>
>>There must be a better solution, which does not force users to hack up
>>there environment to work around this OS limitation... perhaps there are
>>other OS'n out there which have similar limits... who knows. Lets not
>>stick our necks out to find out.
>>
>>Can you please explain all of the details why we need these long
>>filenames. I don't get it.
>>
>>--jason
>>
>>
>>
>>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
