JDK will allow a full-path of LESS THAN 260 bytes (not characters, bytes) only.  Anything longer and an Exception is thrown.  From Windows Native Code's "open()" function.

Attempted File:
C:/ias7/domains/domain1/server1/applications/j2eeapps/ArrayApp_1/ArrayService_War_war/
ArrayServiceServantInterface_ArrayTest_getArrayMixedPrimitiveAndComposite_ResponseStruct_SOAPSerializer.class

Mon Sep 23 12:32:10 MDT 2002	bn80925

Mon Sep 23 12:34:49 MDT 2002	bn80925

Note that in the studio installation this is a little worse because the
s1as7 installation is in:
c:/sun/studio/appserver7/domains/...

Also related is that the studio user directory is another place these files
end up, which is in
c:/documents and settings/Joe User/studio5_se_user/...

But by far the longest component to these names are the jwsdp generated
names.
  xxxxx@xxxxx   2004-04-06

User can create appserver domain in directory named something like: 
c:\f

User can have their userdir be c:\u or something similar.

User can have short classnames and method names and a shallow package structure.
  xxxxx@xxxxx   2004-04-06

The example file, that is in a zipfile, had a full path 276 characters long.  It is impossible for the current code to explode the file into it's given directory.

Ideas for Work-arounds:

1. Use relative instead of absolute paths
 -- If it were possible, we could change-directory to the App's root directory.  That would knock quite a bit off the path.  In the example in the description, it would cut-out:

C:/ias7/domains/domain1/server1/applications/j2eeapps/ArrayApp_1ArrayApp_1 (76 bytes)

Too bad that it is IMPOSSIBLE to change directory at runtime in java!!

1B) We could run the Zip code in a separate VM -- and have the VM start in the right directory.  This solution is error-prone and messy.
That would make the zip explosion work.  Then something else in Deployment will break.  As soon as the full-path for one of these files is used, JDK will fail.

2) Use a temp-dir with a short name to explode everything into.  When done exploding, copy the tree into the final area.  Oops -- JDK will blow up copying the files.  So to copy the files, we need to run the copying code in a separate JVM and do the trick with changing the current directory.

*****  I think this is hopeless -- there are a million places that uses filepaths.  What about the Class Loaders with paths > 260 chars.  Etc.,

I think we need the JVM to start supporting filenames > 260 characters
I think Studio needs to create much shorter filenames when it creates Web Services



Mon Sep 23 12:51:42 MDT 2002	bn80925
I added some code to the appropriate place in ZipFile.java that checks for filename >= 260.
It then throws an official ZipFileException...

Thu Sep 26 13:02:09 MDT 2002	bn80925


JAXRPC RI generates long class names. This causes problems with JDK on some platforms.

For e.g:
C:/ias7/domains/domain1/server1/applications/j2eeapps/ArrayApp_1/ArrayService_War_war/
ArrayServiceServantInterface_ArrayTest_getArrayMixedPrimitiveAndComposite_ResponseStruct_SOAPSerializer.class

In the above, appserver itself produces long directory name. Some of the class names are mandated by spec. For e.g: if a complex type has long XML name, the corresponding java bean has long class name. or Service name in WSDL is long, the corresponding class name is long. So I guess we cannot help in many cases w.r.t JAXRPC specification.

But RI can reduce some names like "_ResponseStruct_SOAPSerializer". This invovles changes in many files and cannot be done for JWSDP1.4 release.

  xxxxx@xxxxx   2004-04-22

I checked a simple java snippet (attached as testbug.java) to verify that the bug still exists in JDK 1.4.  It does.  You can *create* a 298 character file  -- but it can't be opened.  Here is the output from the test program:

length = 249
null
length = 298
java.io.FileNotFoundException: C:\tmp\abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij\abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij\abcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghijabcdefghij\abcdefghijabcdefghijabcdefghijabcdefghij\bolongo (The system cannot find the file specified)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:106)
        at testbug.main(testbug.java:43)

  xxxxx@xxxxx   2004-04-22
win32 longpath support has been fixed in mustang, see#6182812, it's no longer
reproducible in 6.0, close as "dup of 6182812". The backport to 5.0u has been
approved/reviewed.
Posted Date : 2005-09-06 16:35:42.0