Great. In this pretend app though we should have it setup so none of the app jars are in the excludes list so we are tracking our actual startup time with a decent sized app.
If we need to rename all the jars to superbiz-*.jar when we add them to the war, that'd be one way to do it. In the worst case scenario where we have to actually scan a jar completely, I suspect there's plenty of room to do that faster. I know we don't scan only once, so that's definitely another area where we can focus on getting better. -David On Feb 1, 2012, at 1:36 AM, Romain Manni-Bucau wrote: > for jira i needed to tweak conf/exclusions.list file (some can be > duplicated since i didn't clean it): > > google- > saxon- > joda-time- > wstx-asl > crowd- > mail- > xstream- > osworkflow- > javacvs- > org.apache.felix > glue- > xalan- > jai_ > bcvprov- > axis- > jfreechart- > xercesImpl- > js- > atlassian- > crowd- > entity > jira- > lucene- > spring- > ApacheJMeter > XmlSchema- > aether- > activeio- > activemq- > antlr- > aopalliance- > avalon-framework- > axis- > axis2- > bcprov- > bval-core > bval-jsr > catalina- > cglib- > commons-beanutils > commons-cli- > commons-codec- > commons-collections- > commons-digester- > commons-dbcp > commons-dbcp-all-1.3- > commons-discovery- > commons-httpclient- > commons-io- > commons-lang- > commons-lang3- > commons-logging- > commons-logging-api- > commons-net- > commons-pool- > cssparser- > cxf- > deploy.jar > derby- > dom4j- > geronimo- > gragent.jar > guice- > hibernate- > howl- > hsqldb- > htmlunit- > icu4j- > idb- > idea_rt.jar > jasypt- > javaee- > javaee-api > javassist- > javaws.jar > javax. > jaxb- > jaxp- > jboss- > jbossall- > jbosscx- > jbossjts- > jbosssx- > jcommander- > jetty- > jettison- > joda-time- > jmdns- > jsp-api- > jsr299- > jsr311- > juli- > junit- > kahadb- > log4j- > logkit- > maven- > mbean-annotation-api- > myfaces-api > myfaces-impl > neethi- > nekohtml- > openejb-api > openejb-cxf-bundle > openejb-javaagent > openejb-jee > openejb-loader > openjpa- > opensaml- > openwebbeans- > openws- > ops4j- > org.eclipse. > org.junit. > org.osgi.core- > pax- > plexus- > quartz- > rmock- > saaj- > sac- > scannotation- > serializer- > serp- > servlet-api- > slf4j- > spring- > stax-api- > swizzle- > testng- > wagon- > webbeans-ee > webbeans-ejb > webbeans-impl > webbeans-spi > wsdl4j- > wss4j- > wstx-asl- > xalan- > xbean- > xercesImpl- > xml-apis- > xml-resolver- > xmlrpc- > xmlsec- > xmlunit- > > if you don't do it it is complicated to start because of memory, > classloading time etc... > > - Romain > > > 2012/2/1 Jean-Louis MONTEIRO <[email protected]> > >> BcProv is another one which cause long startup delay. >> >> Jean-Louis >> >> 2012/2/1 David Blevins <[email protected]> >> >>> Would be great to get an integration test that creates a webapp with say >>> 10 or 20mb of jars. Then measure that startup time and keep track of it >>> over time. >>> >>> As well we could actually start testing specific libraries inside the >>> webapp to see if there are issues. Spring comes to mind. >>> >>> Likely some others we can do. >>> >>> I personally would be interested to see if Confluence and Jira run >> without >>> issues (would likely be library conflicts if there are issues). >>> >>> We could set these up in buildbot (or jenkins) and run them regularly. >>> >>> >>> -David >>> >>> >>
