On 01/16/2015 02:35 PM, Robert Marcano wrote: > On 01/16/2015 03:27 AM, Jozef Hartinger wrote: >> Hi Robert, >> >> the change sounds good to me. > > The first one or removing entirely the jar extension check? Removing the check. > >> As for IcedTea we never got Weld running >> with it. Last time we tried we got blocked by >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1733 If you can >> help us with IcedTea support that would be very appreciated. > > Sure. I am starting to see what to do with IcedTea. That bug doesn't > trigger here, our JNLP file is parsed perfectly. > > I get this exception when initializing the Weld container, looks like > probably related of why JandexIndexBeanArchiveHandler get http urls > under IcedTea NetX Just wondering: Did you try IcedTea without Jandex? > > java.util.NoSuchElementException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1431) > at java.util.HashMap$KeyIterator.next(HashMap.java:1453) > at > org.jboss.weld.environment.deployment.WeldDeployment.loadBeanDeploymentArchive(WeldDeployment.java:55) > at > org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:37) > at > org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:73) > at > org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:349) > at > org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.weld.environment.se.Weld.initialize(Weld.java:149) > > >> >> Btw did you get better performance with Jandex index? > > Yes I managed to trim 2 seconds of loading time. I resorted to do the > Weld initialization explicitly instead of launching the applications > using the Weld provided launcher, that way I can open the login window > in parallel to the container initialization that way that time is > hidden meanwhile the user is typing the credentials. I am using only a > few beans for testing the technology on a big application, I only > enabled it on a relatively medium archive, with only a few beans and > using bean-discovery-mode="annotated" instead of allowing it to search > the entire archive. I still think 2 seconds is too much for such a > small amount of beans, afraid if could take longer when used fully, > too bad Weld can't do more incrementally, probably because it need to > knows everything before resolving an injection point. Correct, we need to scan and verify everything at once. > > Using jandex without pregenerated indexed was slower, I didn't look > why, I didn't found any saved external index file either, so I think > it was generating the index everytime, probably because of the > file/directory confusion too. > > I added a simple test for a EjbInjectionServices and notice that it is > called at initialization time, Is there a reason this too had to be > done at initialization instead of lazily the first time the injection > point is found? That's very suspicious. Assuming there are no @EJB injection points in your application this service should not be called at all. Wasn't it EjbServices instead? > > >> >> Jozef >> >> On 01/15/2015 03:17 PM, Robert Marcano wrote: >>> Greetings, I am new to using Weld on an Java SE environment, trying to >>> optimized the container initialization, I got help on the developer IRC >>> channel telling me to add jandex as a dependency. I found that jandex >>> indexes could be embedded on jars so I did that. for some reason I got >>> worse times after adding the dependency. The problem is that Oracle >>> WebStart implementation doesn't store cached Jar files with the jar >>> extension anymore. >>> >>> JandexIndexBeanArchiveHandler is looking for path with the .jar ending >>> to detect if it is a Jar or directory path [1]. Changing that line to: >>> >>>> if (urlPath.toLowerCase().endsWith(".jar") || new >>>> File(urlPath).isFile()) >>> This solve the problem and now the embedded jandex indexes are used >>> (log >>> confirmed) on Oracle WebStart implementation. I am not sure about just >>> using: >>> >>>> if (new File(urlPath).isFile()) >>> I think that checking for the .jar ending is redundant, opinions before >>> submitting a patch? >>> >>> Note: I still have a problem with IcedTea NetX where >>> JandexIndexBeanArchiveHandler get the http url of the jar file, it >>> doesn't get a path to the local cached file. Any guide of where I >>> should >>> look at on Weld source code is welcome. >>> >>> >>> [1] >>> https://github.com/weld/core/blob/master/environments/common/src/main/java/org/jboss/weld/environment/deployment/discovery/jandex/JandexIndexBeanArchiveHandler.java#L122 >>> >>> >>> >>> _______________________________________________ >>> weld-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> >
_______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
