On 01/16/2015 03:27 AM, Jozef Hartinger wrote: The first one or removing entirely the jar extension check? 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 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) 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. 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?

On 01/16/2015 11:05 AM, Jozef Hartinger wrote: Yes, but I found the problem, DefaultBeanArchiveScanner is using com.sun APIs in order to get the cached JAR path, com.sun.jnlp.JNLPClassLoader#getCacheFile(URL). Since NetX does not implement that method the mapping from http[s] URL to local file is not done, this is why the archive handler was getting the remote URL. Doing reflection, but using icedtea-web code structure, with this way of getting the path works: Too bad that it is not only a public method call, there is an access to a private field (tracker). The icedtea-web 1.5 branch repository history show this field and method call to have been stable at least since 2010 when the icedtea-web 1.5 repository was created, and master haven't changed. I can bet to use this patch on my deployments since there is already usage of reflection to get the URL on closed source WebStart, it this too hacky for beint committed to Weld? ... True, I added a test @EJB injection, isn't EjbInjectionServices the one I should implement in order to inject my remote EJB interfaces? or should I implements EJBServices instead? I used it because of the warning on the documentation: EJBInjectionServices.resolveEjb(InjectionPoint ij), which allows @EJB injection point to be resolved without prior registration was deprecated in Weld 2 and should no longer be used. An injection point should be registered properly using EjbInjectionServices.registerEjbInjectionPoint(InjectionPoint injectionPoint) instead.