[weld-dev] jandex not used on JNLP applications (Windows)

[Jozef Hartinger]

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
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>