geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Update on Long Paths
Date Thu, 20 Apr 2006 23:57:02 GMT
Ever since I applied Prasad's patch for jaring the WEB-INF/classes of  
our wars the server has been well under the windows path length  
limit.  Unfortunately, you couldn't build the server on windows since  
we actually assemble the server in a deeply nested path.

I just applied a patch from Joe Bohn that shortened the names of  
nested modules in ears.  This has brought the longest path in our  
build to:

229 assemblies/j2ee-installer/target/geronimo-1.1-SNAPSHOT/repository/ 

So as long as you checkout path is less then 27 characters you should  
be able to build on windows.


On Apr 14, 2006, at 6:03 PM, John Sisson wrote:

> It would be good if we could use precompiled jsps so the server is  
> always responsive - that first time hit often happens when you are  
> running a demo :-)
> John
> Prasad Kashyap wrote:
>> I could not use the ant task to precompile jsps. Using the following,
>> simply  nothing happens.
>> <ant:taskdef classname="org.apache.jasper.JspC" name="ant:jasper2"
>>  classpathref="jspc.classpath"/>
>> <ant:jasper2 validateXml="false" uriroot="${webroot}"
>> webXmlFragment="${webroot}/generated_web.xml"  
>> addWebXmlMappings="true"
>> outputDir="${outDir}" />
>> So by passing a few more args to our existing <ant:java >  
>> execution, I
>> was able to generate the xml file too. Using the option
>> addWebXmlMappings, I tried to merge the web.xmls but JspC cried that
>> it was a unrecognized option.
>>      <!-- arg value="-addWebXmlMappings"/>
>>      <arg value="true"/  -->
>> Looking at the JspC code,
>> jasper2/src/share/org/apache/jasper/
>> it seems like you can't pass addWebXmlMappings in a java command line
>> argument. It is not recognized or set by the setArgs(). Seems like a
>> jasper bug ?
>> So I added another goal to our deployment plugin called  
>> "mergeWebXML".
>> This goal merges the generated web.xml fragment with the existing one
>> from source.
>> When I spoke to the Tomcat guys, they feel that precompiling JSPs
>> doesn't buy us anything anymore, except for that first time hit. The
>> request mapper is supposedly fixed in 5.5.x versions and thus we
>> shouldn't see any other performance hit.
>> Anyways, I have uploaded the patch to
>> Cheers
>> Prasad
>> On 4/14/06, Prasad Kashyap <> wrote:
>>> OK. I'll take care of the JSP pages. I am done with jar'ing the
>>> generated class files. I shall look into generating a web.xml and
>>> merging it.
>>> Cheers
>>> Prasad
>>> On 4/13/06, Dain Sundstrom <> wrote:
>>>> Prasad got the patch working on all web applications.  The next big
>>>> offenders left are the auto generated WebServices wrapper class and
>>>> the precompiled JSP pages.  David Jencks has a patch for the
>>>> WebServices class, but we are waiting to get the TCK running so we
>>>> can judge the impact.  I disabled precompiled JSP pages, as they
>>>> didn't work anyway.  We generate the classes and compile them,  
>>>> but we
>>>> never added them to the class path and we are not merging  
>>>> generated-
>>>> web.xml into our web.xml.  I'm hoping Prasad has time to tackle  
>>>> this
>>>> one.
>>>> With these patches in, except for the WS class, the longest paths
>>>> including server name is 224 and 217 characters:
>>>> geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty-
>>>> streamer-client/1.1-SNAPSHOT/daytrader-derby-jetty-streamer-
>>>> activemq-optional-3.2.4-SNAPSHOT.jar
>>>> geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-
>>>> framework-1.1-SNAPSHOT.war/WEB-INF/config/services/
>>>> These will become 179 and 189 characters when we drop -SNAPSHOT  
>>>> from
>>>> all of the version numbers.  I'm also hoping we can change the name
>>>> daytrader-derby-jetty-streamer-client to something shorter.
>>>> This is a lot better and will allow for at least 50 characters of
>>>> head room, which I hope is plenty for windows users.
>>>> As for next steps, I'd like to get the hot deploy service working
>>>> better.  With the addition of the in-place deployment feature from
>>>> Gianny and the timestamp I added to the configuration, we should be
>>>> able to write a much better service.  Once we have the better hot
>>>> deploy service, we will be able to implement the flat deployment
>>>> model that Hernan and others have suggested.
>>>> -dain

View raw message