geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Fri, 07 Apr 2006 18:13:54 GMT
I've thought about not unpacking car files but rather flattening  
everything in them and writing a classloader that can deal with  
offsets within a jar file.  This would completely solve the problem  
except for peoples desire to fiddle with jsp files on the fly.

For this, maybe we should allow a car file has the config.ser (in  
xml :-) as now but the rest of it is a map to the actual locations of  
the files?  I think it might be possible to include this in either a  
second "development-friendly" config store (in a special location) or  
the standard config store.

thanks
david jencks

On Apr 7, 2006, at 10:29 AM, Dain Sundstrom wrote:

> Please stop blaming the m2 repo structure for this problem.  The m2  
> repo structure only increased the path of our longest path by 36  
> characters.  The true problem is that David and I moved the  
> unpacked configurations into the repository.  We did this because  
> of the chunkiness of the numbered directories in the config-store  
> directory.  The m2 repository structure makes querying the  
> repository for version numbers possible and it is this querying  
> that makes optional version numbers possible.
>
> I think we have two issues that both must be addressed:
>
> 1) The ears we generate in our build have very long internal paths,  
> 154 characters.  This is just bad form, and vastly reduces the user  
> path head room.
>
> 2) We need to move the unpacked ears our of the repository and into  
> a separate flat directory structure.
>
> I can look at the second one later today after fixing the redeploy  
> command.  Can someone take a look at getting our build to jar up  
> the classes and compiled jsps in our build.  I'll fix the generated  
> classes in our build.
>
> -dain
>
> On Apr 7, 2006, at 6:50 AM, Matt Hogstrom wrote:
>
>> Thinking about this some more I believe we need to make a good  
>> decision here as having to revisit this issue in the future will  
>> cause users to have to change how the server works.  I've been  
>> talking to a new user that has a larger server farm and is very  
>> interested in the Geronimo server as their new foundation.   
>> However, they run a few thousand servers and are VERY sensitive to  
>> changes in the behaviour of the server in terms of how it impacts  
>> them.  Changes to the repsoistory will affect their operational  
>> experience dramatically and they do run Windows (go Bill Gates).   
>> They are watching this thread with keen interest.  Their biggest  
>> concern is changing how their build and distribution system works  
>> and changes in this area is highly disruptive for them.
>>
>> My view of the problem is that there are really three distinct  
>> areas of a path.  They are the user area, the server area and the  
>> application area.  Let me splain...
>>
>> | 0000000000000000000000000000 |  
>> 11111111111111111111111111111111111111111 | 2222222222222222222 ...
>> C:\my\directory\before\geronimo\geronimo-1.1\repository 
>> \com.apache.geronimo\console-1.1\appArtifacts
>>
>> The area in the 0's are controlled by the user and we need to  
>> leave more headroom than a few characters so they can manage  
>> multiple deployments of Geronimo; this could include multiple  
>> versions or multiple deployments.  The users probably enjoy  
>> flexibility in naming as much as we do.  We don't have control  
>> over this but we influence how much headroom is available.
>>
>> The 1's is really the area we have control over as this is the  
>> server proper.  This includes the area from the top of the tree to  
>> the end of where the files we create end.  So, for instance, this  
>> includes var, repository, etc.  Since were currently experiencing  
>> this problem in the respository I think we should focus on this area.
>>
>> Finally, the 2's are the area that include the application and  
>> Maven dependent information.  The Maven naming convention is  
>> verbose.  The current implementation needs to be changed, the  
>> question is how and can the change survive several releases so  
>> that our users are not forced to change their deployments on each  
>> subsequent release.  *One immediate thought I had was to place  
>> applications back into the config-store (or equivalent name).   
>> Rather than simply use a number as we did previously perhaps the  
>> configId of the deployment would be appropriate.  Its human  
>> readable and would be shorter than the current maven structure.*   
>> I highlighted the previous as I think this is the best option  
>> based on what I know today.
>>
>> Perhaps there some way to provide a Maven abstraction that would  
>> map Maven dir names to an internal format for us.  I expect if we  
>> are running into this its only a matter of time befoew other Maven  
>> users experience the same issues.  For us its the nesting of Maven  
>> articacts / configurations that is causing us the problem.  Jason,  
>> thoughts?
>>
>> Whatever we decide we need to ensure that it is stable enough to  
>> work for a period of time.
>>
>> Matt
>>
>>
>> Dain Sundstrom wrote:
>>> Man I hate Windows....
>>> Anyway, if you have a real OS and list the files in an assembly,  
>>> you  will see that the problem is caused by the combination of  
>>> two  changes: we now keep configurations in the repository and we  
>>> unpack  them. If you look closer you will see that the big  
>>> offenders are  unpacked ears and wars.
>>> I believe the following are the longest paths in the server:
>>> (270)
>>> geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/ 
>>> 1.1- SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader- 
>>> web-1.1- SNAPSHOT.war/META-INF/geronimo-generated/org/apache/ 
>>> geronimo/axis/ client/GenericServiceEndpointWrapper$ 
>>> $EnhancerByCGLIB$$36344d29.class
>>> (264)
>>> geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-  
>>> SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console-  
>>> standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/ 
>>> console/ databasemanager/wizard/DatabasePoolPortlet 
>>> $ResourceAdapterParams.class
>>> One thing to note here is that the longest paths are all classes   
>>> generated by Geronimo, nested classes in wars or compiled JSP  
>>> pages.   Someone should look into makeing maven jar the latter  
>>> two and  Geronimo should be creating jars when generating classes  
>>> (actually we  should stop generating classes a head of time but  
>>> that is another  story).
>>> Breaking down the longest path, we have:
>>> GeronimoName (22)
>>>   geronimo-1.1-SNAPSHOT
>>> RepositoryPath (55)
>>>   repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
>>> FileName (39)
>>>   daytrader-derby-jetty-1.1-SNAPSHOT.car
>>> NestedPath (154)
>>>   daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/  
>>> apache/geronimo/axis/client/GenericServiceEndpointWrapper$  
>>> $EnhancerByCGLIB$$36344d29.class
>>> The first thing to note is if we simply replace "SNAPSHOT" with  
>>> "0",  we drop 28 characters which makes the longest path 242; not  
>>> enough  head room.  Of course, when we switch our groupId to the  
>>> maven  standard org.apache.geronimo we eat up 20 more  
>>> characters.  If we are  going to unpack war files there is very  
>>> little we can do about the  NestedPath, so we have very few  
>>> choices left.  If we simply combine  combine ${GeronimoName}/$ 
>>> {FileName}/${NestedPath} we are up to 115  characters leaving  
>>> only 41 characters for anything else, but when you  add back the  
>>> 28 from "SNAPSHOT", you get to a more comfortable level.
>>> I think if we combine this problem with Sachin's request for a   
>>> separate directory for applications, we could do something like  
>>> this:
>>> ${GeronimoName}/apps/${FileName}/${NestedPath}
>>> There are several problems with this.  I think users will confuse  
>>> the  hot-deploy directory "deploy" with the "apps" directory  
>>> [1].  Then  again, if you look at the problem configurations they  
>>> are all apps  the users may want to remove (sample apps and the  
>>> console), so may be  we should just put these in the hot-deploy  
>>> directory.  Another  problem is that it will be much more  
>>> difficult to query a repository  without a directory structure.   
>>> The server will basically have to  read the configuration from  
>>> these apps on startup to determine what  they are, so again we  
>>> may just want to use the hot-deploy directory.   I'm not a fan of  
>>> the hot-deploy directory, but I'm not sure there is  a better  
>>> solution.
>>> Again I renew my hate of Windows...
>>> /me shakes his fist at Bill Gates
>>> -dain
>>> [1] As a side issue, I prefer the name "apps" because it will be  
>>> most  familiar to tomcat users.
>


Mime
View raw message