geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <hcun...@gmail.com>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Sat, 08 Apr 2006 12:49:54 GMT
Hi All,
here  are some thoughts from my old IT Spec perspective :)

Maybe I'm smoking something but wouldn't it be easier for the end user if we just offer them
a 
simpler directory structure for the applications !?!?!?

- This structure would be beneficial from a production stand point
<system_apps>/
here we put all the product applications. Very little end user updates here, maybe some 
customization at the initial build time if they are customizing Geronimo. We could keep all
the apps 
JARed in this structure.

<user_apps>/
here we put all the user applications deployed via the deployer tool or the console. Here
is where 
we have the bigger problem if the users use the same philosophy as we do with maven. I think
here is 
where we need to focus.

<hot_deploy>/
this is within the <user_apps> dir. It will not be used too often in production, eitherway,
most of 
the apps deployed here will be packaged as a jar or ear so we should not see any problems
with the 
naming here.




- The same structure from a development/customization stand point
<system_apps>/
lots of updates from the end user. It might still be more convenient to maintain a short naming

convention for easier browseability (hmmm, does that word actually exists!?). What is the
problem 
using back the jars? repackaging? can we provide a tool (script, classloader!?) for updating
the jar 
automatically?

<user_apps>/
not much end user interaction, most of the testing may be performed via hot deployment.

<hot_deploy>/
same as before, most of the apps deployed here will be packaged as a jar or ear so we should
not see 
any problems with the naming here.

Cheers!
Hernan


David Jencks wrote:
> 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