7:35 a.m.
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?
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
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.
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?
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/jav...
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev